Kubernetes is not a platform: it is a toolkit

A team says it has “built a platform” because it runs Kubernetes. Then a developer tries to ship a service and still has to assemble a Deployment , Service , HorizontalPodAutoscaler , NetworkPolicy , PodDisruptionBudget , ServiceAccount , and half a dozen bits of environment-specific glue by hand. That is the category error in one scene. Kubernetes is the substrate. The platform is still on the backlog. The Kubernetes project makes the same point in its own overview docs . Under the heading “What Kubernetes is not”, it says Kubernetes is “not a traditional, all-inclusive PaaS” and that it provides “the building blocks for building developer platforms”. Building blocks, from the people who maintain them. So when you hand product teams raw kubectl , raw YAML and a wiki full of tribal knowledge, what you have handed over is a very capable control plane and a pile of homework. Kubernetes is a very good substrate Kubernetes earns its place in all this. It gives you strong primitives and a programmable control plane, and that combination is hard to come by anywhere else. Concretely: declarative desired state reconciliation loops scheduling and placement service discovery rollout machinery extensibility through CRDs and controllers Which is a serious foundation, and it explains why Kubernetes keeps ending up in the middle of internal platforms. Foundations and finished products sit in different categories, though. Postgres is a foundation; the finance dashboard someone logs into every morning is the product built on it. A cluster running important workloads sits on the foundation side of that line, however well run it is. This is where a lot of platform work goes sideways. Infrastructure teams do the hard bit: secure the cluster, patch it, make it observable, get some governance around it. Somewhere in the following six months the organisation starts calling the cluster “the platform”, on the assumption that a working substrate produces a usable product on its own. It neve