The “Kubernetes Is a Scam” Argument
Every few months, someone posts a viral take calling Kubernetes a scam. The argument is always some variation of:
- “It is too complex for what it does”
- “You could just use a VPS and Docker Compose”
- “YAML hell is not engineering”
- “Most companies do not need it”
And honestly? The first point is not wrong. The initial setup is painful. No argument there. The learning curve is steep, the YAML is verbose, the networking model requires a mental shift, and your first cluster will teach you more about failure modes than you ever wanted to know.
But calling it a scam because the first week is hard is like calling a factory floor a scam because it took months to build. The value is not in the construction — it is in what happens after.
What Actually Happens After Setup
Once your cluster, namespace templates, and CI/CD pipelines are in place, something powerful happens:
You stop “creating infrastructure” every time you build an app.
New APIs and services become:
- Plug into existing pipelines — same CI/CD, same monitoring, same logging, same security policies
- Deploy in minutes —
kubectl applyor a Git push, and it is running in production - Auto-scale without re-architecting — HPA, VPA, KEDA handle traffic spikes without you touching a single config
- Roll back in seconds — bad deployment? One command reverts to the previous version
What used to take days of provisioning, configuring load balancers, setting up monitoring, and coordinating with ops teams becomes repeatable, predictable, and fast.
Kubernetes Is Not About Reducing Complexity
This is the key insight that most critics miss.
Kubernetes does not make things simpler. It standardizes complexity so that the same patterns apply everywhere:
| Without Kubernetes | With Kubernetes |
|---|---|
| Each app has its own deployment process | One deployment model for all apps |
| Scaling requires re-architecture | Scaling is a config change |
| New environments take days to provision | New namespaces take seconds |
| Monitoring is different per service | Prometheus/Grafana for everything |
| Secret management varies | Kubernetes Secrets + external-secrets |
| Network policies are ad-hoc | NetworkPolicies are declarative |
| Load balancing is configured per service | Ingress controllers handle everything |
The complexity does not disappear. It gets absorbed once into the platform, and then every team that builds on top of it benefits without paying the cost again.
The Leverage Effect
Here is what leverage looks like in practice. I have seen this pattern across dozens of enterprise engagements:
Month 1-3: Pain
- Cluster setup, networking, storage classes, RBAC
- CI/CD pipeline integration
- Monitoring and logging stack (Prometheus, Grafana, Loki)
- Namespace templates and resource quotas
- Security policies and pod security standards
This phase is genuinely hard. This is where the “scam” criticism comes from — people who stopped here and concluded the whole thing is not worth it.
Month 4-6: Normalization
- First few applications migrated
- Team starts understanding the deployment model
- Incident response improves because everything uses the same patterns
- Developer onboarding gets faster — “here is a namespace, here is the pipeline template, deploy”
Month 6+: Leverage
- New services go from idea to production in hours, not weeks
- Platform team handles infrastructure once, application teams move independently
- Scaling decisions are config changes, not architecture redesigns
- Multi-environment (dev/staging/prod) is trivial — same manifests, different values
- Compliance and security are enforced by the platform, not by individual teams
This is the leverage. The upfront investment creates a force multiplier that compounds with every service you add.
When Kubernetes IS the Wrong Choice
I am not saying Kubernetes is right for everyone. It is genuinely overkill if:
- You run fewer than 5 services — Docker Compose on a single VM is simpler and cheaper
- Your team is under 5 engineers — the operational overhead may not justify the benefits
- Your traffic is predictable and low — you do not need auto-scaling if your load never changes
- You are a solo developer — a managed PaaS (Railway, Fly.io, Render) gives you 80% of the benefits at 10% of the complexity
The break-even point is roughly: if you have 10+ services, multiple teams, and variable traffic, Kubernetes starts paying for itself. Below that threshold, simpler tools are the right call.
The Real Scam: Not Having a Platform
Here is what I actually see as a scam in 2026: teams running 50+ microservices without a platform.
Each service deployed differently. Each team managing their own infrastructure. No standardized monitoring. No consistent security policies. No reproducible environments. Every new hire spending weeks understanding how this specific service gets deployed.
That is the real cost. Not Kubernetes’s complexity — but the accumulated complexity of doing everything ad-hoc across dozens of services and teams.
Kubernetes gives you a vocabulary for infrastructure. Like any language, it takes time to learn. But once your team speaks it, every infrastructure conversation becomes faster, every deployment becomes more predictable, and every new service benefits from everything you have already built.
What I Tell CTOs
When enterprise leaders ask me whether they should adopt Kubernetes, I ask three questions:
- How many services do you run? (If under 10, probably not worth it)
- How many teams deploy independently? (If more than 3, you need standardization)
- Are you spending more time on infrastructure than features? (If yes, you need a platform)
If the answer to questions 2 and 3 is yes, the question is not whether to adopt Kubernetes — it is how fast you can build the platform layer on top of it.
The first setup is painful. That is not a bug — it is the cost of building leverage. And leverage, by definition, is worth more than what you put in.
That is not a scam. That is engineering.
Related Resources:
