Kubernetes Maximalism

Yes, you need Kubernetes. Yes, it is complex.

Kubernetes will become part of most infrastructure stacks. Today, platform teams try and abstract Kubernetes away from developers, but I predict that Kubernetes will become the developer platform in the future. I call this Kubernetes Maximalism.

Kubernetes Maximalist: One who believes that all developer platforms and infrastructure platforms will converge to be based on Kubernetes.

Some background first: I don't just drink the Kool-aid; I'm the one who mixed it. I spent three years at Google working on Kubernetes and developer tools. I've spoken at multiple KubeCons and DockerCons. You might have used some of the projects I maintained: minikube (run Kubernetes on your laptop), skaffold (hot reloading Kubernetes developer tool for infrastructure and code), or Kubeflow (MLOps platform on Kubernetes). You can see the complete list of my projects on my about page.

So, why?

Development/Production Parity. Differences between development and production environments create opportunities for hard-to-debug bugs. Differences between QA and production create opportunities for costly bugs. Kubernetes provides a stable API for all environments. I wrote more about this (almost three years ago!) in Should Your Developers Work in the Cloud?.

Pluggability and Extensibility. Kubernetes lets you easily swap out any significant components and provides countless interfaces at every level of the stack. Storage, scheduling, container runtimes, networking, and API extensions make Kubernetes flexible for most workloads. Confusion happens when abstractions are built on top of Kubernetes that belong a plugins or custom resources (i.e., horizontal integration instead of vertical).

Developer Velocity. Developers shouldn't spend their first week installing and configuring their machines for development. An all-in-one Kubernetes on your laptop comes packaged up in many easy ways like minikube or Docker for Desktop. I use minikube and skaffold to git clone && skaffold dev any of my projects to have an instant hot-reloading developer environment that's always up-to-date.

Generic build and runtime standards. Platforms like Heroku and App Engine were great, but they existed in a language-specific world. Language versions and support were notoriously tricky (for both the customer and the provider). Docker containers and Docker images (or "OCI") are the new generic build and runtime standards. They provide stable, generic APIs to build, package, and run the software. Docker provides the API for declarative environments even where it was difficult before (e.g., dynamically linked libraries, execution of other binaries, or OS-level dependencies). Docker is a compiler.

Kubernetes is indeed complex. Some of this complexity is manufactured (read: Software Wants to be Simple). Kubernetes wins because it makes things simpler in the long run. Once set up, declarative infrastructure, stable build and deploy APIs, and development/production parity pay their dividends. Of course, there's a learning curve (as there is with most software). You probably don't need Helm, a service mesh, or complex operators to start with (or ever).

Not all problems are solved yet, and some cause significant friction in onboarding. For example, there are multiple layers of indirection on macOS and Windows, making it difficult to know where your code is (minikube/Docker for Desktop both run a lightweight virtual machine that runs Kubernetes, which runs the containerized workloads). The inner development loop (build, test, deploy) with containers can be slow (skaffold fixes this).

I bet that Kubernetes is here to stay as part of the infrastructure stack and slowly bleed into the developer stack. Of course, there will be better abstractions built on top - but they will fundamentally be from the same school of containerization and Kubernetes-style APIs.

The distributed system is already here. It's just not evenly distributed.