Why Are People Moving Away From Kubernetes?

Why Are People Moving Away From Kubernetes?

I built SIVARO in 2018. We design data infrastructure and production AI systems. For years, Kubernetes was our default answer. Container orchestration? Kubernetes. Microservices? Kubernetes. Scalable anything? Kubernetes.

Then something shifted. Starting around 2022, I watched teams — smart teams — walk away. Not because Kubernetes is bad. Because it's expensive in ways that aren't obvious.

Let me be direct: Kubernetes solves real problems. But it creates others. The question "what exactly is kubernetes used for?" has a clear answer — it's an open-source platform for automating deployment, scaling, and management of containerized applications (What is Kubernetes?). That's the textbook definition. The practical reality is messier.

This article isn't a hit piece. I've deployed Kubernetes in production across 40+ clusters. I've seen it save companies and bankrupt startups. What follows is what I've learned about why people are moving away from kubernetes — and when you should too.

The Real Cost Nobody Talks About

Most people think Kubernetes is free. Open source, right?

Wrong. Dead wrong.

The software is free. The operation is brutal.

I worked with a fintech startup in 2023. Their Kubernetes bill wasn't compute — it was people. They had 4 engineers whose entire job was keeping the cluster healthy. That's $800K/year in salary for what amounts to plumbing.

Google Cloud's overview shows Kubernetes managing containers across machine clusters. What they don't show you: the 3 AM pages when etcd goes corrupt. The certificate rotations. The network policy debugging that takes three weeks.

Here's a concrete example of the overhead:

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-config
data:
  # This is a simplified version — real configs are 10x longer
  logging.level: "debug"
  retry.count: "3"

That YAML file isn't hard. The 47 other YAML files you need to deploy alongside it? That's the problem.

Complexity Stacking

Kubernetes has a learning curve. That's fine — every powerful tool does.

The issue is complexity stacking. You start with Kubernetes. Then you need Helm. Then Istio. Then Prometheus. Then Grafana. Then an ingress controller. Then a service mesh. Then a custom operator. Then...

Each layer adds capability. Each layer also adds failure modes.

I watched a logistics company in 2022 spend 6 months migrating to Kubernetes. When they went live, their deployment time increased from 10 minutes to 45 minutes. Because every change now required updating 8 different config files, running CI/CD pipelines, and waiting for rolling updates.

The Kubernetes documentation describes Kubernetes as "a portable, extensible, open source platform for managing containerized workloads and services." The key word is "manage" — not "simplify."

When Simple Beats Scalable

Here's the contrarian take: most applications don't need Kubernetes.

Shocking, I know. But hear me out.

If you have 3 microservices and 2 developers, you don't need a container orchestrator. You need docker-compose and a cheap VPS. Kubernetes adds complexity that outweighs its benefits until you hit certain thresholds.

When is Kubernetes actually worth it?

I've found the break-even point around:

• 10+ microservices
• 5+ engineers
• Multi-team deployments
• Variable or unpredictable traffic patterns

Below those thresholds? You're paying for overhead you don't consume.

An edge computing company documented exactly this phenomenon. They ended up not using Kubernetes in their edge platform. Why? Because their workloads were distributed across thousands of edge nodes. Kubernetes assumed a datacenter model. Edge computing needs something fundamentally different.

The Abstraction Tax

Every layer of abstraction costs you something. Usually control.

Kubernetes abstracts away individual machines. That's great — until you need to understand why your database writes are slow. Now you're tracing through CNI plugins, CSI drivers, and kube-proxy to find a disk I/O issue that would take 30 minutes to debug on a bare-metal server.

I'm not saying abstractions are bad. I'm saying they have a cost.

Consider this: a simple Node.js app on a VM. You SSH in, run docker run -d myapp, done. Same app on Kubernetes:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        ports:
        - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 3000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-service
            port:
              number: 80

Is this better? For some teams, yes. For others, it's overhead.

Security Theater

Most people think Kubernetes is more secure. They're wrong.

Kubernetes has an enormous attack surface. API server, etcd, kubelet, container runtime, network policies, RBAC — every component is a potential entry point.

I've audited clusters where developers had cluster-admin access because "it was easier." I've seen secrets stored in ConfigMaps (base64 is not encryption, folks). I've watched teams spend weeks configuring network policies, only to realize they blocked their monitoring stack.

The practical use cases for Kubernetes include running cloud-native applications at scale. Security at scale is harder than security on a single machine. Much harder.

The Vendor Lock-In Paradox

Here's the irony: Kubernetes was supposed to prevent vendor lock-in.

"Write once, run anywhere" was the promise.

In practice? Every cloud provider's managed Kubernetes is slightly different. EKS has different defaults than GKE. AKS integrates with Azure AD in ways that don't transfer. Your Helm charts might work across clouds — but your monitoring, logging, and networking configs won't.

I've seen teams spend months migrating from one cloud's Kubernetes to another. The abstraction layer helped... marginally. Most of the work was rewriting cloud-specific integrations.

The real vendor lock-in isn't Kubernetes. It's the ecosystem around it. Once you're tied to a specific service mesh, monitoring stack, or CI/CD pipeline, switching costs are massive.

When Kubernetes Makes Sense

I'm not anti-Kubernetes. I'm anti-default-Kubernetes.

Here's where Kubernetes genuinely shines:

Multi-team organizations. When 5 teams need to deploy independently on shared infrastructure, Kubernetes provides useful isolation.

Variable workloads. If your traffic spikes 10x during certain hours, auto-scaling saves real money.

Complex microservices. When services need service discovery, load balancing, and health checking at scale, Kubernetes handles it.

Immutable infrastructure. Kubernetes makes it hard to SSH into a box and "fix" something — which is actually a feature.

I use Kubernetes at SIVARO for our AI inference clusters. We have 200+ GPUs across multiple regions. Kubernetes manages allocation, scaling, and failover. Doing this manually would be insane.

But we don't use Kubernetes for our internal tools. Those run on a single server with Docker and cron. Because the complexity isn't worth it.

Alternatives People Are Moving To

So where are people going?

Nomad by HashiCorp — Simpler than Kubernetes. Single binary. Supports containers and non-containerized workloads. Less opinionated. Fewer features, but for many teams that's a feature.

AWS ECS/Fargate — If you're already on AWS, ECS handles 80% of what Kubernetes does with 20% of the complexity. Serverless containers remove the node management entirely.

Google Cloud Run — Deploy containers, get a URL. Auto-scales to zero. No cluster management. The trade-off: less control, potential cold starts.

Docker Compose on Swarm — Old school. Stable. For teams that don't need advanced orchestration, this works fine.

Platform-as-a-service approaches (Heroku, Fly.io, Railway) — More expensive per unit of compute. But you pay with money instead of engineering time. For small teams, this trade-off makes sense.

Some teams are even moving back to virtual machines. Cloud providers now offer auto-scaling groups that handle many of the same problems Kubernetes solves — without the complexity. Packer + Terraform + an auto-scaling group can get you 90% of the way there.

The Real Question

Instead of asking "why are people moving away from kubernetes?", ask yourself: "do I have the problem Kubernetes solves?"

Most teams don't. They have a scaling problem they think Kubernetes will fix. But scaling is usually an application architecture issue, not an infrastructure one. Throwing Kubernetes at a badly designed monolith won't help.

I've seen startups burn 6 months on Kubernetes migrations. Then they realize their bottleneck wasn't deployment velocity. It was a slow database query. Or a missing feature. Or poor product-market fit.

Kubernetes handles symptom #47, not cause #1.

FAQ: Kubernetes Migration Decisions

Why are people moving away from Kubernetes?

Operational complexity and cost. Teams find that 80% of the value comes from containerization itself (Docker), not the orchestration layer. The additional complexity of Kubernetes often outweighs its benefits for teams below certain scale thresholds.

What exactly is kubernetes used for?

At its core, Kubernetes automates deployment, scaling, and management of containerized applications (What Is Kubernetes?). Practical use cases include running microservices architectures, managing batch processing workloads, and orchestrating containerized applications across multiple environments.

Is Kubernetes dying?

No. Kubernetes adoption continues to grow, especially among large enterprises. But the hype cycle is normalizing. Teams are making more deliberate decisions about when to use it — and when not to.

When should I absolutely use Kubernetes?

When you have 10+ microservices, multiple teams deploying independently, and variable workloads requiring automated scaling. Also useful for complex stateful applications requiring advanced scheduling (like Kafka, Cassandra, or Spark clusters).

What's the simplest alternative to Kubernetes for small teams?

AWS ECS Fargate or Google Cloud Run. Deploy containers without managing clusters. Higher per-unit cost, lower operational overhead.

Can I run Kubernetes without the complexity?

Managed Kubernetes (EKS, GKE, AKS) reduces some operational burden. But you still need to understand the underlying concepts to debug when things go wrong. There's no escape from complexity — only trade-offs.

Is Kubernetes secure by default?

No. Kubernetes requires extensive security configuration — RBAC, network policies, pod security policies, secrets management, and audit logging. Default configurations are often insecure.

How do I migrate away from Kubernetes?

Start by identifying what Kubernetes features you actually use. Many teams only use basic deployment and service discovery. Containerizing your applications and running them on simpler platforms (Nomad, ECS, or even VMs with Docker) is often straightforward. The real work is migrating monitoring, logging, and CI/CD integrations.

Conclusion

Why are people moving away from kubernetes? Because they're asking better questions.

They're asking: does this solve my actual problem? They're asking: is the complexity worth the capability? They're asking: what's the simplest thing that works?

Kubernetes is a powerful tool. But powerful tools require skilled operators. If you don't have those operators — or if your problem is simpler than Kubernetes assumes — you're paying for overhead you don't need.

The best infrastructure strategy is the one that lets you ship features. Not the one that looks good on a resume.

---

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.