A typical application stack can be described as following, where infrastructure is the foundation upon which an application platform gets built and then application is deployed on this stack.

Evolution of cloud computing brought opportunities to simplify building of these application stacks. Cloud computing started with the notion of ‘as a Service’ where you have the promise of provisioning elements of this application stack ‘on-demand’. This ‘as a Service’ model started with ‘Infrastructure as a service (IaaS)’ like AWS EC2 and then slowly progressed into ‘Platform as a service (PaaS)’ like Heroku, Amazon Beanstalk, Google App Engine.

In parallel notion of ‘as Code’ got popular primarily with ‘Infrastructure as Code’ systems like AWS Cloud Formation and Terraform. ‘Infrastructure as Code’ systems brought promise of ‘repeatability and shareability’ in provisioning infrastructure elements. You could write infrastructure elements declaratively and provision them repeatedly using this declaration/code. ‘Infrastructure as Code’ systems like AWS Cloud Formation create the same infrastructure elements repeatedly on a single cloud whereas systems like Terraform create this across multiple clouds in multi-cloud environment. These systems rely on abstracting IaaS APIs and capture those in a common declarative language.

The wave of containerization blurred the lines between Infrastructure layer and Platform layer and brought new systems commonly referred to as ‘Container as a Service’ (CaaS). Containers showed the promise of moving the same application stack between different infrastructure layers. This transformed idea of ‘multi-cloud’ from merely provisioning elements across different clouds to ability to move the entire application stacks between the clouds.

Kubernetes with its declarative YAML format helped enable repeatability and shareability for containerized application platform stacks. Such YAML declarations can be for your application code or they can be for containerized platform elements such as MySQL, RabbitMQ, etc.

In fact, Kubernetes and its YAML declarations can be thought of as a system that provides ability to create application Platforms as Code. Drawing parallels with Infrastructure as Code, Kubernetes YAMLs are easily shareable and the application stacks can be created in repeated manner on any Kubernetes cluster on any cloud. The difference between them is that Platform as Code systems provide first class support for applications and their bindings with provisioned Platform elements. In contrast, Infrastructure as Code systems focus solely on provisioning and management of Infrastructure elements.

Thinking about it deeper we realized that there is a spectrum of such ‘Platform as Code’ systems based on how complex the application platform stack requirements are. At one end there is base Kubernetes. With it you can create/recreate application platforms defined using basic Kubernetes constructs where all platform elements are defined as containers.

Basic Kubernetes is not sufficient though if applications want to bind and use platform elements that are available as managed services on a particular cloud (e.g.: Amazon RDS, Google CloudSQL, etc.). To solve such use-cases we created a tool named ‘CaaStle’ that integrates provisioning of hosted managed services with CaaS’s declarative definition format thus offering a full-stack microservices development & deployment experience. CaaStle is an example of ‘Platform as Code’ system that focuses on solving integration of containerized applications with cloud-based managed services. Another example of this type of system is a Kubernetes cluster installed with the Service catalog server.

A different kind of complexity arises if you decide not to use managed services but stick with containerized platform elements to avoid vendor lock-in. In such situations if you want advanced capabilities for your containerized platform elements, such as performing application-specific lifecycle actions (e.g.: taking periodic backups of your MySQL container or updating user passwords for MySQL instance), then basic Kubernetes YAMLs are not sufficient.

This is where the concept of Kubernetes Operator comes in. Kubernetes Operators allow you to extend Kubernetes with custom resources and custom controllers. Using Kubernetes Operator, one can define custom resources for required platform elements such as MySQL, Nginx similar to any other native Kubernetes resources like Pods, Services etc. Your platform elements become integral part of Kubernetes declarative YAML definition. The required application-specific lifecycle actions are coded in the custom controllers that manage these custom resources. A Kubernetes cluster extended with Operators becomes yet another kind of ‘Platform as Code’ system.

We are now working on framework named ‘KubePlus’ that follows this approach of Platform as Code in regards with extending Kubernetes with Operators. We are standardizing number of open source Kubernetes Operators so that they are certified to work with each other to form an entire application stack.

A key distinguishing feature of systems like KubePlus is that they focus on extending the base CaaS layer (in this case Kubernetes) rather than abstracting it. This is in sharp contrast to traditional Platform-as-a-Service systems which have tended to focus on abstracting underlying CaaS systems. With regards to Kubernetes, extension over abstraction allows users to leverage full power of Kubernetes. Moreover, they can customize their platform as per their needs without getting stuck with opinionated choices of pre-built PaaSes. So in a way ‘Platform as Code’ approach of KubePlus can be considered as enabling ‘Build Your Own PaaS’ experience for Kubernetes.

We believe that ‘Platform as Code’ forms the grounding principle on which next generation custom platforms and Platform as a Service systems will be built for Kubernetes. They will offer repeatability in creating custom platform stacks on any Kubernetes cluster. The platform artifacts such as Kubernetes YAML files, Helm charts, Operator manifests, etc. will be shareable between teams. If managed services are needed, they will be directly integrated within application orchestration templates. And if avoiding vendor lock-in is critical, Kubernetes Operators that embed custom lifecycle actions will be the way to go.

www.cloudark.io