“Je ne peux plus passer l’aspirateur… parce que [la région AWS] us-east-1 est en panne.”
Ce tweet a fait le tour du monde. Mais au-delà de son aspect humoristique, c’est surtout son auteur qui nous a marqué : Geoff Belknap n’est autre que le patron de la sécurité chez LinkedIn, quelqu’un très au fait des enjeux de disponibilité de service.
5 ans après une autre interruption majeure sur la même région, AWS a expérimenté ces derniers jours une nouvelle indisponibilité, qui a embrasé la Twittosphère. L’aspirateur de Geoff peut prêter à sourire, mais on imagine aisément que d’autres applications, plus critiques, ont occasionné des pertes de revenus significatives.
Alors pourquoi un tel émoi ? Que s’est-il passé en 5 ans ? Le constat est simple : de plus en plus de sociétés ont migré tout ou partie de leur infrastructure sur le Cloud, sans forcément faire évoluer leurs pratiques. Or, quel que soit le fournisseur, aucun des SLAs du Cloud n'affichera jamais 100% : le CTO d’AWS le clame régulièrement “Everything fails all the time”.
Il est donc illusoire de se reposer sur la disponibilité sous-jacente de l’infrastructure, et il est vital de faire évoluer les pratiques de développement logiciel et d’architecture vers un “Design for failure” (se préparer au pire… la chute d’une région entière étant assez proche de ce concept de pire).
Chez WeScale, nous prônons depuis de nombreuses années (depuis notre création, il y a 5 ans, pas loin du premier incident AWS d’ampleur… Coïncidence ?) le Cloud Native Development, soit des méthodes d’ingénierie logicielle susceptibles de “contrer” ce type d’incident.
Alors, qu’aurions-nous pu faire pour l’aspirateur de Geoff ?
Une première stratégie, mise en avant par AWS, est bien sûr un déploiement multi-régions : redonder les services sur une autre région, et à l’aide de “simples” mécanismes réseau, basculer l’intégralité du trafic sur le continent européen par exemple. Bien sûr, cela induit une certaine latence et se base sur la certitude que les services transverses d’AWS, principalement hébergés aux Etats Unis, ne sont pas impactés.
Une autre solution aurait été de faire un hébergement multi-cloud, en utilisant les services d’un autre provider Cloud. Mais bien sûr, comme nous sommes de plus en plus nombreux à prôner l’utilisation de Services Managés, très souvent spécifiques à leur provider, cela nous aurait obligé à redévelopper une partie de l’application Aspirateur.
Nous aurions pu aussi imaginer une multitude de stratégies de repli, de la dégradation partielle des services, à un fonctionnement asynchrone (pas pratique pour un aspirateur quand on vient de renverser son paquet de farine).
Mais tout cela a un coût...
Alors, pour l’aspirateur de Geoff, nous vous aurions probablement conseillé de ne pas surinvestir, et d’accepter que le service puisse tomber pendant quelques heures. Chaque architecture est une savante alchimie entre les opportunités business, les coûts afférents et les risques encourus.
Nous ne vous aurions probablement pas conseillé la même chose pour votre application critique (tiens d’ailleurs, vous avez remarqué que Netflix, malgré un hébergement massif de ses services chez AWS, n’avait pas tremblé une seule seconde ?).
N’hésitez pas à retrouver notre analyse Cloud Native Dev dans notre livre blanc.
