When Kubernetes is the wrong answer.

Kubernetes is rarely chosen. It's defaulted to. The discipline is asking, out loud, before the first cluster exists, whether the problem in front of you actually needs it.

Every platform decision tells two stories. One is the architecture diagram, the kind that looks ambitious on a slide. The other is the on-call rotation it creates, the pages at 3am, the upgrade nobody wants to own, the YAML that has quietly become a second codebase. Kubernetes makes the first story look impressive and the second one a lot longer.

None of that is an argument against Kubernetes. It's an argument against reaching for it by reflex. It is an extraordinary piece of engineering, built to solve the problems of teams running hundreds of services at a scale most companies will never touch. The trouble starts when its complexity is adopted long before its capabilities are needed, when a team of six inherits the operational surface of a platform built for six hundred.

Ask why it's being chosen and the honest answer is often something other than the workload: it's the default in every conference talk, it looks good on a résumé, it's what the last company used. Those are real forces. None of them are your traffic. The CNCF's annual survey puts production Kubernetes use past 80%, up from 66% a year earlier, and that's precisely how reflex forms. When something is everywhere, adopting it stops feeling like a decision and starts feeling like the absence of one.

Complexity you don't need isn't power. It's risk you've agreed to pay for.

The complexity has to live somewhere

Kubernetes doesn't remove complexity; it relocates it. The application gets simpler to deploy, and in exchange you now operate a distributed system: a control plane, an overlay network, RBAC, ingress, secrets, autoscalers, and a cluster-upgrade cadence that never stops. That's a fair trade when the complexity buys you something real, many teams, many services, genuine elasticity. It's a terrible one when you've taken on a platform team's workload to run three containers that a single managed service would have hosted for a fraction of the attention. And that workload is real: the same CNCF survey reports that the top barrier to running containers in production is no longer technical, it's cultural, cited by 47% of teams, ahead of training, security, and complexity. The cluster isn't the hard part. Building an organization that can operate it is.

Most teams aren't Google

The boring options are right far more often than they get credit for. A managed container runner like Fargate or App Runner, a queue, a managed database, and one well-understood VM will carry a company further than most founders expect, usually all the way to the point where they have the scale, and the people, to actually want Kubernetes. The people part is not a detail: roughly three in four organizations report a shortage of the skills needed to run cloud-native infrastructure well, which means most teams adopting Kubernetes are committing to operate something they cannot fully staff. And there is a point where it's worth it anyway. Multiple teams shipping independently, real horizontal scale, a hard portability requirement across clouds, these are genuine reasons, and when they're genuine, Kubernetes earns its complexity. The discipline is telling the difference between needing it and wanting to have chosen it.

Choose the failure modes you can staff

Every architecture is a set of failure modes you've agreed to own. The right question isn't which system is most powerful, it's which one your team can actually run at 3am, with the people you have, on the worst night of the quarter. A platform you can't operate calmly under pressure isn't an asset; it's a liability with great documentation. Pick the smallest system that solves the real problem and still leaves you the capacity to run it well.

Standing up Kubernetes is easy now, a managed cluster is a few clicks and a weekend of tutorials. Knowing whether you should is the harder, more valuable judgment, and it's the one that compounds: every piece of complexity you don't adopt is attention you keep for the problems that are actually yours. The goal was never the most sophisticated platform. It was the right-sized one.

Choose the smallest thing that solves the actual problem. That isn't under-engineering, that's the engineering.