The cloud-native movement has largely been defined in recent years by the rise of Kubernetes and its broad adoption. While Kubernetes is well-known for being the best-of-breed container orchestration platform, that’s not necessarily its greatest strength.
Kubernetes’ true ‘superpower’ is that it can become the control plane for any kind of resource, not just the containers. In fact, containers were just the first use case of the control theory approach implemented by the Kubernetes community where each resource is automatically reconciled by a control loop. The next logical application of these ideas is to use Kubernetes as a universal control plane which manages containers, VMs, serverless and all of the infrastructure they connect to.
This is a monumental shift, and the shift is happening first with organizations creating internal platform engineering teams to enable them to operate like they’re an internal cloud provider. This is a transition from the traditional DevOps model, in which developers have direct access to infrastructure. The ability to enable platform teams with a universal control plane, based on Kubernetes, is the future of cloud-native.
Platform Engineering Teams (PETs) Are Not DevOps
Platform engineering teams (PETs) are responsible for essentially building, running and managing infrastructure. They are also tasked with providing a self-service experience for the development teams so they can deploy applications in a more automated and streamlined way. While in the physical world, humans take care of pets, in the cloud-native world, PETs take care of developers.
Platform engineering is not DevOps. With DevOps, organizations hire developers who also do Ops. That’s not what we’re seeing in the field. In fact, we’re actually seeing the opposite.
The term DevOps is overloaded and can mean different things, but it’s essentially about managing access to infrastructure and connecting infrastructure to applications. By now, most organizations have realized it’s an anti-pattern to give application developers cloud credentials, and that doing so is a recipe for disaster; non-infrastructure experts can easily misconfigure services, resulting in outages.
The Kubernetes Control Plane
PETs are taking a page out of the cloud provider playbook and deploying control planes to consolidate operations across environments and empower developer teams.
Kubernetes didn’t only pioneer the process of managing containers, it pioneered the management of infrastructure and services with an API-driven approach, which is the basis of the control plane. With Kubernetes, resources are managed around APIs and not templates. In a template model, often referred to as infrastructure-as-code (IaC), code and tooling is a one-time setup, where the operator runs a command to deploy based on a template that defines what should be included.
Kubernetes is different in that it runs continuously in an automation loop to reconcile changes and adjust for drift, whereas traditional IaC architectures adopt a “fire and forget” model, causing day two operations headaches. A control plane model ensures that things are maintained in accordance with an organization’s security, compliance or governance policies.
Kubernetes introduced an API designed for both platform engineers and developers. Platform engineers can configure infrastructure, policies, quotas and controls. Developers consume a higher-level API that has built-in guardrails. This separation of concerns is designed to achieve higher levels of automation and enable developers to self-service.
The Kubernetes control plane can serve as a foundation to enable a universal control plane, which is what the open source Crossplane project is all about.
The Rise of the Universal Control Plane
The vision behind Crossplane is that a universal control plane could provide an entry point to the platforms PETs were building and a way for those operators to offer their APIs to application teams to consume.
The elegance of this approach is that APIs act as a really clear contract between what the platform teams offer and what the application teams want to consume. APIs are not tied to any language or framework and provide the most interoperable and scalable way of creating contracts between teams.
A control plane brings it all together acting as a central point for PETs to enforce policy, whether it’s security, compliance or governance. A universal control plane is a single place where you can capture automation.
This whole architectural pattern of using an API control plane is validated and proven by the largest IT firms in the world, the hyperscale cloud providers themselves. Using a control plane is literally right out of their playbook; they build and operate these massive platforms, and that’s now ready to come back into the enterprise.
Building on Kubernetes’ Superpower
The true power of control planes is well understood by the founders of Kubernetes.
At the Crossplane Community Day in December 2020, the community brought together Kubernetes creators Joe Beda, Brian Grant and Brendan Burns in a panel moderated by Kelsey Hightower to discuss the power of control planes. Collectively, the panelists agreed on Kubernetes’ extensibility and saw a future where it was possible to separate the control panel from the Kubernetes project – without all the container management stuff – to enable a generic control plane.
The universal control plane is the promise of Crossplane, which is building itself on the shoulders of giants, with the strong foundation that the Kubernetes control plane provides. Kubernetes’ superpower is not the fact that it connects containers – the true magic is the control plane, an idea echoed by the founders of the Kubernetes project.
The future of cloud-native isn’t about containers, it’s about extending the Kubernetes control plane in an open source and composable way to enable a universal control plane. And we believe Crossplane is the project where this vision will unfold.