You Don't Need Kubernetes (Yet): When It's Worth It and When It Isn't

Kubernetes has become the default answer whenever a team wants to "scale for real." And most of the time it's the right answer… to the wrong question.

The Evoheim team has seen this up close enough times to say it without hedging: most teams that think they need Kubernetes don't. Realizing it in time saves them months of complexity. Here's what we look at before making that call.

The question almost nobody asks

Let's be clear up front: this isn't an anti-Kubernetes stance. It's an extraordinary piece of engineering. The problem isn't the tool; it's reaching for it by reflex, without first asking the one question that matters: do we actually need it?

And that question almost never gets asked. Teams jump straight to the "how": which distribution, which provider, how do we configure the cluster. When you start with the how, you've already assumed the whether. A big part of our work is getting a team to step back and answer the whether first.

Because the pressure to adopt is real and understandable: it's what the big companies use, it fills job postings, it sounds like the future. So saying no feels like putting the brakes on progress. In practice, we hear the same three arguments almost every time. Each one sounds reasonable. None of them, on its own, holds up.

Argument 1: "It's what the big companies use"

The most common one. If Google, Netflix, and Spotify use it, there must be a reason.

And it's true, they do. But look at what's behind it: those companies run hundreds — sometimes thousands — of services, and have entire teams whose only job is to operate the platform. For them, Kubernetes solves a real coordination problem at a scale most of us will never see.

Compare that with the average team asking this question: one app, one database, maybe a couple of services, and two or three people who also have to build the product. It's a different sport. Adopting the tool of a thousand-engineer company when you have three doesn't bring you closer to their level: it gives you their complexity without their need. Google's standard is, for almost everyone, over-engineering.

Argument 2: "We need autoscaling"

It sounds more technical, and that's why it lands harder. But it hides a costly confusion: people mix up "I want autoscaling" with "I need Kubernetes." They're not the same.

Autoscaling — growing with demand and shrinking when it's gone — already comes built into managed compute: AWS App Runner, Google Cloud Run, ECS Fargate, Render, Fly.io. You hand it your container, set a minimum and a maximum, and the platform scales on its own. No cluster, no nodes, no operating any of it.

For the vast majority of products, that covers 95% of cases. You get the benefit you were after without the heavy machinery behind it. Choosing Kubernetes for autoscaling is like buying an 18-wheeler because you needed to carry the groceries home. Yes, it carries the groceries; but now you have to park, maintain, and drive a truck all year.

Argument 3: "It's future-proof"

The one that hooks the most responsible people: put it in now, so we're ready when we grow.

It sounds like maturity, but it hides a time trap. You pay the complexity today — full, real, every single day — for a benefit that only arrives in a future that may never come.

And that complexity isn't free even if the software is. Someone stands up the cluster, maintains the nodes, applies the patches, is on call when something falls over at midnight, writes and maintains mountains of YAML. Evoheim's engineers call it operational debt: you don't see it in the code, but you pay it in every night on call and every hour your best engineer spends fighting the cluster instead of building what moves the business. On a small team, your people's attention is the scarcest currency you have.

In engineering there's a principle for this: YAGNI — you aren't gonna need it. Build for the problem you have, not the one you imagine. And if one day you grow enough to genuinely need it, that's a wonderful problem to have: you'll get there with more users, more revenue, and more people to migrate well.

A real case

An example lands the whole pattern. A health startup, around 150 users, in the middle of growth. Exactly this proposal came up: set up Kubernetes to be ready to scale. An understandable idea — the team wanted to do things right.

And note: nobody there was naive. They were monitoring and knew what they were doing. The proposal didn't come from ignorance, but from that healthy pressure to be prepared. That's why the case is useful: it's not the story of someone who got it wrong, but of a decision that looked prudent and, examined with judgment, wasn't.

The right call was not to do it: autoscaling was already handled with a managed option. And the epilogue ties it all together: months later, that platform's costs climbed again. The culprit? Not compute, not orchestration. It was the data layer. Kubernetes wouldn't have touched that problem; it would have been an enormous layer of complexity right on top of the wrong one. The team would have spent months operating a cluster while the real spend was about to surface in another, far more critical layer.

So when DOES it make sense?

Because it does. The question is never "Kubernetes yes or no" in the abstract, it's "for your scale?".

It's worth it when you have many services to coordinate, a dedicated platform team to run it, real operational complexity, or cross-cloud portability as a business requirement. Picture 20 or 30 microservices deploying independently, different teams touching each one: there, Kubernetes stops being a luxury.

It's not worth it when you have one app, one database, a small team, and tens or hundreds of users. And recognizing that in time isn't falling behind: it's judgment.

Put differently: the best architecture isn't the one that impresses in an interview, it's the one your team can operate without losing sleep while it keeps building the product.

How to hold that "no"

The hard part isn't understanding it, it's defending it when the person proposing it has more time at the company or a higher rank. Here's how the Evoheim team frames it:

1. Never a flat "no." It's a "no, and here's why." That difference is everything.
2. Put the numbers on the table. Real users, services, people to operate it. Numbers defuse the prestige argument.
3. Don't attack the tool; offer the alternative. "We solve this with a managed option in an afternoon; if we ever need more, we migrate with the business already grown." You give an exit, not a wall.
4. Acknowledge when yes. Say out loud the conditions under which you'd change your mind. That turns your "no" into judgment, not stubbornness.

And underneath all of this there's something Evoheim doesn't compromise on: method. The team never proposes anything without doing the research. We put two or three options on the table, each with numbers — cost, operational effort, migration time — and explicit trade-offs. Never a single alternative sold as "the" answer. Because a "no" only carries weight if it comes with a "here's what yes looks like, and here's why, with data."

Because sometimes the most valuable technical deliverable isn't what you build, but what you talk someone out of building.

At Evoheim we help companies choose the architecture for their real scale, not the trendy one. If you're about to add — or finally remove — a piece of infrastructure and want an honest second opinion from our team, let's talk.