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 never has.

A platform is a product with users

The CNCF Platforms white paper uses much stricter language than most teams do in everyday conversation. It defines a platform as an integrated collection of capabilities defined and presented according to the needs of the platform’s users, and it calls out interfaces such as web portals, project templates, and self-service APIs.

“We run Kubernetes” clears none of that bar. The platform is the opinionated layer above it, the one that turns raw technology into something people can use safely and repeatedly.

Usually that means some combination of:

• self-service interfaces so teams can create or change what they need without waiting on tickets
• paved roads so the safe path is the easy path
• policy and defaults so teams do not need to rediscover every security and reliability lesson themselves
• documentation and examples that reflect how the organisation actually expects software to be shipped
• support boundaries so people know what is standard, what is allowed, and what will get help at 02:00

The last one does more work than it looks. A platform is partly software and partly promises. An interface where no one can tell you the support status is a hopeful abstraction: teams route around it the first time it surprises them, and now you maintain two paths instead of one.

The category error shows up as cognitive rent

When teams say “Kubernetes is our platform”, they usually mean “Kubernetes is where our applications run”. The second claim is easy to earn; the first one is a product commitment.

There is a test for which one you have: what does a product engineer still need to understand to ship a normal service safely? If the answer runs to “quite a lot of Kubernetes”, you are still handing over the substrate.

That usually means developers still need working knowledge of things like:

• how requests and limits interact with scheduling
• when an HPA will or will not behave the way they expect
• why a missing PodDisruptionBudget only hurts during maintenance windows
• how NetworkPolicy defaults work in their cluster
• which ingress, gateway, or certificate path is considered standard
• which bits of YAML are mandatory because the platform has no stronger abstraction yet

Developers learning infrastructure is fine, and plenty of them should. The trouble starts when shipping an ordinary service requires them to learn the platform team’s entire problem space.

That is the bill for confusing a toolkit with a platform. The complexity stays exactly where it was; it just gets paid for by every team that touches it, in small instalments, every time they deploy.

This is why the Team Topologies framing still holds up. A platform is valuable in proportion to the cognitive load it takes off the teams consuming it. Ask developers to become part-time Kubernetes operators and you have moved that load rather than absorbed it.

A thin platform still counts

One reason teams overstate what Kubernetes gives them is that they imagine the alternative must be some giant internal developer portal project. If they are not ready to build Backstage templates, service catalogs, policy packs, and self-service workflows, they decide the cluster itself must count as the platform. Most of the useful work lives in the gap between those two options.

Team Topologies has a saner idea: the thinnest viable platform. On the Team Topologies TVP page, Matthew Skelton says that this can be “just a wiki page” if that is all you need at your current scale. That line keeps the argument grounded. What qualifies something as a platform is whether it gives your developers a clearer, safer, more repeatable way to get work done. Scale decides how thick it has to be; nothing else does.

Sometimes the thinnest useful platform is:

• one golden path for a standard web service
• a starter template with the right defaults already wired in
• one supported CI path
• one documented way to expose a service
• one place to request a database or secret with known guardrails

That is still platform work, and at most organisations it is the right platform work to do first.

Starting small is fine. The mistake is skipping the product layer entirely and calling the control plane beneath it finished.

What a real platform adds on top of Kubernetes

If Kubernetes is the substrate, what does the platform layer actually contribute?

At minimum, it should remove repeated decisions that your teams do not benefit from making over and over.

A decent internal platform usually adds:

1. An opinionated service shape. New services start from a template or scaffold that already includes the organisation’s baseline for probes, resources, identity, networking, and delivery.
2. A supported path to production. One default route that the platform team actively maintains, and that most services can take without needing a conversation first.
3. Guardrails with teeth. Policy, admission control, CI checks, and defaults that catch the boring mistakes before they get merged.
4. Self-service for common needs. Databases, secrets, DNS, certificates, queues, environments, or delivery workflows that do not require a human to hand-hold every request.
5. A product experience. Good docs, clear ownership, visible support boundaries, and feedback loops so the thing improves instead of calcifying.

Notice what is missing from that list: “owning a cluster”. Owning a cluster is an operational capability, and platform engineering usually needs one. It buys you the right to start.

Use the maturity model as a self-check

The CNCF Platform Engineering Maturity Model is useful here because it stops the conversation from collapsing into slogans.

It describes four levels — Provisional, Operationalized, Scalable, and Optimizing — and looks across five aspects: investment, adoption, interfaces, operations, and measurement.

That works better as a diagnostic than asking whether you “have a platform”. Almost every team is somewhere in the middle of that grid, and the useful question is which cell they are in and which one they want to be in next.

A few blunt checks help:

• Interfaces: do teams have a real self-service interface, or are they still stitching together YAML and Slack messages?
• Adoption: do product teams voluntarily use the paved road because it is better, or because they were told to?
• Operations: is there a supported day-two story behind the abstraction, or only a shiny day-one story?
• Measurement: can you show that the platform shortens delivery loops or reduces support load, or is that still mostly assumed?
• Investment: is there sustained ownership, or is the “platform” just a side project orbiting the cluster team?

Answer those five properly and the picture resolves fast. A team with a well-run cluster, ad-hoc interfaces and adoption it has never measured is doing valuable infrastructure work. The platform sits a column to the right of where that team is standing.

Where the finish line actually is

The finish line is a state where most teams can ship a service without writing a production-grade manifest from scratch.

You still want depth somewhere. Strong operational understanding in the platform team, and enough shared literacy that developers can reason about what runs underneath their code — that is a real asset, and it is a different thing from requiring it of everyone before they are allowed to deploy.

Developers should be able to use the platform the way you hope customers use any good product — confidently, and without carrying a mental model of its internals around with them.

Calling the substrate the platform has a specific cost. It lets you declare victory early, and after that every improvement gets spent on the cluster rather than on the people using it.

If you want one thing to do this quarter: take the service shape your teams create most often and give it a single supported path — a template, a sane set of defaults, one documented route to production. Then time how long it takes somebody outside the platform team to get from an empty repository to a running service, before and after. If that number holds steady, you built the abstraction for your own convenience.