Garçon, c'était amusant ou quoi ? Lorsque la région Amazon Web Services (AWS) US-EAST-1 a commencé à s'adapter à ses interfaces de programmation d'applications (API) le 7 décembre, nous avons découvert à quel point nous dépendions tous d'AWS. (Même les gens qui n'en avaient jamais entendu parler savaient que quelque chose n'allait pas lorsque ses émissions Disney+ et Netflix n'étaient pas à la télévision, que le nouveau robot aspirateur Roomba avait arrêté de nettoyer et que ces lumières « intelligentes » ne fonctionnaient pas car elles s'appuient sur AWS).
Bien qu'ennuyeux, c'était bien pire pour les nombreuses entreprises qui dépendent d'AWS pour leurs opérations informatiques. Ou pour ceux qui ont découvert que même s'ils n'ont jamais donné un centime à AWS, de nombreux services pour lesquels ils ont payé (Asana, Smartsheet, Trello et Slack, pour n'en nommer que quelques-uns) ont été construits sur AWS.
Oh.
Amazon a déclaré vendredi dans un article de blog sur son site qu'un "comportement inattendu" avait déclenché la panne d'une heure.
"Une activité automatisée visant à augmenter la capacité de l'un des services AWS hébergés sur le réseau principal AWS a provoqué un comportement inattendu de la part d'un grand nombre de clients au sein du réseau interne", a écrit la société dans le message. En conséquence, les appareils connectés au réseau AWS étaient surchargés.
Alors, que pouvez-vous faire ? Eh bien, pour commencer, arrêtez de compter sur tant d'appareils Internet des objets (IoT). Votre lave-vaisselle, vos lumières de Noël, votre réfrigérateur et votre brosse à dents n'ont vraiment pas besoin de dépendre du cloud. Plus sérieusement, cependant, vous pouvez abandonner l'idée de faire réexécuter par votre service informatique tous vos propres serveurs. Voyez où en était votre entreprise quand cela avait du sens et où elle en est maintenant.
Lors de la panne de la semaine dernière, un de mes amis administrateur système a dû faire face au PDG d'une entreprise qui faisait une dépression nerveuse. Le PDG souhaitait récupérer toutes les données de l'entreprise (plusieurs centaines de téraoctets) et redémarrer immédiatement une application.
Mais peu importe ce que veut le patron, vous ne pouvez pas toujours faire fonctionner les choses comme par magie, surtout lorsqu'elles sont hors de votre contrôle. De même, si vous vous asseyez avec votre directeur financier et passez en revue les chiffres, vous pouvez probablement transférer toutes ces données et toutes ces applications dans votre entreprise. Il y a une raison pour laquelle il a été déplacé vers le cloud, généralement parce qu'il coûte moins cher d'y faire fonctionner les choses que localement.
Peut-être que vous pouvez le faire moins cher avec votre propre salle de serveurs. Si oui, tant mieux pour vous ! Mais avant d'appuyer sur la gâchette, jetez un œil à votre temps d'arrêt avant le cloud. Je parie que vous constaterez que vous étiez en réalité plus souvent déprimé lorsque vous faisiez les choses vous-même.
Alors devriez-vous « résoudre » votre problème de cloud en passant à une configuration multi-cloud ? Cela peut fonctionner, mais pour bien le faire, il faudra au moins deux fournisseurs de cloud public et éventuellement votre propre centre de données. Cela devient très, très cher.
Et si ce que vous voulez vraiment, c'est un filet de sécurité en cas de panne comme AWS, désolé, le multicloud ne suffira pas. Comme l'a déclaré Lydia Leong, vice-présidente analyste émérite chez Gartner : « Le basculement multi-cloud nécessite que vous mainteniez une portabilité totale entre deux fournisseurs, ce qui représente une lourde charge pour les développeurs d'applications. L'exécution de calcul de base (qu'il s'agisse de VM ou de conteneurs) n'est pas le problème, donc OpenShift, Anthos ou d'autres solutions « Puis-je déplacer mes conteneurs » ne seront pas vraiment utiles. Le problème réside dans tous les différenciateurs : les différentes architectures et fonctionnalités réseau, les différentes capacités de stockage, les capacités PaaS propriétaires, les capacités de sécurité très différentes, etc.
Assez de mauvaises nouvelles. Voici ce que Leong et moi pensons que vous pouvez faire pour que votre entreprise continue de fonctionner même lorsque votre cloud principal est en panne.
Soyons honnêtes. Le cloud est là pour rester. Puisque c'est le cas et que les nuages continueront de s'effondrer, il est logique d'utiliser les meilleurs outils qu'ils nous donnent pour nous protéger de leurs inévitables échecs.
Nous aurons encore des jours où tout ira en enfer dans un panier à main, mais au moins il y en aura moins.
Alors lisez ceci:
Droits d'auteur © 2021 IDG Communications, Inc.