It’s Time to Make Kubernetes Disappear
The cloud, Kubernetes, developer platforms — these are all, fundamentally, abstractions. But when you look at the cloud native landscape, you see the opposite of abstract.
This map reflects ground-level reality: For your average developer, working in cloud-native environments is complexity, all the way down.
Platforms like Kubernetes, meant to abstract resource management, now require dozens of new tools and technologies to be orbiting them. Kubernetes has turned from a platform, used to manage resources, into yet another thing that needs to be managed.
When complexity swells to this degree, as it has done in many technological paradigms in the past, the solution pattern repeats: We have to abstract again.
What DevOps Forgot to Fix
Over the past decade, the DevOps movement has swept through the software industry and fixed many things. But we cannot deny that DevOps spent much more time on operations (ops) and automation and comparatively little on development (dev). As a result, new movements including platform engineering and developer portals have risen to provide developers with better ways to access the systems that DevOps teams built.
By now, most organizations have a platform with a collection of tools and a web of automation connecting various processes, but there is constant friction when developers try to use them.
Imagine the number of steps involved in provisioning a new microservice and creating a repository.
- Is the repository provisioned in the right organization?
- Is the right person the owner of the repository within the subgroup that has the required access controls?
- Are you configuring the repository with the standard set of restrictions and guardrails that all repositories must have in your organization?
- Do you need to go into a change management tool and file a request?
- Are you approved to deploy this thing into the right clusters?
- Do you have a DNS entry provisioned for this?
- Have you hooked it up to the right monitoring and dashboards?
- Are on-call resources assigned prepared to deal with incidents?
When we step back and consider, we realize that the amount of work we have accepted as normal is dizzying. But that is just the beginning because the friction gets worse with scale.
Kubernetes is a hallmark example of this dynamic. It is not just a nice UI on top of infrastructure; it is a platform that abstracts that infrastructure. Operating within the abstraction, however, has only become more onerous for developers over time. Already, Kubernetes requires many things in its orbit, such as observability, replication and failover.
As Kelsey Hightower an esteemed Kubernetes thought leader explains, “Kubernetes allows you to declare your infrastructure concerns, including storage requirements, load balancing and service discovery, and enough extension points to integrate your policies into the platform itself. This is 10x better than what enterprises were doing before. The problem is we asked developers to do all that.”
Kubernetes is not a dev tool, but we have handed it to developers anyway. It is as if we abstracted servers to the cloud but then asked developers to drive over to Virginia and oversee the addition of new servers any time they wanted to scale up. It is an abstraction in name only.
Hightower makes this point too, going on to say in no uncertain terms, “Kubernetes is not a tool for developers. They can use it, but we have to be honest, Kubernetes is low-level infrastructure and works best when people do not know it is there.”
Today, we are in the opposite situation. Many developers are painfully aware Kubernetes is there.
Automation, Orchestration and Choreography
The problems described above are not a critique of Kubernetes (nor any cloud platform) but a call to action to zoom out, realize Kubernetes is not the endpoint and abstract further.
Automation is the first layer of abstraction
Before anyone thought of Kubernetes, cloud platforms or the cloud in general, we were automating.
Automation automates a single formerly manual task. Before automation, organizations had one process — they had to operate manually and arduously. After automation entered the arena, organizations could schedule these processes and run them automatically.
As organizations automated more processes, this first layer of abstraction became more visible. Over time, this layer, which we now often take for granted, became the foundation for further abstractions.
Orchestration and Kubernetes form the second layer of abstraction
Eventually, managing a multitude of discrete automated processes becomes a tedious, manual task. This friction provided the reason for the next layer: Orchestration.
Orchestration is the next layer of abstraction after automation, and it is where Kubernetes currently sits. Orchestration groups multiple automated tasks into a central orchestration platform with a single orchestrator.
The work involved in orchestration has grown over time, overburdening the single orchestrator. For example, let us take the music metaphor for ‘orchestra’ — where a single conductor is barely keeping up with an orchestra, which now comprises hundreds of musicians filling the stage and every seat in the concert hall.
The latest layer of abstraction
Due to the complexity that spills from the second layer of abstraction, it is evident we need a third — the choreography layer. Choreography is defined by decentralizing the orchestration level. Going back to the music metaphor — choreography allows each musician (or service) to take cues from each other instead of looking at a single central conductor (or platform).
If a developer wants to provision a database, the orchestration layer will likely enable that. But what then?
- Are you approved to run it in production?
- What is the service that is consuming it?
- How is the service going to be deployed?
- How is the service going to talk to the database?
A platform that produces a database but cannot configure the above settings is almost useless.
Choreography is what turns the work done in the orchestration level into a consumable artifact. When orchestration becomes consumable, developers can have true self-service, which enables them to stitch together their favorite routines on their own (including other orchestration platforms).
The choreography layer allows developers to ignore thinking about the building blocks that form the platform without ignoring them.
Developers should have a single interface to scaffold their apps, get their infrastructure and do their jobs. If Kubernetes is your platform, then you need to find a way to integrate all the different subcomponents that make up the final ecosystem in a way that developers can easily use. The platform engineering work is not completed after building a platform.
Will Choreography ‘Revive’ DevOps?
When we talk about ops teams building more accessible, usable and consumable products for developers, it can sound like we want teams to shift work from one team to the other. The ops team might think, “Hey, why should I put in the work to make this easier for developers who could put the work in themselves?”
When teams abstract the orchestration layer with a choreography layer, both teams benefit and their efforts become a positive feedback loop instead of a source of friction. By abstracting orchestration, developers can experience productivity, efficiency and profit by not thinking about how services make it to production.
When you abstract orchestration, developers can more easily, reliably and efficiently adhere to your organization’s best practices. When you add a choreography layer, engineering teams can maintain psychological safety without sacrificing productivity or velocity. And when you add a choreography layer, developers and platform teams can return to focusing on their respective specialties.
The question now is — what does the choreography layer comprise?
