I ditched Kubernetes last year. My infrastructure has been more stable since.
David Crawshaw posted “I am building a cloud” this week and the HN thread went crazy. Top comment said making Kubernetes good is “inherently impossible, a project in putting high quality lipstick on a pig.” It has 600+ upvotes. The developers in the replies are not shy about sharing their own k8s regrets.
One person said they fired their devops team, nuked the cluster, booted up a single VM with Debian, enabled the firewall, and used Kamal to deploy. It never been more stable and reliable. That’s the whole comment. No qualifications. No “but k8s is good for…” Just, it works better.
Here’s the thing. Kubernetes won the architectural war. It lost the practical one.
Why the Complexity Tax Is Killing Your App
Kubernetes is a coordination layer for distributed systems. It solves problems that appear when you have thousands of nodes, multiple teams deploying independently, and requirements for zero-downtime upgrades that actually need zero downtime. That is not most applications. That is not your application.
Crawshaw makes the point that most business applications need to handle hundreds to thousands of users. Google handles hardware failures so you don’t need cluster-level redundancy. Blue/green deploys with IP changes in DNS work fine. You don’t need a service mesh to route traffic between two containers on the same machine.
Here’s the uncomfortable math. One big VM versus a Kubernetes cluster. Same workload. The k8s setup costs 2-3x more. Incidents take 2-3x longer to debug because you have to untangle the k8s layer from your application layer. Your devops engineer is 30% less productive because they’re learning k8s quirks instead of shipping features.
That complexity tax hits small agencies hardest. You don’t have a platform team. You don’t have a dedicated SRE. You have one or two people who are supposed to ship features, manage infra, and keep the lights on. Every hour spent on k8s is an hour not spent on your product.
What You Actually Need Instead
Here’s the practical part.
Single big VM. Debian or whatever Linux flavor you know. Kamal for deployment. That’s it. Kamal does rolling deploys, health checks, and rollbacks. It handles everything most applications need.
The HN reply that resonated: “I ended up saying goodbye to those devops folks, nuked the cluster, booted up a single VM with debian, enabled the firewall and used Kamal to deploy. It never been more stable and reliable.”
That’s not a compromise. That’s the correct engineering decision for that workload.
You know what else it does? Makes incidents tractable. When something breaks on a single VM, you SSH in and look at logs. When something breaks in a k8s cluster, you check the deployment, the service, the ingress, the pod, the container, the network policy, the storage class. Twelve layers of indirection. At 3am. With your phone ringing.
Your Permission Slip
Here’s the take nobody in the industry will say out loud.
The k8s resume-driven-development is real. Devops engineers default to k8s because it looks good on a resume. Managers mandate it because it’s what big companies use. And small agencies end up paying the complexity tax for a scale problem they don’t have.
This week is your permission slip. Crawshaw is ex-Cloudflare. He’s not some hobbyist who doesn’t know what he’s doing. He built infrastructure for a company that handles millions of connections. And he’s saying, you probably don’t need k8s.
If you’ve been hesitating to simplify your infra because “everyone uses k8s,” stop. If you’ve been avoiding shipping because the deployment story feels too complex, Kamal it. If your app has 500 users and you’re running a 12-node k8s cluster, that’s a problem you created, not a problem you need to solve.
The real skill in engineering is knowing when to scale up complexity. Most of us never reach that point. The person who built the simple system and can sleep through the night beats the person who built the complex system and gets paged at 3am.
Sources: HN Discussion | Crawshaw Blog
