No new proprietary CLI
Choose your technology stack
Workflows as-Code in Kubernetes YAMLs
Learn how Platform-as-Code approach enables teams to compose their platforms with Kubernetes API extensions and build their application workflows declaratively.
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.
In order to build complex or stateful workflows like AI, Analytics, CI/CD or SaaS applications on Kubernetes, DevOps teams typically work with application developers to identify required platform elements like database, API gateway, SSL certificate manager etc. in their stacks. Then a custom platform layer is constructed on base Kubernetes using API extensions / Operators of these platform elements. Integration of these Operators and use of the Custom APIs/Resources introduced by them to realize the platform workflows is not easy.
Platform-as-Code approach is designed to bring consistency and ease of use in such multi-Operator platform stacks. It enables efficient integration of disparate Kubernetes Operators and realization of codified platform workflows.
Any ‘as-Code’ system is designed to offer a common declarative language to provision a technology stack leveraging underlying APIs / resources. An important aspect of the first- and second-generation systems was that the set of underlying APIs that these systems wrapped were static and known apriori. In the Kubernetes world, this is no longer the case as the set of control plane APIs in a Kubernetes cluster can be extended anytime by installing new Operators in a cluster. Hence, for an as-Code system in Kubernetes world, the goal is to simplify integration of disparate Custom APIs to realize platform workflows using Kubernetes native YAML definitions.
Platform-as-Code refers to the process that application developers follow to create declarative platform workflows in Kubernetes YAMLs leveraging Custom APIs / Resources introduced by Operators along with built-in Resources. This involves discovery, binding and orchestration of Kubernetes Custom APIs / Resources to create platform workflows declaratively.
- DevOps engineer is responsible for assembling the platform layer by selecting required Kubernetes CRDs/Operators.
- Application developer then creates application platform workflows in Kubernetes YAMLs using various Custom and built-in Resources leveraging the platform layer.
We have created detailed guidelines to enable consistency and standardization across various community CRDs/Operators for enabling Platform-as-Code experience.
We have developed KubePlus API add-on to simplify discovery and use of Kubernetes Custom APIs / Resources towards building Platform-as-Code workflows.
KubePlus API add-on is designed to provide discovery & binding of Custom Resources to orchestrate a technology stack in Kubernetes YAMLs.
New endpoints to learn static and dynamic information about Custom Resources.
New functional constructs to be used in YAML definition to bind Custom Resources.
New CRD to define interdependencies between Custom Resources in a technology stack.
Comprehensive guidelines for Operator readiness for multi-Operator environments.
Extend Kubernetes without any custom automation using Curated Operators for Platform-as-Code.
Repeatable and shareable way of creating platforms workflows as-Code with Kubernetes YAMLs.