Choisir entre Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, AWS Lambda et AWS Batch revient à déterminer où le code s’exécute et qui prend en charge les tâches opérationnelles. Dans ce cours, nous élaborons un cadre reproductible reliant les exigences de la charge de travail au comportement de mise à l’échelle, aux limites de défaillance, à la responsabilité opérationnelle et aux facteurs influençant le coût total. Nous éviterons l’approche basée sur un simple catalogue de services pour privilégier une démarche où chaque choix est justifié par des contraintes et des éléments factuels.
Commençons par définir l’axe de responsabilité, car il explique la plupart des compromis. La responsabilité opérationnelle désigne l’entité chargée d’appliquer les correctifs au système d’exploitation, de gérer la capacité et d’exécuter le planificateur (scheduler) qui répartit les tâches sur les ressources de calcul.
Avec Amazon EC2, nous exploitons des machines virtuelles ; nous choisissons donc l’AMI, la stratégie de mise à jour (patching) et l’approche de mise à l’échelle. Avec Amazon ECS ou Amazon EKS, nous exploitons un orchestrateur qui planifie les conteneurs, tout en devant décider quel système fournira la capacité sous-jacente. Avec AWS Fargate, la couche de capacité des conteneurs est gérée par AWS ; nous nous concentrons donc sur les définitions de tâches et la mise à l’échelle des services plutôt que sur la gestion de flottes de nœuds. Avec AWS Lambda, AWS gère l’infrastructure de calcul et la mise à l’échelle ; nous nous concentrons quant à nous sur le code de la fonction et son modèle d’invocation. Avec AWS Batch, AWS gère la mise en file d’attente et la planification des tâches de traitement par lots, et peut placer ces tâches sur des ressources ECS, EKS, Fargate ou EC2.
Examinons, de manière générale, comment la responsabilité varie selon ces différentes options.
Nous pouvons désormais aborder le choix de la solution de calcul comme un exercice d’adéquation aux contraintes plutôt que comme un débat fondé sur des préférences. Le modèle d’exécution définit si la tâche s’exécute sous forme de service permanent, de fonction déclenchée par un événement ou de tâche mise en file d’attente avec un début et une fin clairement définis.
Le profil du trafic est souvent la première contrainte critique. Un trafic irrégulier avec de longues périodes d’inactivité favorise généralement les modèles basés sur les requêtes, tandis qu’un trafic stable privilégie une capacité disponible en permanence, garantissant un taux d’utilisation élevé.
La durée et la gestion de l’état restreignent rapidement les options. AWS Lambda impose une durée d’exécution maximale (timeout) actuellement fixée à 900 secondes ; les tâches plus longues sont donc généralement transférées vers des conteneurs ou des traitements par lots (batch). Les charges de travail avec état (stateful), qui conservent des données locales ou nécessitent une configuration spécifique de l’hôte, sont souvent mieux adaptées à Amazon EC2 ou à des conteneurs s’exécutant sur des instances EC2.
La sensibilité à la latence revêt également une importance opérationnelle. Pour les flux de type requête-réponse, les facteurs clés sont le risque de démarrage à froid (cold start), le placement réseau et la rapidité avec laquelle la plateforme peut ajouter de la capacité en parallèle. Pour les flux asynchrones, on s’intéresse à l’accumulation des tâches en attente (backlog), à la stratégie de nouvelle tentative (retry) ainsi qu’à la manière dont les échecs sont isolés et gérés.
Visualisons la correspondance entre ces exigences et les contraintes liées aux ressources de calcul.