It’s been 5 years of Kubernetes in the enterprise space for many of us. Five years since Kubernetes went 1.0, since OpenShift went 3.0, and since GKE went GA. An almost incomprehensible amount of change has occurred in just this one landscape of technology in that amount of time. We’ve seen companies in this space rise and fall from relevancy (and in some cases, existence). In all of the incredible progress made and the innovations built, we still can’t seem to get the developer experience “right” in Kubernetes. There are plenty of answers from various vendors vying for a position, but it’s still an open-ended area.

As the title suggests, and I’ll be more explicit here: the developer experience doesn’t belong in Kubernetes at all. As a community we have formed this false premise that the developer experience is some measure of the quality of a platform, or that it’s an area of necessary development. I hold the strong opinion however that Kubernetes was never meant for developers, at least not in enterprise usage patterns (where open source is still making its way). I am not discounting the importance of developers in the Kubernetes community, rather, I think the consequence of having such focus on an explicity developer experience as part of the platform has resulted in us driving the wrong usability pattern entirely for Kubernetes. Where we struggle to find a suitable developer workflow atop the Kubernetes API, we should be laser focused on personas that truly end up as its owners: sysops, network teams, and security teams.

As far as a developer experience goes, one should exist. I believe that current tools frame the scope quite well in that they highlight the appropriate level of interaction for developers with Kubernetes. Tools like Skaffold, Draft, and many others do a great job of granting developers the tooling they need (and nothing more or less) to quickly engage with Kubernetes environments without having to deal with Kubernetes itself.

At the risk of coming off as pedantic, this is also known as the “inner loop” of the dev workflow. I think it’s ideal to limit the devex scope here when it comes to Kubernetes. The context here to keep in mind is that the adoption of Kubernetes in enterprise settings is what I’m after, and quite frankly, the inner loop of developer workflows does not typically factor into the decision to adopt Kubernetes. I’m not saying developer-driven use cases don’t exist, but the overwhelming majority of adoption of Kubernetes in the enterprise org setting involves platform operator teams, with developers engaging through major guard rails. This use case deserves its own discussion but for now, it suffices to say that the guardrails put in place for developers to engage with Kubernetes are often found implicitly packaged within the aforementioned developer tools.

I think we’re at a point where we can conclude that the developer experience atop Kubernetes beyond what’s already out there for the inner loop, is just us trying to answer an un-asked question from enterprise consumers.