In our post on Evolution of PaaSes to Platform-as-Code in Kubernetes world, we discussed how PaaSes are evolving to Platform-as-Code systems with Kubernetes.

In this evolution block diagram, Kubernetes is represented at two layers: Container-as-a-Service (CaaS) and Platform-as-Code (PaC). Kubernetes by its design is a CaaS system. In addition, it can also be considered as Platform-as-Code system with its declarative YAML definitions.

A Platform-as-Code system is one that allows defining application platform elements in a declarative format and enables repeatable creation of the application platform using that definition. Examples of platform elements can be MySQL (database), Nginx (web server) etc.

There are other existing CaaS or PaaS systems that support declarative definitions as well. However, what sets Kubernetes apart from these systems is the unique way in which its API can be extended to create new platform elements as native Kubernetes objects. Using Kubernetes mechanisms of Custom Resource Definition (CRD) and Aggregated API server (AA), it is possible to extend the Kubernetes API to add new platform elements as native Kubernetes objects in a Kubernetes cluster. This extendibility combined with Kubernetes YAML definitions allows Kubernetes to be called as a Platform-as-Code system along with a CaaS system.

Benefits of API Extensions

Implementation of a system at Platform layer (PaaS or PaC) introduces new abstractions in order to deliver the desired platformization. Traditionally there was only one way to create these abstractions — by wrapping the APIs of the underlying layer. As discussed earlier, Kubernetes has introduced a new way to create the abstractions — by extending the APIs. So now there are two options to implement Platform abstractions on Kubernetes as shown below:

Platform abstractions written as Kubernetes extensions instead of Kubernetes API wrappers provide following advantages:

1. End users of the platform abstractions don’t have to learn any new CLI to consume them.

2. In order to offer the simplicity, abstraction created as API wrappers end up hiding some of the underlying API functionality and consequently end users may not get the required level of control.

3. Tools written for base Kubernetes (e.g. Helm) can be easily used with abstractions created as API extensions, but it may not be the case with abstractions created as API wrappers.

4. Similarly, advanced functionality like auditing, RBAC, etc. that works with base Kubernetes can be easily leveraged for your platform abstractions created using API extensions. This may not be the case with abstractions as API wrappers and you will have to take care of such advanced functions for your abstraction layer in your code.

Effect of Platform-as-Code

This new Platform-as-Code experience that leverages Kubernetes extendibility enables teams on following aspects:

Common language between Devs and Ops

Traditionally communication between Devs and Ops has suffered due to lack of common tooling between them. Ops use their preferred tooling to provision platform elements and Devs need to learn part of Ops automation to consume these resources in their application stacks. Platform-as-Code on Kubernetes establishes one declarative language with Kubernetes YAMLs at CaaS and PaC layers and brings more consistency between Ops and Dev toolchain. Ops use kubectl and YAML to extend the base Kubernetes cluster with Operators/API extensions for required platform elements. And Devs consume these added custom resources along with native Kubernetes resources using the same kubectl and YAML.

Build your own PaaS

Instead of relying on a single PaaS vendor and their proprietary abstractions, teams can compose their own PaaS by using multiple community platform abstractions that are written as Kubernetes API extensions.

www.cloudark.io