← Blog
Kubernetes Is Not the Answer for Everything

Kubernetes Is Not the Answer for Everything

kubernetesdevopsdockerarchitectureopinion

I’ve run production workloads on Kubernetes at a major fintech company. hundreds of services, dozens of teams, real scale. I’ve also run a homelab on a Mac Mini with Docker Compose, deploying side projects to a single VPS with docker compose up -d. Both are valid. Both work. And picking the wrong one for your situation will cost you.

This isn’t an anti-Kubernetes post. K8s is one of the most impressive pieces of infrastructure software ever built. But somewhere along the way, the industry decided it was the default. the thing you reach for first. and that’s where things go sideways.

The Kubernetes Tax

Every technology has a cost. Kubernetes has a big one:

  • Cognitive overhead. Pods, Deployments, Services, Ingresses, ConfigMaps, Secrets, PVCs, HPA, CRDs. the abstraction surface is enormous.
  • Operational complexity. Cluster upgrades, node management, networking plugins, RBAC policies, observability stacks. Even managed K8s (EKS, GKE) leaves plenty of sharp edges.
  • Time-to-first-deploy. Getting a single app running on K8s for the first time takes hours. Getting it running on Docker Compose takes minutes.
  • Hiring. Now you need people who understand K8s. That’s a real constraint for small teams.

None of this matters if you actually need what K8s provides. All of it matters if you don’t.

When Kubernetes Is the Right Call

K8s earns its complexity when you have genuine scale problems:

  • Multiple teams deploying independently. K8s namespaces, RBAC, and GitOps workflows let teams ship without stepping on each other.
  • Dozens or hundreds of microservices. Service discovery, load balancing, rolling deployments, health checks. K8s handles this natively.
  • Auto-scaling requirements. HPA and cluster autoscalers react to traffic spikes without human intervention.
  • Multi-cloud or hybrid deployments. K8s gives you a consistent abstraction across providers.
  • Compliance and governance. Network policies, pod security standards, admission controllers. real security at the infrastructure level.

At a major fintech company, K8s made sense. Hundreds of engineers, hundreds of services, strict compliance requirements, traffic that could spike dramatically. The Kubernetes tax was worth paying because the problems it solved were real.

When It’s Not

Here’s where I see teams reach for K8s and regret it:

  • Solo dev or small team (< 5 engineers). You’ll spend more time on infrastructure than product. A PaaS or a single server with Docker Compose will get you further, faster.
  • One or two services. If your entire backend is a single API and a database, K8s is a yacht for crossing a puddle.
  • Predictable, low traffic. If you know your app serves 1,000 requests/hour, you don’t need auto-scaling. You need a $20/month VPS.
  • Side projects and MVPs. Ship it. Validate it. Worry about scale when you have scale.
  • Homelab and self-hosting. I run ~15 services on my homelab with Docker Compose. It works perfectly. No etcd, no kubelet, no YAML manifests.

The Decision Tree

Here’s how I think about it:

flowchart TD
    A["How many services?"] -->|"1-3"| B["Docker Compose or PaaS"]
    A -->|"4-10"| C["How many engineers?"]
    A -->|"10+"| D["Kubernetes likely makes sense"]

    C -->|"1-3"| E["Docker Compose + CI/CD"]
    C -->|"4+"| F["Need auto-scaling?"]

    F -->|"No"| G["Docker Compose or Nomad"]
    F -->|"Yes"| H["Kubernetes or managed PaaS"]

    D --> I["Need multi-team isolation?"]
    I -->|"Yes"| J["Kubernetes"]
    I -->|"No"| K["Consider Nomad or managed PaaS"]

The point isn’t that there’s a magic number. It’s that Kubernetes should be a deliberate choice, not a default one.

The Alternatives Are Good Now

The tooling landscape has matured dramatically:

  • Docker Compose. Perfect for single-server deployments. Add a reverse proxy (Traefik, Caddy) and you’ve got TLS, routing, and zero-downtime deploys.
  • Fly.io / Railway / Render. PaaS options that handle scaling without you managing infrastructure.
  • HashiCorp Nomad. Simpler orchestrator that handles 80% of what K8s does with 20% of the complexity.
  • Kamal (from Basecamp). Deploy Docker containers to bare servers. No orchestrator needed.
  • A single server. Seriously. A well-configured VPS with Docker, Caddy, and a deploy script handles more traffic than most apps will ever see.

A Docker Compose Setup That Covers Most Cases

For context, here’s roughly what my homelab looks like:

# docker-compose.yml
services:
  app:
    image: myapp:latest
    restart: unless-stopped
    environment:
      - DATABASE_URL=postgres://db:5432/app
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"

  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data

  traefik:
    image: traefik:v3
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  pgdata:

That’s it. Add more services as you need them. When this stops working. when you need multi-node scheduling, auto-scaling, or team isolation. that’s when you graduate to K8s. Not before.

The Real Problem: Résumé-Driven Development

Let’s be honest about why Kubernetes gets adopted at companies that don’t need it:

  1. “Everyone else is using it.” Survivorship bias. You hear about companies using K8s because they blog about it. You don’t hear about the thousands of successful companies running on Heroku or a single EC2 instance.
  2. Résumé-driven development. Engineers want K8s on their résumé. That’s human nature, but it’s a bad reason to choose infrastructure.
  3. Vendor push. Cloud providers make more money when you run K8s (more compute, more managed services, more lock-in).
  4. Premature scaling. “We’ll need it eventually” is the most expensive sentence in engineering. Solve today’s problems today.

My Rule of Thumb

Start with the simplest thing that works. Graduate to more complexity only when the pain of simplicity exceeds the cost of complexity.

For most applications, that means:

  • Day 1: Single server, Docker Compose, Caddy
  • Day 100: Maybe add a second server, load balancer
  • Day 1,000: If you’re here and growing fast, now consider K8s

The boring answer is usually the right one. Kubernetes is incredible technology. Use it when you need it. Don’t use it to feel like a real engineer.

You already are one.