Kubernetes Alternatives
Kubernetes is not the only way to run containers, and sometimes it is not the best one. Knowing the neighbours helps you choose honestly — and explain the choice to your team.
The rule
Pick the smallest tool that still keeps your promises.
The main alternatives, from smallest to largest:
- Docker Compose — one YAML file that starts several containers together on one machine. Perfect for local development and small single-server apps. No automatic spreading across machines.
- Serverless containers — services such as Google Cloud Run, AWS Fargate or Azure Container Apps. You hand over an image; the provider runs and scales it. Little to operate, less to control.
- Amazon ECS — AWS's own container orchestrator. Simpler than Kubernetes and deeply tied to AWS.
- Docker Swarm — clustering built into Docker, with a gentle learning curve and a small ecosystem.
- HashiCorp Nomad — a lightweight scheduler that can run containers and plain programs alike.
- Kubernetes — the most capable and most portable, with the largest ecosystem, and the most to learn.
The notes app in Compose looks like this:
services:
web:
image: ghcr.io/example/notes-web:1.2
ports:
- "8080:8080"
db:
image: postgres:16That is enough for a laptop. It will not move work to another server when this one dies.
The shortcut
Ask three questions in order:
- One machine enough? Use Compose.
- Don't want to run infrastructure at all? Use serverless containers.
- Need many services, many machines, portability and a big ecosystem? Kubernetes.
A student's side project
One server, one app, no uptime promise. One machine is enough: Compose.
The trap is thinking the choice is permanent. Compose files, serverless services and Kubernetes all run the same container images, so moving up later is a change of wrapping, not a rewrite of the app.
Drills
Answer fast — trust the rule.
What is Docker Compose's main limit compared with Kubernetes?
A team wants to hand over an image and never manage servers or clusters. Which fits best?
Which alternative is tied most closely to one cloud provider?
Why is starting with Compose and moving to Kubernetes later usually not a rewrite?
Remember
- Pick the smallest tool that still keeps your promises.
- One machine → Compose; no ops → serverless; many services and machines → Kubernetes.
- Trap: thinking the choice is forever. Images move; only the wrapping changes.
