Why Kubernetes Isn't a Scam: A Developer's Honest Take

You've seen the tweets. "Kubernetes is a scam." "Just use a VM." "We replaced our K8s cluster with a single bash script." And honestly? The first time you stare at a 200-line YAML file just to deploy a web server, you get it. The frustration is real.

But calling Kubernetes a scam misses something important. The criticism mistakes setup cost for ongoing cost. And as a developer who's lived through both sides — the painful bootstrapping AND the "everything just works" phase — I want to make the case for what happens after the hard part.

The Pain Is Real (Let's Not Pretend Otherwise)

Before defending Kubernetes, let's acknowledge what developers actually hate about it:

• YAML everywhere: Deployments, services, ingresses, configmaps, secrets, PVCs — the verbosity is overwhelming
• Steep learning curve: Pods, ReplicaSets, Deployments, StatefulSets, DaemonSets — concepts that take months to internalise
• Debugging is opaque: "CrashLoopBackOff" tells you something went wrong but not what. Tracing issues across pods, nodes, and networking layers is painful.
• Local development friction: Running a production-like K8s environment locally (Minikube, Kind, k3d) adds complexity that a simple docker-compose up doesn't
• Networking complexity: Service meshes, ingress controllers, network policies — layers upon layers

If your project is a single API with a database, Kubernetes IS overkill. Nobody's arguing otherwise. The question is: what happens when it's not a single API?

The Inflection Point: When Pain Becomes Leverage

Something shifts once your platform team (or you, wearing all the hats) has the foundation in place:

Namespace Templates = Instant Environments

Need a new service? Create a namespace from your template. It comes pre-configured with:

• Resource quotas and limits (no runaway pods eating the cluster)
• Network policies (your service can only talk to what it should)
• RBAC roles (the right people have the right access)
• Default monitoring and logging (Prometheus scraping, log forwarding — already configured)
• Ingress templates (expose an endpoint in 3 lines, not 30)

What used to be a week of provisioning tickets becomes a 30-second kubectl apply.

CI/CD Pipelines Become Universal

Once your deployment pipeline targets Kubernetes, every service uses the same flow:

• Build container → push to registry → update deployment manifest → rolling update
• The pipeline doesn't care if it's a Python API, a Go microservice, or a Java monolith
• Rollbacks are one command: kubectl rollout undo
• Canary deployments, blue-green, or progressive rollouts become configuration changes, not architectural decisions

Scaling Stops Being a Project

Before Kubernetes: "We need to handle 10x traffic for Black Friday" meant weeks of capacity planning, provisioning VMs, load balancer reconfiguration, and praying.

After Kubernetes: Horizontal Pod Autoscaler scales your service based on CPU, memory, or custom metrics. Cluster Autoscaler adds nodes when pods can't be scheduled. Your service handles the spike. You sleep through it.

The Developer Experience After Setup

Here's what daily development looks like once the platform is mature:

• New microservice: Clone template repo → customise → push → pipeline deploys to dev namespace → 15 minutes from idea to running endpoint
• Environment parity: Dev, staging, and production use the same manifests with different values. "Works on my machine" becomes "works in every environment"
• Observability built in: Every service automatically gets metrics (Prometheus), logs (Loki/ELK), and traces (Jaeger/Tempo) without writing any instrumentation code
• Service discovery: Need to call another team's service? It's at service-name.namespace.svc.cluster.local. No DNS tickets, no load balancer configuration.
• Secrets management: External Secrets Operator syncs from Vault or AWS Secrets Manager. Developers reference secrets by name, never handle raw credentials.

What "Just Use a VM" Actually Means at Scale

The VM alternative sounds simple until you scale:

• 20 services × 3 environments = 60 VMs to provision, patch, and maintain
• Each service has its own deployment mechanism (rsync? Ansible? Custom scripts?)
• Monitoring requires per-VM agent installation and configuration
• Scaling means provisioning new VMs, updating load balancers, copying configurations
• Rollbacks mean... hoping you have a recent snapshot?
• Resource utilisation: each VM reserves full CPU/memory even when idle. With Kubernetes, pods share node resources efficiently.

At 5 services, VMs are simpler. At 50, they're an operational nightmare. Kubernetes standardises the complexity so you don't reinvent it for every service.

The Real Problem: Platform Engineering

Most "Kubernetes is a scam" complaints are actually "we tried to do Kubernetes without a platform team." And yes — expecting every developer to understand Kubernetes internals is a recipe for frustration.

The model that works:

• Platform team: Owns the cluster, builds the templates, maintains the pipelines, provides golden paths
• Application developers: Use the platform. Push code. Get deployed services. Don't need to know what a kubelet is.

This is exactly what platform engineering is about: abstracting infrastructure complexity into a self-service platform that developers can use without becoming Kubernetes experts.

When Kubernetes Genuinely Isn't the Answer

Intellectual honesty matters. Don't use Kubernetes when:

• You have fewer than 5 services and no plans to grow
• Your team is 3 developers and there's nobody to maintain the platform
• Your workload is a single monolithic application with predictable, stable traffic
• You're a startup validating product-market fit — optimise for speed, not scalability
• Managed services (Lambda, Cloud Run, App Service) genuinely cover your use case

Kubernetes solves the problem of running many services reliably at scale. If that's not your problem, it's not your solution.

The Bottom Line

Kubernetes isn't about reducing complexity — it's about standardising it so you can move at scale. The initial setup is genuinely painful. But once your cluster, templates, and pipelines are in place, new services become plug-and-play. That's not a scam. That's leverage.