The Kubernetes tax

The pattern is common enough to be worth writing down as one.

A five-person startup spends its first six months with one engineer, its best one, mostly absent from the product. He's the only person who understands the Kubernetes cluster, so he's the only person who can touch it, and the cluster needs touching constantly.

A networking config that works in staging and not in prod. An autoscaler tuned for a load pattern the company doesn't have yet. A secrets manager breaking on every deploy for reasons nobody has time to root-cause, because there's always something more urgent.

Forty customers. No scaling problem anywhere in sight. The company chose to have an operations problem instead, on purpose, before anybody asked it to.

Close to the default story, in my experience, and it keeps happening because the advice to run Kubernetes arrives dressed as seriousness while the advice to skip it arrives dressed as cutting corners. Founders trying to look serious pick the wrong one with predictable regularity.

The actual question nobody asks

Kubernetes solves real problems: workload portability across clouds, sophisticated scheduling across a large, heterogeneous fleet, a consistent operational model when you're running hundreds of services maintained by dozens of teams who don't talk to each other daily. Those are real. At five people, or fifteen, or honestly most companies under thirty engineers, none of them are your problems yet, and "yet" is doing an enormous amount of unexamined work in that sentence.

The question that would actually settle it, and that almost nobody asks out loud in the meeting where this gets decided: what specific thing, happening this quarter, does this solve that a managed platform doesn't? Not eventually. This quarter. If the honest answer is "nothing, but we'll need it later," you've just described nearly every infrastructure decision that ever went badly, because "we'll need it later" is true of almost anything and is not, on its own, a reason to pay for it now. The same test decides whether to split a monolith into services before anything actually needs it.

What the bill actually looks like

The setup is a weekend. That was never the expensive part, and pretending it is is how this decision keeps getting made badly.

The expensive part is that every subsequent problem, forever, now runs through a Kubernetes layer. A slow request might be your code, or it might be a networking policy nobody remembers writing. A deploy that hangs might be your service, or it might be a resource quota set by whoever configured the cluster eighteen months ago and left since. At five or fifteen people, you don't have anyone whose job is to know this layer cold, so every one of those investigations costs your best engineer's attention, pulled off the actual product, on a rotating and unpredictable schedule. That's the real price, and it's not on the invoice.

"We'll need it eventually" is true and irrelevant

The migration-later argument is the one people find most persuasive and it's the weakest one in the room. Yes, migrating off a managed platform once you genuinely outgrow it is real work. It is dramatically cheaper than eighteen months of a small team's best attention spent operating infrastructure sized for a company you might become. And a meaningful share of companies planning around "eventually" never get there, for reasons that have nothing to do with infrastructure, which means the insurance was purchased against a future a lot of the buyers never reach.

When it stops being self-harm

There's a real point where this flips, and it's worth being precise about it instead of leaving it as "eventually."

Start with the gate, which is necessary and never sufficient: a named person whose job includes this layer, not a generalist absorbing it between other things. Without that name nothing below matters, because what you've bought is a system with no operator.

Then the reason, and there are fewer good ones than the conversation implies. The strongest is workloads with genuinely different operating characteristics running across a large fleet, one memory-bound and one CPU-bound, where a single runtime means provisioning everything for the union of both. That's the only one you can put a number against, and it's the same test worth applying to splitting out a service at all. A compliance requirement that names the technology is the other legitimate one. Rare, real, and not worth arguing with.

"Real multi-cluster scale" used to sit on that list and shouldn't. It's close to circular, because organisations tend to be at multi-cluster scale precisely because somebody already chose Kubernetes. That's an artefact of the decision rather than a reason for making it.

And the reason has to be current rather than anticipated. For most companies the point arrives well past thirty engineers, and considerably later than the point at which the conversation usually starts.

Until then: a managed platform, one that takes code and runs it, and an engineering team that spends its best attention on the product instead of the plumbing underneath it.