Pourquoi le multi-cloud n'est probablement pas la réponse à la résilience

Le multi-cloud - C'est le sujet brûlant du moment, ici, là et partout. Suite à quelques pannes très médiatisées, les entreprises sont plus anxieuses que jamais à l'idée de mettre tous leurs œufs dans le même panier cloud et cherchent à s'assurer qu'elles ne seront pas victimes de la prochaine. Cependant, cet architecte cloud grincheux pense que le multi-cloud n'est peut-être pas la réponse à tous les problèmes, comme le prétendent certains blogs, et que nous devons revenir aux bases avec une bonne vieille architecture résiliente.

Remarque : je parle ici du multi-cloud non pas dans le sens hybride sur site, mais plutôt dans un contexte de cloud public, c'est-à-dire multi-cloud ⊂ {gcp, aws, azure, ...}, |multi-cloud| > 1

Soyons réalistes et rappelons-nous d'abord qu'il existe des scénarios où le multi-cloud est la solution que vous recherchez. Les meilleurs produits de leur catégorie doivent toujours être utilisés, quel que soit l'hyperscaler qui les propose ; par exemple, qui ne voudrait pas utiliser BigQuery pour l'analyse, quel que soit l'endroit où se trouve le reste de votre infrastructure (comme le démontre Monzo) ? De plus, la flexibilité dans vos choix d'infrastructure maintiendra votre gestionnaire de compte cloud sur le qui-vive en matière de tarification et de négociation, ce qui garantira la satisfaction des responsables de votre budget et de votre directeur financier. Cette même flexibilité devrait également aider votre responsable des risques à mieux dormir la nuit.

La question de la résilience et de la disponibilité

Pas de problème, voici la traduction complète en français :

La question de la résilience et de la disponibilité

Maintenant que les plaisanteries sont terminées, nous pouvons commencer sérieusement la diatribe. Je ne pense pas que découper une solution en deux et en mettre la moitié dans GCP et l'autre moitié dans A. N. Other soit la bonne façon d'améliorer votre résilience et votre disponibilité pour la grande majorité des utilisateurs du cloud.

L'esprit du temps actuel du multi-cloud est principalement motivé par le désir de ne pas se retrouver hors ligne lorsque votre fournisseur de cloud l'est, et cela est désormais sur le radar des plus hauts échelons des organisations. Les temps d'arrêt sont effrayants et mauvais pour les affaires, et les hyperscalers ne sont pas infaillibles ; la technologie tombe en panne, la matière organique molle appuie sur le mauvais bouton - si cela peut arriver, cela arrive généralement.

Cependant, se précipiter vers un autre cloud, c'est s'attaquer au symptôme et non au problème. Si vous perdez votre infrastructure lorsqu'une région ou une zone entière est hors ligne, pourquoi ne pas répliquer la même infrastructure dans une deuxième région, il y en a beaucoup d'autres parmi lesquelles choisir - cela permettra d'obtenir exactement la même résilience qu'avec un deuxième cloud, et sera probablement beaucoup plus facile à configurer et à maintenir. Le fournisseur de cloud que vous avez choisi dispose d'une multitude d'outils pour rendre cela aussi simple que possible, de l'équilibrage de charge global dans GCP aux bases de données SQL globales dans AWS, en passant par le stockage qui s'étend sur plusieurs continents dans Azure. (Ou les trois dans GCP).

Se retrouver hors ligne avec votre fournisseur de cloud est une défaillance de la conception redondante, qui ne sera pas automatiquement résolue en faisant un chèque à un deuxième fournisseur.

"Et si mon fournisseur de cloud perdait toutes ses régions aux États-Unis ?", vous exclamez-vous. "Alors, basculez vers l'Europe", vous répond l'abîme. Cela nous amène à la mise en garde de ce débat : les secteurs réglementés. Si vous avez des exigences strictes en matière de conformité et de souveraineté, et que vous vous trouvez dans un petit pays sans grand choix de régions (le Royaume-Uni ou la Suisse, par exemple), alors j'accepte que le multi-cloud puisse être la seule option pour augmenter votre nombre de 9.

Un cloud chaud/chaud

Option A - faire fonctionner deux clouds en permanence.

Si l'on décortique cette option, des problèmes commencent à apparaître, avec l'infrastructure du plus petit dénominateur commun en tête de liste. Pub/Sub a-t-il la même sémantique de livraison que SQS ? Cet opérateur fonctionnera-t-il à la fois sur GKE et AKS ? Cette méthode d'authentification peut-elle fonctionner à la fois avec API Gateway et Cloud Functions ? Mon modèle Vertex AI se déploie-t-il sur Cognitive Services ? Les fournisseurs de cloud proposent une gamme d'outils pour vous faciliter la vie - la livraison sans friction et le délai de déploiement sont l'une des plus grandes valeurs ajoutées, et essayer d'être tout pour tous les clouds neutralise cet avantage. Au fur et à mesure que vous descendez l'échelle, en vous éloignant des services entièrement gérés pour vous tourner vers des solutions agnostiques au cloud, votre charge de gestion de l'infrastructure et vos besoins en outils ne font qu'augmenter, ce qui fait grimper les coûts.

La gestion du déploiement simultané sur plusieurs clouds n'est pas une mince affaire, car elle nécessite des couches d'abstraction supplémentaires dans votre infrastructure en tant que code et ajoute une charge cognitive pour vos développeurs. Des outils tels qu'Anthos et Crossplane vous aideront certainement, mais les services conteneurisés ne représentent probablement qu'un sous-ensemble de votre infrastructure totale. N'oubliez pas que si l'ajout d'une infrastructure multi-cloud améliore mathématiquement votre résilience, il est plus difficile de bien faire les choses, et se tromper ne fera que miner les gains nets et pourrait même dégrader votre résilience.

Le routage entre les clouds est la question épineuse ; par définition, vous ne voulez pas que ce soit exclusivement chez l'un ou l'autre des fournisseurs de cloud, ce qui vous amène probablement à utiliser un fournisseur de périphérie tel que Cloudflare ou Akamai, mais vous êtes alors à la merci du SLA d'un seul fournisseur de périphérie (qui n'est pas non plus infaillible), ce qui nous ramène au point de départ.

Un cloud chaud/froid

Option B - faire fonctionner un cloud, avec un second en veille. C'est ce qui vient à l'esprit lorsque les gens parlent de "multi-cloud" et l'on suppose qu'il s'agit de la configuration la plus simple.

Cependant, les points relatifs à l'abstraction et à l'infrastructure du plus petit dénominateur commun de l'option A subsistent. En plus de cela, vous avez quelques inconvénients supplémentaires, avec la question additionnelle de "Qu'est-ce que froid signifie ?". Avez-vous toute votre infrastructure secondaire hors ligne, auquel cas il y aura un délai pour la mettre en ligne le jour J, ou la laissez-vous disponible, mais réduite ? Cela entraînera des coûts 24 heures sur 24 et 7 jours sur 7 et augmentera votre coût total de possession.

Où que vous vous situiez sur ce spectre, le cloud secondaire courra toujours le risque d'être une infrastructure "veilleuse". À moins qu'il ne bénéficie d'une maintenance quotidienne pour rester en phase avec les développements de la configuration principale et qu'il ne démontre qu'il peut être mis en place aussi régulièrement, il est très probable qu'il tombe en panne le moment venu.

Maintenir les données synchronisées sera une tâche encore plus difficile. Imaginez que vous ayez une poignée de files d'attente en vol, une ou deux bases de données et peut-être un cache de session. Sans une réplication et une synchronisation des données minutieuses (et probablement coûteuses), lorsque Azure UK South disparaît dans un trou noir, même si votre deuxième cloud est prêt à fonctionner, il sera difficile de reconstituer où vous en étiez. Et n'oubliez pas que vous devez également récupérer les données intermédiaires dans l'autre sens pour ensuite revenir au cloud principal.

Le nœud du problème de cette option pour moi est "Vous êtes bon, mais êtes-vous meilleur que Google ?". Si l'informatique d'une zone est hors ligne à 2 heures du matin, qu'est-ce qui est susceptible de se produire le plus rapidement ?

• Vous pouvez mettre en ligne votre cloud froid qui a été testé pour la dernière fois il y a 3 semaines, vous assurer que les données sont toutes cohérentes et commencer à y acheminer le trafic.
• Google mobilise une équipe SRE de classe mondiale pour rétablir les ressources informatiques.

Peut-être suis-je pessimiste, ou peut-être que je bois le Kool-Aid depuis trop longtemps (probablement les deux), mais je préfère tomber sur une belle page statique "Nous serons bientôt de retour" dans un bucket que d'essayer de mettre en place une deuxième infrastructure complète plus rapidement qu'un hyperscaler.

Réflexions finales

Le multi-cloud est un excellent outil qui responsabilise le consommateur, et il ne faut pas le rejeter en l'espace d'une séance de thérapie à peine voilée en billet de blog. Cependant, comme mon excellent collègue Will Parsons l'a décrit, cela dépend de l'endroit où vous vous trouvez dans votre parcours vers le cloud :

• Votre application peut-elle être équilibrée en charge ? Si ce n'est pas le cas, travaillez à la séparation de votre couche d'état et de votre couche d'application.
• Votre infrastructure se trouve-t-elle entièrement dans une seule zone de disponibilité ? Vous devriez peut-être commencer à franchir les frontières des zones.
• Votre infrastructure se trouve-t-elle entièrement dans une seule région ? L'étape suivante consiste à la déployer dans une deuxième région.
• De nombreuses régions fonctionnent-elles correctement ? Ajoutez des régions aussi loin que vos exigences de conformité le permettent - des points bonus maintenant que vos clients éloignés verront des latences améliorées.
• Entièrement géo-distribué ? Si vous voulez toujours plus de 9 dans votre temps de disponibilité, commencez à penser au multi-cloud.

Et n'oubliez pas : il ne s'agit pas seulement d'un exercice théorique. Avant d'essayer de passer à autre chose, prouvez-vous que vous pouvez passer d'une zone à l'autre de manière transparente et automatique grâce à des exercices de reprise après sinistre. Ensuite, prouvez-le à nouveau. Et encore une fois pour faire bonne mesure. C'est là que réside la véritable résilience, et pas seulement dans l'achat d'une machine virtuelle dans un deuxième cloud.

Le multi-cloud a sa place, mais il y a d'autres travaux fondamentaux à faire en premier lieu, qui porteront leurs fruits plus rapidement et avec beaucoup moins d'efforts. Lorsque vous franchissez le pas du multi-cloud, soyez prêt à opérer à des niveaux d'abstraction avec des outils indépendants des fournisseurs, ce qui nécessite une réflexion approfondie sur ce qui sera réellement portable, reproductible et gérable dans différents environnements. Toutefois, si vous en êtes à la quatrième étape, au-delà de l'inévitable mort thermique de l'univers, les chances sont astronomiquement faibles que votre fournisseur de cloud perde simultanément les États-Unis, l'UE et l'Asie. Même lors de l'une des pires "pannes" mondiales, qui a duré 47 minutes, seul un total d'environ 5 % des clusters Kubernetes ont été touchés.

Depuis qu'AWS a mis hors service Tinder et Disney+, les entreprises sont plus que jamais désireuses d'éviter d'être sous les feux de la rampe pour la même raison, et le multi-cloud est présenté comme la solution par de nombreuses personnes. Cependant, très souvent, ces mêmes entreprises ont encore un long chemin à parcourir dans leur voyage vers le cloud unique.

Guillaume d'Ockham résume parfaitement la situation : "Les entités ne doivent pas être multipliées au-delà de la nécessité."