5.1Swarm vs Kubernetes: when to move to orchestration?
The essentials in 30 seconds
- Compose = one machine: it does not spread across multiple hosts, does not replace a dead node, does not finely balance load — as soon as you need multi-machine, zero-downtime or self-healing, you must orchestrate.
- Swarm = simple multi-host: built into Docker, close to Compose, ideal for 2 to 5 machines (replicas, zero-downtime updates).
- Kubernetes = demanding fleet: the large-scale standard (deployments, services, autoscaling, secrets) but a serious learning curve — rule: Compose → Swarm → Kubernetes, by proven need, never by hype.
Running mini-case — Idir, junior DevOps in Algiers
Idir, junior DevOps in Algiers, runs his small company's app on a single server with Compose: it works. One day he is asked “why not Kubernetes?”. Instead of rushing in, he audits: one machine, simple updates, no multi-host requirement. Verdict: well-equipped Compose (CI, backups, healthchecks) is enough. He still notes the next step: if the team moves to 2 or 3 machines needing replicas, it will be Swarm; Kubernetes only if the fleet and teams require it. This case returns in the lesson, the diagram, the script and the 48h challenge — and continues in 5.2, 5.3 and 5.4.
This same case returns in the lesson, the diagram, the script and the 48h challenge — and continues in 5.2, 5.3 and 5.4.
1. What Compose does not do
Compose excels on one machine: it starts, links and replays a stack reliably. But it does not spread containers across multiple hosts, does not automatically replace a dead node, and does not finely balance load between replicas. Idir verifies this on his server in Algiers: as long as he has a single host and simple updates, these limits do not bother him.
As soon as you want zero-downtime across multiple machines, multi-host or self-healing, you need an orchestrator: a multi-machine pilot that places replicas, monitors and repairs. The question is therefore not “which tool is trendy?” but “which real pain must I address?”.
2. Swarm: Compose's big brother
Swarm is built into Docker and speaks almost Compose (docker stack deploy -c compose.yml). You learn it fast: one manager, workers, replicas, replica-by-replica updates. Idir sees it as the natural step if his company moves to 2 or 3 machines: same Compose reflexes, plus scheduling and zero-downtime updates.
Ideal for 2 to 5 machines and simple needs. Its limit: a smaller ecosystem and less finesse than Kubernetes (no equally advanced native autoscaling, fewer extensions). For simple multi-host, it is an excellent effort/benefit ratio.
3. Kubernetes: the demanding standard
Kubernetes orchestrates at large scale: deployments, stable-address services, autoscaling, secrets, advanced exposure. But it requires serious learning and a cluster to operate — or a managed cluster operated by a provider. Idir remembers the escalation rule: Compose → Swarm → Kubernetes, one step at a time, by proven need.
Kubernetes without a need is complexity without benefit: more parts to monitor, back up and update, for zero gain if one machine was enough. Move up a step when the pain requires it — never to learn in production.
Did you know?
Kubernetes without a need is complexity without benefit.
🔎 Concrete example — Idir's decision grid
Each step answers a real pain.
1 machine, deploiements simples -> Compose + CI + sauvegardes
2-5 machines, replicas, MAJ sans coupure -> Swarm (stack deploy)
Parc, autoscaling, multi-equipes -> Kubernetes (manage)
Question piege : on veut du K8s
-> Quel besoin precis ? Sinon : Compose.Reading: Idir places his real need on the scale before choosing.
Lesson: an orchestrator without a need = complexity without benefit.
Section vocabulary
- Orchestrator
- The multi-machine pilot: it places replicas, monitors and repairs.
Simple example: Idir compares Compose (one host) to an orchestrator as soon as several machines are needed.
What it is not: a simple Compose file on a single machine.
Reflex: do I need to spread across multiple hosts?
- Replica
- One copy of a service, spread by the orchestrator.
Simple example: Idir plans 3 replicas of his web app on his future cluster.
What it is not: a single container launched by hand.
Reflex: how many copies does my service require?
- Rolling update
- The zero-downtime update, replica by replica.
Simple example: Idir updates his app one replica at a time, the service always answers.
What it is not: stopping everything then relaunching in the middle of the day.
Reflex: does my update interrupt the service?
- Node
- One machine in the cluster (manager or worker).
Simple example: Idir counts his real machines before choosing his scale.
What it is not: an isolated container.
Reflex: how many machines do I really have?
- Managed
- A cluster operated by a provider instead of being operated by hand.
Simple example: Idir targets a managed cluster if Kubernetes becomes necessary.
What it is not: a cobbled-together cluster with no team to operate it.
Reflex: who operates the cluster if I choose Kubernetes?
In practice — Audit your need
- List your real machines and services (like Idir: one machine, one web app).
- Note your requirements: downtime acceptable? multi-host? autoscaling?
- Place yourself on the Compose / Swarm / Kubernetes scale.
- Write the next step ONLY if the need requires it.
Ready-to-say script — justifying the scale choice
“Today in Algiers, our app runs on one machine with simple updates: Compose with CI, backups and healthchecks is enough. If we move to several machines needing replicas, I suggest Swarm; Kubernetes only if the fleet and teams require it. We move up one step by proven need, not by hype.”
Say to the team to frame the choice before any tool change.
Copy-paste template — scale-choice card
FICHE CHOIX D'ECHELLE — date : ___
MACHINES REELLES : ___ · SERVICES : ___
EXIGENCES : coupure OK ? OUI / NON · multi-hote ? OUI / NON · autoscaling ? OUI / NON
ECHELLE : Compose / Swarm / Kubernetes (entourer)
PREUVE DU BESOIN : ___
PROCHAINE ETAPE : ___ (seulement si besoin prouve)Solo / small budget
Idir alone: Compose + CI + backups is enough — noting the Swarm step just in case.
Small company / small team
One audit card on display: everyone sees why we stay on Compose for now.
SME in Algiers
Idir schedules a review in Algiers with his mentor: machines, requirements and written next step.
Starting team
Pair: one lists the machines, the other the requirements — joint, written decision.
✓ Best practices
- Exhaust Compose + CI before moving up a step.
- Swarm for simple multi-host (2 to 5 machines).
- Preferably managed Kubernetes if Kubernetes it must be.
✗ Common pitfalls
- Moving to Kubernetes “to learn” in production.
- Believing the orchestrator backs up your data.
- Multiplying tools before needs exist.
Key takeaways
- Compose = 1 host, simple and robust — no scheduling or repair across machines.
- Swarm = simple multi-host (2 to 5 machines), close to Compose, ideal to start orchestration.
- Kubernetes = demanding fleet, large-scale standard, serious learning.
- Move up by proven need: Compose → Swarm → Kubernetes, never by hype.
48h challenge — apply tomorrow
Fill in the scale-choice card (template above) for your real app: do your machines and requirements justify your scale?
- I can place my need on the Compose / Swarm / Kubernetes scale.
- My audit card is written and justified.
- I know why an orchestrator without a need costs more than it brings.
Frequently asked questions
Is Swarm outdated compared to Kubernetes?
No: built into Docker and maintained, Swarm remains formidable at its scale — simple multi-host (a few machines, replicas, zero-downtime updates). Less trendy than Kubernetes, but much simpler to learn and operate. Choose by need: Swarm for a few machines, Kubernetes for a fleet with advanced requirements.
Can you stay on Compose in production?
Yes, in many cases (one or two machines) with CI, healthchecks, tested backups and reverse proxy. Orchestration is not mandatory: well-equipped Compose beats an oversized orchestrator. Only move to Swarm or Kubernetes on proven need (multi-host, zero-downtime, autoscaling).
An app on 1 server, simple updates. What to choose?