In 2020, people were predicting that Kubernetes would disappear within a year. They believed someone would create a service that would reduce the adjacent choices and make Kubernetes the easy default. Everyone would use Kubernetes, but few people would work at the nuts-and-bolts level.
I checked this morning, and it’s still here — and so are the nuts and bolts. So, why has the solution to the Kubernetes complexity problem proven so elusive?
An Ecosystem of Choices
In isolation, Kubernetes isn’t particularly complicated, but a broad ecosystem of tools, options and decisions surrounds it. You can run Kubernetes anywhere, from a local machine to the cloud. You can run on a single low-powered machine or thousands of hyperscale nodes. You can use it to run one monolith or thousands of microservices.
There isn’t one opinionated way to use Kubernetes. It’s designed to be highly flexible. That means you get to make all the decisions. You choose exactly how to configure Kubernetes and which tools to use alongside it.
It’s the sheer volume of decisions you have to make to get started that people are talking about when they say things are hard, not the complexity of Kubernetes itself.
And this is before you consider the software itself. If you’ve just written a microservice in Go that runs in a container, it’s pretty easy to run it in Kubernetes. If you have a heritage monolith written under the assumption it would run on a virtual machine, there’s a great deal of work to bend it to work in a container.
It’s no wonder a developer responsible for delivering software that solves business problems reaches overload when faced with so many options along the way, especially when seen in aggregate across the different choices to be made for containers, infrastructure automation and container registries, with the various file formats and conventions used.
If you want to cycle to work, selecting a bicycle is a research-heavy task, so imagine buying a frame, wheels, handlebars, brakes and gearing separately. Some riders will want this level of control, but it’s overwhelming when your job is just getting to a destination.
Cognitive Overload and Platform Teams
The view that Kubernetes would settle into quiet utility and effectively disappear while also running all our workloads failed to materialize. Nobody managed to create a single opinionated path for Kubernetes that would take care of all these choices.
The simple reason for this is that the mythical one true way wouldn’t work for most applications and services. It’s impossible to create a simple, simple path without acknowledging the context of the application and organization.
This is why platform engineering has gained traction. While there’s little chance of creating an industrywide path of simplified choices, creating one within an organization is perfectly feasible.
A minimal viable platform could be a wiki page listing pre-baked decisions and providing a standard example for each configuration file. This might evolve into a facade that allows developers to specify what they need along a simple dimension, such as “size,” with the platform taking care of the details behind the flag.
Platforms should provide simplified ways to do the right thing while letting expert developers peel back the layers when the standard approach isn’t suitable.
Fewer Options Without Limiting Teams
The lack of a single opinionated path for Kubernetes underscores the importance of contextual factors for the application and organization. While creating a universal, simplified approach is impractical, platform engineering is one way to reduce the many decisions that need to be made along the way, especially when such decisions aren’t crucial.
Despite the perceived complexity issues, Kubernetes has done nothing but grow. Clearly, the benefits outweigh the adoption pain. So, imagine what would happen if Kubernetes and the associated moving parts were easier to adopt?
Platform teams could be the crucial factor in creating an opinionated Kubernetes setup that still respects the local context. Perhaps the predictions aren’t wrong, just delayed.
To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon Europe in Paris from March 19–22.
The post Kubernetes Predictions Were Wrong appeared first on The New Stack.
Why has the solution to the Kubernetes complexity problem proven so elusive?