Five years ago, if you asked me how a growing startup should deploy their application, I would have said “Kubernetes” without blinking. Everyone was doing it. It was the future. You’d be irresponsible not to.
I was wrong.
Not completely. Kubernetes is genuinely brilliant at what it does. But I was recommending it to teams that had no business running it — three-person startups, internal tools at mid-sized companies, side projects that would never see more than a thousand users. And I wasn’t alone. The entire industry spent half a decade telling every developer they needed Kubernetes, the way we once told everyone they needed microservices, MongoDB, and a standing desk.
The Promise That Sold Kubernetes
Let me be fair. Kubernetes earned its reputation honestly. It solves real problems.
Before containers, deploying software meant configuring servers by hand — installing dependencies, setting up reverse proxies, praying the staging environment matched production. Docker fixed the packaging problem. But Docker alone didn’t solve the orchestration problem. How do you make sure containers restart when they crash? How do you roll out updates without downtime? How do you scale from three instances to thirty when traffic spikes?
Kubernetes answered all of that. It gave you declarative configuration — you describe the desired state of your system, and Kubernetes continuously works to make reality match. Auto-healing, auto-scaling, rolling updates, service discovery, secret management. It turned infrastructure into code. For organizations with dozens of services and hundreds of engineers, it was transformative.
And that’s where the trouble started. Because the same features that make Kubernetes a miracle at scale make it a burden at small scale.
What Nobody Tells You in the Tutorial
Here’s the thing about Kubernetes tutorials: they’re almost always written by people who already have it running in production. They skip the setup. They assume you have a cluster. They show you a Deployment YAML, a Service, an Ingress, and it all looks so clean — maybe fifty lines of YAML total.
What they don’t show you is everything else.
The Hidden Stack
To run a single web application on Kubernetes in any kind of production-ready way, you also need: a container registry (because your cluster needs to pull images from somewhere), a CI/CD pipeline to build and push those images (and if you’re doing it right, GitHub Actions makes this part manageable), an ingress controller to route traffic, cert-manager for TLS certificates, some form of persistent storage if your app needs to remember anything, and a monitoring stack so you know when things go wrong.
That’s the minimum viable cluster. Each piece has its own configuration, its own update cycle, its own failure modes. You haven’t even started on security policies, network policies, or resource limits yet.
I’ve spent entire afternoons debugging why a pod wouldn’t start, only to discover it was a missing ConfigMap that another team had renamed three sprints ago. These are not problems your users care about. These are problems Kubernetes invented so it could solve them.
The Monitoring Tax
Once your application is running on Kubernetes, you need to know what’s happening inside it. That means Prometheus. Maybe Grafana. Maybe Loki for logs. Setting up Prometheus and Node Exporter for basic Linux server monitoring is one thing. Configuring it to scrape Kubernetes metrics — pods, nodes, deployments, horizontal pod autoscalers — is another universe entirely.
I have watched teams spend more time maintaining their monitoring stack than building features. When your observability infrastructure needs its own on-call rotation, something has gone wrong.
The YAML Explosion
Kubernetes configuration is YAML. Lots of YAML. A modest application might need a Deployment, a Service, a ConfigMap, a Secret, an Ingress, a ServiceAccount, and a HorizontalPodAutoscaler. That’s seven files just to run. Multiply by the number of environments — dev, staging, production — and multiply again by the number of microservices.
Eventually someone introduces Helm to manage the YAML. Then someone introduces Kustomize because Helm templates became unreadable. Then someone writes a script that generates the Kustomize overlays. At some point you realize you’ve built an entire metaprogramming system just to produce configuration for a configuration system.
YAML was supposed to be human-readable. What you actually end up with is human-readable in the same way tax forms are human-readable — technically correct, practically impenetrable.
When Kubernetes Is Actually Worth It
I don’t want to sound like I’m anti-Kubernetes. I’m not. If your organization meets several of these conditions, Kubernetes is probably the right call:
You have more than three distinct services that need to communicate. You have a dedicated platform or infrastructure team — not just one person who also writes backend code. Your traffic patterns are unpredictable enough that auto-scaling saves real money. You need zero-downtime deployments across multiple availability zones. You’re already running more than ten servers.
If you checked fewer than three of those, keep reading.
What I Recommend Instead
For most small teams, the answer is simpler than you think. And it’s been sitting there the whole time.
Option 1: One Big Server (Or Three)
Rent a VPS — a good one, not the five-dollar tier. Put your application on it. Put your database on it, or on a managed database service. If you need redundancy, rent two more in different regions. Use Nginx as a reverse proxy, configure TLS with Let’s Encrypt, and set up a simple health check.
This is what most web applications actually need. A single $80/month VPS can handle tens of thousands of concurrent users if your application isn’t doing something computationally expensive on every request. I’ve run production services this way for years. They rarely go down. When they do, the fix is usually one SSH command, not a three-hour debugging session through five layers of abstraction.
The objection people raise is “but what about scaling?” My answer: cross that bridge when you’re actually approaching it. Most applications die from lack of users, not from too many of them. Optimize for the problems you actually have.
Option 2: Managed Container Services
If you really want containers — and containers are genuinely useful, I’m not arguing against those — use a managed service. AWS ECS Fargate, Google Cloud Run, Azure Container Apps. These give you the packaging benefits of Docker without the orchestration overhead of Kubernetes. You define a container, you specify how much CPU and memory it needs, and the cloud provider runs it.
Yes, it costs more per compute hour than raw EC2 instances running Kubernetes. But compute is cheap compared to engineering time. The hours your team spends maintaining a Kubernetes cluster — even a managed one like EKS or GKE — add up faster than you think.
Option 3: PaaS (Yes, Still)
Platform-as-a-Service offerings like Railway, Render, and Fly.io have quietly become excellent. They take the container, handle the orchestration, and give you a URL. The Heroku model never died; it just evolved. For early-stage products — the kind where speed of iteration matters more than infrastructure flexibility — a PaaS is often the right choice.
The trade-off is vendor lock-in and less control. But when you’re a three-person team trying to find product-market fit, those are tomorrow’s problems. Today’s problem is shipping. A PaaS lets you ship.
The Real Cost Nobody Calculates
I’ve seen companies burn through months of engineering time building “the right way” — microservices, Kubernetes, service mesh, the whole nine yards — before they had a single paying customer. It’s the infrastructure equivalent of buying a Formula 1 car to drive to the grocery store.
There’s a parallel here to what’s happening in enterprise IT right now. Tesco is ditching VMware after Broadcom’s price hike, and 40,000 other companies might follow — not because virtualization is bad, but because the cost of complexity exceeded the benefit. The same calculus applies to your deployment stack. Complexity has a price. You only pay it when the return justifies it.
The Verdict
Kubernetes is an extraordinary piece of engineering. It solves hard problems at a scale most of us will never reach. But the industry has spent years treating it as the default answer, and that was a mistake.
If you’re a small team — say fewer than ten engineers, fewer than five services, fewer than a million users — you probably don’t need Kubernetes. You need a reliable server, a reverse proxy, and a deployment script. Maybe Docker Compose. Maybe a managed container service. Maybe just systemd and a binary.
Start with the simplest thing that works. When that breaks, fix it. When you outgrow it — genuinely outgrow it, not just worry that you might — then reach for Kubernetes. By then, you’ll understand your own problems well enough to know whether Kubernetes actually solves them.
The best infrastructure decision I ever made wasn’t adopting Kubernetes. It was admitting I didn’t need it yet.
Rating: 9/10 for enterprises, 4/10 for small teams, and the industry still hasn’t learned the difference.