Hier, AWS a rencontré des interruptions de service qui ont duré une bonne partie de la journée. On parle beaucoup de DNS, mais quand on se fie à la chronologie partagée par Amazon, il apparaît que, suite au problème initial, des difficultés liées au lancement de nouvelles instances et à la gestion de leur réseau interne dans la région us-east-1 ont prolongé la durée d’indisponibilité de l’ensemble des services.
Évidemment, quand le DNS d’AWS tombe, c’est tout Internet qui tremble et, immanquablement, nous avons droit à une avalanche de commentaires de nombreux “experts” de l’infonuagique. Dans l’attente de l’analyse détaillée d’AWS sur l’origine exacte du problème, ce billet a pour but de préciser quelques vérités importantes à garder en tête face à ce déluge d’analyses de comptoir, souvent rédigées par des LLM…
-
« Les clients n’ont qu’à avoir des architectures redondantes pour éviter de dépendre d’une seule région. » Sur le fond, je suis entièrement d’accord, sauf qu’en l’occurrence, le service DNS est un service global. Par conséquent, même s’il est effectivement lié à la région us-east-1, il touche absoluement toutes les autres régions. Pour tous ceux qui font ce genre de commentaires, je recommande de passer une certification Architect Associate.
-
« C’est le piège d’un seul fournisseur cloud, adoptez des architectures multi-cloud. » En général, c’est le genre de commentaire d’architectes cloud qui n’ont jamais travaillé sur des environnements complexes de grandes entreprises. La réalité est que, s’il est effectivement possible d’avoir des architectures multi-cloud, cela représente un investissement énorme qui n’est absolument pas justifié quand on regarde le nombre d’heures d’interruption de service par année de votre fournisseur cloud. C’est une très bonne idée, mais qui en général ne passe pas l’étape de l’évaluation détaillée, sauf pour de très rares cas d’affaires particulièrement critiques.
-
« Le cloud, c’est un piège, il faut rester on-prem. » Alors celle-là, c’est ma préférée ! Encore une fois, c’est la parole de “professionnels” qui confondent militantisme et réalité d’affaires. Le choix d’une migration vers le cloud ne se fait pas avec une promesse de disponibilité à 100 %, mais avec une promesse de valeur en termes d’innovation, d’élasticité et de rapidité. Et bien souvent, la disponibilité est également largement améliorée, car — attention, accrochez-vous — le on-prem aussi peut se briser et devenir indisponible ! Il le fait d’ailleurs régulièrement ; c’est juste qu’on en parle beaucoup moins car, par définition, il ne concerne pas de nombreuses entreprises simultanément.
Alors, que faire ?
Ce type d’événement ne devrait pas vous faire douter de votre stratégie cloud. Il devrait par contre vous alerter sur le besoin de mettre en place des architectures hautement découplées et multi-régions pour vos systèmes critiques.
En effet, suite à ces différents problèmes d’AWS, on a pu constater que les SaaS utilisant leurs services n’ont clairement pas retrouvé leur disponibilité en même temps. D’un côté, on a eu un Reddit, par exemple, qui est revenu rapidement en ligne, et de l’autre, un Atlassian qui, encore une fois, a brillé par son délai de retour en production. Pourquoi ? Certainement grâce à des architectures découplées utilisant des systèmes hautement élastiques pour gérer l’afflux de messages à traiter au retour en ligne des services, et peut-être également à des plans de basculement vers d’autres régions quand le service EC2 a présenté des difficultés dans us-east-1.
Des délais de retour en production améliorés de plus de 6 heures entre fournisseurs SaaS, c’est clairement quelque chose de significatif qui mérite un investissement dans vos architectures. Et ce n’est malheureusement pas vraiment le type de publication qu’on peut lire aujourd’hui sur LinkedIn…
