Le récent incident de Google Cloud à Londres est le genre d’événement qui devrait obliger les entreprises à repenser ce que signifie réellement la résilience du cloud. Google a déclaré que la perturbation avait été causée par un « événement électrique » affectant les centres de données basés à Londres dans sa région Europe-Ouest2. Le problème est apparu très tôt et a affecté les services cloud dont dépendent de nombreuses organisations, soit directement via leurs propres déploiements, soit indirectement via des plates-formes tierces qui s’exécutent sur Google Cloud.
Ce qui a rendu cet incident important n’était pas simplement le fait qu’une région nuageuse avait des problèmes. L’infrastructure cloud, comme toute infrastructure, peut échouer et échouera. Le véritable problème était l’étendue de la chaîne de dépendance. Les banques, les services de livraison, les fournisseurs de vélos électriques, les applications de budgétisation, certains services de rendez-vous via l’application du National Health Service et les systèmes de liaison vidéo des tribunaux ont tous été pris dans la perturbation. Ces services peuvent sembler sans rapport, mais en réalité, ils peuvent partager les mêmes fournisseurs de cloud sous-jacents, infrastructures régionales, services gérés, réseaux, systèmes d’identité, API et dépendances opérationnelles.
Google a déclaré plus tard que les services s’étaient rétablis pour la plupart des charges de travail affectées, seul un petit nombre de clients étant toujours concernés. Cependant, le mal était déjà fait. L’incident a montré à quel point les entreprises modernes dépendent de plates-formes cloud très performantes mais pas à l’abri des pannes. Elle a également montré que la résilience n’est pas quelque chose que les entreprises gagnent automatiquement en passant à un hyperscaler. Une architecture résiliente doit être conçue, financée, testée et détenue.
