Most production apps don't need Kubernetes and never did. The cleanest proof is how quickly things improve when teams stop using it.
You nuke the cluster, let go of the devops team, bring up a single Debian VM with the firewall on, and deploy the app with Docker. Uptime goes up, costs drop, and the on-call burden that had been eating into people's weekends quietly disappears.
This is supposed to be the controversial take in 2026. It isn't. The math has always been on the side of the single VM for most apps. A serious cloud VM will run the vast majority of web apps with room to spare if you size it right, the provider handles hardware failures, and for an upgrade you spin up a second VM next to the first, provision it, and flip the DNS record - without any of the load balancers, control planes, ingress controllers, or network meshes that come with running a cluster.
The part nobody wants to admit is why we keep building Kubernetes for apps that don't need it.
The math, and why it keeps getting ignored
Before anyone touches a YAML file, there's a number worth looking at. A Hetzner CX23 - a €4/month shared cloud VM - does about 3,900 IOPS. A dedicated Hetzner box at AX41-NVMe levels does 325,000 read IOPS and over a gigabyte a second of throughput. A €13 Netcup VPS hits around 100k IOPS total. Your laptop is probably doing 500,000 right now.
Now compare that to the default on big cloud. AWS sells you a VM at 3,000 IOPS. Beyond that you pay per IOP, you pay for bandwidth, you pay for NAT gateway time and load balancer hours and managed database uptime and for the kind of storage abstraction that was solved at the hardware layer fifteen years ago. This isn't a design flaw, it's a pricing strategy. As David Crawshaw puts it in the post that kicked the whole argument off:
Traditional Cloud 1.0 companies sell you a VM with a default of 3000 IOPS, while your laptop has 500k. Getting the defaults right (and the cost of those defaults right) requires careful thinking through the stack.
Most apps never come close to saturating a single beefy VM. Six-figure MAU with peak concurrent staying in the low thousands isn't really a scale problem; it's a deployment problem dressed up as one.
There's a story I keep coming back to from the discussion around Crawshaw's post - an insurance company burning mid-six-figures a month on cloud spend to serve 100K MAU with peak concurrent never crossing 5,000 users, and a 20-person team whose entire job was managing their Kubernetes setup. The company had forty years of usage data telling them they'd never hit a bigger spike than that. They built the space shuttle anyway, then hired a crew to fly it.
If the math favors a single VM, why does every serious engineering org still reach for Kubernetes first?
The technical answer is that Kubernetes solves a real problem. Running 40 services across 14 machines with shared auth, logging, monitoring, and deployment patterns is genuinely hard, and Kubernetes is one of the better tools we have for it. A small team can maintain a sane cluster with a generated YAML pipeline and a few CI hooks. I've seen that work. The pro-k8s case isn't imaginary.
But almost no app is that app, and the less flattering answer explains why we keep pretending it is. Kubernetes keeps winning because it's the safest résumé decision, the easiest vendor sale, and the cleanest way for management to avoid making a real call. Nobody gets fired for choosing it. A devops engineer with Kubernetes on their CV has better odds at the next job than one whose résumé reads "I ran production on a single Debian box with Kamal." The incentives aren't secretly aligned with the complexity - they're openly aligned with it.
Vendors know this too. Cloud sales teams show up with slide decks about auto-scaling and six-nines availability and the kind of compliance language that looks serious on a quarterly review - because those are the words management trusts more than its own staff. When a sysadmin with twenty years of production experience says "you don't need this," and a well-dressed rep from a hyperscaler shows up with "here's what your competitors are using," the rep wins most of the time. There's a comment buried deep in the thread around Crawshaw's post that nails it:
Management very often trusts the sales and marketing departments of big vendors more than their own staff.
That one line explains more modern infrastructure spending than any architecture diagram ever will. A huge share of every production Kubernetes cluster I've seen in the wild is just that trust, compounded over years.
When Kubernetes actually makes sense
I'm not a "single VM forever" person. I run services in production, and I know the shape of the problems that chew through a single-box setup. If your traffic is genuinely lumpy and you need horizontal scaling that kicks in within seconds, a single VM won't cut it. If you're a platform team serving hundreds of internal developers who each need self-service, it won't cut it either. And if you're an open-source LLM inference company onboarding a new GPU vendor every month and you need a portable, standardized control plane, a single VM is a bad joke.
There's a take in the same thread from someone running an inference company on K8s that's worth quoting directly, because it's the cleanest version of the pro-Kubernetes case I've read in a while:
K8s isn't even hard! My team of three manages everything on K8s and we spend ~0 minutes per week on it. Write a script to generate some YAML files, stick it in a CI pipeline, and it's basically fire-and-forget.
That's a real case, not a résumé-driven one. If your team is that clear about what it's buying, Kubernetes is fine.
The problem is that most teams don't buy Kubernetes that way. They buy it because the platform team decided a managed k8s namespace is the only supported deployment model, or because someone on the team read a blog post about "future growth," or because the cloud bill lives on opex and nobody has to think hard about it for another quarter. And somewhere in all of that, everyone's quietly afraid of being the team that didn't.
That - not the YAML, not etcd, not the ingress controllers, but the invisible gravity it puts on how a team is shaped - is the real cost of Kubernetes. It's a social technology wearing a technical disguise. The complexity it introduces into an org lives less in the config files and more in the headcount it justifies and the conversations it forecloses.
Kubernetes isn't the problem. It's a tool that works beautifully for the two or three percent of teams that genuinely need it, and sits like a radioactive rock in the other ninety-seven. The move that keeps showing up in the good setups I've seen goes like this: buy or rent cheap dedicated hardware, carve it into one or two VMs, run services with Docker or a small orchestrator, let the database be managed and the rest be yours. It isn't web-scale, and it doesn't need to be. For most apps, web-scale is marketing material.
The cloud in 2026 still wins on convenience for the first six months and still loses on cost after two years. Kubernetes is still a great tool that most people are using for the wrong job - and the longer they use it for that wrong job, the harder it gets to admit.
Next time someone on your team tells you a single VM is too primitive for your app, ask which part is actually primitive - the setup, or the reasoning behind skipping it.
