23 Oct 2026 · 2 min read · Ravi Sanchala
Do you actually need Kubernetes?
Kubernetes is powerful and widely used. For many small teams it's also the most expensive way to run a handful of services. Here's how I decide.
I get asked this a lot, usually by founders who’ve heard that “serious companies run on Kubernetes”.
Many do. Kubernetes is a genuinely great tool for the problems it was built for. The question isn’t whether it’s good. It’s whether you have those problems yet.
What Kubernetes gives you
- Scheduling containers across many machines
- Restarting failed containers automatically
- Rolling updates and scaling up and down
- A standard way to describe services, networking and config
- A huge ecosystem of tools built around it
What it costs you
The cost isn’t mainly the cloud bill. It’s people and attention.
- Learning curve. Someone needs to understand pods, deployments, services, ingress, persistent volumes, RBAC and network policies well enough to debug them at 2 a.m.
- Operations. Even managed Kubernetes needs upgrades, add-ons, certificate management, monitoring and security patching for the cluster itself.
- Indirection. When something breaks, there are more layers between you and the cause.
- Tooling sprawl. Helm charts, operators, service meshes, GitOps controllers. Each solves a real problem and adds something else to maintain.
For a team of five running two services, that’s often more work than the product itself.
My rule of thumb
Kubernetes starts to make sense when most of these are true:
- You run five or more independent services that deploy separately
- You need to scale parts up and down with traffic, often
- You have, or are hiring, people whose job includes running the platform
- Your workloads already run in containers
- You need consistency across many environments or teams
If only one or two are true, there’s usually a simpler option that does the job.
What I use instead, for most teams
Virtual machines with one job each, configured as code. A gateway, an app server, a database and a monitoring server, built with OpenTofu and configured with Ansible. Apps run as systemd services. It’s easy to understand, easy to debug and cheap to run. I’ve run production platforms this way that handle real traffic with good uptime.
Docker Compose on a server when you have a few containers that belong together. It’s not fashionable, and it works.
A managed container service from your cloud provider when you want containers without running a cluster.
Managed databases wherever possible. Running your database inside Kubernetes is one of the hardest ways to run a database.
Signs you’ve outgrown the simple setup
- Deploying one service regularly forces you to redeploy others
- You’re writing your own scripts to place containers on servers
- Traffic swings enough that fixed-size servers waste money most of the day
- Several teams are stepping on each other’s deployments
When those show up, Kubernetes stops being overhead and starts being leverage. I’m happy to help with that migration when the time comes.
The real question
Don’t ask “should we use Kubernetes?” Ask “what problem are we trying to solve, and what’s the simplest thing that solves it?”
Sometimes the answer is Kubernetes. Often, for now, it’s four boring servers and a good deploy script. Choose the boring option until it stops being enough, and you’ll know when that happens because the problems will tell you.