Small teams should not run Kubernetes

I want to be careful here, because this argument usually gets made badly. Kubernetes is not bad. It is very good at the problem it solves. The trouble is that running it is a full-time job, and a team of six has not hired for that job — they have hired six people to build a product, and one of them is about to become a part-time platform engineer without anyone deciding that.

Here is what six engineers actually get from it: rolling deploys, health checks, and a way to run more than one copy of a service. All three are worth having. All three are also available from a managed platform for roughly the cost of an afternoon.

And here is what it actually costs: someone has to own upgrades. Someone has to understand why a pod is pending. Someone has to know what the ingress controller is doing when the certificate does not renew. That someone will be whoever is unlucky enough to look first, and they will get good at it, and then they will become the person who cannot go on holiday.

The honest test is not "can we run it" — a competent engineer can run anything for a quarter. The test is whether the thing survives that engineer leaving. Most small-team clusters do not.

There are three cases where I still say yes. If you are already deploying twenty-plus services and the coordination is genuinely the hard part. If your customers demand you run inside their infrastructure and that infrastructure is a cluster. And if you have actually hired someone whose job title contains the word platform, and they want it.

Otherwise: boring hosting, one process per service, and spend the engineer you would have burned on the cluster building the thing customers are paying for.