Kubernetes is not your platform!

In my work, I often hear some version of this: “We have Kubernetes, so we have a container platform.”

I don’t quite see it that way. Kubernetes runs and orchestrates containers. It gives you scheduling, networking primitives, service discovery and an API to manage workloads. That makes it a good foundation for a platform, but not necessarily the platform your teams need.

The difference becomes obvious in production. Who handles identity, secrets, certificates, network policy, logging, backups, image provenance, tenant isolation and upgrades? Kubernetes has mechanisms for many of these, but it does not decide how your organisation uses them. That is where the platform starts. A Kubernetes cluster can be up and running while these questions are still unanswered. Every team then needs a way to deploy, get access, expose services, store secrets and see what its application is doing. If every team solves that for itself, you have shared infrastructure with Kubernetes on top.

The diagram shows the distinction I mean. Kubernetes provides the orchestration primitives, while the platform turns recurring decisions about identity, networking, security, delivery and operations into defaults and supported paths. Teams can deviate when there is a reason to, but they should not have to assemble the platform before they can deploy an application.

Which decisions should teams actually make?

This changes the question. Instead of starting with “Which Kubernetes distribution should we choose?”, I would rather start with “Which decisions do we actually want application teams to make?”

We have been moving that boundary for years. DevOps gave development teams more ownership beyond writing and committing code. In many organisations that also meant making decisions about pipelines, deployment, infrastructure, observability, secrets and parts of the runtime environment. More ownership also meant more technical choices for every team.

Platform engineering is partly a response to that. There is little value in every application team deciding how certificates are issued, how workloads authenticate, where logs go or which deployment mechanism to use. Those choices can often be made once and provided as defaults, with room to deviate when the default does not fit.

This is also where platform engineering can go wrong. Putting capabilities behind a portal does not remove complexity. A catalogue full of Helm charts, Terraform modules, operators, databases and deployment options may provide self-service, but someone still has to understand those options and choose between them.

Self-service should not mean that teams have to do everything themselves. For the common case there should be a supported path. Leave too much open and every team starts solving platform problems. Abstract too much and the platform team creates another layer that it has to develop and maintain.

Where did the complexity go?

I have seen the technology arrive before that model was finished. A container platform can run workloads while questions about tenant isolation, identity, observability, lifecycle and ownership are still being worked out. The same applies to automation: a working pipeline tells you that something can be automated, not what belongs in the pipeline or who should make the decisions it implements.

DevOps, platform engineering and AI-assisted development are not three generations replacing each other. They coexist. The diagram is about where the technical decisions end up.

AI makes this more interesting because producing an implementation is getting cheap. We can already generate Dockerfiles, Kubernetes manifests, pipelines and infrastructure configuration with little effort. An AI coding agent can produce a technically valid manifest in seconds, but that does not mean it should decide how workload identity works, where data may be stored or which network boundaries apply.

This could make standardisation harder rather than easier. If another deployment or pipeline variant costs almost nothing to generate, we can also create unnecessary variation much faster. Automating a choice does not remove the choice.

What should a platform decide?

For me, that is the more useful way to look at a platform. It should make common technical choices once, provide a usable default and leave application teams with the decisions that actually belong to them. The same becomes relevant for AI agents: they should be able to work within those defaults without inventing a new platform model every time they generate an implementation.

Kubernetes gives us a lot of freedom, and that is one of its strengths. We do not need to pass all of that freedom on to every team and every workload.

A platform is therefore not only defined by the capabilities it provides, but also by the decisions its users no longer have to make.

Kubernetes can provide the foundation. Deploying Kubernetes does not make those decisions for you.