There’s a Gap Between Devs and Kubernetes

But don’t assume you need more tech to close it.

Iwork with Kubernetes for a living — mostly developing open source platforms, middleware, and tools for Kubernetes. As an exercise, I frequently ask myself and my collaborators questions like, “What problem are we trying to solve?” and, “Who are we solving it for?” This helps us to focus, remain objective, and improves our ability to articulate a product’s value. I often pose similar questions to former colleagues and local meetup attendees — all of whom are at various milestones in their own company’s “journey to Kubernetes.” If they are building or adopting a new Kubernetes-related tool, I may ask them what problem the tool solves and for who. More broadly, I may ask what problems they’re experiencing with Kubernetes adoption in general.

Regardless of where the respondent falls on the spectrum of Kubernetes experience, I typically receive one of a couple common responses. The first is, “Kubernetes is too hard.” The second is, “Kubernetes is the wrong abstraction.” This second statement is frequently disguised as an inquiry. “Is Kubernetes even the right abstraction?” is a question which betrays a suspicion that the answer is no.

Statements such as these are missing important context. They do not qualify for whom Kubernetes is too hard or for whom it is the wrong abstraction. In seeking clarification, the answer I hear, almost invariably, is “developers.” To the credit of those responding this way, these are accurate observations — Kubernetes is too hard for developers and it is the wrong level of abstraction for developers.

What is often meant by, “Kubernetes is the wrong abstraction for developers,” is that Kubernetes only provides primitives for declaratively describing the deployment of an application or service. What it does not provide is a “higher order abstraction” that models the notion of an application or a service in a way that would feel intuitive to a developer who’s rightfully more concerned with delivering business value than learning the minutiae of Kubernetes. There is no option to say, “Just deploy my damn app!” As for why it is too hard for developers — it is too hard entirely because it is the wrong abstraction.

This take us to the point in the conversation where I typically assert that Kubernetes isn’t for developers to begin with. Many will readily agree with me, but shockingly, this seems to be a point of view that many haven’t considered.

What if less is actually more? What if the right abstraction for developers is no abstraction at all? After all, developers have been writing and testing applications using their preferred stacks for decades before Kubernetes or even Docker came onto the scene and the lack of some mythical application abstraction never got in the way. My best advice is for developers to carry on paying no mind to Kubernetes whatsoever.

Who then is Kubernetes for?

In the pre-Kubernetes era, someone, or many someones, in an organization— let’s call them “deployment specialists” — have always taken responsibility for building and deploying applications and services. Historically, this has required detailed platform and stack-specific knowledge. It can involve esoteric, sometimes home-grown deployment tools, and lots of scripting. To make matters worse, the hoops one jumps through to deploy a Ruby application, a Python application, a Java application on Tomcat — a Java application on WebSphere — are all different. These are the people for whom Kubernetes is the right abstraction — people who understand the science of deployment. By providing them with a uniform deployment model for (containerized) applications of all kinds, Kubernetes gifts this class of user with a pretty decent productivity boost and a massive net reduction in cognitive load.

A common misconception seems to be that Kubernetes is a platform — in the “Platform as a Service” sense — which it is not. Even those who know this tend to lose site of it, and in doing so, often forget that the deployment specialist role exists. Perhaps subconsciously this role tends to be replaced with an unrealistic expectation that developers should be able to use Kubernetes themselves.

Knowing is half the battle. Knowing now that Kubernetes wasn’t meant for developers, we can contemplate the path forward. I can readily identify three options.

1. My preferred approach is to re-insert deployment specialists into the equation. To succeed with this approach, deployment specialists must be embedded within development teams (devops anyone?) or at least collaborate closely with them, much as they would have in the past. I favor this approach because a competent deployment specialist can optimize deployments and accommodate complex scenarios in ways that the other approaches cannot. Unfortunately, this approach is perhaps the hardest to implement for the simple fact that too many organizations lack the self-awareness or gumption to close the gap between developers and Kubernetes by hacking themselves instead of the technology. Many organizations that are otherwise capable of this approach cannot be convinced that they are.
2. Whether you’re a startup with five developers that cannot afford anyone pulling double duty as a deployment specialist or you’re an enterprise with thousands of developers that cannot scale its deployment specialist practice adequately to support them, it is possible that resource constraints may preclude the first approach. Organizations such as these must rely on technology in the form of tools or platforms to close the gap between developers and Kubernetes. Frankly, this is why people such as myself have jobs. Do not, however, underestimate the cost of identifying or building an appropriate solution (home-grown platforms are all the rage these days). The level of effort can easily dwarf that required to implement the first approach. It must also not be overlooked that platforms and tools all come with their own opinions. Be careful that these opinions do not paint you into a corner down the road. Solving one problem only to introduce two new ones is no help to anyone.
3. Last, it is possible your organization isn’t ready for Kubernetes — or simply does not even need it. If a PaaS such as Heroku or even a self-hosted platform that doesn’t sit on top of Kubernetes meets your organization’s needs, why pay the Kubernetes tax? Perhaps the best answer to closing the gap between developers and Kubernetes is not to use Kubernetes at all. Again — be prepared to accept some constraints and be sure of what you’re getting yourself into.

In conclusion, Kubernetes isn’t for developers, but do not be quick to conclude that technology is the only way to close that gap. Strongly consider hacking your organization first.