Three microservices, Postgres, Redis — the CTO reads "everyone is on Kubernetes." Six weeks later the team debugs cluster DNS while the real bottleneck was an SQL query. The orchestrator was not the problem; the premature answer was.
Docker Compose describes a container graph on one or few machines: docker compose up -d, local volumes, bridge network. Kubernetes orchestrates pods on a cluster: scheduling, self-healing, rolling updates, ingress, secrets — with real learning curve and ops cost.
Pragmatic decision thresholds
| Signal | Compose enough | Consider Kubernetes |
|---|---|---|
| Service count | ≤ 5–8 stable | > 10 or high churn |
| Nodes | 1–3 VPS | Multi-AZ, horizontal autoscaling |
| Deploys / day | Few | Dozens, canary or blue-green |
| Ops team | Generalist dev | SRE or managed K8s |
| Stateful | Volume plus simple backup | DB operators, complex PVC |
| Ops budget | Minimal | Accept cluster overhead |
Adopting Kubernetes for team CV costs more than a well-sized VPS for 95% of web SMBs.
Compose: strengths and limits
Strengths. Readable compose.yml, local env close to small prod, fast start, docker compose logs -f.
Limits. No native multi-machine scheduler without Swarm, manual rolling update, secrets poorly handled if everything stays in .env.
Healthy pattern: Compose on NVMe VPS plus managed DB at host plus external restic backup. PaaS like Clever Cloud or Alwaysdata fit if the goal is Git deploy without running a cluster.
Kubernetes: when complexity pays off
Automatic horizontal scaling on event traffic. Internal multi-tenant with namespaces and quotas. Canary deploys and automatic rollback — use service mesh carefully. Postgres or Kafka operators if you can operate them. European managed offers reduce control plane pain; you remain responsible for manifests, limits/requests and ingress TLS.
Anti-patterns to avoid
Kubernetes for WordPress monolith — shared or VPS plus cache suffices. Compose in prod without healthcheck or restart policy. Tiny one-node cluster "to be ready" — worst of both worlds. Home-grown StatefulSet without tested backup.
The peak: orchestrator does not fix bad decomposition
Decide and move forward without blind spots
Count services, weekly deploys and nodes needed over twelve months. Stay on Compose plus managed DB if you fit on three nodes or fewer with a generalist team. Pilot managed Kubernetes on one stateless service before full migration. Budget training and cluster on-call — not just plan price. Compare VPS and managed Kubernetes in the comparator; follow with Kubernetes or serverless if scaling stays occasional.
Frequently asked questions
Kubernetes mandatory in production?
No. Relevant when services, environments or nodes make manual deploy too risky.
Compose for high availability?
Single VPS no. Two VPS plus load balancer plus identical compose can suffice without Kubernetes.
Hidden Kubernetes cost?
Training, upgrades, monitoring — often 0.5–1 ops FTE. Managed reduces but does not remove all.
Gradual migration?
Yes: externalised state, stateless Compose, then Kubernetes if horizontal scaling is recurring.
Before installing kubectl in prod, ask: how many failed deploys this year came from missing orchestration — and how many from forgotten config or tests?