EKS ou ECS : différences inattendues et conseils pratiques pour bien choisir

Déterminer si EKS ou ECS convient le mieux à un projet n'est pas toujours évident.

Si l'on raisonne en termes de caractéristiques individuelles, désigner un vainqueur est aisé. La difficulté vient du fait que, pour établir une comparaison valable, il faut considérer chaque produit comme un ensemble de caractéristiques. Il est donc plus juste de voir chaque produit comme un compromis mêlant simultanément avantages et inconvénients.

Une fois ce constat posé, deux conséquences naturelles s'imposent :

1. Aucune des deux options n'est meilleure par défaut. Le choix optimal doit s'appuyer sur les exigences et contraintes propres au projet et à l'organisation.

2. Identifier objectivement la meilleure option pour un projet exige un peu d'esprit critique et un raisonnement nuancé.

Dans cet article, vous découvrirez des différences rarement documentées, leurs implications, ainsi que des observations pertinentes face aux contraintes courantes des projets et des organisations, en plus d'autres facteurs à prendre en compte au moment de trancher.

Considérez ce contenu comme un raisonnement guidé sous forme de conseils conditionnels qui, appliqués à un projet précis, se transforment rapidement en recommandations pratiques pour prendre une décision bien fondée.

L'essentiel d'emblée

Sommaire

Public visé

Introduction

Section 1 : différences mineures entre EKS et ECS

1. ECS propose une tarification Fargate nettement plus avantageuse (Fargate sur EKS coûte cher).

2. La densité de conteneurs sur EC2 est nettement supérieure avec EKS qu'avec ECS.

3. ECS offre des options de service discovery plus avancées.

4. EKS dispose d'un léger avantage sur ECS en matière de multicloud et de développement local, puisqu'il s'appuie sur Kubernetes.

5. ECS ne facture pas le control plane, contrairement à EKS.

Section 2 : observations sur des différences potentiellement décisives

1. EKS offre par défaut un scaling plus rapide des conteneurs et un support d'autoscaling avancé via l'add-on keda.sh.

2. L'IaC (Infrastructure as Code) d'EKS est fondamentalement supérieure à celle d'ECS : standardisée, lisible, découplée, déclarative, et avec prise en charge des métadonnées avec état.

3. ECS ne prend pas en charge nativement les volumes.

4. La difficulté d'EKS est variable et paradoxale :

EKS est difficile parce qu'il est trop facile.

5. Les mises à jour ECS sont extrêmement rares, ce qui constitue un atout majeur en matière de stabilité et de réduction des contraintes liées à l'exploitation des clusters.

6. EKS impose une charge de maintenance incontournable et compte un ordre de grandeur de plus de composants mobiles qu'ECS, qui n'a jamais besoin de maintenance.

Section 3 : règles empiriques pour choisir ECS, EKS, ou aucun des deux.

1. ECS peut être le meilleur choix lorsque :

2. Justifier objectivement EKS comme meilleur choix demande une réflexion plus approfondie sur les facteurs contextuels (cette section contient également de bons conseils sur EKS Auto Mode).

3. Les applications avec état constituent un cas suffisamment fréquent pour mériter une discussion sur la logique des règles empiriques :

Conclusion

Cet article s'adresse à toute personne souhaitant prendre une décision bien fondée entre EKS et ECS.

Si c'est votre cas, la lecture relativement longue de cet article vaudra votre temps : vous serez ensuite en bonne position pour atteindre l'objectif principal — prendre une décision bien fondée — ainsi que les trois objectifs secondaires utiles suivants :

1. Découvrir des différences, avantages et inconvénients inattendus.

(Je me concentrerai sur ceux qu'il est difficile de trouver via Google et qui sont souvent peu documentés.)

2. Apprendre les métadonnées de la décision.

(Comme les implications concrètes des choix et les observations sur les facteurs critiques et contraintes fréquemment rencontrés qui méritent une pondération forte au moment d'évaluer les options. Ces éléments servent aussi parfaitement à établir des recommandations sous forme de règles empiriques.)

3. Comprendre le raisonnement qui sous-tend les affirmations.

Si vous comprenez, partagez et savez reformuler le raisonnement et les justifications présentés pour démontrer la validité d'une affirmation, d'une implication ou d'une observation, vous pouvez utiliser ce savoir pour renforcer la confiance (à l'échelle individuelle, d'une équipe ou d'une organisation) dans le caractère raisonnable d'une décision et la validité des arguments qui la fondent.

La suite de cet article est organisée selon le sommaire ci-dessus. Chaque section contient une liste d'affirmations accompagnée d'un mélange d'explications, de preuves factuelles et de témoignages destinés à établir leur validité.

La première section présente une liste numérotée de différences spécifiques à EKS ou ECS, utiles à connaître mais généralement sans grand impact.

La deuxième section apporte des éclairages sur des différences qui méritent attention, car elles peuvent devenir des facteurs décisifs au moment de choisir.

La troisième section propose des règles empiriques conditionnelles fondées sur des préoccupations courantes au niveau du projet, de l'équipe ou de l'organisation. En les confrontant à votre situation, vous obtiendrez des conseils pratiques.

ECS comme EKS peuvent reposer sur Fargate ou sur EC2. Cela étant, ECS tend fortement à utiliser Fargate, et EKS, EC2.

Les deux premières différences de cette section soulignent un atout de chacun qui explique pourquoi cette tendance s'est imposée. Les trois suivantes portent sur des avantages mineurs accompagnés d'explications sur leur portée relativement limitée.

1. ECS propose une tarification Fargate nettement plus avantageuse (Fargate sur EKS coûte cher).

Cette différence reste mineure, car indépendamment du prix, les utilisateurs d'EKS peuvent préférer EC2 pour ses avantages fonctionnels. (EC2 prend en charge le cache d'images de conteneurs et les daemonsets, ce que ne fait pas Fargate.)

• En théorie, selon la documentation AWS Fargate, les instances Fargate sont censées être légèrement plus chères qu'EC2 en contrepartie d'avantages en matière de praticité et de sécurité, ce compromis visant à favoriser un coût total de possession plus bas.

En pratique, cette logique ne tient que pour ECS, car ECS prend en charge les instances Fargate AMD (alias Intel/x86_64), ARM, à la demande et Spot.

• EKS ne prend en charge que les instances Fargate AMD à la demande.

EKS ne prend en charge ni les instances Fargate Spot, ni Fargate sur ARM.

• Ainsi, lorsqu'on compare les prix sur EKS, il faut comparer l'option la plus chère à la moins chère ET composer avec la logique d'arrondi des tailles d'instances Fargate, en plus de ses surcoûts.
• Pour donner un exemple concret, supposons qu'une analyse de right-sizing détermine qu'un conteneur fonctionne au mieux avec 1,8 CPU et 1,2 Go de RAM.

Si vous demandez 2 CPU, Fargate vous arrondit automatiquement à 4 Go de RAM, et il faut utiliser la tarification Fargate AMD à la demande. En us-east-1, le prix Fargate est de 2,37 $/jour. Ce conteneur tiendrait sur un nœud EC2 EKS Spot de type t4g.small (ARM), qui coûte 0,1512 $/jour.

• EKS sur Fargate peut donc coûter jusqu'à 15 fois plus cher qu'EKS sur EC2 ! (À noter également que ce calcul porte sur la région la moins chère ; l'écart est encore plus marqué dans des régions plus onéreuses.)

2. La densité de conteneurs sur EC2 est nettement supérieure avec EKS qu'avec ECS.

Note : si la plupart de vos conteneurs utilisent au moins 1 CPU et 1 Go de RAM, l'écart de prix sera minime, car un t3/t4g.small peut héberger 2 tâches ECS de cette taille.

Si vous déployez un grand nombre de microservices à faible consommation de CPU et de RAM, ces conteneurs peuvent être nettement moins coûteux à exécuter sur EKS grâce à sa densité de conteneurs supérieure. (Note : cela peut représenter une économie significative pour les organisations qui déploient à grande échelle de nombreux microservices, mais pour la plupart, je ne pense pas que la différence de coût soit franchement déterminante. Je considère donc qu'il s'agit d'une différence mineure mais à connaître.)

• De nombreux utilisateurs d'ECS ont tendance à recourir aux instances Fargate, qui ne permettent de toute façon qu'une seule tâche/pod par instance. Ce qui est moins connu, c'est qu'ECS sur EC2 est nettement moins performant qu'EKS sur EC2.
• Un t4g.small peut exécuter 11 pods EKS, ou 2 tâches ECS.

Un t4g.large peut exécuter 35 pods EKS, ou 2 tâches ECS.

• J'ai calculé cela à l'aide de :

aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=t4g.*" \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table

• La sortie de la commande montre que t4g.small prend en charge 3 ENI. ECS en utilise 1 pour la VM hôte, puis 1 par tâche. Une formule pratique : $MAX_ENI -1 = $MAX_TASKS_PER_EC2_INSTANCE. (3-1=2).
• Note : ECS dispose d'une fonctionnalité au nom peu heureux appelée ENI trunking (alias AWS VPC Trunking). En théorie, elle est censée augmenter la densité de conteneurs d'ECS, mais en pratique elle n'est prise en charge que par des types d'instances qui n'ont JAMAIS de sens d'un point de vue d'optimisation des coûts FinOps. Je vous recommande personnellement de faire comme si elle n'existait pas.
• Quelques notes connexes intéressantes :

Habituellement, les instances AMD constituent le meilleur choix par défaut, en raison d'un coût plus bas et de meilleures performances. Le " a " de t3a signifie AMD ; en règle générale, t3a est donc préférable à t3. Mais la densité de conteneurs d'ECS fait figure d'exception : t3 bat t3a, car t3a.small ne dispose curieusement que de 2 ENI et ne peut donc supporter qu'1 tâche ECS, alors que t3.small possède 3 ENI et peut prendre en charge 2 tâches ECS.

• Selon moi, les 2 principales raisons pour lesquelles les utilisateurs d'ECS préfèrent les instances Fargate sont :

1. Mettre en place ECS sur Fargate est relativement clé en main, alors qu'ECS sur EC2 demande un travail supplémentaire.

2. L'absence de gain de densité de conteneurs significatif sur EC2 réduit l'incitation à passer d'ECS sur Fargate à ECS sur EC2.

3. ECS offre des options de service discovery plus avancées.

Je considère cela comme un avantage mineur d'ECS, car il n'est utile que dans de rares cas, et dans ces cas, EKS peut obtenir des résultats similaires en installant des outils optionnels qui étendent ses fonctionnalités de base.

• Le service discovery d'EKS prend la forme de noms DNS internes au cluster, résolvables uniquement par les pods du cluster, qui suivent un schéma prévisible : $SERVICE.$NAMESPACE.svc.cluster.local
• ECS propose deux options de service discovery. La première est basée sur API et prend en charge les communications internes au cluster ECS ; la seconde, basée sur DNS, prend en charge les communications internes au VPC. (Vous pouvez en lire davantage ici si cela vous intéresse.)

4. EKS dispose d'un léger avantage sur ECS en matière de multicloud et de développement local, puisqu'il s'appuie sur Kubernetes.

Voici pourquoi cette différence reste relativement négligeable :

• Le multicloud est presque toujours une mauvaise idée ; la seule façon de bien le faire passe par une conception cloud-agnostique, qui est elle-même rarement une bonne idée. Le principal souci avec le multicloud, c'est qu'en pratique on rencontre facilement 10 problèmes réels pour 1 bénéfice théorique.
• Minikube et Rancher Desktop permettent d'exécuter Kubernetes localement, mais en pratique je n'ai vu que des ingénieurs très expérimentés en tirer parti, en l'implémentant manuellement sur leur poste personnel.

De nombreuses subtilités liées aux intégrations rendent prohibitive la mise en place d'une expérience de développement locale cohérente et dotée d'intégrations utiles à l'échelle d'une équipe sans investissement conséquent. En réalité, la valeur pratique de cet avantage tend à être très limitée.

• Comme ECS s'appuie sur Docker, des ingénieurs très expérimentés peuvent faire du développement local basé sur Docker sur leur poste personnel. Le développement local Docker s'applique partiellement à ECS, comme Kubernetes en local s'applique partiellement à EKS.

De même, comme seuls des ingénieurs très expérimentés peuvent surmonter les subtilités d'intégration pour obtenir des bénéfices qui ne profitent qu'à eux en tant que développeurs individuels, la base Docker tend à avoir une valeur pratique également limitée pour ECS.

5. ECS ne facture pas le control plane, contrairement à EKS.

Je considère cela comme un avantage relativement mineur, car les coûts d'EKS sont très abordables et faciles à justifier. Cela dit, je conçois que cela puisse compter pour une startup qui doit fonctionner au plus juste.

• Si vous maintenez votre cluster EKS à jour, le coût est de 864 $/an par cluster. Cela dit, il est courant d'avoir un cluster dev, stage, prod et quelques sandbox temporaires ; 3 000 $/an constitue donc une estimation plus réaliste.
• Voici 3 raisons pour lesquelles les coûts du control plane d'EKS sont faciles à justifier :
• 1. Ils ont du sens indépendamment d'ECS.

Si vous deviez exécuter une distribution Kubernetes cloud-agnostique comme Talos ou Rancher, il faudrait payer 3 VM jouant le rôle de nœuds de control plane HA/FT. Les coûts du control plane d'EKS sont moins élevés que l'option DIY, tout en offrant les avantages d'un service managé.

• 2. EKS dispose de fonctionnalités qui méritent une légère prime, principalement une meilleure facilité de débogage et des boucles de retour plus rapides. (La section suivante développe ce point.)
• 3. EKS dispose de ses propres leviers d'économies : EKS sur EC2 est moins cher qu'ECS sur Fargate et potentiellement moins cher qu'ECS sur EC2 grâce à une densité de conteneurs supérieure. Kubernetes Ingress facilite la configuration de load balancers partagés entre plusieurs services, ce qui réduit le nombre d'AWS LB à payer. karpenter.sh propose un autoscaling avec right-sizing automatisé, et keda.sh offre un autoscaling de conteneurs avancé.
• Tout cela peut conduire EKS à présenter un coût d'hébergement inférieur à ECS. Trop de variables conditionnelles entrent en jeu pour désigner systématiquement un vainqueur côté coût, mais il n'est pas rare qu'EKS revienne globalement moins cher ou que la différence soit nulle, ce qui rend potentiellement non pertinent l'argument du coût du control plane d'EKS.

Cette section présente trois atouts d'EKS, un paradoxe d'EKS qui tend à être un inconvénient mais peut devenir un atout, suivis de deux atouts d'ECS.

1. EKS offre par défaut un scaling plus rapide des conteneurs et un support d'autoscaling avancé via l'add-on keda.sh.

• EKS tend généralement à scaler plus vite qu'ECS. Pour la comparaison EKS sur EC2 et ECS sur Fargate, c'est intuitif puisque Fargate ne prend pas en charge le cache d'images de conteneurs.

Ce qui l'est moins, c'est qu'EKS produit également des temps de démarrage rapides plus fréquemment, même lorsqu'EKS et ECS sont tous deux adossés à des instances EC2.

Cela vient de la densité de conteneurs plus élevée d'EKS, qui permet de tirer parti du cache d'images de conteneurs plus souvent. Grâce à ce cache, il n'est pas rare qu'un pod EKS démarre en quelques secondes.

• ECS gère bien l'autoscaling et prend en charge le scaling sur métriques CloudWatch personnalisées, mais il reste en deçà d'EKS en la matière. EKS est sensiblement plus rapide et meilleur pour l'autoscaling de conteneurs en raison de quelques subtilités liées aux détails d'implémentation d'ECS, à la résolution des métriques et à la prise en charge du scaling à 0.
• Je vais détailler les détails d'implémentation problématiques d'ECS. L'autoscaling target-based ne peut scaler vers le haut que par un nombre fixe d'unités de capacité ; il propose une seconde option, le step-based autoscaling, qui permet une certaine variabilité, mais on se retrouve avec un délai d'1 minute entre les décisions de scaling, car les métriques sont collectées une fois par minute.
• (La fréquence de collecte des métriques est souvent appelée résolution des métriques.)
• EKS utilise le HPA (Horizontal Pod Autoscaler) de Kubernetes, dont la résolution de métriques par défaut est de 15 secondes, ce qui lui permet de scaler 4 fois plus vite.
• Le scaling d'ECS repose sur les métriques et alarmes CloudWatch, et un mélange de valeurs par défaut sous-optimales et non modifiables le rend moins performant que les options HPA d'EKS.

ECS dispose d'un scénario optimal où il peut battre EKS sur un point précis, en échange de mauvais compromis. Mais globalement, ses options sont moins bonnes.

• Voici à quoi ressemble le meilleur scénario d'autoscaling sur métriques d'ECS :

Une métrique CloudWatch personnalisée haute résolution peut atteindre une résolution allant jusqu'à 1 seconde.

En pratique, seules les tranches de 10 secondes comptent, car le déclencheur du scaling est l'alarme CloudWatch, dont la période d'évaluation minimale est de 10 secondes.

Cela bat techniquement la période d'évaluation par défaut non modifiable de 15 secondes du HPA d'EKS, mais ce bénéfice s'accompagne d'un mauvais compromis. Avec une résolution de métrique de 10 secondes (en réalité, toute valeur inférieure à une minute), vous ne disposez que de 3 heures de rétention.

• Voici à quoi ressemble en général l'autoscaling sur métriques d'ECS dans des scénarios courants :
• Les métriques CPU et RAM d'ECS ont une résolution d'1 minute, valeur par défaut non modifiable, ce qui contraint la période d'évaluation minimale de l'alarme CloudWatch à 1 minute dans la majorité des cas.
• Même en implémentant une métrique personnalisée, vous opterez peut-être pour une fois par minute afin de conserver 15 jours de rétention et un coût plus faible.
• Il convient également de souligner que la résolution des métriques d'ECS a une valeur par défaut implicite d'1 minute, et qu'une configuration explicite est nécessaire pour activer la granularité de 10 secondes.

Le metrics server de Kubernetes a une valeur par défaut implicite de résolution de métrique meilleure : 15 secondes.

• ECS ne peut scaler à 0 que lorsque des métriques de file d'attente SQS sont utilisées ; sinon, le scaling à 0 est impossible.
• EKS peut installer un add-on gratuit nommé keda.sh pour activer des capacités d'autoscaling plus robustes : métriques personnalisées, scaling du trafic HTTP à 0 et scaling planifié via cron.

L'option cron est particulièrement utile dans le scénario courant où il faut une capacité de base supplémentaire en complément de l'autoscaling, afin d'absorber sans heurts les pics de trafic aux heures de pointe et permettre à la capacité de base de se réduire pendant les périodes de faible activité prévisibles.

2. L'IaC (Infrastructure as Code) d'EKS est fondamentalement supérieure à celle d'ECS : standardisée, lisible, découplée, déclarative, et avec prise en charge des métadonnées avec état.

Ces caractéristiques produisent des avantages d'un ordre de grandeur en matière de facilité de débogage, de boucles de retour et d'expérience DevOps globale.

• EKS suit le standard Kubernetes : kubectl + yaml.

Lecture, apprentissage et édition rapides et faciles pour les humains. (La prise en charge intrinsèque de JSON par YAML est un bonus, puisque YAML est un sur-ensemble de JSON.)

• ECS n'a pas vraiment de standard officiel, ni en IaC ni en outillage. Cela rend l'IaC d'ECS plus difficile à apprendre, car il faut immédiatement se renseigner et choisir parmi des options courantes : AWS Copilot, AWS CDK, Terraform ou Pulumi.
• Côté options d'IaC et d'outillage, EKS en propose davantage, mais en termes de standard, il n'y en a qu'un. Toutes les options EKS reposent sur ce standard unique ; cela donne à EKS un avantage notable, à la fois en facilité d'apprentissage et en probabilité de développer un savoir-faire transférable entre employeurs qui privilégient les standards courants.
• Le manque de découplage conceptuel et d'IaC d'ECS entraîne plusieurs inconvénients intrinsèques.

Un service ECS équivaut conceptuellement à un deployment, service, configmap, secret et rôle AWS IAM EKS étroitement couplés en un même bloc. Cela crée plusieurs problèmes :

• 1. Le couplage fort des déploiements ECS impose des limites aux modifications sur place que l'on peut apporter à un objet déjà déployé.

Il n'est pas rare que des changements nécessitent des redéploiements complets ou des processus en deux étapes pénibles impliquant suppression et recréation.

Cela devient vite usant lorsqu'on doit faire des modifications itératives.

ECS rend très pénible l'ajout, le retrait ou le changement de type de load balancer. Vous constaterez qu'il est impossible de réutiliser le même nom de service sans tout supprimer et recréer, ce qui provoquerait une indisponibilité. Un basculement blue-green permet de contourner ce souci, mais cela engendre une charge supplémentaire.

Les Engineers qui interagissent avec EKS, en revanche, bénéficient d'une excellente expérience grâce à des mises à jour déclaratives et idempotentes.

• 2. Les déploiements ECS sont naturellement plus lents que ceux d'EKS.
• 3. Quand un déploiement ECS échoue, vous vous retrouvez facilement à déboguer une boîte noire, sans signaux de retour clairs vous indiquant que l'état réel a convergé vers l'état souhaité.

Il n'est donc pas rare que les Engineers ECS doivent attendre des timeouts et passer environ 4 minutes entre chaque itération à voir " l'ordinateur dit non ".

Certains choix d'outillage, comme AWS Copilot, peuvent aggraver cette expérience de boîte noire. Lorsque Copilot rencontre certains scénarios de débogage, le temps d'attente peut souvent atteindre 20 à 60 minutes entre les itérations, le temps qu'ECS, Cloud Formation et d'autres couches d'abstraction opaques arrivent en timeout.

N'oublions pas qu'en cas d'échec, la nature de boîte noire d'ECS échoue souvent à fournir un retour ou un indice sur la cause de l'erreur.

• 4. Le débogage des problèmes de déploiement ECS tend à exiger plus d'itérations que celui d'objets YAML EKS, plus simples et découplables.

Cette tendance s'explique par le fait que les tâches ECS sont un bundle étroitement couplé de plusieurs composants ; la portée du dépannage est plus large, sans moyen aisé de cibler le composant à examiner.

• Lorsque vous finissez par devoir déboguer EKS, vous pouvez aisément déployer, modifier et déboguer les composants indépendamment les uns des autres, de façon systématique. Et il est facile d'atteindre une boucle de retour mesurée en secondes, car les signaux sont clairs lorsqu'on lance un kubectl describe ou qu'on consulte la sortie YAML d'un objet pour examiner ses événements et son statut. La boucle de retour d'EKS tend à n'être limitée que par votre vitesse de réflexion et de saisie.
• Grâce à kubectl port-forward, déboguer des services à IP privée sur EKS est trivial. ECS ne dispose pas vraiment d'équivalent.
• Un élément essentiel de l'excellente expérience utilisateur de Kubernetes en matière de retour est que les controllers ajoutent des métadonnées avec état au manifeste YAML des objets composants, lors d'un kubectl apply contre la base etcd d'un cluster en production.

Grâce à cela, les Engineers peuvent utiliser les commandes kubectl describe et la sortie YAML pour consulter les métadonnées d'événement ou de statut d'un objet ; cela fournit un retour rapide et souvent précis sur la réussite ou l'échec des différentes étapes au sein de chaque objet composant.

Ainsi, lorsque quelque chose ne va pas, vous savez rapidement quel composant a échoué et ce qui s'est mal passé.

• Comparons cela au workflow défaillant d'ECS, où l'interface web AWS vous laisse créer un service ECS de type load balancer, et le questionnaire de déploiement vous demande dans quels sous-réseaux déployer.

Il vous indiquera que vous ne pouvez pas déployer à la fois en public et en privé et qu'il faut choisir, mais sans préciser un détail crucial :

S'agit-il des sous-réseaux pour le load balancer ou pour les instances backend ?

De plus, il ne pose la question des sous-réseaux qu'une seule fois, alors qu'il devrait la poser deux fois, pour vous laisser appliquer la bonne pratique standard : load balancer public et instances backend privées.

Le workflow d'ECS vous autorise à faire des choses qu'il devrait empêcher, comme déployer un load balancer à IP publique dans un sous-réseau privé.

Cela ne fonctionnera évidemment pas et devrait être détecté par une validation des entrées ; à la place, vous obtenez une erreur évitable assortie d'un retour médiocre sur les raisons du dysfonctionnement.

• Un autre scénario de débogage courant où EKS brille :

Imaginons qu'un ingénieur crée un VPC vierge pour des tests, puis déploie par erreur un cluster EKS ou ECS dans un VPC dépourvu de NAT gateway.

• Avec ECS, vous n'aurez aucun log et aucune métrique, car le pull de l'image de conteneur échouera faute d'accès Internet. Concrètement, vous volez à l'aveugle, sans aucun retour sur ce qui ne va pas. ECS exec n'est pas intégré clé en main à la plateforme et activé par défaut, et il est difficile à activer.

Il est facile de gaspiller de nombreuses itérations à déboguer en vain la configuration de la tâche ou du service ECS si vous ne réalisez pas que c'est un souci de VPC, car ECS s'apparente davantage à une boîte noire avec un retour médiocre.

Rien ne vous indique même que le pull d'image a échoué ; vous devez deviner que c'est probablement la cause.

• Si vous rencontrez ce même scénario problématique avec EKS, il est bien plus simple à résoudre, car même si les nœuds workers n'ont pas accès à Internet, le control plane est joignable publiquement par défaut. kubectl peut donc fournir des retours du type " image pull failed ", un bon indice d'un défaut de connectivité Internet.

3. ECS ne prend pas en charge nativement les volumes.

• Une chose qui m'a surpris à propos d'ECS : si vous voulez injecter une configuration ou un secret (depuis une config inline dans un ecs-task-definition.json ou référencée via AWS Secrets Manager), les variables d'environnement sont la seule option officielle intégrée d'ECS pour charger une configuration. Aucune option simple, intégrée à la plateforme ECS, ne permet de monter une config ou un secret comme un fichier.
• Cette incapacité à injecter facilement des fichiers de configuration dynamiques explique en grande partie pourquoi ECS n'a pas d'équivalent au concept d'Ingress Controller de Kubernetes.
• ECS peut utiliser EFS pour le stockage avec état, et des solutions de contournement existent pour monter des fichiers, mais ce sont toutes des méthodes forcées et peu faciles à mettre en œuvre, faute de prise en charge native des volumes au niveau de la plateforme ECS.

Une nuance mérite d'être clarifiée :

ECS bénéficie d'un support EFS au niveau de la plateforme AWS, mais aucune intégration au niveau de la plateforme ECS ne facilite sa mise en place.

(Non seulement ce n'est pas facile, mais je dirais qu'il est souvent plus difficile de configurer EFS sur ECS que sur EC2 standalone ou sur EKS, car ECS tend à se comporter en boîte noire difficile à déboguer avec une boucle de retour lente.)

• EKS, en revanche, dispose d'un driver CSI EFS pour configurer une Storage Class Kubernetes ; cette intégration et le support intégré au niveau de la plateforme EKS facilitent la mise en place d'EFS sur EKS.
• Sur EKS, configurations et secrets peuvent être montés sous forme de variable d'environnement ou de fichier. Statefulsets, storage classes, persistent volumes et autres fonctionnalités avancées rendent les workloads avec état relativement faciles à implémenter.

4. La difficulté d'EKS est variable et paradoxale : EKS est difficile parce qu'il est trop facile.

La difficulté d'ECS est relativement statique, car ECS impose plus de contraintes fondamentales. L'intérêt de ces nuances : lorsqu'une équipe d'implémentation a accès à des conseils éclairés fondés sur l'expérience et applique une bonne stratégie d'implémentation, EKS peut être plus simple qu'ECS.

(Pour ceux qui l'ignoreraient, c'est un point de vue fondé sur l'esprit critique qui s'oppose à une affirmation courante de la documentation AWS, selon laquelle ECS serait toujours plus simple qu'EKS.)

• Soyez patient car cette observation demande du temps : elle implique des nuances, un paradoxe empirique et le partage de raisonnements indispensables pour la rendre intuitive :
• EKS peut être plus simple qu'ECS. ECS présente des inconvénients intrinsèques incontournables ; les principaux ont déjà été évoqués. Les inconvénients d'EKS sont fondamentalement différents, car ils relèvent souvent d'une propriété émergente issue d'un paradoxe causé par des biais naturels.

Si vous comprenez la vue d'ensemble du désavantage paradoxal d'EKS, sa cause et la manière de l'éviter stratégiquement, EKS devient bien plus simple.

• EKS illustre parfaitement un vieil adage : " On peut avoir trop d'une bonne chose. Poussées à l'extrême, les bonnes choses font souvent surgir des problèmes. "
• Kubernetes est si bon, si performant et si largement adopté qu'il dispose d'un écosystème massif. Cet écosystème est complexe, et cette complexité, associée au biais naturel qui pousse à adopter des outils Kubernetes aux bénéfices apparents mais aux coûts cachés, explique en grande partie pourquoi EKS est perçu comme difficile.
• Une prise de conscience importante : le grand écosystème complexe de Kubernetes est entièrement optionnel. Si vous choisissez stratégiquement d'en limiter l'usage, EKS reste simple.
• Je vais donner un peu de contexte, puis aborder un autre paradoxe lié :
• L'une de mes compétences clés en ingénierie est de distinguer les solutions de problèmes des transformations de problèmes. Les transformations de problèmes sont des outils et techniques qui résolvent 1 problème en en créant N nouveaux ; ce sont généralement de mauvaises idées à éviter, sauf si vous savez vraiment ce que vous faites et avez réfléchi aux conséquences de second ordre.
• C'est cette logique qui me fait considérer les éléments suivants comme de mauvaises idées :

Kubernetes Operators, statefulsets, utilisation d'API qui ne sont pas v1, operators déployant des statefulsets via des API alpha (un classique), service meshes, et nginx-ingress controller. Sans oublier Hashicorp Vault : " Les amis n'imposent pas Hashi-Vault à leurs amis ".

• Parmi les problèmes introduits, on trouve des CVE critiques, une charge de maintenance, et des mises à jour forcées d'EKS qui finissent par entraîner des mises à jour forcées des applications.

Il n'est pas rare que les mises à jour introduisent des changements cassants, et il existe désormais de nouvelles façons pour vos services d'échouer, avec un rayon d'impact plus large en cas de problème, ce qui implique des tests supplémentaires.

• Une configuration suffisamment complexe peut entraîner des soucis liés à l'IaC, à l'automatisation, à la documentation, à des goulots d'étranglement de compétences, à la dotation en personnel, etc.
• Avec ce contexte en tête, voici le paradoxe associé :

Quand quelqu'un a une mauvaise idée, ECS est restrictif, rigide et juste assez difficile pour qu'il devienne vite évident qu'une mauvaise idée sera ardue à mettre en œuvre. Le strict minimum sera déjà difficile, donc seul le strict minimum sera fait, et de ce fait, ECS est perçu comme plus simple.

• EKS, à nouveau, est trop flexible et trop performant pour son propre bien.

Quand quelqu'un imagine une mauvaise idée, EKS offre tant de liberté et de facilité d'implémentation que toute idée peut être mise en œuvre, y compris les mauvaises.

C'est dommage quand de mauvaises idées circulent, car Kubernetes est si simple à utiliser que d'autres peuvent les adopter et les implémenter sans même s'en rendre compte.

Puis, lorsque les problèmes surviennent, c'est Kubernetes qui prend pour son grade, accusé d'être trop difficile.

La vérité cachée, c'est que beaucoup de problèmes peuvent être évités simplement en évitant les mauvaises idées.

Autrement dit : EKS est difficile quand on le rend difficile.

• Ces observations peuvent se combiner pour fonder une bonne stratégie d'implémentation EKS :

En résumé, restez sur des fonctionnalités EKS simples en appliquant la règle d'or de privilégier les fonctionnalités intégrées, gardez régulièrement à l'esprit le principe YAGNI, et évitez les fonctionnalités absentes d'ECS. (ECS n'a pas vraiment d'operators, d'ingress controllers, de persistent volumes, d'API non stables, d'écosystème massif d'outils tiers, et la prise en charge d'AWS App Mesh est en cours de retrait.)

Si vous comparez les deux avec cette stratégie en tête, vous vous rapprochez d'une comparaison à armes égales ; et là, EKS commence à ressembler à une savoureuse pomme Honeycrisp.

5. Les mises à jour ECS sont extrêmement rares, ce qui constitue un atout majeur en matière de stabilité et de réduction des contraintes liées à l'exploitation des clusters.

• En théorie, une instance Fargate à la demande pourrait fonctionner des années sans mise à jour ; cela évite les pannes liées aux changements cassants associés aux mises à jour.
• La plateforme EKS finira par contraindre ses utilisateurs à mettre à jour, et si les applications du cluster ont été négligées et jamais mises à jour, une mise à jour forcée de la plateforme risque de casser des versions obsolètes d'applications conçues pour fonctionner avec des versions spécifiques de Kubernetes.
• Le contrôleur nginx-ingress en est un bon exemple : un tableau liste les versions de Kubernetes sur lesquelles chaque version du contrôleur est censée fonctionner.
• Un scénario auto-infligé, mais relativement courant et problématique, dans lequel certaines organisations tombent avec EKS : elles font appel à un prestataire pour mettre en place une solution EKS aussi vite et à moindre coût que possible. Puis, le contrat terminé, le cluster EKS et ses workloads peuvent rester intacts pendant des années.

À un moment, quelqu'un découvre que la plateforme EKS finit par imposer des mises à jour. C'est soit après une panne, soit après que ladite organisation a confié, à la dernière minute avant une mise à jour automatique forcée, la tâche de mettre à jour son cluster EKS à un ingénieur.

Très souvent, l'ingénieur découvre qu'il a sous-estimé l'effort requis, car il faut mettre à jour plusieurs workloads déployés sur le cluster en plus du cluster lui-même.

• D'ordinaire ce n'est pas grave, mais ça devient stressant face à une échéance de dernière minute. Et un dépassement peut entraîner des pannes en production. D'autant que ces organisations confient souvent cette tâche à quelqu'un qui n'est pas expert Kubernetes, et que les clusters EKS négligés résultent généralement de chantiers précipités mal planifiés, donc dépourvus d'IaC ou de documentation rédigée par un ingénieur parti depuis plus de 2 ans.
• Outre les mises à jour forcées, les nœuds EC2 d'EKS connaissent davantage de scénarios où les nœuds workers doivent redémarrer qu'un cluster ECS adossé à des instances Fargate.

(Les nœuds EC2 peuvent être réduits par un cluster autoscaler économique comme karpenter.sh, qui par défaut redémarre aussi les nœuds à la demande tous les 30 jours pour qu'ils reçoivent les derniers correctifs des VM Worker Node EKS.)

• EKS facilite également l'introduction d'une complexité optionnelle via karpenter.sh, les contrôleurs Kubernetes gateway-api, les ingress controllers et les service meshes.
• L'adoption de ces composants optionnels introduit du risque : nouveaux modes de défaillance, davantage de choses qui peuvent mal tourner, scénarios de panne inédits comme les mauvaises configurations, mises à jour défaillantes, vulnérabilités de la chaîne d'approvisionnement, vulnérabilités critiques exigeant des mises à jour précipitées, redémarrages semi-fréquents en tant que fonctionnalité, ou changements cassants liés aux mises à jour.
• Une ironie : les service meshes comme Istio embarquent des fonctionnalités censées améliorer la disponibilité, comme la formation d'un mesh multi-régional entre plusieurs clusters, la logique de retry, etc. ; pourtant, en pratique, ils sont souvent une source courante d'indisponibilité.
• Une fois une application déployée et en fonctionnement, ECS tend à être sans maintenance.
• Les mises en place EKS comptent souvent au moins 3 clusters, chacun avec plusieurs composants, qui se mettent tous à jour et engendrent collectivement une charge de maintenance inéluctable.
• Heureusement, de nombreuses avancées ont permis de minimiser cette charge ; un grand pas en avant est EKS Auto Mode, mais même sans cela, les AWS Managed Add-ons et les API v1 stables pour ingress et karpenter ont rendu les mises à jour plus simples, plus rapides et plus sereines.

6. EKS impose une charge de maintenance incontournable et compte un ordre de grandeur de plus de composants mobiles qu'ECS, qui n'a jamais besoin de maintenance.

Ces 2 inconvénients d'EKS, en apparence mineurs, produisent des effets de second ordre qui se traduisent par des désavantages notables en matière de surcharge opérationnelle. Pour donner un peu de contexte au mot " notable ", tablons sur 2 à 14 jours/an de temps d'ingénierie consacrés à la maintenance d'EKS comme estimation indicative.

• Les caractéristiques d'ECS le rendent très indulgent lorsque les bonnes pratiques DevOps courantes sont méconnues ou volontairement ignorées/minimisées.

Les administrateurs ECS peuvent obtenir une bonne fiabilité malgré des pratiques peu recommandables comme :

• 1. Mettre en place des workflows mêlant opérations manuelles et automatisation partielle, avec un IaC minimal ou une automatisation du déploiement des workloads mais pas du provisionnement des clusters.

(Cela peut fonctionner, car une fois ECS opérationnel pour une équipe, il a tendance à le rester.)

• 2. Ignorer les bénéfices sécurité de plusieurs clusters et tout regrouper dans 1 seul cluster ECS.

(Même si dev et prod cohabitent dans 1 cluster ECS, cela nuit rarement à la fiabilité, grâce aux schémas architecturaux courants d'ECS, qui font que la plupart des problèmes possibles ont un faible rayon d'impact :

Il est fréquent que les services ECS aient leur propre LB managé AWS plutôt qu'un Ingress Load Balancer Kubernetes partagé. Les conteneurs Fargate disposent de leur propre VM individuelle, ce qui améliore l'isolation.)

• 3. Ne pas implémenter de limites et de requests de ressources précises.

(Le ratio de 1 tâche ECS pour 1 VM des instances Fargate fait que ce n'est qu'un problème d'optimisation des coûts, et non un problème à la fois d'optimisation des coûts et de fiabilité.)

• EKS comporte suffisamment de composants mobiles et de complexité pour que l'application rigoureuse des bonnes pratiques soit pratiquement obligatoire pour les administrateurs souhaitant que leurs clusters EKS restent fiables et maintenables sur le long terme.
• L'exigence d'une mise en œuvre rigoureuse des bonnes pratiques a un revers important.

Les corvées liées à la maintenance et à l'application des bonnes pratiques mobilisent du temps d'ingénierie, et les heures d'ingénierie coûtent cher. Pire encore, la quête des bonnes pratiques peut entraîner les Engineers dans des spirales de DevOps Yak Shaving.

Le DevOps Yak Shaving peut être une activité parfaitement raisonnable, mais c'est aussi un piège potentiel, car il est difficile de distinguer ce qui est parfaitement raisonnable de ce qui est potentiellement excessif ou totalement inutile.

J'aimerais souligner l'importance de ce point : les administrateurs ECS sont non seulement épargnés des corvées, mais ils rencontrent aussi moins de scénarios de DevOps Yak Shaving.

• Toute équipe gérant EKS conclura rapidement qu'elle a besoin d'au moins 2 clusters EKS pour des raisons de fiabilité.

On découvre aisément que les mises à jour de composants EKS ou les mauvaises configurations peuvent entraîner des changements cassants, et que les problèmes touchant de nombreux composants comme ingress, DNS, CNI, karpenter.sh, les service meshes et les nœuds en mauvais état ont un rayon d'impact étendu.

Il devient alors intuitivement évident que des environnements isolés et le test des mises à jour dans des environnements inférieurs sont essentiels à la fiabilité d'EKS.

• Une fois habituées à un workflow de promotion d'environnements, les équipes EKS font une autre prise de conscience courante :

Tester dans un environnement inférieur n'a de sens que si ce dernier est relativement similaire à l'environnement supérieur.

• De nombreuses équipes EKS investissent du temps dans des implémentations rigoureuses d'infrastructure as code, d'automatisation de bout en bout et de pipelines CICD pour maintenir leurs environnements inférieurs et supérieurs synchronisés.
• Autre constat fréquent : les environnements de dev évoluent plus vite, plus souvent, et sont sujets à des changements manuels. Les modifications manuelles d'urgence en production pour résoudre pannes et incidents ne sont pas rares non plus.

Il n'est donc pas rare que les équipes EKS rencontrent du config drift : un environnement en production ne correspond plus à l'IaC ou à l'automatisation définis dans Git ou un pipeline CICD.

Garantir la conformité entre la production et l'IaC exige donc une mise en œuvre encore plus rigoureuse des bonnes pratiques, généralement via une combinaison de pipelines CICD et d'implémentations GitOps.

1. ECS peut être le meilleur choix lorsque :

• Vous voulez concevoir une application destinée à fonctionner 2 à 10 ans avec une disponibilité maximale et une maintenance minimale.

Imaginons que vous ayez une application rarement mise à jour, comme des services internes — par exemple une application d'audit interne sur mesure — ou une application publique dont la compromission par une vulnérabilité d'exécution de code à distance critique de type zero-day n'entraînerait pas de problèmes majeurs. (Grâce à des bonnes pratiques telles que l'usage d'une image distroless sans shell et de droits IAM respectant le principe du moindre privilège.)

Dans de tels cas, il peut être pertinent de privilégier l'atout d'ECS — une charge opérationnelle quasi nulle — par rapport aux atouts d'EKS que sont la facilité de débogage et des boucles de retour plus rapides.

• Vous avez des applications relativement simples, ne déployez de mises à jour qu'à quelques reprises par jour, vos besoins applicatifs et architecturaux sont stables et changent rarement, ou vous prévoyez d'investir dans un pipeline CICD ECS personnalisé qui ne déploie que des schémas simples et toujours fiables.

Dans ce contexte, vous limiterez probablement votre exposition aux inconvénients d'ECS : difficulté à déboguer en cas de problème et boucle de retour lente.

• Vous avez une petite équipe, composée uniquement de développeurs, et aucun de ses membres n'est intéressé ni disposé à apprendre à mettre rigoureusement en œuvre les bonnes pratiques DevOps.

ECS est alors plus indulgent (par rapport à EKS) lorsque les bonnes pratiques opérationnelles font défaut ou sont minimisées.

2. Justifier objectivement EKS comme meilleur choix demande une réflexion plus approfondie sur les facteurs contextuels :

• ECS et EKS sont tous deux des compromis, avec des bénéfices et inconvénients simultanés. Cela dit, on peut considérer ECS comme plus équilibré, avec des bénéfices et inconvénients tous deux relativement modestes (faible risque, faible récompense). EKS, lui, présente des bénéfices plus marqués et des inconvénients modérés (risque modéré, récompense significative).
• Avant de présenter les bénéfices d'EKS, mieux vaut commencer par les inconvénients ; les considérer en amont vous met dans un meilleur état d'esprit pour tirer le meilleur parti d'une question qui apporte une bonne perspective :

Les bénéfices que je perçois compensent-ils, voire dépassent-ils, les inconvénients ?

• 1er inconvénient d'EKS : une adoption réussie d'EKS exige une mise en œuvre rigoureuse des bonnes pratiques DevOps, qui requiert à son tour de la volonté et un investissement significatif de ressources.

Cela peut prendre plus de temps que beaucoup ne le supposent, car les " problèmes DevOps " exigent souvent des " solutions DevOps ", qui doivent souvent elles-mêmes être associées à des transformations de problèmes avant que de véritables solutions puissent être appliquées.

C'est aussi pour cela que les professionnels DevOps se qualifient parfois en plaisantant de " tondeurs de yaks professionnels ". Transformez un problème un nombre infini de fois et il dégénère en une séance de tonte de yak.

(Estimation indicative : 1 à 4 mois d'investissement ponctuel en effort d'ingénierie.)

• Pour influencer favorablement cet engagement de 1 à 4 mois : payez suffisamment pour recruter des esprits critiques qui saisissent les nuances entre solutions et transformations de problèmes. Assurez-vous que votre équipe comprenne la logique et le raisonnement derrière le paradoxe éclairant : EKS est difficile parce qu'il est trop facile.

Et privilégiez les principes et conseils suivants :

KIS (Keep it Simple), YAGNI (You aren't gonna need it), les API v1 stables sont vos amies, les services managés comme l'AWS LB Controller sont à préférer aux Ingress Controllers DIY comme Nginx (indice : le premier est une solution, le second une transformation de problème, le scan de vulnérabilités de quay.io a relevé qu'une image vieille de 6 ans de nginx-ingress-controller comptait 76 vulnérabilités critiques, soit en moyenne 1 CVE critique par mois !), et EKS Auto Mode mérite considération.

(Auto Mode est aussi une transformation de problème : il présente quelques inconvénients comme l'introduction d'un effet boîte noire et l'augmentation des coûts ; cela vaut toutefois souvent le coup pour des clusters greenfield à petite échelle.)

Faites cela, et EKS peut rester relativement simple.

Souvenez-vous : EKS est difficile quand on le rend difficile.

• 2e inconvénient d'EKS : il impose une charge de maintenance incontournable.

(Estimation indicative : 2 à 14 jours de maintenance par an pour 3 clusters.)

• Il convient de souligner qu'EKS Auto Mode, lancé en décembre 2024, peut grandement aider à minimiser ces 2 principaux inconvénients d'EKS.
• EKS Auto Mode élimine une grande partie du travail préalable (lié à la mise en place des add-ons courants), des prérequis de connaissances, de la maintenance continue, et même des modes de défaillance, puisqu'il évite les changements cassants en n'utilisant et n'automatisant que les mises à jour d'add-ons reposant sur des API v1 stables.
• Cela dit, il ne supprime pas entièrement la maintenance et présente quelques inconvénients : il ajoute des coûts et transforme un peu plus EKS en boîte noire, ce qui nuit à la facilité de débogage.

(Il fait tourner les pods karpenter.sh sur les nœuds du control plane managé, vous ne pouvez donc pas accéder aux logs des pods karpenter.sh, souvent nécessaires pour déboguer les cas particuliers.)

• EKS Auto Mode n'élimine pas non plus tous les prérequis. Cette page précise qu'il vous faudra fournir une ingress class spécifique à Auto Mode, des annotations sur les services de load balancer et une storage class référençant un EBS Volume Provisioner spécifique à Auto Mode pour exploiter toutes ses fonctionnalités.
• Bon à savoir : passer d'Auto Mode désactivé à Auto Mode activé est ardu. À première vue, le portail web EKS donne l'impression qu'il suffit d'activer/désactiver un interrupteur.

Cependant, si vous lisez cette page de référence sur la migration, vous découvrirez qu'une migration sur place est un processus manuel très pénible, au point qu'il est souvent plus simple de déployer un nouveau cluster et d'effectuer une migration blue-green vers celui-ci. Cette difficulté tient au fait qu'EKS Auto Mode possède sa propre ingress class, son propre load balancer class et son propre EBS CSI volume provisioner ; en cas de migration sur place d'EKS Auto Mode désactivé à activé sur un cluster existant, il vous faudra recréer les services Kubernetes de type Load Balancer, les objets Ingress, ainsi que tous les PVC créés avant l'activation d'Auto Mode.

• Compte tenu de ces inconvénients mineurs et des coûts ajoutés, il n'est pas pertinent de recommander EKS Auto Mode dans tous les cas ; cela reste néanmoins souvent un bon choix pour des clusters greenfield à petite échelle gérés par des équipes peu familières d'EKS. Je trouve aussi qu'EKS Auto Mode a beaucoup de sens pour quiconque prévoit d'avoir plus de 6 clusters longue durée.
• Parlons à présent des bénéfices, et le plus important à souligner est un gain de temps qui a le plus grand impact pour compenser les coûts en temps évoqués plus haut.
• EKS apporte un avantage significatif en matière de débogage plus simple et plus rapide, et de boucles de retour plus rapides ; dans les bonnes circonstances (le développement implique souvent un débogage continu), cette seule caractéristique peut suffire à générer assez de gain de temps pour compenser les coûts en temps et produire un gain net, en plus des autres bénéfices d'EKS.
• Voici quelques scénarios courants où EKS devient facile à justifier : votre application se déploie en environnements assez fréquemment pour justifier un pipeline CICD aussi rapide que possible, connaît des changements fréquents, des intégrations complexes, une architecture orientée services, est en cours de transformation d'une architecture monolithique vers une architecture orientée services via le pattern strangler, ou présente des complexités telles que la possibilité de déboguer aisément avec une boucle de retour rapide est jugée très précieuse.
• Anticipez-vous que certaines de vos applications connaîtront un trafic très en dents de scie, et qu'un scaling le plus rapide possible pourrait être un facteur déterminant ?

Si oui, les options de scaling avancées d'EKS (offertes par l'add-on keda.sh), comme le scaling à zéro et le scaling planifié via cron, peuvent constituer des avantages significatifs, en plus d'opportunités d'économies.

• L'une de vos applications a-t-elle une exigence forte de chargement de la configuration applicative sous forme de fichiers ? Des options de stockage robustes ?
• Avez-vous besoin ou voyez-vous suffisamment de bénéfice à disposer de fonctionnalités et schémas d'ingénierie avancés tels que le RBAC au niveau cluster, la policy as code, le GitOps, le load balancing avancé, les intégrations OIDC/Authn/z, et plus généralement une personnalisabilité qui facilite la mise en œuvre de toute idée avec une excellente expérience d'ingénierie ?
• EKS peut être un excellent choix pour les projets dont les bénéfices l'emportent sur la charge de maintenance de 2 à 14 jours/an qu'implique son adoption, et pour lesquels vous pouvez obtenir l'accord des parties prenantes sur un délai d'investissement ponctuel de 1 à 4 mois pour le mettre en œuvre selon les bonnes pratiques.

3. Les applications avec état constituent un cas suffisamment fréquent pour mériter une discussion sur la logique des règles empiriques :

• EKS facilite l'exécution d'applications avec état et les prend bien en charge, mais ce n'est pas parce que c'est facile que c'est automatiquement une bonne idée. J'ai essayé d'offrir une vue éclairée du niveau de difficulté d'EKS aux côtés de ses bénéfices, mais voici une précision importante : le niveau de difficulté évoqué jusqu'ici suppose que vous exécutez des applications sans état (et peut-être quelques applications avec état où la perte de données est acceptable, comme des caches valkey/redis ou des outils de monitoring auto-hébergés type stack d'observabilité PLG de Grafana Labs).
• Souvent, on installe des applications avec état sur Kubernetes sans considérer le cycle de vie complet de l'application, incluant les sauvegardes automatisées, les restaurations automatisées, les tests et les intégrations dans le pipeline CICD.

Quand tout cela est pris en compte, la charge opérationnelle nécessaire pour assurer une grande fiabilité sur la durée est souvent extrêmement élevée.

• Suffisamment élevée pour envisager 3 options :
• 1. Envisager d'accepter un risque accru de connaître plusieurs heures d'indisponibilité environ une fois par an, en échange de l'évitement d'une charge opérationnelle importante, en choisissant délibérément de ne pas mettre en œuvre rigoureusement les bonnes pratiques associées aux workloads avec état.
• 2. Si vous avez besoin d'une disponibilité très fiable et d'options de reprise après sinistre plus simples, déléguer à un service managé onéreux peut aboutir à un coût total de possession plus bas.
• 3. Vérifier si les parties prenantes sont prêtes et disposées à investir 1 à 6 mois (par application/base de données avec état) de temps et d'effort d'ingénierie dédiés pour mettre en œuvre rigoureusement les bonnes pratiques associées aux workloads avec état, ainsi qu'une charge de maintenance accrue.