Kubernetes Isn't a Religion — It's a Tool. And Maybe You Don't Need It

Let's be honest — Kubernetes has become the default answer to every infrastructure question. Need to deploy a simple API? Kubernetes. Want to run a couple of internal tools? Kubernetes. Have a monolith that hasn't changed in three years? "Containerise it and put it on Kubernetes!"

But I keep noticing something that doesn't get talked about enough: most organisations aren't actually running Kubernetes as one big beautiful elastic platform. They're running fifty small, disconnected clusters — each team spinning up their own, each managing it differently, none of them realising the economies of scale we were promised. And for what? Sometimes I wonder if we're doing it because it solves our problems — or just because it's what everyone else does.

The VMs and Load Balancer Alternative — Seriously

Let's start with the boring stuff that just works. A couple of virtual machines behind a load balancer. You know the pattern — it's been around for well over a decade.

For a small team running a handful of services? Two or three VMs and a simple load balancer is not a compromise. It's a deliberate choice. It's less to learn, less to break, less to debug at 2am. And modern VMs are resilient — they live on redundant hosts, they snapshot, they migrate. They're not the physical servers from 2010.

Where the Sprawl Actually Lives

This is the part that drives me crazy. I don't know a single enterprise that runs "enterprise-wide Kubernetes." Not really. What I see is:

• Team A has a cluster in AWS
• Team B has their own cluster in Azure
• QA has another one
• Staging is yet another
• The data science team spun up something that nobody else is allowed to touch

Suddenly you've got 20 clusters, each under-utilised — industry benchmarks put average CPU utilisation across production clusters at just 8% — and every single one needs patching, upgrading, monitoring, and securing independently. The very elasticity and efficiency Kubernetes promises? Gone. Because you're not sharing resources across teams — you're walling them off from each other. You're paying the full complexity tax while capturing almost none of the benefits.

The Hidden Cost of Cognitive Load

This is the quiet killer. Kubernetes changes the job description. Suddenly your infrastructure team isn't just deploying code — they're also:

• Managing cluster upgrades every few months, navigating deprecated APIs and breaking changes
• Troubleshooting networking layers that didn't exist before
• Managing certificates, service accounts, RBAC, ingress controllers, storage classes…
• Learning a whole new vocabulary of YAML, operators, CRDs, and custom resources

I've seen Series A startups with 8-person engineering teams dedicate 1.5 to 2 full-time equivalents just keeping the lights on in Kubernetes. That's 20% of your engineering capacity — not building product. Just maintaining the platform.

The argument is always "once it's set up it's smooth sailing." But when is it ever done? Kubernetes isn't a set-it-and-forget-it appliance. It's a distributed operating system that needs constant care and feeding.

When Kubernetes Actually Makes Sense

Let me be clear — I'm not anti-Kubernetes. It solves real problems. You probably do need it when:

• You're running 20+ distinct services that deploy independently
• Demand spikes unpredictably and you genuinely need auto-scaling from zero
• Your teams are large enough that a dedicated platform team makes sense
• You need consistent deployment patterns across multiple environments or clouds
• You're doing complex things — service meshes, batch jobs, stateful sets, custom operators

If you check those boxes? Kubernetes is brilliant. It's the best tool for the job. But if you're running three monolithic apps and a database? You're building a skyscraper when you just needed a garden shed.

The Middle Ground Nobody Talks About Enough

Here's what I think we should be doing more of: match the platform to the workload. Not "everything on Kubernetes" or "everything on VMs" — a sensible mix.

• Simple web apps, internal tools, steady workloads: Use VMs, or something even simpler — Cloud Run, App Service, Fly.io, ECS. Containerise them if it makes deployment cleaner, but skip the orchestrator entirely
• Microservices that scale independently, release often, need complex networking: Kubernetes is your friend here
• Stateful workloads: Seriously ask yourself — does this belong in a cluster, or on dedicated infrastructure where performance and stability are easier to guarantee?
• Teams of 1–5 people: You almost certainly do not need self-hosted Kubernetes. Start simple. Evolve only when the pain of your current setup is genuinely worse than the pain of the alternative

Here's Where I Might Ruffle Some Feathers

I think we've collectively accepted a very expensive premise: that Kubernetes is the "modern" way and anything less is "legacy." That's marketing, not engineering judgment. The right tool is the one that solves your problem with the least amount of ongoing operational cost. Sometimes that's a cluster. Sometimes that's three VMs running Docker Compose. Sometimes that's a managed PaaS you don't even have to think about.

And here's the hard truth about those sprawled-out enterprise clusters: if you can't operate Kubernetes efficiently — sharing capacity across teams, keeping versions aligned, standardising your approach — then you're paying more and getting less. You'd be better off with a simpler foundation that you actually understand and can maintain consistently.

Over to You

I know this is a debate people feel very strongly about.

Where does your organisation sit on this? Did you adopt Kubernetes and wonder where the efficiency went? Or have you deliberately kept things simpler and found that VMs + a good deployment process are all you actually needed? I'd love to hear your real-world experience — especially the ones that don't make it to conference talks. Drop a comment below 👇