Mercredi 25 novembre, plusieurs sites et services sont indisponibles, internet tremble. Les pages de statut virent aux rouges écarlates, les unes après les autres. Très rapidement sur les réseaux sociaux, on voit des situations parfois cocasses être remontées. Je pense notamment à des personnes qui se retrouvent bloquées hors de leurs habitations, la serrure connectée étant totalement dépendante du service en ligne. Des situations qui peuvent prêter à sourire, mais qui peuvent être plus dramatiques quand on les subit surtout avec le nombre d’objets connectés grandissant notamment dans le secteur de la santé.

Panique sur Twitter

Comme vous le savez surement, j’utilise pas mal Twitter (@damyr.fr), et j’ai pu voir en direct beaucoup de réactions avec un peu de tout. Mais je vais revenir plus particulièrement sur un type de réaction, celle des anti-GAFAM. À savoir qu’à titre personnel je suis globalement opposé à beaucoup de choses sur les GAFAMs et opposé à pas mal d’abus. Mais comme à chaque fois, j’ai vu des réactions, notamment de libriste que j’apprécie réagir à coup de : “AWS est down comme quoi ça ne vaut rien”, “Voilà ce qui vous en coutera d’héberger vos données chez AWS”

Alors, qu’on les aime ou pas AWS est surement aujourd’hui le service de cloud le plus au point. Que cela puisse arriver ne prouve rien, et ça arrive aussi aux acteurs locaux, OVH a déjà connu de grosses pannes. Les attaques sur l’aspect technique d’AWS qui a fait ce qui était à faire : informer, isoler et corriger le problème sont hors de propos et ne font que mettre en avant une méconnaissance du sujet. Encore une fois, les GAFAMs posent beaucoup de soucis, mais il ne faut pas se perdre a les attaquer sur des aspects comme ceux-là où, il faut le reconnaitre ils travaillent bien, cela fait juste perdre en crédibilité.

J’ai eu aussi l’occasion de tomber sur 2,3 articles web allant parfois jusqu’à décrire AWS comme le centre d’internet. Même si AWS est un grand acteur, ce n’est pas internet, c’est un bout d’internet, mais il ne représente pas celui-ci. De plus pour rappel, tout AWS n’était pas hors service, une région en particulier (un ensemble de plusieurs datacenters sur une zone géographique) était réellement hors service, le reste fonctionnait sans accro.

Alors oui, AWS est tombé, oui c’est arrivé, ça arrivera encore et vous savez quoi ben c’est normal au fait dans nos métiers.

Everything fails all the time

Oui, cette situation si on paraphrase le CTO d’AWS arrive souvent, ce qui veut dire qu’on doit y être préparée. À l’heure où nos infrastructures sont de plus en plus complexes, pour répondre aux nouveaux défis du web, on augmente assez logiquement le nombre de pannes possible. C’est d’ailleurs aujourd’hui un enjeu de taille, assurer que le service soit toujours disponible, redonder ce qui est possible et prévoir toutes les situations. À tel point que des approches comme le chaos engenering, l’observabilité et les métiers du SRE sont apparues en grande partie résoudre cette problématique.

Donc AWS n’échappe pas à la règle, malgré les efforts colossaux qui sont mis sur cet aspect, rien ne les protège à 100%. D’ailleurs ils en sont très conscients eux-mêmes, et insistent toujours sur cela dans les formations, prévoyez des soucis, créer des infrastructures fonctionnelles sur plusieurs régions si vous souhaitez être résilient. Leurs responsabilités étant prises, c’est aux clients et technique, architecte, opérationnel de prévoir cela dans les infrastructures qu’ils conçoivent. Si votre disponibilité est d’une importance critique, ne vous contentez pas d’une région, voire même d’un fournisseur cloud, créez un plan de continuité d’activité !

Alors, oui cela revient cher on va pas se mentir. Il faut bien comprendre que c’est comme la sécurité, il y a un équilibre à trouver. Vous n’aurez peut-être ni le besoin ni les moyens de vous assurer une redondance parfaite et en soi ce n’est pas un drame. Cela n’est peut-être pas nécessaire à votre business, voire même un risque à prendre. Mais en cas de problème, l’interruption de service sera à assumer, car il résultera de vos choix.

Que retenir de tout ça ?

Être opposé à une technologie ou une entreprise ça arrive, j’ai beaucoup d’entreprises que je n’aime pas, mais garder du recul et un regard juste est important. Réagir brutalement, sans justification ne fera que desservir vous et les causes que vous souhaitez défendre.

Testez vos plans de reprise d’activité (PRA), comme les sauvegardes on y pense rarement, mais si elles ne sont pas testées régulièrement, partez du principe qu’elles ne fonctionneront pas. Si vous être féru d’IoT, assurez-vous d’un fonctionnement minimal hors ligne, même si celui-ci est dégradé afin de ne pas rester bloqué. Exemple très simple, j’ouvre ma voiture avec une carte, mais je dispose d’une clé que je peux utiliser en cas de panne de l’électronique. C’est moins sexy, mais je réduis le risque de rester bloqué.

Quel que soit votre fournisseur, celui-ci peut rencontrer des problèmes, personne n’est à l’abri et ne le sera jamais totalement. Ayez toujours en tête que chaque brique d’une infra peut rencontrer un souci, prévoyez de les rebondir et des modes dégrader afin d’absorber les temps d’incident.

Vous devez aussi prévoir à votre échelle la résilience de vos services et de chaque brique que vous utilisez. Cela passe aussi aux dépendances, notamment JavaScript de vos sites quand elles sont distantes.

Si vous souhaitez en savoir plus et découvrir un autre point de vue notamment sur l’aspect résilience multicloud et gestion de risque, je vous invite à lire le poste de Ted - Arretez internet, AWS ne répond plus ! offrant un autre point de vue sur la situation.