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. 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 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. This separation of concerns is designed to achieve higher levels of automation and enable developers to self-service. Developers consume a higher-level API that has built-in guardrails. Platform engineers can configure infrastructure, policies, quotas and controls. Kubernetes introduced an API designed for both platform engineers and developers. A control plane model ensures that things are maintained in accordance with an organization’s security, compliance or governance policies. 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.
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. With Kubernetes, resources are managed around APIs and not templates. 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. PETs are taking a page out of the cloud provider playbook and deploying control planes to consolidate operations across environments and empower developer teams. 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 term DevOps is overloaded and can mean different things, but it’s essentially about managing access to infrastructure and connecting infrastructure to applications. In fact, we’re actually seeing the opposite. That’s not what we’re seeing in the field. With DevOps, organizations hire developers who also do Ops. While in the physical world, humans take care of pets, in the cloud-native world, PETs take care of developers.
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. Platform engineering teams (PETs) are responsible for essentially building, running and managing infrastructure. Platform Engineering Teams (PETs) Are Not DevOps The ability to enable platform teams with a universal control plane, based on Kubernetes, is the future of cloud-native. This is a transition from the traditional DevOps model, in which developers have direct access to infrastructure. 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. 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. 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. Kubernetes’ true ‘superpower’ is that it can become the control plane for any kind of resource, not just the containers.
While Kubernetes is well-known for being the best-of-breed container orchestration platform, that’s not necessarily its greatest strength. The cloud-native movement has largely been defined in recent years by the rise of Kubernetes and its broad adoption.