Challenge 2: Compose, Swarm, or Kubernetes? — Possible Solution
====================================================================

SOLO DEVELOPER, SMALL SIDE PROJECT, ONE VPS — COMPOSE. This is exactly
the scope Compose was built for: a defined set of containers running
on a single machine. There is no multi-host requirement at all here —
introducing Swarm or Kubernetes would add real operational complexity
(learning a new mental model, managing cluster infrastructure) to
solve a scaling problem that genuinely doesn't exist for a solo
developer's one-VPS project. This is precisely the premature-adoption
mistake this chapter's closing gotcha warns against.

COMPANY, DOZENS OF MACHINES, STRICT UPTIME REQUIREMENTS — KUBERNETES
(or, as a lower-learning-curve alternative from a Compose starting
point, Swarm). This scenario has BOTH signals this chapter names as
genuine reasons to reach for real orchestration: true multi-host scale
(dozens of machines) and a real availability requirement (strict
uptime) that specifically needs automatic rescheduling if any one
machine fails — exactly the self-healing-at-the-cluster-level
capability Compose structurally cannot provide. Given the described
scale (dozens of machines) and the industry-standard tooling at that
scale, Kubernetes is the more likely long-term fit, though Swarm
remains a reasonable option if the team specifically wants to
minimize the learning curve coming from an existing Compose setup.