Quel orchestrateur pour quel problème ?
Une antisèche pour décider vite. Le critère n'est pas le meilleur outil, mais l'échelle et la complexité opérationnelle : local, cluster simple, edge, production complète ou cloud géré.
Pars de Docker Compose en local. Si l'appli grandit vers plusieurs serveurs, évalue k3s ou k8s selon la taille de l'équipe. ECS/Fargate si tu es déjà sur AWS et que tu ne veux pas gérer un cluster.
Docker Compose / orchestration locale
Un seul hôte, plusieurs conteneurs.
Choisir si : dev local, CI/CD, petite appli mono-serveur sans besoin de haute disponibilité.
Éviter si : dès que tu répartis sur plusieurs machines ou que tu as besoin d'un failover automatique.
Docker Swarm / cluster Docker natif
Docker, mais en mode cluster.
Choisir si : infra Docker existante, besoin simple de multi-nœuds, équipe sans expertise Kubernetes.
Éviter si : workloads complexes, scaling fin, écosystème Helm/CNCF — manque d'outillage avancé.
Nomad / orchestrateur multi-workload
Jobs, conteneurs, VMs — un seul scheduler.
Choisir si : workloads mixtes (conteneurs + binaires + VMs), stack HashiCorp (Vault, Consul), besoin de la puissance k8s sans sa complexité opérationnelle.
Éviter si : écosystème k8s déjà en place — faible adoption = moins d'intégrations natives que k8s.
Kubernetes / orchestration production
La puissance complète, au prix de la complexité.
Choisir si : microservices, workloads critiques, scaling automatique, équipe DevOps dédiée.
Éviter si : petite équipe sans ops dédiés, déploiements simples — la courbe d'apprentissage est réelle.
ECS / Fargate / géré AWS
Conteneurs sans gérer le control plane.
Choisir si : stack AWS, déléguer l'orchestration à AWS, Fargate = serverless pur sans gérer les nœuds.
Éviter si : multi-cloud ou on-premise — lock-in fort avec l'écosystème AWS.