Deployment & Infra
Compose vs Kubernetes: make the orchestration call
Reading the decision tree is not the same as running it under pressure. Take a real multi-service app, run it on Compose, deliberately find the wall — a crashed container, a dead host, a deploy that drops traffic — and then write the orchestration call you would defend in a design review, backed by what you actually observed, not a hunch.
Turn the unit’s mental model into an evidence-backed decision: stand up a real Compose stack, probe exactly where its single-host model breaks, weigh the middle ground, and produce a written orchestration recommendation grounded in measured behaviour rather than fashion.
Run a realistic multi-service app under Docker Compose, empirically establish where its single-host model fails, and deliver a defensible orchestration recommendation (stay on Compose, move to a middle ground, or adopt Kubernetes) backed by observed evidence and an honest complexity-tax accounting.
- A working docker-compose.yml that starts the full stack with one command and survives a single-container crash via restart: always (demonstrated, not asserted).
- Recorded evidence of the two failure modes: total stack loss on host failure, and a measured downtime window on an in-place redeploy (with the numbers, not estimates).
- A one-page decision memo stating the scale assumptions, the observed Compose limits, the middle-ground comparison, the Kubernetes complexity-tax accounting, and the final recommendation — each claim tied to evidence or a stated assumption.
- The recommendation correctly maps capability to need: it does not adopt Kubernetes for capabilities the stated scale never exercises, and it does not ignore a single-host ceiling that the assumptions make unacceptable.
- Actually implement the chosen next step for the API service: e.g. port the stack to Docker Swarm (docker stack deploy) and show a rolling update gated on a healthcheck, or deploy the API to a managed PaaS and show zero-downtime rollout — then compare the operational effort to what you predicted.
- Stand the same stack up on a local single-node Kubernetes (kind/k3s/minikube): write the Deployment, Service, and readiness probe, drive a rolling update, and kill a pod to watch the reconciliation loop replace it — then write up how much YAML and concept overhead it took versus the Compose file.
- Add a decision checklist / runbook a teammate can reuse: the three signals that justify leaving Compose, the middle-ground options ranked by weight, and the questions to ask before reaching for self-managed Kubernetes.
- Model the break-even: at what traffic, team size, or availability target does the Kubernetes complexity tax start to pay for itself for this app? Express it as a concrete threshold, not a vibe.
This is the call you will defend in real design reviews: run the app at the lightest weight that fits, find the actual ceiling by observation rather than rumour, account honestly for the complexity tax, and only then choose — Compose, a middle ground, or Kubernetes — strictly against measured limits and stated scale. Doing it once on a real stack turns ‘just use Kubernetes’ from a reflex into a decision you can justify.