Cloud multiple ou multi-cloud : comment faciliter le passage de l’un à l’autre ?

CloudOrchestration
DBPaaS fournisseurq

Malgré l’adoption généralisée des stratégies multi-cloud dans les entreprises, il y a toujours une pénurie de solutions efficaces qui répondent aux nombreux défis auxquels sont confrontées les organisations qui les mettent en œuvre.

L’un de ces défis est l’interconnexion sécurisée des charges de travail hébergées par plusieurs fournisseurs – un problème dont l’intensité s’accroît lorsque d’autres fournisseurs de cloud sont ajoutés.

Selon une enquête de Propeller Insights, parmi la majorité (75 %) des entreprises qui déploient des applications dans plusieurs clouds, 63 % utilisent trois clouds ou plus. Dans l’ensemble, plus de la moitié (56 %) trouvent qu’il est difficile de gérer les charges de travail entre différents fournisseurs de clouds, citant des problèmes de sécurité, de fiabilité et, généralement, de connectivité.

Une partie de cette difficulté peut être attribuée à des modèles opérationnels concurrents.

Chaque cloud individuel offre des services et des API respectives qui sont uniques au fournisseur de cloud individuel – et qui exigent souvent que les clients se conforment à des compétences, des politiques et des approches différentes.
Chaque cloud offre une expérience de réseau défini par logiciel, mais il n’y a pas deux clouds qui offrent la même expérience de réseau défini par logiciel.

Cela conduit souvent à des configurations incohérentes qui affectent la sécurité et les performances lorsque ces différences inter-environnements ne sont pas correctement prises en compte.

Cette difficulté d’interconnectivité est accentuée par l’introduction d’applications cloud natives, basées sur des microservices, augmentant considérablement le nombre d’instances de communication croisée.

L’enquête Propeller a révélé que « plus de 70 % des personnes interrogées déclarent que les problèmes de sécurité sont exacerbés dans les environnements multi-cloud par les différents services de sécurité entre les fournisseurs (77 %), le nombre croissant d’API (75 %) et la prévalence des applications basées sur les microservices (72 %) ».

Tout cela entraîne un besoin, et une demande, d’une nouvelle approche de la mise en réseau multi-cloud.

Le défi de la mise en réseau multi-cloud

La mise en réseau multi-cloud unifie deux approches différentes pour simplifier la mise à disposition des applications :

Elle adopte l’inter-réseautage défini par logiciel de bas en haut. Elle crée une superposition qui fait abstraction des différences entre les environnements de mise en réseau et simplifie considérablement les défis liés à l’utilisation conjointe de plusieurs environnements cloud. L’infrastructure physique fixe est utilisée comme une sous-couche capable avec un plan de contrôle standard inter-cloud permettant une mise en réseau virtuelle dynamique par-dessus.

Elle étend la mise en réseau simple des conteneurs à une distribution sophistiquée du haut vers le bas. Alors que le secteur a commencé à normaliser les charges de travail des conteneurs en tant qu’unité d’application de facto, le réseau relativement peu sophistiqué qui les sous-tend doit être étendu à d’autres environnements. Cela marque l’émergence éventuelle d’un cloud distribué pour aider à la gestion du trafic applicatif entre les environnements.

La convergence de ces deux éléments a déjà conduit à la création de deux couches d’abstraction dans les architectures applicatives des clients – Kubernetes pour faciliter la gestion des charges de travail du réseau et SDN pour simplifier l’inter réseau. Mais la façon dont ces deux approches convergent actuellement cause encore une douleur importante aux clients.

De nombreuses entreprises sont confrontées à la manière dont ces technologies obligent les opérations à adopter des configurations trop granulaires pour obtenir une approche standardisée de l’interconnexion lorsque plusieurs clouds sont impliqués.

L’approche adoptée par un fournisseur de cloud, même pour des tâches de mise en réseau extrêmement simples comme la gestion des VLAN, est nettement différente de celle adoptée par un autre fournisseur… et les deux peuvent être complètement étrangères à l’approche adoptée par l’entreprise pour ses propres efforts de cloud privé.

La manière dont les réseaux sont provisionnés et gérés à travers les propriétés du cloud conduit souvent à la nécessité de maintenir une équipe d’experts dans les différences entre les environnements respectifs, juste pour suivre le rythme de la normalisation des réseaux.

Le cloud distribué comme solution

Si l’on ajoute plus d’un fournisseur de services cloud au mélange, l’intensité du problème s’en trouve accrue. De toute évidence, il existe de meilleures façons d’aborder ce problème en rapprochant Kubernetes et SDN, en résolvant les différences environnementales et en supprimant la nécessité d’être un expert en réseau pour que tout cela se produise. Cette approche est appelée le  » cloud distribué « .

Les clients rencontrent généralement ce problème lorsque leurs décisions commerciales et les besoins de leurs applications sont étudiés avant de choisir le  » meilleur réseau/cloud  » pour leur service. Cette décision intègre une variété de facteurs, tels que le coût, la capacité de lancement, la vitesse de déploiement, ou la nécessité d’être dans une région particulière – quel que soit le facteur que le client décide comme étant critique pour le succès de son application.

Les facteurs liés au réseau ou l’interopérabilité avec d’autres cloud sont rarement pris en compte dans la décision commerciale initiale. Malheureusement, cela entraîne de nouveaux défis à mesure que l’application progresse dans sa durée de vie prévue et que d’autres éléments de l’entreprise prennent des décisions différentes concernant l’utilisation du cloud.

Il n’y a rien d’intrinsèquement incorrect dans les décisions prises pour utiliser les technologies de cloud qui sont particulièrement adaptées aux besoins de l’entreprise, même si cela conduit à l’utilisation de plusieurs fournisseurs ou environnements. Les entreprises ne doivent pas rechercher uniquement les avantages d’un fournisseur de cloud particulier, mais plutôt de chercher à créer des points communs entre tous ces fournisseurs avec des solutions à l’échelle raisonnable et à la portée des compétences réseau des clients, de leurs besoins applicatifs et de leurs souhaits commerciaux.

Une approche qui s’appuie sur trois convictions essentielles :

Le réseau doit prendre en charge un modèle de partout, à tout moment, sans perte de qualité ou d’expérience client.

Tout cloud d’interconnexion doit être simple, complet et cohérent, quel que soit le cloud sous-jacent choisi par les organisations.

Ces dernières devraient être en mesure d’obtenir plus de valeur grâce à une unification simple, déclarative et pilotée par API sur les plans de contrôle et de gestion.

Le modèle de cloud distribué considère que les utilisateurs des applications des entreprises doivent être servis avec les plus hauts aspects de qualité, de performance et de sécurité en temps quasi réel. L’objectif est de fournir un cloud distribué qui apporte les concepts d’élasticité inter-cloud sans augmentation massive des coûts, sans contraintes de temps pour le provisionnement ou sans variations environnementales.

Pour faire face à ces moments critiques en fournissant un ensemble de technologies et de pratiques, un éditeur doit travailler dur pour étendre cela à chaque application dans les architectures de ses clients.

Dans le cadre de sa mission visant à évoluer vers des applications plus adaptatives, il doit avoir l’intention d’aider les clients à effectuer ces transitions pour leur permettre de déplacer facilement les charges de travail vers les emplacements, les régions ou les modèles de coûts les plus efficaces et les plus performants. Sans employer une équipe d’assistants de réseau pour chaque environnement


Auteur
En savoir plus 
CTO
F5
Geng Lin est EVP et CTO chez F5
En savoir plus 

Livres blancs A la Une