CloudARK

Platform-as-Code

Platform-as-Code

Platform-as-CodePlatform-as-Code

Sign-up for your free copy of Platform-as-Code eBook

Learn how Platform-as-Code approach enables teams to assemble their platforms with Kubernetes API extensions and build application workflows declaratively.

Kubernetes extensibility and Platform-as-Code

Kubernetes Operators

One of the key reasons for Kubernetes’s popularity is its extensibility. Kubernetes API extensions (commonly referred as Operators) extend Kubernetes API to manage third-party software as native Kubernetes objects. There are 400+ GitHub repositories of Operators for softwares like databases, key-value stores, API gateways etc. 

Multi-Operator platform stacks

Enterprise DevOps teams are looking to leverage these API extensions or Operators to create custom platform layers for their application workloads. Assembling such multi-Operator stacks and building required platform workflows is not easy.  The challenge in this is twofold. First, API extensions are independently developed by different authors/platform vendors and hence lack a level of consistency or uniformity. Second, there needs to be additional tooling that simplifies discovery and use of the added custom APIs for building the workflows. 

Platform-as-Code

 At CloudARK, we are exploring ways to simplify creation of application-specific platform workflows that leverage disparate Kubernetes API extensions.  We are pioneering an approach called - ‘Platform-as-Code’. Platform-as-Code tools and techniques enable aggregation of disparate Kubernetes API extensions and allows creation of required application-specific platform workflows leveraging the custom APIs.

Challenges in building workflows with Kubernetes Custom APIs

image22

Composability

Composability refers to establishing linkage between various Kubernetes Custom API Resources and/or built-in Resources for realizing the required workflow. These linkages can be established using primarily following Kubernetes native mechanisms -

a.) Spec property based – Spec property of a resource depends on a value coming from another resource.

b.) Label based – A resource depends on a specific type of label/s to be given on other resources to take certain action.

c.) Annotation based - A resource depends on a specific type of annotation/s to be given on other resources to take certain action.

d.) Group based – A group of resources share certain properties such as worker nodes, privileges, etc. 

In order to establish such linkages for Custom Resources, it is important to know various assumptions made by Operator developers. 

Traceability

From the traceability perspective the challenges are: 

a) How to find out various linkages or relationships between resources mentioned above?

b) Is there any way to figure out lineage of actions performed as a part of the workflow? 

Platform-as-Code

We are building Platform-as-Code technology to address the challenges around composability and traceability for building platform workflows involving Custom API Resources. The solution is two pronged

  1. Methodology to curate Kubernetes API extensions / Operators.
  2. Tooling to simplify use of  Custom APIs.

Our Operator curation methodology allows embedding design assumptions made by Operator developers in Helm chart packaging of the Operator without having to update its source code. Our tooling leverages this information and provides additional mechanisms to establish, maintain and visualize the relationships between the Kubernetes resources involved in a workflow.

Methodology to curate Kubernetes Operators

We have developed Operator Maturity Model to help calibrate an Operator’s maturity towards increasingly complex multi-Operator setups. As a part of this model, we have introduced a methodology to create Operator packaging (Helm charts). This methodology provides a uniform way to capture all the Operator assumptions made while designing Custom Resources. It primarily uses mechanism of annotations on CRD (Custom Resource Definition). 

Tooling to simplify use of Custom APIs

Our open-source tooling (KubePlus API add-on) provides mechanisms to establish, maintain and visualize the relationships between the Kubernetes APIs / resources involved in a workflow. 

The core idea of our work is the ability to capture the relationships between various resources involved in a workflow and then use this extended resource relationship graph towards solving composability and traceability challenges for the workflows. 

Kubernetes, KubePlus

KubePlus API add-on

KubePlus API add-on simplifies creation of platform workflows by providing required information about consuming Custom API Resources on the cluster. 

Following are the key kubectl endpoints that are used to provide this information: 

1. kubectl man <Custom Resource>: Provides information about how to perform supported actions by the Custom Resource.

2. kubectl composition <Custom Resource Instance>: Provides information about sub resources created by the Operator as part of handling Custom Resource Instance.

3. kubectl cr-relations <Custom Resource Instance>: Provides information about relationships of Custom Resource Instance with other resource instances via labels / annotations / Spec Properties.

image23

Building platform workflows

 A purpose-built platform is built by installing required Operator packages curated with Platform-as-Code annotations. KubePlus API add-on is installed on the cluster that helps with discovery and use of added Custom Resources on the cluster. Platform workflow YAMLs that use Custom and built-in resources on the cluster are easily defined leveraging KubePlus API add-on endpoints.

Evolution of as-Code systems

CloudFormation, Terraform, Platform-as-Code, KubePlus, Infrastructure-as-Code

Any ‘as-Code’ system is designed to offer a common declarative language to provision a technology stack leveraging underlying APIs / resources. First generation systems like AWS CloudFormation focused on delivering this for a single cloud (AWS). Second generation systems like Terraform focused on offering a common language to provision technology stack on multiple clouds.


 In the Kubernetes world, Kubernetes cluster’s control plane can be extended anytime by installing new API extensions or Operators. There is no need to invent a new language here as Kubernetes YAML itself supports the use of Custom API resources along with built-in API resources to define workflows. However, the challenge here is that API extensions are independently developed by different authors/platform vendors and hence lack uniformity. Discovery and consumption of Custom API resources on a cluster is not trivial for defining the platform workflows. 


At CloudARK, we are building tooling to address this as a part of our Platform-as-Code offering with the goal to enable aggregation of disparate Kubernetes API extensions towards building platform workflows. KubePlus API add-on is open-source tooling that helps with discovery and consumption of Custom APIs on the cluster. Platform-as-Code approach enables DevOps teams to model, create, visualize and debug Kubernetes application workflows with Custom APIs. 

Kubernetes and the future of as-Code Systems

How Kubernetes API Extensions enable Platform-as-Code Experience

How Kubernetes API Extensions enable Platform-as-Code Experience

How Kubernetes API Extensions enable Platform-as-Code Experience

How Kubernetes API Extensions enable Platform-as-Code Experience

How Kubernetes API Extensions enable Platform-as-Code Experience

Evolution of PaaSes to Platform-as-Code in Kubernetes world

Platform-as-Code: how it relates to Infrastructure-as-Code and what it enables

Platform-as-Code: how it relates to Infrastructure-as-Code and what it enables

Platform-as-Code: how it relates to Infrastructure-as-Code and what it enables

Platform-as-Code: how it relates to Infrastructure-as-Code and what it enables

Platform-as-Code: how it relates to Infrastructure-as-Code and what it enables