Every few months I get the same question in workshops and team calls: "Should we move to Kubernetes?" And almost every time, the real answer isn't about Kubernetes at all — it's about what problem the team is actually trying to solve.
Kubernetes is an extraordinary piece of infrastructure. It's also one of the most over-adopted technologies in the industry right now. Teams reach for it because it signals maturity, because cloud providers make it easy to click "create cluster," and because everyone else seems to be doing it. That's the wrong reason to run Kubernetes.
What Kubernetes Actually Solves
Let's be precise. Kubernetes is a container orchestration platform. At its core, it solves a specific set of problems that become painful at a certain scale:
- Bin packing: Efficiently placing workloads across a cluster of nodes to maximize resource utilization
- Self-healing: Restarting failed containers, rescheduling from failed nodes, replacing instances that fail health checks
- Rolling deployments: Updating services with zero downtime at the platform level, with automatic rollback
- Service discovery & load balancing: Internal DNS and traffic routing across pods without manual configuration
- Secret & config management: Centralized management of environment configuration across many services
If your team doesn't feel the pain of these problems today, Kubernetes will add complexity without adding value. Simple as that.
The Real Cost Nobody Talks About
When I train teams on Kubernetes, I always start with the total cost of ownership — not in euros, but in engineering attention. A production Kubernetes cluster requires:
- Someone who understands networking (CNI plugins, ingress controllers, network policies)
- Someone who manages the control plane, upgrades, and API deprecations
- A team that understands RBAC, pod security, namespace isolation
- Logging and observability infrastructure that can handle ephemeral pods (hint: your existing VM-based approach probably won't)
- A mature CI/CD pipeline that builds, tests, and deploys container images
For a small engineering team, this can easily represent 20-30% of total engineering capacity, permanently. That's not nothing. That's a person.
A Framework for the Decision
I use a simple decision matrix in workshops. Score your team on each dimension from 1 to 3:
| Dimension | 1 — Not yet | 2 — Partially | 3 — Solid |
|---|---|---|---|
| Number of services | < 5 services | 5–15 services | 15+ services |
| Deployment frequency | Monthly or less | Weekly | Daily or more |
| Container maturity | No containers yet | Docker in dev/staging | Containers in production |
| Team K8s knowledge | Zero experience | One or two people | Broad team familiarity |
| Scaling patterns | Stable, predictable load | Occasional spikes | Frequent, variable load |
Score 5–8: Don't run Kubernetes. You'll spend months learning the platform instead of shipping features. A simple container setup (Docker Compose, single-node Docker Swarm, or even a few well-configured VMs) will serve you better.
Score 9–11: You're approaching the point where Kubernetes starts paying for itself. Consider a managed Kubernetes service for one non-critical workload as a learning project. Don't migrate production yet.
Score 12–15: You're likely feeling the pain Kubernetes solves. Evaluate seriously. Start with a managed service, invest in team training, and migrate incrementally — never as a big bang.
What to Use Instead
If Kubernetes isn't the right answer today, you still need to run containers reliably. Here are the patterns I recommend most often:
Docker Compose + a single VM or VPS
For small teams with fewer than 10 services, this is underrated. A well-configured Compose file with health checks, restart policies, and resource limits covers 80% of what most small teams need. Add a reverse proxy (Traefik or nginx), a monitoring stack (Prometheus + Grafana), and you have a production-grade setup with far less complexity.
AWS ECS / Google Cloud Run / Azure Container Apps
If you want managed orchestration without operating a control plane, these are excellent choices. Cloud Run in particular is ideal for stateless services — you pay per request, scale to zero, and never think about nodes. I've seen teams ship 20+ services on Cloud Run and never look back.
Nomad
HashiCorp Nomad is a simpler orchestrator that handles containers, VMs, and raw executables. If your team already uses Vault and Consul, Nomad is worth serious consideration. The learning curve is a fraction of Kubernetes.
When You Do Go Kubernetes
If the matrix points you toward Kubernetes, here's how to start well:
- Start with a managed service (GKE Autopilot, EKS, AKS). Never manage your own control plane unless you have a very specific reason.
- Use a GitOps workflow from day one (Argo CD or Flux). Kubectl-apply-in-terminal doesn't scale.
- Invest in observability before you need it — cluster metrics (kube-state-metrics), application traces, and centralized logging should be in place before you run production traffic.
- Namespace your workloads and define RBAC policies from the start. Retrofitting security controls is painful.
- Don't underestimate networking. Most Kubernetes incidents I've seen in practice are networking incidents.
Final Thought
Kubernetes is not a destination. It's a tool — a powerful one, with real costs and real benefits. The teams I've worked with that are happiest with Kubernetes are those who adopted it because they felt specific pain it could solve, not because it appeared on a roadmap or a job description.
Take the decision seriously. Be honest about your team's current capacity and expertise. And remember: running boring, reliable infrastructure is always better than running exciting, broken infrastructure.