What Comes After Kubernetes?

Few projects are ever “finished”, but the Kubernetes APIs have reached a steady state. Core APIs are well into v1 and the extensibility model (custom resource definitions) is stable.

What comes next? Some ideas as someone who has been working with Kubernetes since 2016.

Native Scale to Zero — Frameworks like Knative offer a “scale-to-zero” functionality. This is essential for many infrastructure startups (and customers), especially those dealing with expensive resources (e.g., GPUs). But scale-to-zero has it’s own problems — the biggest being cold starts. There’s not a one-size-fits-all solutions yet — you have to either full environment specification (e.g., containers) or startup speed with constraints (e.g., WebAssembly functions).

Smaller API Surface — There have been projects that have focused on more lightweight deployments (e.g., minikube, which I maintained at Google, or k3s), but none have focused on constraining the API surface.

I think there’s room to build an opinionated yet generic constrained API here. An API that’s purpose-built for developers, not operators, or even DevOps. Not as simple as a Heroku, but not as generic as Kubernetes.

Distributions — Many thought we would have distributions of Kubernetes like we have distributions of Linux (e.g., Debian, Arch Linux, Red Hat Linux, etc.). This hasn’t been the case. My hunch is that there’s too much cloud-specific coupling in Kubernetes to make distributions that get enough momentum.

Kubernetes Configuration Language — Another problem that has eluded developers since Kubernetes inception. How do you easily configure and deploy Kubernetes? YAML and YAML templates are too complicated, and other attempts at configuration languages have all failed. There’s an infrastructure-as-code angle that I think is promising (e.g., the combination of AWS CDK and CDK8s) — but it still leaves a lot to be desired. Again, I think a developer angle is essential here.

Orchestration for {WebAssembly, Functions, something else} — Kubernetes can be modified to run deployments other than containers (e.g., virtual machines, gVisor, and even some for WebAssembly), but it is possible that the next orchestrator focuses on a new primitive. A purpose-built system  will most likely outperform a generic one (in terms of developer experience and functionality).

Whatever comes next will have to (1) leverage Kubernetes and (2) solve some of the problems that Kubernetes created. It won’t replace Kubernetes.

• Native scale-to-zero

• Easier configuration

• Built for developers (not DevOps or Platform Engineering)

• Smaller API

• More cloud-native