Les défis du passage à une stratégie multicloud

Les stratégies hybrides ou multi-cloud sont utilisées par les entreprises pour diverses raisons, allant de la législation à la réduction des coûts et à l'agilité des applications. Les entreprises recherchent souvent la flexibilité nécessaire pour tirer parti des meilleurs prix ou des meilleures fonctionnalités de différents fournisseurs de cloud public. Éviter le verrouillage des fournisseurs est une autre raison pour laquelle une entreprise souhaitera une stratégie multi-cloud.

Bien qu'une entreprise ne veuille pas être liée indéfiniment à un seul fournisseur de cloud, le passage à une stratégie multi-cloud ne convient pas à tout le monde. En fait, le risque d'être lié à un seul fournisseur de cloud n'est pas nécessairement le risque auquel il est souvent perçu.

Cet article explique pourquoi le passage à une stratégie multi-cloud n'est pas pour tout le monde, ainsi que les obstacles et les défis à surmonter si cette option est envisagée.

Tous les nuages ​​ne sont pas identiques

En théorie, une application peut être étendue sur plusieurs environnements de fournisseurs de cloud, mais la « véritable portabilité des applications » implique des obstacles qui doivent être surmontés avant que l'application ne devienne portable ou véritablement multi-cloud.

Tout d'abord, les machines virtuelles (VM) doivent être éliminées de l'architecture de l'application. Tous les nuages ​​ne sont pas identiques sous les couvertures. Chaque cloud a sa propre couche d'abstraction sous-jacente, souvent appelée Cloud Service Fabric, c'est là que le réseau, le calcul et le stockage sont présentés à la machine virtuelle qui est généralement utilisée pour héberger des applications. Par exemple, AWS Networking est très différent de Fonctionnel avec Azure Networking et à son tour AWS et Azure Networking sont très différents dans leur configuration de GCP Networking. Il en va de même pour les machines virtuelles, une VM s'exécutant sur Azure ne peut pas être automatiquement déplacée vers AWS et une VM AWS ne peut pas être directement déplacée vers GCP.

Si une machine virtuelle doit être déplacée vers un nouveau fournisseur de cloud, l'image de la machine virtuelle devra être modifiée pour correspondre à la structure cloud de la plate-forme cible sous-jacente. Les offres de calcul et de stockage diffèrent selon les fournisseurs de cloud et présentent souvent leurs propres défis en matière de portabilité des applications. Ces problèmes sont aggravés si l'application utilise des offres de plate-forme en tant que service (PaaS), par exemple une base de données en tant que service (DBaaS), des applications Web ou des composants de courtier de messages où les éléments de stockage de données sous-jacents, les mécanismes de livraison de site Web et la logique d'application est la propriété de cette offre cloud particulière.

Si l'application utilise des fonctions en tant que service (FaaS) (des services cloud qui fournissent une plate-forme automatisée permettant aux clients de développer, d'exécuter et de gérer les fonctionnalités de l'application sans la complexité de la construction et de la maintenance de l'infrastructure eux-mêmes), la tâche de portabilité devient d'autant plus complexe qu'une fois de plus les nuances FaaS de chaque cloud sont spécifiques au fournisseur de cloud.

Mais si les architectures VM, PaaS et FaaS (sans serveur) ne sont pas disponibles, que peut faire un développeur ?

Résoudre le défi du multi-cloud

Ce problème d'interopérabilité entre les clouds peut être considéré comme le problème rencontré par un voyageur international lorsqu'il souhaite recharger son ordinateur portable dans plusieurs pays différents. Soit vous transportez une prise pour chaque système d'alimentation (donc une pour le Royaume-Uni, une pour l'Europe et une pour les États-Unis), soit vous transportez un adaptateur qui fonctionne n'importe où.

Pour l'architecture d'application, cet adaptateur serait un produit comme Docker, un framework de conteneur qui est le même quel que soit le cloud sur lequel il repose. Cependant, la conteneurisation d'une application existante n'est pas nécessairement une chose facile ou rentable à faire. Les conteneurs sont une architecture d'hébergement légère conçue pour démarrer et s'arrêter rapidement, en évoluant pour faire correspondre les ressources directement à la demande. Les conteneurs vous permettent de payer le moins possible tout en offrant le meilleur de votre cloud. Plus un conteneur est lourd, moins il est portable.

Premier défi : décomposer une application en microservices

Pour pouvoir exécuter des conteneurs à grande échelle sur n'importe quel cloud, la première chose à faire est de diviser l'application en petits composants appelés microservices. Chaque microservice a son propre conteneur. Les microservices sont des capacités discrètes au sein d'une application qui, une fois assemblées, présentent une application plus grande et plus complexe à l'utilisateur. Par exemple, si nous examinons une simple application de commerce électronique avec : un site Web, une base de données contenant les préférences des clients, un catalogue de biens à vendre et une capacité de paiement, cela nécessiterait un minimum de quatre micro-services dans son architecture. Si vous ajoutiez ensuite une notification de paiement et une messagerie d'exécution à un entrepôt pour livrer les marchandises, vous auriez besoin d'au moins six microservices. Et ainsi, ça continue. Chaque nouvelle fonction d'application nécessite ses propres composants de service.

Prendre une application existante et la décomposer en une architecture basée sur des microservices est coûteux et prend du temps. Mais c'est un pré-requis à la portabilité des applications car le conteneur est l'adaptateur universel.

Deuxième défi : appliquer un orchestrateur pour exécuter des applications conteneurisées

Malheureusement, l'histoire ne s'arrête pas là. Pour exécuter une application conteneurisée complexe, vous avez besoin d'un composant essentiel - un orchestrateur - qui surveillera et gérera vos conteneurs. L'orchestrateur comprend l'architecture globale des microservices, y compris quels conteneurs et combien d'entre eux constituent une application spécifique. Il peut indiquer à chaque conteneur où trouver les autres conteneurs utilisés pour livrer l'application. L'orchestrateur le plus courant pour la livraison d'applications conteneurisées est Kubernetes, qui est assez complexe à utiliser.

La décomposition de l'application en microservices est le plus grand obstacle à l'activation du multi-cloud. Vous éviterez peut-être de vous enfermer dans un seul fournisseur de cloud, mais vous vous retrouverez toujours « enfermé » dans Docker et quiconque fournit les fonctionnalités Kubernetes que vous exploitez pour orchestrer votre application basée sur des microservices. Le verrouillage du fournisseur à un certain niveau est malheureusement une réalité, il vous suffit de décider à quel niveau vous souhaitez que ce verrouillage se produise.

Troisième défi : il est extrêmement difficile d'éviter la dépendance vis-à-vis d'un fournisseur de cloud

Si le coût vous préoccupe, vous devez tirer parti des capacités PaaS ou FaaS dans le cloud. Cependant, bien que ces deux services soient moins chers à exécuter, ils augmenteront votre niveau de verrouillage vis-à-vis du fournisseur de cloud que vous avez choisi. Si vous comptez sur FaaS ou PaaS et que le fournisseur décide de retirer ou de modifier ces services, vous serez à votre tour obligé de retravailler les services qui en dépendent. Vous êtes enfermé dans le cycle de mise à niveau du fournisseur ainsi que dans sa technologie !

À moins que votre application ne soit déjà basée sur des microservices, l'effort de redéveloppement l'emportera largement sur les économies de coûts réalisées en utilisant un seul fournisseur de cloud. De plus, s'il s'agit d'une application logicielle commerciale prête à l'emploi, vous êtes entièrement à la merci du fournisseur de logiciels quant au moment ou s'il a l'intention de convertir le logiciel en une architecture basée sur des microservices adaptée à la conteneurisation et à la livraison de Kubernetes.

Utiliser un cloud qui convient le mieux à chaque charge de travail

La plupart des stratégies multi-cloud utilisées aujourd'hui n'impliquent pas d'étendre une seule application sur plusieurs clouds (voir ci-dessus). Il est bien préférable de se concentrer sur l'exploitation des atouts et des avantages en termes de coût de l'exécution des charges de travail les mieux alignées sur ce cloud. Par exemple, si vous créez votre propre logiciel en combinant des capacités Open Source avec une base DevOps, vous exécuterez probablement cette charge de travail sur AWS. Si vous avez besoin d'énormes quantités de calcul pour exécuter une modélisation scientifique ou statistique, vous le ferez probablement sur GCP, ou si vous avez des problèmes d'assurance de la sécurité des informations, vous pouvez choisir de les exécuter dans Fonctionnel avec Azur. (Avis de non-responsabilité : chaque fournisseur de cloud mentionné expliquera avec plaisir pourquoi son coin du cloud est super merveilleux pour chacune des charges de travail mentionnées ci-dessus - les étiquettes stéréotypées s'estompent à mesure que les capacités mûrissent - bien que…).

Il y a trois considérations importantes à prendre en compte avant de déplacer votre service cloud.

1. Éviter les temps d'arrêt est une considération importante

De nombreux services spécifiques à un fournisseur sont fournis à partir de régions uniques au sein d'un cloud, mais sont présentés à plusieurs régions comme s'ils étaient natifs de cette région. Certaines pannes récentes d'AWS et d'Azure très médiatisées ont été attribuées à des pannes spécifiques dans un ou deux centres de données basés aux États-Unis. Faites attention aux services et aux régions sur lesquels vous comptez. Le DNS et l'authentification centralisés sont la pierre angulaire des applications, vous pouvez donc souhaiter renforcer la résilience de ces services critiques. Une chose à noter est que les pannes d'hyperscaler sont peu fréquentes et lorsqu'elles se produisent, elles sont souvent résolues beaucoup plus rapidement que les pannes informatiques traditionnelles dans un centre de données sur site. Si une panne affecte plusieurs clients, vous pouvez garantir que le fournisseur de cloud analysera comment la panne a commencé et comment l'empêcher de se reproduire, ce qui signifie souvent investir pour rendre le service plus résilient.

2. Rendre les architectures et les applications géographiquement résilientes

La consommation distribuée de services doit être fournie à partir d'au moins deux centres de données régionaux, en gardant les données à proximité de l'endroit où elles sont consommées, ce qui réduit la latence pour les utilisateurs. Tous les fournisseurs de cloud hyperscale ont une bonne répartition régionale des centres de données, donc ce n'est pas nécessairement une raison pour une stratégie cloud multi-fournisseurs, c'est juste une bonne pratique simple pour éviter une panne dans un seul centre de données affectant tous les utilisateurs de cette région .

3. La sécurisation de plusieurs clouds est toujours beaucoup plus complexe que la sécurisation d'une architecture cloud d'un seul fournisseur.

Tirez parti des références CIS (Center for Internet Security) pour la cyber-résilience, utilisez l'authentification multifacteur et, si vous passez au cloud, disposez d'un système SIEM qui surveille ce qui se passe dans chaque environnement dans une seule console. Si vous ne disposez pas d'un volet de visibilité en temps réel sur votre environnement, il sera difficile de rechercher une activité suspecte et vous ne détecterez jamais une attaque pendant qu'elle se produit. Cela signifie que les dégâts causés seront toujours beaucoup plus élevés qu'ils ne le seraient si vous surveilliez les choses en temps réel. En fin de compte, les environnements publics et multi-cloud se développent au-delà de l'échelle humaine pour surveiller et gérer. C'est là que les systèmes de gestion des ressources d'application (ARM), d'observabilité avancée et de détection et de réponse étendues (XDR) indépendants du cloud, alimentés par l'intelligence artificielle, permettent l'optimisation, la correction et la protection automatisées que les efforts humains manuels n'atteindront jamais.

En résumé

Je recommanderais toujours qu'une organisation commence avec un seul fournisseur de cloud et devienne compétente dans l'utilisation des outils et services natifs de ce fournisseur. Ensuite, à mesure que l'organisation mûrit son utilisation du cloud et maîtrise tous les aspects de l'exploitation et de l'utilisation des capacités de ce fournisseur de cloud, elle peut commencer à évaluer les avantages réels qui peuvent être obtenus en passant à une stratégie multi-cloud. N'essayez pas de faire bouillir l'océan - il vaut mieux être un expert sur chaque nuage qu'un généraliste sur plusieurs nuages. Des ensembles d'outils tiers seront nécessaires pour les stratégies multi-cloud, mais les ensembles d'outils natifs du fournisseur ont généralement un ensemble de fonctionnalités plus complet pour les capacités cloud de ce fournisseur.