Docker vs Kubernetes — When You Need K8s (and When You Absolutely Don't)

Docker and Kubernetes are often compared as if they compete. They don't. Docker packages an app into a container. Kubernetes orchestrates thousands of those containers across a cluster. The real question is not "Docker or Kubernetes?" It's "how much orchestration do I actually need?"

Layers of the stack

Layer	Tool	Problem it solves
Container runtime	Docker, containerd, Podman	Run one container in isolation
Local multi-container	Docker Compose	Run 5-15 containers on ONE machine
Single-machine orchestration	Docker Swarm (deprecated-ish), Nomad	Restart, scale, service discovery on 1-few machines
Cluster orchestration	Kubernetes	Scheduling, self-healing, service mesh across 10+ machines
Managed platform	Fly.io, Railway, Render, App Runner	Someone else's k8s + Docker, hidden

When Docker (alone or with Compose) is enough

• Traffic fits on one big VM — you can go a LONG way with a single 32-core machine. Stack Overflow ran on ~9 servers total until 2020.
• You have one or a few services — a Node API + Postgres + Redis is a docker-compose.yml, not a k8s cluster
• Team size < 10 — the operational overhead of k8s is not worth it
• Zero downtime is nice-to-have, not required — a 30-second restart is fine for most apps

When you actually need Kubernetes

• 10+ machines you need to schedule work across — this is the ONLY problem k8s solves cleanly
• You have infra as a competitive advantage — Uber, Netflix, Stripe. Not "we're a SaaS startup with 100 customers."
• You need to run compute-heavy batch workloads next to your web tier — ML jobs, video processing, etc.
• Multi-tenant runtime — you're hosting other people's code (e.g., building a serverless platform)
• Regulatory / compliance requires specific separation — k8s namespaces + network policies

The "startup adopted k8s too early" pattern

The most common regret in modern DevOps. Five engineers pick k8s, spend 40% of their engineering time managing YAML, ingress controllers, Helm charts, cert-manager, and Prometheus — the whole time, their actual product ships slower than a competitor who deployed a monolith to a $200/month VM.

Symptoms of premature k8s adoption:

• More than one engineer spends more than 20% of their time on cluster ops
• Deploys require Helm chart edits nobody understands
• Local dev requires minikube/kind and is different from prod
• Nobody can tell you why you're using k8s specifically vs a simpler alternative

The alternatives to k8s people sleep on

Fly.io

You give it a Dockerfile. It runs your container in multiple regions with a global anycast IP. No YAML. No etcd. No control plane to babysit. For 90% of startups this is what you want.

Render / Railway

Git push, they build the container, they run it. Sleep-mode auto-scaling, managed Postgres, managed Redis. Zero infra learning curve.

AWS App Runner / Google Cloud Run

Container in, HTTPS URL out. Scales to zero. Pay per request. For request-response APIs this is often cheaper than a k8s cluster with an idle pod.

Nomad

HashiCorp's scheduler. Runs containers, VMs, or raw binaries. Config is HCL, not YAML. Much simpler than k8s. Chosen by Cloudflare and CircleCI, among others.

Docker Swarm

Docker's built-in orchestrator. Deprecated in enterprise interest but still works fine for small teams. If you already know Docker Compose, Swarm is a 30-minute learning curve.

If you're going to use Kubernetes, use it right

• Managed control plane — EKS, GKE, AKS. Never run your own etcd.
• Ingress controller — pick one. Nginx or Traefik. Don't try three.
• Helm for templating, but keep charts minimal. Don't over-abstract.
• GitOps (Argo CD or Flux) so cluster state lives in git.
• Observability day one — metrics, logs, traces. Otherwise you're flying blind.

Related

Docker vs Virtual Machines · YAML to JSON converter · JSON to YAML.