There's a default in infrastructure decisions that goes unchallenged in most teams: when you don't know what you need, reach for Kubernetes. It's the safe choice because everyone uses it and the job market rewards knowing it. It is, for most teams I've worked with, the wrong choice.
The honest cost of Kubernetes
The marketing material says Kubernetes is "free and open source." The real cost looks like this:
- A control plane. Even on a managed service (EKS, GKE, AKS), you're paying $70–$150/month per cluster before you run a single workload. Self-hosted control planes need three nodes minimum for HA, more realistically five.
- Networking complexity. CNI plugins, service meshes, ingress controllers, NetworkPolicies. Each one is a learning curve and a failure mode.
- Storage. PersistentVolumes that don't follow your pods around. CSI drivers that need separate IAM. Backup tooling that's a whole product category.
- Observability. Prometheus, Grafana, Loki, Tempo. Or Datadog billing per pod. Either way, a separate stack.
- Upgrades. Three-month minor-version cadence. Deprecated APIs across versions. Cluster upgrades that touch every workload.
- The people. A Kubernetes-capable platform engineer in 2026 costs $180k–$260k. Most small teams cannot justify a dedicated one.
For a team of five engineers running a single application, this is overhead that competes directly with shipping features.
What works at small scale
| Scale | Right answer | Why |
|---|---|---|
| 1–3 services, single region | Docker Compose on a beefy VM | Boring, debuggable, one file describes the whole system |
| 4–10 services, modest traffic | Compose + a managed Postgres + Cloudflare in front | The VM is the abstraction; restart on failure, restore from snapshots |
| 10–30 services, multi-region | Nomad, Fly.io, or Railway | Schedules containers without the K8s tax |
| 30+ services, multiple teams | Kubernetes earns its weight | You actually have the operational surface to justify it |
The line where Kubernetes earns its weight is roughly "more teams than clusters can comfortably share". Before that, the platform is buying you nothing you can't get with simpler tools, and it's taking on-call rotation and incident debugging from you in exchange.
The argument for K8s, taken seriously
The strongest argument for adopting Kubernetes early is portability. A workload that runs on a managed K8s service runs on a self-hosted one with the same manifest, runs on a competing cloud's K8s, runs on your laptop in kind. That's real. But it's also worth less than it sounds, because:
- Migrations between clouds are dominated by data egress, not workload manifest rewrites.
- The differentiator of a small team's stack is not "we can switch clouds in a week," it's "we shipped the feature."
The second strongest argument is declarative configuration. K8s manifests describe desired state and the cluster reconciles. That's genuinely better than imperative scripts. But Docker Compose v3+ is also declarative; you don't need a control plane to get that property.
What I'd evaluate before picking K8s
Before adopting Kubernetes, run this checklist honestly:
- Do you have 10+ services owned by 3+ teams? If no, you don't need multi-tenant scheduling.
- Do you need horizontal autoscaling that beats "add a bigger VM"? If no, you don't need HPA.
- Are you doing canary or blue/green deploys today? If no, Kubernetes won't make you start.
- Do you have a dedicated platform engineer? If no, K8s ownership will fall on whoever is least afraid of YAML, and they will resent it.
If you answer no to three of these, your current stack is probably correct.
The contrarian default
A boring, opinionated default for a small team in 2026: one beefy VM per environment, Docker Compose for orchestration, managed Postgres, Cloudflare in front, and a backup script you actually test once a quarter. That stack will get you to a million dollars in revenue with less operational pain than any K8s setup.
When the simple stack starts to hurt, you'll know exactly what it isn't giving you, and you can adopt the next tool with intent. That's a much better position than adopting Kubernetes because the conference talks told you to.