You Probably Don't Need Kubernetes. You Just Think You Do.

Somewhere along the way, Kubernetes stopped being a tool and started being a personality trait. Teams adopt it not because their infrastructure demands it, but because it signals technical seriousness. It's the engineering equivalent of buying a commercial espresso machine for your apartment because you drink a lot of coffee.

The result? Hundreds of startups and mid-sized dev teams are running orchestration platforms designed to manage thousands of containers across massive distributed workloads — and they're using them to deploy a monolith, a background worker, and a Postgres instance. The operational overhead is real. The benefits are theoretical.

Let's talk about how this happens, what it actually costs you, and how to figure out whether K8s is solving your problems or creating new ones.

The Cargo Cult Problem in Modern Infrastructure

Cargo culting in engineering is when you copy the form of something without understanding the function. You see a successful company using a technology, you adopt it, and you expect the same outcomes — without replicating the conditions that made it work.

Kubernetes is the current poster child for this pattern. Google built Borg (the internal precursor to K8s) to manage tens of thousands of machines running millions of containers. It solved a genuinely gnarly distributed systems problem at a scale most organizations will never touch. The open-source version of that thinking is powerful — but it's powerful in the same way a semi-truck is powerful. Useful if you're moving freight across the country. Overkill if you're picking up groceries.

When teams adopt Kubernetes without that context, they're not inheriting Google's scalability. They're inheriting Google's complexity.

What Kubernetes Actually Costs You (Beyond the AWS Bill)

The financial cost of running K8s gets talked about plenty — the compute overhead, the managed cluster fees on EKS or GKE, the extra nodes you're spinning up to handle the control plane. Those are real, and for small teams they're not trivial.

But the bigger cost is cognitive and operational.

Someone on your team has to own the cluster. That means understanding RBAC configs, debugging pod evictions at 2 a.m., managing ingress controllers, figuring out why your HorizontalPodAutoscaler is scaling to zero during a traffic spike instead of up. Kubernetes has a steep learning curve that doesn't flatten quickly — it just shifts from "how does this work" to "why is this broken in a new way."

For a team of four engineers trying to ship a product, that's not an acceptable tax. Every hour spent debugging a misconfigured liveness probe is an hour not spent building something users actually care about.

When K8s Legitimately Earns Its Place

None of this means Kubernetes is bad. It means it's a specific solution to a specific class of problems. Here's when it actually makes sense:

You're running a genuinely large number of services. If you have 20+ microservices that need independent deployment, scaling, and rollback, a container orchestrator starts to pay for itself. Trying to manage that with shell scripts and EC2 instances is its own kind of nightmare.

Your scaling needs are highly variable and unpredictable. If you have real traffic spikes — think event-driven loads, flash sales, API products with bursty usage patterns — the autoscaling primitives in Kubernetes can save you money and prevent outages that manual scaling would miss.

You have dedicated platform or SRE capacity. K8s rewards teams that have people whose job it is to manage infrastructure. If you're a startup where your backend engineers also own deployment, you're signing those people up for a second job.

You need strong isolation between workloads. Multi-tenant systems, compliance-heavy environments, and teams that need hard resource guarantees between services are good candidates.

If none of these apply to you right now, you should be asking harder questions before provisioning that cluster.

The Alternatives That Actually Let You Ship

The infrastructure landscape in 2024 gives you options that didn't exist five years ago. The "it's K8s or raw VMs" framing is outdated.

Fly.io, Railway, and Render have made deploying containerized apps with sane defaults genuinely fast. You get horizontal scaling, zero-downtime deploys, and managed databases without writing a single YAML manifest. For early-stage products, this is often the right call.

AWS App Runner and Google Cloud Run are solid if you're already in those ecosystems and want serverless-adjacent container deployment without managing nodes. Cold starts are a real consideration, but for many workloads they're acceptable.

A boring ECS setup is underrated. Elastic Container Service on Fargate gives you container orchestration without the full Kubernetes mental model. It's less flexible, but for a lot of teams that's a feature, not a bug.

The common thread: these options let your team stay focused on product velocity. You can always migrate later if you genuinely outgrow them.

A Practical Decision Framework

Before you stand up a Kubernetes cluster, run through this:

1. How many services are you actually deploying? Under ten, and they're mostly stable? You probably don't need K8s.
2. Do you have someone who can own cluster operations? Not "someone who took a Udemy course" — someone with genuine production K8s experience. If the answer is no, you're setting yourself up for a painful incident.
3. Is your scaling challenge real or anticipated? "We might get a lot of traffic someday" is not a scaling problem. It's a hypothesis. Don't architect for a hypothesis.
4. What's the deployment complexity you're actually managing? If your deploy process is docker build && docker push && ssh and restart, Kubernetes is not the next logical step. A managed platform is.
5. What would you do with the engineering hours you're spending on infrastructure? This is the real question. If the answer is "ship features that drive revenue," you have your answer.

The Maturity Trap

There's a subtle status game happening in engineering culture where infrastructure complexity gets mistaken for technical maturity. Teams use Kubernetes because it makes them feel like they're building something serious. It makes job postings look impressive. It gives engineers something to put on their resumes.

But maturity isn't complexity. Maturity is choosing the right tool for the problem you actually have — not the problem you imagine you'll have at Series C.

The teams that ship fastest aren't necessarily running the most sophisticated infrastructure. They're running the simplest infrastructure that handles their actual load, freeing up their engineers to work on the things that move the needle.

Build What You Need, Not What You're Afraid Of

Kubernetes is a genuinely impressive piece of technology. When the problem fits, it's hard to beat. But most teams running it today aren't in that situation — they're paying an infrastructure tax that shows up in slower deploys, harder oncall rotations, and engineers who spend too much time keeping the lights on.

The goal is to ship software that works, at a pace that lets you learn and iterate. Sometimes that means Kubernetes. More often, it means something simpler that gets out of your way.

Figure out which one you actually need before you spend the next quarter debugging node affinity rules.