Comment bien approcher le multicloud selon les experts

Pour mettre en émoi une foule d’experts IT, rien de plus simple... Parlez-leur de multicloud ! Les opinions ne manquent pas. Dans ce contexte, j’ai pensé qu’il pouvait être utile de faire un tour d’horizon sur ce sujet brûlant. J’ai donc contacté quatre brillants experts - Corey Quinn de Duckbill Group, Armon Dadgar de Hashicorp, Tammy Bryant Butow de Gremlin et James Watters de VMware – pour avoir leur avis sur ce qu’est le multicloud, recueillir leurs analyses et savoir pour quelles raisons vous devriez aller (ou ne pas aller) vers le multicloud.

Cinq points clés sont ressortis de ces échanges. Si vous avez commencé à mettre en place une stratégie multicloud, ou si vous envisagez de le faire, cet article devrait vous intéresser. 

À faire : choisissez le multicloud pour les bonnes raisons

Selon Corey Quinn, il ne faut surtout pas faire du multicloud parce que le Gartner le préconise. Avant de vous lancer dans une approche multicloud, définissez un « pourquoi » axé sur la recherche de valeur business pour votre entreprise, ajoute Armon Dadger. Vous pourriez, par exemple, vouloir utiliser les services différenciés de chaque cloud public, estime Tammy Bryant Butow. Armon cite également des raisons réglementaires, des relations historiques avec un ou plusieurs prestataires ou encore un contexte de fusion/acquisition qui impose de s’adapter à la situation. Ainsi que le souligne Corey, il est généralement plus couteux et difficile de consolider quand on achète une entreprise qui n’utilise pas le même cloud que vous que de laisser son existant sur place.

À ne pas faire : Sur-investir en portabilité des workloads et des données

D’après notre groupe d’expert, si vous imaginez que vous allez construire un système qui peut être déplacé d’un cloud à l’autre sans effort, arrêtez tout de suite. Armon précise que certains éléments d’une chaine d’outils ou de votre architecture peuvent être multicloud (tels que certains workflows ou routages du réseau global). Mais le déplacement d’un workload ou de données est loin d’être simple. Corey estime que concevoir des designs selon le concept « write once, run anywhere » (écrire une fois et l’exécuter partout) ralentit les entreprises, d’autant que ce concept ne tient pas compte des spécificités propres à chaque plateforme. Corey cite notamment l’adhérence sur la gestion des identités, les fonctionnalités liées à la sécurité ou encore au réseau, chaque cloud ayant ses spécificités. Sans oublier la « gravitation des données » ou data gravity (concept selon lequel les données et les applications sont attirées les unes vers les autres, à la manière dont les objets sont attirés entre eux par la loi de la gravité) qui pousse certaines entreprises à rejeter purement et simplement le multicloud, selon James.

Si vous utilisez plusieurs clouds publics, sachez profiter de la valeur distincte intrinsèque à chacun d’eux, souligne Armon. Exploitez les services cloud natifs dès que c’est possible afin de tirer avantage d’innovations intéressantes, de la résilience embarquée et des meilleures pratiques associées. La valeur d’un workload spécialement conçu avec et pour les spécificités d’un cloud donné peut l’emporter sur les avantages de la portabilité.

À faire : Tenez compte des intérêts et des besoins des différentes parties prenantes

Très judicieusement, James note que bien des désaccords autour du multicloud proviennent du fait que les gens abordent la question avec des perspectives différentes. Le contexte est important. Ainsi, si vous êtes un responsable d’infrastructure qui investit massivement dans la solution de gestion des accès et des identités d’un cloud spécifique, le multicloud ne semble pas la solution idéale. Idem si vous êtes un data engineer avec des pétaoctets de données hébergés dans un cloud en particulier : le multicloud ne semble clairement pas être la bonne approche.
James souligne que beaucoup de développeurs s’orientent vers le multicloud parce que leurs outils de prédilection sont par défaut multicloud : l’IDE d’un développeur et la plupart des frameworks de développement ne sont liés à aucun cloud en particulier.

Prenez donc bien en compte qu’au sein de votre organisation, chaque groupe abordera le multicloud avec des perspectives différentes. Cela peut impacter votre approche !

À ne pas faire : Allez vers le multicloud seul

Corey souligne à quel point il est important de se renseigner et d’interroger vos pairs afin de savoir ce qui fonctionne et ce qui ne fonctionne pas. Tammy propose ses meilleures pratiques en matière de collecte de retours d’expériences. L’objectif est de partager les connaissances afin qu’elles profitent à toute la communauté, précise-t-elle. D’autres ont peut-être déjà testé ce que vous essayez de réaliser et peuvent vous aider à éviter les pièges les plus fréquents. De la même façon, si vous avez fait un choix d’architecture qui n’a pas fonctionné, partagez-le afin d’éviter à d’autres de commettre la même erreur.

Lisez les rapports d’analystes, allez aux conférences, regardez les vidéos portant sur des études de cas et rejoignez les communautés en ligne offrant un espace sûr pour partager ses erreurs et apprendre des autres.

À faire : Commencez par expérimenter les techniques de déploiement multi-régions

Corey suggère qu’avant de se lancer dans la gestion de systèmes repartis sur plusieurs clouds, il pourrait être judicieux d’essayer de les gérer sur différentes régions d’un seul et même cloud. Faire fonctionner correctement un système réparti entre différentes régions est loin d’être une évidence, explique-t-il.  Cette expérience peut vous aider à découvrir des problèmes d’architecture ou opérationnels qui, en mode multicloud, pourraient s’avérer pires encore.

Cette technique consistant à tester son déploiement sur plusieurs régions d’un même cloud constitue une excellente approche, surtout si vous envisagez l’utilisation de plusieurs clouds pour alimenter une seule application (par opposition à la définition plus standard du multicloud qui consiste à utiliser plusieurs clouds pour plusieurs applications). Elle peut aussi faire ressortir des problèmes dans vos processus de support ou dans votre chaine de traitements quand elle est confrontée à des systèmes distribués. Commencez par des déploiements multi-régions et n’hésitez pas à utiliser les pratiques de l’ingénierie du chaos pour réaliser vos expériences avant de vous lancer dans les architectures multicloud. 

Le point de vue de Google

Suivez les conseils de ces experts, ils sont excellents. J’ajouterai trois autres conseils basés sur les retours d’expérience de nos clients :

1. N’ayez pas peur du multicloud, vous le pratiquez déjà. De fait, vous ne dépendez déjà pas d’un seul fournisseur. Comme Corey l’a mentionné, vous avez déjà probablement choisi un cloud pour vos outils de productivité, un autre pour le développement des codes sources et encore un autre pour l’infrastructure cloud. Pour une même application, vous utilisez les solutions logicielles et les services applicatifs d’un ensemble de fournisseurs. Autrement dit, vos équipes pratiquent le multicloud depuis des décennies et ont donc déjà une certaine expérience.
   Le modèle le plus délicat – celui qui inquiète à juste titre le plus les dirigeants – consiste à utiliser plusieurs services d’infrastructure pour une même application. Une telle approche peut introduire des problèmes de latence, de sécurité et de logistique.  Assurez-vous de savoir quel modèle votre équipe envisage.
2. Utilisez les bons composants fondamentaux, Kubernetes compris. Est-ce que tout doit fonctionner sur Kubernetes ? La réponse est non bien entendu. Mais Kubernetes est aussi ce qui se rapproche le plus d’une API multicloud. Les entreprises utilisent Kubernetes pour se forger une expérience uniformisée dans un environnement multicloud. Et les usages de Kubernetes ne se limitent pas à l’orchestration des conteneurs : il est aussi utilisé pour gérer l’infrastructure et les services natifs du cloud. Dans ce cadre, pensez aussi aux autres domaines où une approche uniformisée est souhaitable, tels que le provisionnement ou la fédération des identités. 
3. Utilisez Google comme point d’ancrage. Autre point sur lequel vous allez devoir prendre une décision : allez-vous exporter vos technologies et vos pratiques vers le cloud ou, inversement, importer en interne les technologies et les pratiques du cloud ? Nous croyons sincèrement que la deuxième approche est la meilleure. Arrêtez votre stratégie en fonction de l’objectif à atteindre. Avec Anthos, nous proposons une solution pour concevoir et exécuter des parcs de clusters Kubernetes distribués au sein de Google Cloud et à travers différents clouds. En utilisant un socle cloud au lieu d’un socle « on-premise », vous allégez considérablement votre charge de travail tout en exploitant les services managés pour renforcer la sécurité et votre capacité à évoluer. Le tout en introduisant des pratiques modernes au sein de votre équipe.

Nous avons appris beaucoup de choses sur le multicloud au cours de ces échanges avec des experts et il semble que d’autres en aient également profité. C’est pourquoi nous avons décidé de procéder à une deuxième série d’entretiens avec un nouveau groupe d’experts afin de continuer à approfondir le sujet. Ne ratez pas notre prochain article !