Préparez-vous pour la prochaine panne d'Internet

Jeudi dernier, Internet est tombé en panne. Encore une fois. Oui, les médias ont transformé une panne de deux heures en une crise mondiale pour faire du putaclic.

Ce qui a rendu cet incident significatif, ce n’est pas seulement la perturbation de Google Cloud, mais aussi les centaines de sites web et d’applications qui sont tombés en panne en même temps. Cela incluait certains grands noms comme Cloudflare, qui utilise GCP pour certains de ses services. Cloudflare étant un CDN, un cache et un proxy largement répandus, cela a créé un effet domino et a, à son tour, fait tomber d’innombrables sites web.

Cela nous rappelle la fragile interconnection de notre monde numérique. Je ne veux pas pointer du doigt, mais plutôt tirer des leçons de cet incident. Ce n’était pas juste un incident ; cela a mis en lumière des principes fondamentaux que, à l’ère du “tout en tant que service”, nous avons peut-être involontairement négligés.

Voici mes principaux enseignements.

Ne mettez pas tous vos œufs dans le même panier de fournisseurs

Le cloud est devenu synonyme d’une mise à l’échelle infinie, d’un stockage infini, d’une puissance de calcul infinie, d’une flexibilité infinie. Il est construit sur la promesse de réduire les coûts (ce qui peut être vrai lorsqu’il est utilisé correctement). Cependant, cela cache une vérité souvent négligée, qui est aussi son plus grand risque : la dépendance à un seul fournisseur. La récente panne a montré comment une panne d’un seul fournisseur, ou même d’un composant de leur infrastructure, peut avoir un effet en cascade sur la plupart des services.

Ajoutons à cela que AWS, Azure et Google Cloud Platform ont une part de marché combinée de 63 % en valeur. Même si votre entreprise n’utilise pas directement ces fournisseurs d’infrastructure, il est probable que vous utilisiez des fournisseurs qui dépendent d’eux, ou des fournisseurs qui pourraient dépendre d’eux. Oui, il est probable que votre application SaaS dépende d’au moins l’un de ces fournisseurs.

Ce que vous pouvez faire :

• Cartographiez vos dépendances : Connaissez-vous vraiment tous les services sur lesquels repose votre produit, directement et indirectement ? Quels IaaS, PaaS, API, CDN, etc., utilisez-vous ? Lesquels ces services utilisent-ils à leur tour ? Dépendez-vous de NpmJS pour construire votre produit ? Votre application est-elle déployée avec une action Github ? Plus vous en savez, mieux vous êtes préparé.
• Faites une évaluation approfondie de vos fournisseurs : Les garanties de disponibilité (3 ? 4 ? 5 neufs ?) ne sont que du marketing. Prenez-les comme tel. Quelle est l’architecture de votre fournisseur ? Son plan de continuité ? Sa transparence sur les incidents ? Ce sont des critères bien plus importants.
• Envisagez des stratégies multi-cloud : Vous ne mettriez pas tous vos serveurs dans le même centre de données ? Alors ne mettez pas toute votre infrastructure chez le même fournisseur IaaS ! (Si vous le feriez, vous devriez faire quelque chose à ce sujet !)

Contrôlez vos données, contrôlez votre entreprise

Le monde du cloud et des API dans lequel nous vivons est formidable. Il nous permet de construire rapidement, d’itérer rapidement, de tester des choses et d’améliorer nos solutions. Vous avez besoin d’une authentification, utilisez Supabase ou Auth0. Paiement en ligne ? Il y a Stripe ou Paypal. E-mails transactionnels ? Sendgrid et MailChimp. Recherche ? Algolia. La liste peut être longue, mais maintenant, vous pouvez travailler à créer de la valeur.

Pourtant, comme l’a montré cette panne, si ces services deviennent indisponibles, vos utilisateurs pourraient être bloqués, ou votre application pourrait cesser de fonctionner, indépendamment de la santé de votre propre infrastructure. Cela peut entraîner une perte significative de contrôle sur les opérations commerciales de base et l’accès aux données. Les services tiers SONT des points de défaillance uniques !

Ce que vous pouvez faire :

• Mécanismes de repli pour les services principaux : Si un service devient indisponible, comment le remplacez-vous ? Pouvez-vous développer une alternative de repli ?
• Mirroring de données robuste : Assurez-vous d’avoir des sauvegardes régulières et accessibles de vos données critiques, même si elles résident principalement chez un tiers. Pouvez-vous les restaurer rapidement dans un environnement différent si nécessaire ?

Construire pour la résilience

La résilience a toujours été une conséquence de la redondance. Vous devriez toujours avoir un système de secours qui peut assurer le service pendant que votre système principal est en panne.

Mais il ne suffit pas d’avoir de la redondance. Votre application doit également être conçue pour être tolérante aux pannes et utiliser tout ou partie du système de secours lorsque nécessaire. Au moins, elle doit garantir que l’impact pour vos utilisateurs soit le moindre possible : l’impossibilité d’envoyer un e-mail ne doit jamais bloquer toute votre application.

Ce que vous pouvez faire :

• Architectures distribuées : Concevez vos systèmes avec des architectures de type microservice. Déployez vos services sur plusieurs fournisseurs IaaS. Répliquez les données critiques sur plusieurs fournisseurs. L’objectif est de limiter l’impact de toute défaillance d’un seul composant.
• Systèmes auto-cicatrisants : Mettez en place des mécanismes qui peuvent détecter automatiquement les défaillances, réacheminer le trafic ou redémarrer les services sans intervention humaine. Plus votre système peut réagir rapidement, moins une panne aura d’impact.
• Concevoir pour l’échec : N’attendez pas qu’un événement externe expose vos faiblesses. Il sera trop tard. Ajoutez quelques tests de défaillance automatisés à votre pipeline CI : que se passe-t-il si le client a une latence de 5 secondes avec votre serveur ? Que se passe-t-il si la base de données est indisponible ? Que se passe-t-il si un paiement ne peut pas être traité immédiatement ? Quelle est l’expérience utilisateur lorsque quelque chose ne va pas ? Ces problèmes ARRIVERONT.

Conclusion

La prochaine panne arrivera. C’est certain. Peut-être pas aussi importante, mais il y en aura qui affecteront votre entreprise.

Soyez préparé :

• Connaissez votre infrastructure, vos fournisseurs, leurs fournisseurs, etc.
• Évaluez les risques régulièrement. Votre application évolue, vos fournisseurs aussi. Ce qui est vrai à un moment ne l’est plus au suivant.
• Prévoyez le pire des cas. Les incidents arriveront. Votre travail est de faire en sorte que l’expérience utilisateur ne soit pas impactée.