Kubernetes API Evolution

Kubernetes is the infrastructure foundation layer for modern platforms. It is powerful, flexible, has a strong community, and lots of integrations and tools that simplify its use. It is not, however, the platform itself. Teams still need to figure out how to run their workloads on it; they still need to deal with the cognitive load associated with Kubernetes and the plethora of tools available; they still need to handcraft the experience they want on the platform.

An evolution of “Kubernetes as the Platform” is to provide more than just access to a barebones cluster. Platform teams can ask application developers what services they are seeking to deploy, or look around for commonalities across different teams. Furthermore, platform teams can start reasoning about what patterns and standards teams should follow, and find ways to ease the onboarding for teams.

For example, a platform team will want to enforce security standards and may choose to use a secrets management system. This could be an external system running on a public cloud provider, or in-cluster deployments. The requirements may also differ depending on the intended use of the cluster: potentially stricter for production workloads than for development workloads. Those standards may be documented in a shared-wiki somewhere in the organisation, but the platform team may not have visibility on what exactly people are doing.

Platform teams can, though, make the “right” way the easy way (also referred to as Golden Paths). On the provisioning of the cluster, the platform team can determine what standards need to be enforced and pre-install and configure the necessary software on the cluster, simplifying the entire application team experience. The platform team can include telemetry, opening doors to monitoring and traceability.

Platform team provides a standardised and compliant cluster to the App team

Talking to users to better understand their needs and taking the time to bootstrap the cluster to meet these needs (along with additional services provided by platform team) pushes the value line of the platform up, reducing the gap application teams need to cross to get their products running. Over time, the platform team can evolve to offering customised and pre-configured environments, tailored to the user needs. With a high level of abstraction, Kubernetes can become an implementation detail, unseen by the user.

To illustrate, a team building a web application may need a cluster with an application running engine (like knative or Kubevela), a database (like PostgreSQL or MongoDB), and a CI/CD system (like Jenkins or Tekton). A team building a backend service may also need caching, messaging, and monitoring. By implementing a product approach to the platform, the platform team increases the value their users gain from it. 

Kratix is a Kubernetes native framework for building platforms and is built upon a concept called Promises. Promises are the encapsulation of a service you want to provide. You define how you want your application teams to consume Promises (API), and what should happen when they are consumed, via the execution of pipelines. By leveraging the power of Compound Promises, platform teams can combine multiple Promises to deliver entire developer experiences.