Kubernetes extensions (commonly referred as Operators) extend Kubernetes Resource set (APIs) and enable adding application specific workflow automation in Kubernetes native manner e.g. Operators for softwares like databases, key-value stores, API gateways etc. Enterprise DevOps teams use Kubernetes Operators and create their Kubernetes native stacks.
Enterprise application workflows are realized in Kubernetes YAMLs by establishing connections between Kubernetes Resources (APIs). These connections can be based on various relationships such as labels, annotations, ownership etc.
Platform-as-Code is about simplifying the process of creating application workflows using Kubernetes Resources (APIs). We have developed KubePlus tooling for this purpose. At its core, this tooling enables building the Kubernetes Resource relationship graphs for various application workflows running on a cluster. This graph is then utilized to aggregate metrics, events and logs at workflow level.
Mechanisms used to establish Kubernetes Resource relationships include - labels, annotations, spec properties and owner references. When working with Custom Resources introduced by Operators, it is important that Operator developer's assumptions around what relationships can be established with a Custom Resource and what actions will be performed as a result of them are clearly articulated. KubePlus provides a set of annotations on Custom Resource Definitions to encode such assumptions.
KubePlus leverages knowledge of relationships between Kubernetes built-in resources and combines that with the CRD annotations. It dynamically constructs Kubernetes Resource relationship graphs for various application workflows running on a cluster. KubePlus offers number of kubectl plugins that internally leverage this graph and enables teams to visualize and monitor application workflows.
Any ‘as-Code’ system is designed to offer a common declarative language to provision a technology stack leveraging underlying APIs / resources. In the Kubernetes world, Kubernetes YAML itself supports the use of Custom API Resources along with built-in API Resources. The challenge is in discovery and consumption of variety of Custom API resources towards building the application workflows.
At CloudARK, we are pioneering Platform-as-Code approach for this. It involves curating Custom Resource Definitions (CRDs) in your stack with a few annotations. They allow our KubePlus platform as code tooling to work specifically for your Kubernetes Native stack. The tooling significantly simplifies the process of building and managing your application workflows.
Due to composable and declarative nature of Platform-as-Code approach, enterprises can easily create their platform stacks on any Kubernetes cluster. This simplifies transfer or recreation of workloads across hybrid multi-cloud environments, or dev/test/prod environments.
Over the years PaaSes focused on delivering end-to-end developer workflows and Infrastructure-as-Code tools focused on simplifying Ops challenges in infrastructure provisioning. Adoption of different tooling created tooling gap between development and DevOps teams. Platform-as-Code bridges this gap by standardizing on Kubernetes YAML as the common language between Devs & Ops.