Retour d'expérience : Quand ECS s'impose comme une alternative pertinente à Kubernetes

Thibault CORDIER ☁ - Nov 19 - - Dev Community

Ces derniers mois, j'ai accompagné un client dans sa transition d'une infrastructure traditionnelle AWS (EC2 + Auto Scaling Groups, orchestrée via CodePipeline et CodeDeploy) vers AWS ECS.

Cette migration, que nous appréhendions initialement, s'est révélée étonnamment fluide. Avec peu d'effort, nous avons réussi à mettre en place une infrastructure conteneurisée robuste et efficace, tout en conservant les avantages de l'intégration continue déjà en place.

Cette expérience m'a ouvert les yeux : ECS ne serait-il pas trop souvent négligé au profit de Kubernetes, particulièrement pour les structures de taille moyenne qui cherchent à moderniser leur infrastructure sans complexité excessive ?

La tendance Kubernetes

Ces dernières années, nous avons assisté à une adoption massive de Kubernetes dans le paysage du cloud computing. Ses promesses d'orchestration puissante, de scalabilité et de portabilité en ont fait un standard de facto. Cependant, cette adoption s'accompagne souvent d'une complexité non négligeable en termes de maintenance, de mises à jour et de gestion quotidienne.

Le défi des petites structures

Pour une entreprise disposant d'une équipe DevOps dédiée, la complexité de Kubernetes fait partie du quotidien. Les problèmes techniques trouvent rapidement leur solution grâce à l'expertise interne.
Mais qu'en est-il des structures plus modestes ? En l'absence d'équipe interne, le recours à une ESN ou à des freelances devient nécessaire, engendrant des coûts significatifs et une dépendance externe.

Au fil de mes missions freelance auprès de startups et PME, une question revient systématiquement : ont-elles réellement besoin de toute la puissance (et la complexité) de Kubernetes ?

ECS : L'alternative pragmatique

C'est dans ce contexte que j'ai récemment guidé un client vers AWS ECS plutôt que vers EKS (la version managée de Kubernetes par AWS). Bien que moins médiatisé que Kubernetes, ECS offre un ensemble de fonctionnalités particulièrement adaptées aux équipes réduites :

Simplicité opérationnelle

Aucune gestion de version du cluster requise
Déploiement familier, proche de docker-compose
Debug simplifié via l'accès console aux tâches

Intégration native AWS

Connexion transparente avec AWS Secret Manager et SSM Parameter Store
Configuration simple des Load Balancers et security groups
Gestion des droits intuitive via IAM et les rôles de tâches

Flexibilité et coût-efficacité

Support de Fargate et Fargate Spot (non disponible sur EKS)
Gestion flexible des volumes
Scaling automatique efficient

Déploiement continu

Intégration native avec CodePipeline
Support du rolling release et blue-green deployment
Transition douce depuis une infrastructure EC2 classique

Le cas concret de notre migration

Dans le cas de notre client, la transition depuis une architecture EC2 traditionnelle vers ECS s'est faite progressivement, en conservant les pipelines existants et en adaptant simplement la phase de déploiement. Les développeurs ont rapidement pris en main le nouveau système, notamment grâce à la similarité avec docker-compose qu'ils utilisaient déjà en développement.
L'équipe technique réduite a particulièrement apprécié l'absence de maintenance du cluster et la simplification des processus de déploiement, leur permettant de se concentrer sur le développement de fonctionnalités plutôt que sur l'infrastructure.
Un choix pragmatique

Si Kubernetes reste incontournable pour certains cas d'usage complexes, ECS s'impose comme une alternative crédible pour les équipes qui cherchent à moderniser leur infrastructure sans démultiplier la complexité opérationnelle. Il offre un excellent compromis entre fonctionnalités modernes et simplicité d'utilisation, particulièrement dans l'écosystème AWS.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .