Don’t Let Kubernetes Developers Suffer From Solved Problems

For developers, one of the most exciting things about Docker—and the wider container revolution—was the way it improved developer experience. 

Base images reduced the escape velocity necessary for new projects. Portable, sandboxed environments cut down on “it runs on my machine” nightmare scrambles. Docker was built from a developer’s perspective, and it showed. 

It still shows. Docker tops its category in StackOverflow’s annual survey results for “most loved” and “most wanted” developer tools. 

But something happened on the way to containers’ present world domination. In the pursuit of running complex containerized applications at scale, orchestration systems like Kubernetes took a big-picture, operational perspective. That made sense, but it came at a steep cost for developers. And with Kubernetes’ increasing maturity and ubiquity, it’s clearer than ever that there is a better way.

You have been assimilated

Kubernetes had its design roots in Google’s internal “Borg” cluster management system—not a developer-centric tool after the fashion of Docker, but a nice excuse for a nerdy extended metaphor.

In Star Trek, the Borg are a cybernetic people/paradigm who assimilate any form of life they encounter into a consistent, coherent, streamlined system. Hence the name of Google’s system: if you’re an IT infrastructure operator, all that assimilation and standardization sounds pretty good. You want to treat components and applications the way the Borg treats living beings: incorporate them into your system as a set of common abstractions that you can manage in standardized ways.

That’s great from an operational perspective. But the needs and priorities of large-scale orchestration systems aren’t the same as those of human beings writing code. So to developers, even the core concepts of Kubernetes can seem alien—as though they’ve originated in another sort of mind entirely. Pods, nodes, ReplicaSets…it all even sounds vaguely science-fictional. But this sort of conceptual unfamiliarity is nothing compared to the way Kubernetes asks developers to re-learn what they thought they knew about, say, using persistent storage. And it’s really nothing compared to the ongoing hassle of YAML manifests or the inefficiency of the Kubernetes inner development loop. 

An Inconvenient Loop

The inner development loop is a given programmer’s workaday cycle from writing to testing to debugging code. If you’re simply writing and testing Node or Python code on your local machine, for deployment on a traditional server, your inner loop is pretty straightforward: write the code, run it, and fix the problems. Rinse and repeat. 

But if that same code is going to be containerized and deployed via Kubernetes, you now have several more steps: building a container image, uploading it to a registry, creating a Kubernetes resource, actually running the container, and then debugging any issues that arise (which might be a pure code problem, or might be a result of improper Kubernetes configurations). Oh, and you’ll need a development cluster that matches the production environment to actually do all of that. 

It’s a lot. The simple fact is that a standard Kubernetes development loop is not tailored to developer happiness or efficiency. From a developer's perspective, it’s a sub-optimal process.

The point here isn’t that “Kubernetes is too hard” or “developers hate Kubernetes.” (Developers are a diverse group with a lot of different opinions, but StackOverflow’s annual survey suggests that, on the whole, they don’t.) The loop I’ve just described isn’t the only possible experience for Kubernetes developers, but it is the default experience if you’re simply using Kubernetes out of the box. 

Fortunately, Kubernetes can be so much better.

More Than What’s in the Box

Even if Kubernetes seems alien and inaccessible, it actually provides the means to solve its own learning curve problems. Because of its hunger to assimilate, Kubernetes is also—fundamentally and crucially—designed to extend. And its genius extensibility empowers us to abstract away even Kubernetes’ own complexity. 

The cloud-native ecosystem is full of open-source tools that synergize to make Kubernetes richer and friendlier:

• Knative: A project for serverless deployment on Kubernetes, bringing the simplicity and developer-friendliness of serverless to an open-source, cloud-agnostic platform. 
• Lagoon: A web-application development platform that builds dev environments from the same images as production, simplifying parity between environments.
• Argo: A suite of CI/CD tools enabling developers to use Git as a single source of truth, a popular approach called “GitOps.”
• Prometheus: An observability system with rich APIs that plug into everything from the Lens graphical user interface for Kubernetes to the Grafana visualization platform to CI/CD systems, helping keep developers informed about what’s happening in a cluster.

We’re barely scratching the surface here—Kubernetes is overflowing with amazing open-source tooling to make developers’ lives easier. 

Developers don’t have to be consumed by an entirely new paradigm—it’s just a matter of prioritizing developer experience and leveraging cloud-native expertise and the increasingly rich ecosystem. Knowing the right tools and the ways to configure them isn’t trivial, but that’s where operators come in—and for organizations with constrained resources, DevOps-as-a-service offerings can help to provide better dev experiences with minimal hassle on the end of the op. 

Star Trek fans know that the Borg threat is resisted due to knowledge gained from people who have been assimilated. For developers, Kubernetes doesn’t have to be a threat at all—and with the right tools and insights from the cloud-native community, it has the power to make development even simpler and more powerful than ever before.