The first time I watched a senior engineer spend forty minutes debugging a pod that refused to schedule — not because the application was broken, but because a node affinity rule had been copy-pasted from a Stack Overflow answer nobody fully understood — I had a quiet, uncomfortable thought: we built a skyscraper to store a bicycle.
That engineer was good. Sharp, experienced, the kind of person who reads release notes for fun. And still, Kubernetes had swallowed an entire afternoon over a configuration detail that had nothing to do with the actual product the company was trying to ship. The application, a modest API serving maybe two thousand requests a day, would have run fine on a single DigitalOcean droplet with a systemd service file and a cron job for restarts. Instead, it lived inside a cluster with three node pools, a custom ingress controller, cert-manager, external-dns, and a Helm chart that had grown, through successive good intentions, into something nobody dared touch without a backup plan.
This is not a screed against Kubernetes. It is a reckoning with the question that the industry has been too polite to ask plainly: for most of the teams running it, is Kubernetes complexity actually worth it?
The Tool That Became the Job
Kubernetes was born at Google, and that origin story has done enormous damage to how the rest of us think about infrastructure. Google needed something to orchestrate workloads at a scale most companies will never approach. The engineering problems they were solving — bin-packing containers across tens of thousands of machines, rolling updates with zero downtime across global regions, automatic rescheduling when hardware fails — are real problems. They are just not your problems, unless you are operating at a scale that only a handful of organizations on earth actually reach.
When Kubernetes went open-source in 2014, it arrived wearing Google's credibility like a tailored suit. The message, rarely stated but always implied, was: this is how serious companies do infrastructure. Adopting it felt like a signal of maturity. Rejecting it felt like technical debt you'd regret later.
So teams adopted it early. Then startups adopted it because the job listings demanded it. Then mid-sized companies adopted it because their new hires expected it. And somewhere in that chain of social proof, the tool stopped being a solution to a specific problem and became the default answer to a question nobody had fully formed.
The result is an industry full of teams where a meaningful percentage of engineering hours — sometimes the majority of a platform engineer's week — goes not into building product features but into managing the infrastructure that was supposed to make building product features easier.
What Complexity Actually Costs
There's a version of this argument that gets dismissed as laziness or naivety. Surely, the counterargument goes, the operational benefits — self-healing, horizontal scaling, declarative configuration — justify the learning curve. And for some teams they do. I want to be precise about that. If you are running dozens of microservices with genuinely independent scaling needs, if you have a dedicated platform team with the headcount to own the cluster, if your traffic patterns demand the kind of elasticity that Kubernetes provides — then yes, the tradeoff tilts in your favor.
But complexity has costs that compound in ways that don't show up on the architecture diagram. The first is cognitive load. Kubernetes has its own vocabulary — Deployments, ReplicaSets, StatefulSets, DaemonSets, ConfigMaps, Secrets, ServiceAccounts, ClusterRoles, PodDisruptionBudgets — and that vocabulary must live in the working memory of everyone who touches the system. Every new abstraction is a tax on attention. When something breaks at 2 a.m., the engineer on call is not just debugging the application; they are debugging the platform underneath it.
The second cost is organizational gravity. Once a team is running Kubernetes, it becomes very difficult to stop running Kubernetes. The knowledge is distributed across the team, the tooling is built around it, the CI/CD pipelines assume it. Migrating away requires a project of its own, and projects of their own require budget and political will. So the cluster persists, and the complexity persists with it, long after the original justification has faded.
The third cost — the one I find most insidious — is that it crowds out simpler thinking. When Kubernetes is the answer you already have, you stop asking whether the problem needed that answer in the first place.
The Alternatives Nobody Talks About at Conferences
Here is something I have noticed: the engineers who are most enthusiastic about Kubernetes are rarely the ones paying the operational bill. Conference talks celebrate the architecture. The person who gets paged when the ingress controller has a memory leak is usually not on stage.
Meanwhile, a quiet counter-movement has been growing in the margins. Teams are rediscovering the virtues of boring infrastructure. A single well-provisioned virtual machine, managed with Ansible or even a few shell scripts, can handle more traffic than most startups will ever generate. Render, Railway, and Fly.io have built entire businesses on the premise that most developers want to deploy an application, not manage a cluster. AWS App Runner and Google Cloud Run let you hand a container to a managed service and never think about nodes, taints, or tolerations again.
None of these options make for compelling conference talks. There is no certification for running a single VM well. But they have something Kubernetes often lacks: the property that when something goes wrong, the blast radius is small and the debugging surface is narrow.
Docker Compose, in particular, has been unfairly maligned as a toy for local development. I have seen this guide running production workloads for years without incident, on machines that cost less per month than a Kubernetes cluster's egress bill. The engineers maintaining those systems spend their time on the product. The Kubernetes teams I've observed spend a measurable fraction of their time on the platform.
The Honest Question About Your Actual Scale
I want to leave room for the genuine use cases, because they exist. Kubernetes complexity is worth it when you are running enough workloads that manual orchestration becomes its own source of chaos. It is worth it when you have the team size to absorb the operational burden without cannibalizing product work. It is worth it when the specific features — pod autoscaling, rolling deployments, sophisticated networking policies — solve problems you are actively experiencing rather than problems you are pre-emptively afraid of.
The honest question is whether your team is in that category. And the honest answer, for a large fraction of the organizations running Kubernetes today, is no.
There is a particular kind of engineering hubris that disguises itself as prudence. We call it scaling for the future, or building for growth, or not wanting to rewrite the infrastructure later. It sounds responsible. What it often is, in practice, is optimizing for a scale you may never reach while paying the costs of that optimization every single day at the scale you actually have.
The bicycle doesn't need the skyscraper. It needs a good lock and a dry place to sleep.
I think about that engineer and the forty-minute node affinity detour more than I probably should. Not because it was a disaster — it wasn't, the pod eventually scheduled, the day moved on — but because of what it represented: talent, time, and attention flowing into the container orchestration layer instead of into whatever the company was actually trying to build. Multiplied across a team, across a year, that is a significant tax. Multiplied across an industry, it is a staggering one.
Kubernetes is a remarkable piece of engineering. But remarkable tools, adopted without the honest question of whether the problem demands them, have a way of becoming the problem themselves. The teams I most admire right now are not the ones with the most sophisticated infrastructure. They are the ones who asked, clearly and without ego, what level of infrastructure complexity their actual situation warranted — and had the discipline to stop there.
The harder question isn't whether Kubernetes is powerful. It clearly is. The harder question is whether power, in your specific case, is what you needed.