A startup has three services, five developers, and no dedicated infrastructure team. Six months later it has Helm charts, an ingress controller, Argo CD, cert-manager, monitoring, secrets tooling, and a backlog of cluster upgrades.
The application still has three services.
Kubernetes isn't the mistake. Adopting an operating model you cannot afford is.
The question nobody asks before choosing Kubernetes
The interesting question is not, "Can Kubernetes run our application?" Of course it can. The question is, "Which problem will Kubernetes remove that we cannot solve more simply?"
Good reasons exist: multiple independently deployed workloads, strong workload isolation requirements, a platform team supporting many product teams, portability constraints, or operational needs that justify declarative orchestration. "Everyone uses Kubernetes" is not one of them.
The bill is not just compute. Someone owns cluster upgrades, node failures, networking, certificates, storage, access controls, CI/CD integration, and recovery. Managed Kubernetes removes some responsibility, not all of it.
Compare operating models, not just technologies
| Question | Simpler managed platform or VMs | Kubernetes |
|---|---|---|
| Who operates the orchestration layer? | Mostly the provider, or a smaller internal footprint | Your team still owns workloads and many cluster components |
| How do we deploy? | Platform deployment or a small pipeline | Kubernetes manifests, releases, and policy |
| How do we recover? | Provider tooling plus application backups | Cluster reconstruction plus application data recovery |
| Can we hire for it? | Usually easier to support with a small team | Requires specific operational knowledge |
This is not an argument that VMs are inherently safer or cheaper. Poorly operated VMs can be worse. It is an argument for comparing the total operating model.
My test before recommending Kubernetes
- List the failure modes the product must survive, not the tools the team wants to learn.
- Estimate service count, deployment frequency, scaling pattern, compliance requirements, and team capacity over the next year.
- Compare a managed application platform, managed containers, and Kubernetes against those requirements.
- Include engineer-hours, on-call responsibility, upgrades, and incident recovery in the cost.
- Write down the exact conditions that would trigger a move to Kubernetes later.
A useful outcome is sometimes "not yet." That is still an architecture decision, not a failure of ambition.
When Kubernetes is absolutely worth it
If several teams deploy independently, you need consistent scheduling and policy boundaries, and someone owns the platform as a product, Kubernetes can be a very good choice. The goal is not to avoid complexity at all costs. It is to pay for complexity only when it buys something measurable.
If you're already on Kubernetes, the right question may be whether the platform has a clear owner and delivers the value you expected—not whether to rebuild everything tomorrow.
Discussion: What was the first concrete requirement that made Kubernetes worthwhile for your team?
If you're deciding whether to adopt, simplify, or stabilize a cluster, explore Kubernetes consulting or request a free discovery call.