Leaders d’opinion
Commencez à vous préparer maintenant pour la prochaine panne de cloud

Des incidents majeurs de cloud comme celui de cette semaine avec AWS sont inévitables. Ces quatre méthodes peuvent aider votre entreprise à traverser.
Avec des heures innombrables de productivité perdue, les systèmes financiers perturbés pour des millions d’utilisateurs, et potentiellement des centaines de milliards de dollars perdus, la panne de AWS de cette semaine a été une journée terrible pour les équipes mondiales de TI. Bien sûr, c’était également la pire catastrophe de cloud au niveau mondial depuis la dernière… et jusqu’à la prochaine.
Que vous soyez sur AWS, GCP, Azure ou toute autre plate-forme, les pannes majeures sont une réalité du cloud computing. Alors, que peut faire votre entreprise pour atténuer l’impact ? Ci-dessous, je proposerai quatre étapes que votre équipe peut prendre immédiatement.
Apportez votre scepticisme – et faites vos devoirs.
Souvent, les équipes vont courir au désastre en entrant dans des arrangements de cloud en supposant que les grandes entreprises de cloud sont inhérentement fiables. Pour être sûr, les entreprises les plus fiables ont gagné leur réputation pour une raison. En même temps, chaque cloud et hyperscaler offre une large gamme d’options d’infrastructure – AWS North America seul a 31 zones de disponibilité et 31 emplacements de réseau de bordure – et certaines options sont beaucoup plus fiables que les autres.
En effet, la région US-EAST-1 d’AWS, la cause de la panne de cette semaine, avait été à l’origine de perturbations majeures en 2020, 2021 et 2023, et il était bien connu dans certains cercles de TI comme la région la moins fiable. De nombreuses entreprises ont probablement compris la situation mais ont pris un risque calculé compte tenu du faible coût de la région et de ses offres abondantes. Mais étant donné l’ampleur de la panne, il est impossible de ne pas se demander combien d’entreprises ont été prises au dépourvu – et auraient certainement opté pour les régions plus fiables s’ils en avaient été conscients. J’ai personnellement rencontré des dirigeants de TI qui ont choisi de passer à d’autres régions d’AWS uniquement après de mauvaises expériences avec US-EAST-1 dans le passé.
La leçon à tirer est de faire vos devoirs lorsqu’il s’agit d’options d’infrastructure de cloud, quelle que soit la plate-forme de cloud que vous utilisez. Les endroits pour commencer incluent des outils gratuits tels que cloudprice, Cloudping, et les vues d’incidents historiques des outils de santé de service cloud fournis par les hyperscalers.
Choisissez portable plutôt que cloud-native.
Lorsque vous concevez des configurations de cloud, la voie la plus simple est d’aller cloud-native. Mais même si il est pratique de sélectionner des applications prêtes à l’emploi par et pour votre fournisseur de cloud, ces options cloud-native vous laissent plus exposé si votre cloud est hors service.
Pour éviter cette couche supplémentaire de dépendance au cloud, optez pour des produits indépendants et/ou open-source lorsque cela est possible. Quelques exemples de remplacements incluent les suivants :
|
Catégorie |
Exemple d’offre native |
Les alternatives open-source incluent… |
|
Authentification et identité |
AWS Cognito |
Keycloak |
|
Recherche |
Azure Monitor |
Elasticsearch |
|
Bases de données relationnelles |
Google Cloud SQL |
PostgreSQL |
|
Bases de données NoSQL |
AWS DynamoDB |
MongoDB |
|
Orchestration de conteneurs |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Supervision et observabilité |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Files d’attente de messages |
AWS SQS/SNS |
Apache Kafka |
|
Stockage d’objets |
Azure Blob Storage |
MinIO |
|
Passerelle d’API |
Google Cloud API Gateway |
Kong |
Pour être sûr, construire plus de votre pile de cloud à partir de zéro signifie plus de travail pour vos équipes. Cependant, dans mon expérience, une fois que vous avez l’infrastructure en place et en cours d’exécution, il y a peu ou pas de différence entre l’ajout d’une charge de travail à une infrastructure maison établie ou à une infrastructure cloud-native. Et les avantages en termes de résilience – sans parler de la réduction de la dépendance au cloud – font des options indépendantes très rentables.
Concevez pour la défaillance.
Étant donné que les défaillances de cloud se produiront, assurez-vous de concevoir vos produits en tenant compte de la défaillance de cloud. Un exemple à considérer est Datadog : lors d’un incident en 2023, l’entreprise a soudainement perdu l’accès à plus de la moitié de ses nœuds Kubernetes en production et a complètement repensé son approche de la reprise en cas de catastrophe. Les changements ont inclus la suppression des goulots d’étranglement architecturaux et la résolution de la dette technique afin que les défaillances partielles ne se propagent pas dans le système, l’amélioration de l’ingestion et du stockage des données pour une meilleure disponibilité des données pendant les pannes, et la construction de systèmes pour se rétablir automatiquement à grande échelle. Un excellent endroit pour commencer dans votre parcours est de suivre la recommandation de Datadog de « commencer par ce qui est important pour l’utilisateur final », et de construire des systèmes de sauvegarde pour protéger ce qui compte le plus.
Exécutez sur au moins deux clouds.
Bien sûr, la meilleure façon de ne pas être tributaire des défaillances de cloud est la redondance multicloud. Atteindre une véritable fluidité multicloud est une tâche colossale pour de nombreuses entreprises, car il est extrêmement difficile de traduire l’infrastructure d’un cloud dans un autre. Mais la construction d’infrastructures sur deux clouds seulement est un bon – et souvent réalisable – point de départ. Il est essentiel d’avoir une équipe en place avec un expert dans chacun des clouds sur lesquels vous exécutez.
Pour être sûr, rien ne peut protéger complètement les entreprises de l’impact d’une panne massive comme celle que nous avons vue cette semaine. Mais avec la bonne diligence, une approche portable de cloud, la conception pour la défaillance et l’utilisation de « double-cloud » comme tremplin vers une véritable multicloud, les entreprises peuvent être beaucoup plus agiles lors de la prochaine (et malheureusement inévitable) incident majeur de cloud.










