Le multicloud représente le nouvel axe d’attaque des principaux fournisseurs d’infrastructure, mais qu’en est-il réellement aujourd’hui ? Comment les entreprises perçoivent-elles ce nouveau front d’évolution de leur informatique ?
Pas une conférence de presse, ni un événement, que ce soit en ligne ou non, qui ne fasse une place à la future grande tendance de l’informatique : le multicloud ! Le problème est que chacun a sa propre définition de la chose et que le concept combine souvent des réalités et des besoins différents. Ainsi pour certains c’est l’utilisation de différents Clouds publics. Pour d’autres c’est la combinaison entre un Cloud privé et un ou des Clouds publics. Pour d’autres encore, il faut y ajouter les différentes utilisations du SaaS (Software as a Service) et dans une moindre mesure du Edge Computing, qui dans bien des cas, rebat les cartes autour du Cloud.
Selon les cas exposés et les stratégies choisies par les entreprises, les besoins, les priorités et les nécessités ne sont pas les mêmes. On peut cependant regrouper les atouts d’une stratégie multicloud en différents thèmes : le fait d’éviter un verrouillage chez un fournisseur, une optimisation des tâches à effectuer, une automatisation plus poussée de la production informatique, une recherche de flexibilité et d’agilité, une équation économique différente en passant de dépenses en capital vers des dépenses en frais fixes…
Les raisons de choisir le multicloud
Le premier argument mis en avant pour développer une stratégie multicloud reste de ne pas être soumis au verrouillage sur une seule offre, le vendor lock-in. Celui-ci est une réalité et provient de l’aspect propriétaire de chaque pile de Cloud public. Il intervient lors du choix d’une base de données, d’une API vers tel ou tel stockage en ligne.
Pour Arnaud Lemaire, en charge de l’avant-vente chez F5 Networks, il s’agit surtout de chercher le moins d’adhérence possible avec les solutions de Clouds publics, afin de se garder une porte de sortie ou de réaliser des choix suivant le moment et les cas d’usages. Ce point est cependant moins évident dans le cas d’une hybridation entre un Cloud privé et le Cloud public.
Bien souvent, le choix est monocloud in fine. Dans la stratégie, ce sont souvent les entreprises qui visent plutôt à une consistance du système avec la possibilité de chercher des évolutions en cas de besoin ou, si nécessaire, comme on l’a vu récemment lors de la pandémie où il a fallu réagir rapidement pour trouver de la capacité et de l’espace. Ce choix est souvent retenu par des entreprises ayant fortement virtualisé leur environnement et qui souhaitent utiliser le même environnement dans le Cloud public et dans leur Cloud privé. En France, pour beaucoup, c’est surtout une étape sur le chemin d’un véritable multicloud public en se faisant la main car, bon an mal an, la plupart des Clouds publics fonctionnent de la même manière et de comprendre les subtilités d’un environnement souvent complexe.
Il ne faut pas oublier aussi l’importance du secteur d’activité de l’entreprise. Il est rare qu’une entreprise dans le secteur de la distribution choisisse AWS. Google est d’ailleurs en train de monter une offre spécifique pour viser les entreprises dans ce domaine et profiter de ce trou dans l’offre d’AWS.
Se décharger du patching
Le deuxième point important est l’optimisation et l’automatisation de la production informatique. Par le biais du Cloud public, les entreprises souhaitent trouver des possibilités d’opérations plus automatiques pour mieux répondre aux demandes des clients (internes ou externes à l’entreprise) en évitant d’avoir à gérer des tâches qui consomment du temps et de la ressource comme le patching ou toute autre tâche à faible valeur ajoutée dans les opérations de production. L’optimisation est un autre axe de ce point avec un choix qui s’approche de la spécialisation de chaque Cloud public. Selon la tâche à effectuer, l’entreprise va choisir le Cloud public le plus approprié. Ainsi du fait du choix d’un outil bureautique, l’entreprise va choisir Azure ou Google. De la même manière, l’entreprise va choisir le meilleur Cloud ou celui qui correspond le mieux à ses processus ou ses méthodes de production, son utilisation de l’Intelligence artificielle ou de la conservation des données. Voir l’exemple d’ASL Airlines (lire article dans ce numéro) qui utilise déjà le multicloud suivant les différentes tâches. Le troisième axe du choix du Cloud en général et du multicloud reste la recherche de flexibilité et d’agilité. La première stratégie est d’éviter d’avoir à acheter les ressources de production qui ne seront nécessaires que pour les pics d’utilisation. Le bursting permet d’acquérir, juste pour le temps nécessaire, les ressources pour passer des pics annuels ou mensuels comme un black friday dans le secteur de la distribution ou l’utilisation de ressources de traitement pour des opérations d’analytiques sans avoir à les conserver ou les maintenir en permanence. La possibilité d’avoir ainsi les ressources qu’il faut au moment qu’il faut est certainement un atout important. Il se décline comme on l’a vu précédemment par une distribution plus fine des tâches selon les points forts et les caractéristiques de chaque Cloud public.
Limiter l’adhérence
Ce point pousse aussi les entreprises à se lancer sur de nouvelles architectures dites cloud natives à base de containers et de microservices sous un orchestrateur, le plus souvent Kubernetes. Ce choix permet de limiter l’adhérence à un offreur de Cloud en garantissant une véritable portabilité aux applications d’un Cloud à l’autre.
La recherche d’optimisation des coûts vient après tout cela car il est souvent difficile de tenir la promesse que le voyage vers le Cloud, a fortiori dans le multicloud, soit moins cher. La facture dépend de nombreux paramètres et les entreprises découvrent souvent à ce moment des coûts cachés qui font grossir le prix. La connaissance des offres clouds et de leur prix est devenue une spécialité à part entière, le FinOps qui demande une réelle expertise.
Encore des freins
Les freins à un large déploiement sont connus mais tenaces. Le premier est la sécurité et tout ce qui en découle comme la conformité dans les secteurs très régulés. Elle n’est souvent pas prise en charge par les offreurs de Clouds publics. Ils se contentent d’offrir en général l’assurance que vous ne perdrez pas de données et que leurs centres de données sont protégés contre les attaques qui d’ailleurs sont de plus en plus fréquentes.
La deuxième pierre d’achoppement est le manque de ressources spécialisées dans ces nouveaux Clouds, souvent complexes et faisant appel à des technologies pas toujours très matures, mais qui demandent là aussi une véritable expertise. Les ressources sont rares et chères et le plus souvent situées chez les offreurs de services ou les sociétés de services d’où il est difficile de les faire partir à défaut de salaires mirobolants.
L’optimisation des coûts et la compréhension du modèle du Cloud est un autre frein car les entreprises ont du mal à être sûres que la promesse d’une visibilité sur les coûts est réelle. Le cas est critique lorsque les applications demandent beaucoup de mouvements de données, un poste qui coûte cher lorsqu’on choisit le Cloud.
Une réalité multiple
Le multicloud est une réalité émergente aux multiples facettes : PME qui fait du multicloud sans trop le savoir par un recours important au SaaS ; entreprises qui ont un environnement hybride; certains grands comptes qui ont la maturité et les ressources pour réaliser un choix judicieux entre les différents workloads à produire sur les Clouds les plus appropriés.
Si ce phénomène est déjà bien engagé en Amérique du Nord, il est encore balbutiant en Europe mais des exemples d’entreprises comme PSA ou la SNCF indiquent que cela sera la voie d’avenir pour les grandes entreprises dans un premier temps. Il reste encore à éviter l’écueil de recréer dans le Cloud les silos existants sur site ou dans les Clouds privés par des intégrations et des environnements qui doivent se standardiser autour de technologies comme les containers ou les microservices pour assurer la portabilité de Cloud à Cloud des workloads.
Gestion du multicloud
Le marché des logiciels de gestion des environnements multiclouds qui regroupe l’ensemble des logiciels pour la supervision, la facturation, ainsi que la gestion des ressources et services des services en ligne est un marché qui connaît une forte croissance selon le cabinet MarketsandMarkets. Évalué globalement à 1,165 milliard de dollars en 2017, le marché va être multiplié par 4 d’ici à 2022 pour un montant de chiffre d’affaires de 4,492 milliards de dollars avec un taux de croissance annuel pondéré de plus de 30%. Si la zone Nord-Amérique va rester la première utilisatrice, l’Europe suit juste derrière du fait d’un passage de solutions en Clouds isolées vers des plates-formes qui intègrent les éléments sur site, en Clouds privés et publics : 81% des utilisateurs de Clouds publics indiquent avoir différents fournisseurs. Les 5 premiers acteurs du secteur détiennent 77% de parts de marché dans le IaaS (Infrastructure as a Service). Dans une étude réalisée pour le compte de Turbonomic, 83% des répondants indiquent croire qu’ils vont pouvoir migrer librement des tâches d’un Cloud à l’autre. La sécurité et la portabilité des applications restent cependant les deux défis majeurs pour que cela devienne une réalité. À 43% les technologies de containers et d’orchestration vont jouer un rôle clé pour y parvenir. Plus de la moitié des utilisateurs de containers (en moyenne 4 applications containerisées) les font fonctionner dans des environnements hybrides combinant Clouds privés et publics, voire sur site. À une forte majorité, ces entreprises se tournent vers Kubernetes (86%), quelle que soit la forme d’utilisation.
Des impacts sur l'infrastructure
On ne se réveille pas un matin en se disant que son entreprise devrait aller vers le multicloud. Cette voie demande un vrai projet et les impacts sur l’infrastructure sont souvent importants.
Oubliez de croire que passer dans le Cloud, et a fortiori à une stratégie multicloud, va vous débarrasser à jamais d’une infrastructure informatique dont la gestion n’est pas votre métier et qui pèse lourd dans votre budget. Passer au multicloud demande souvent beaucoup d’attention et si les offreurs s’occupent du côté « physique » de la démarche, il reste à la charge de l’entreprise de veiller à son bon fonctionnement.
De nombreux services à déployer
Les entreprises n’entreprennent pas une démarche multicloud sans un but précis : déployer des applications cloud native, éviter le verrouillage chez un fournisseur et les autres cas que nous avons vu les pages précédentes de ce numéro sur la réalité du multicloud aujourd’hui.
Le premier point important est le réseau. Pour une application ou simplement avoir des échanges avec des machines virtuelles ou des containers placés dans un Cloud public, il est nécessaire de disposer d’une bande passante à l’échelle des besoins. Cela peut nécessiter des discussions et des remises en cause de la situation présente avec l’opérateur de télécommunication qui est utilisé. Il convient ensuite de veiller à la performance de l’application, de la latence. Le passage de passerelle en passerelle n’ajoutant que quelques millisecondes peut parfois faire que l’utilisation d’une application en ligne devienne un vrai calvaire. La tendance actuelle dans les entreprises ayant entamé une démarche multicloud est de passer par des liaisons privées de type DirectConnect ou ExpressRoute, des liaisons directes vers les différents Clouds publics mises en place par les fournisseurs de Cloud comme nous l’a indiqué Fabrice Coquio, en charge de la destinée d’Interxion en France. C’est le choix qu’il constate dans ses centres de données en colocation.
Ce choix ne résout pas tout car la mise en œuvre demande le déploiement de différents services pour obtenir la performance ou la latence désirée. Dès le code d’une application développé, il s’agit ensuite de mettre en œuvre un serveur d’applications ou un serveur web, un contrôleur d’entrées/sorties, une passerelle d’API, un répartiteur de charge, les outils de sécurité, le service DNS, le service contre les attaques DDoS et le service de livraison d’applications adéquat pour avoir quelque chose d’utilisable. Ces briques proviennent souvent de fournisseurs différents et il faut donc veiller à leur bon fonctionnement ensemble. De plus, tous ne s’adaptent pas à l’ensemble des architectures qu’elles soient monolithiques, trois tiers ou de microservices. Au bilan, les services se retrouvent en silos ce qui multiplie les coûts et la complexité. Imaginez répéter cette chaîne de services sur l’ensemble des Clouds que vous voulez utiliser ! Il existe des solutions comme celle de F5 qui simplifie cette chaîne en prenant en charge la plupart des éléments que nous avons cité. Cet éditeur n’est pas le seul.
Machines virtuelles ? Containers ? Bare Metal ?
Le choix dans le Cloud des serveurs ou du stockage dépend du cas dans lequel l’entreprise développe sa stratégie cloud ou multicloud. Consistance, agilité, nouvelles applications nativement cloud ? Les cas de figure sont nombreux. Pour du burst ou de l’extension dans le Cloud de l’infrastructure présente dans le Cloud privé ou le centre de données, il est souvent préférable de mettre en place la même infrastructure dans le Cloud. Le Cloud public choisi ne sera ainsi qu’une extension de votre environnement existant.
Le projet devient plus complexe lorsqu’il s’agit de mélanger différents environnements demandant des infrastructures différentes comme un environnement fortement virtualisé dans le centre de données et des déploiements en containers dans le Cloud. Les environnements demandent parfois des outils différents pour leur administration, leur suivi ou leur orchestration dans des processus. Des plates-formes comme celle de VMware ou de Nutanix visent à simplifier la question en prenant en compte l’ensemble des environnements. Ces deux éditeurs sont cités à titre d’exemple, il existe d’autres solutions sur le marché qui permettent de faire de même.
À noter que le choix du bare metal est souvent lié à l’utilisation de containers et à la recherche de la performance pour éviter la couche de virtualisation qui pourrait ralentir les accès à la ressource.
La montée à l’échelle de l’utilisation peut entraîner aussi une inflation des ressources nécessaires. Fabrice Coquio, que nous avons déjà cité, indique constater chez ses clients une augmentation de la densité des matériels avec des racks de 56 U qui demandent des ressources en électricité et de refroidissement importantes ayant un impact sur les coûts de production. Il s’agit donc de bien suivre la structure de coûts d’exploitation de l’environnement en mettant en place des métriques adaptées et en effectuant les bons scénarios de tests avant de se lancer, comme les tests de charge par exemple.
La sécurité au centre de l’ensemble
Avec le passage dans différents Clouds, les entreprises augmentent la surface d’attaque contre elles. La tendance des utilisateurs est de choisir des solutions totalement sous forme de services en ligne ou de déléguer cette fonction à un prestataire dans des SOC (Security Operations Centers) dédiés à la sécurité de l’environnement. Cela implique cependant de mettre en place des structures de contrôle pour suivre ce qui se passe et être prêt à réagir si un incident ou une attaque survient.
De plus il est nécessaire de mettre en place le respect des règles de conformité demandées par la législation ou les règles de l’entreprise. Un moyen intéressant de mise en œuvre passe par une véritable gouvernance des usages du Cloud avec une gestion des identités et des accès, une protection des données adéquates suivant la criticité de ces données.
Éviter de recréer des silos
Du fait des côtés propriétaires de chaque Cloud public, il est nécessaire de ne pas recréer des silos dans un autre environnement si ce n’est par un choix conscient de spécialisation de chaque Cloud choisi en fonction de son utilisation tel pour les applications analytiques, tel pour les tests, tel pour les applications transactionnelles et les bases de données. Il convient surtout de veiller aux flux de données entre ces Clouds car c’est ce qui alimente la facture. L’intégration et la maîtrise des API devient donc un enjeu majeur dans ce contexte. L’optimisation des flux est un point important ou du moins un point de réflexion à approfondir. Cela peut impliquer de revoir certaines applications par trop bavardes voire de décider de ne pas les mettre dans le cloud de ce fait. Il convient aussi de s’interroger sur la portabilité de ces applications d’un cloud à l’autre. Pour le faire les entreprises se convertissent aux architectures sur containers avec comme chef d’orchestre Kubernetes. Par ces caractéristiques le container assure cette portabilité puisqu’il enveloppe tout ce que l’application nécessite pour fonctionner sur un environnement. La décomposition des applications en containers en microservices est assujettie à la maîtrise des APIs pour créer des processus par des chaînes de microservices. Ces microservices ne sont cependant pas la panacée et réclament une grande attention du fait de la complexité qu’ils ajoutent dans l’infrastructure et dans la gouvernance, de la surcharge sur le réseau ou la latence pour y accéder, la cohérence des données, la gestion des versions…
Une automatisation nécessaire
Pour faire fonctionner l’ensemble il devient vite nécessaire d’automatiser le fonctionnement en production du fait à la fois de l’échelle à laquelle l’infrastructure va produire, sa complexité. Une des tendances est d’ailleurs de s’appuyer de plus en plus sur des outils qui autorisent cette automatisation par l’ajout de fonctions d’apprentissage machine ou d’intelligence artificielle (AIOps) pour à la fois automatiser la production mais aussi prédire ou prévoir des incidents et ainsi assurer une disponibilité maximale de l’infrastructure et de l’environnement. IBM, Nutanix, Dell EMC, et les offreurs de clouds proposent en général ces processus d’automatisation sans lesquels la gestion quotidienne d’un multicloud peut devenir rapidement un casse-tête.
Les impacts collatéraux
Ces changements à la fois dans la manière de produire l’informatique, de développer des applications, jusqu’à leur mise en œuvre sur des Clouds publics demandent de plus de ressources humaines rares sur le marché. La plupart des spécialistes des nouveaux environnements comme les containers ou Kubernetes sont chez des éditeurs ou des sociétés de services informatiques. Les débaucher demande un véritable budget. Le salaire moyen d’un salarié dans le DevOps est de plus de 43000 € en moyenne actuellement. Pour un salarié vraiment expérimenté il faudra mettre plus de 75000 €! Bref il s’agit de savoir sur quoi l’on s’engage.
Il convient aussi de bien cerner au plan légal les responsabilités de chacun avec les fournisseurs de Clouds et de préparer à la fois les migrations d’un environnement à l’autre mais aussi de documenter les procédures de roll back ou de réversibilité si nécessaires. Cela permet d’éviter des – mauvaises ? – surprises. De plus, pour être complet sur le niveau «administratif» du multicloud, un suivi financier strict semble important. Des éditeurs comme Apptio ont des plates-formes qui permettent de suivre les dépenses sur les différents Clouds mais aussi d’éviter par leur framework des coûts cachés ou non prévus lors de la mise en place du projet visant à se développer dans différents Clouds.
Les applications brisent leurs chaînes
Les frontières entre Cloud privé et Cloud public et entre acteurs du Cloud s’estompent. Bases de données et applications s’affranchissent de plus en plus des plates-formes : une révolution rendue possible par l’essor des conteneurs et de Kubernetes.
S’il est de plus en plus simple de basculer des machines virtuelles d’une ferme de serveurs on-premise vers le Cloud public, ou même d’un fournisseur cloud vers un autre, obtenir une telle souplesse au niveau des applications reste une tout autre affaire. Les applications ont de multiples dépendances vis-à-vis de leur infrastructure qui vont compliquer sa migration vers le Cloud. Même une application moderne déployée pour Azure ou AWS et qui fait appel à des services PaaS de ces plates-formes risque de demander beaucoup d’efforts d’adaptation pour être transférée vers un autre fournisseur cloud.
Déployer une base de données MongoDB indifféremment
sur les trois hyperscalers du marché, c’est la vocation d’Atlas. Une tendance
forte chez les fournisseurs de bases de données As-a-Service.
Les éditeurs de base de données, notamment les challengers ont cherché à faciliter la tâche des développeurs. Snowflake, par exemple, prône l’agnosticité en matière de Cloud. «Le multicloud est incontestablement une tendance forte», explique Olivier Leduc, directeur technique France de Snowflake, « Les entreprises développent une stratégie multicloud, avec des clients qui ont un compte principal sur la côte Est sur AWS, par exemple, un compte secondaire sur la côte Ouest chez Azure et qui répliquent tout ou partie de leurs données de manière très simple.» Bien que non disponible en mode on-premise, Snowflake supporte aujourd’hui tant AWS qu’Azure et GCP pour supporter son offre de base de données cloud. Venu du monde on-premise, son rival MongoDB a lui aussi déployé une stratégie multicloud via son offre Atlas, MongoDB propose une solution simple de déploiement des bases de données indifféremment sur AWS, Azure et Google Cloud. Enfin, avec Autonomous Operator 1.2, Couchbase autorise lui-aussi un déploiement sur AWS, Microsoft Azure, Google Cloud ainsi que OpenShift, la plate-forme de conteneurs de Red Hat qui s’appuie sur Kubernetes.
Kubernetes s’est imposé comme standard de fait
Car si les conteneurs ont apporté plus de souplesse dans le déploiement des applications, c’est bien les orchestrateurs qui permettent aujourd’hui aux applications de passer au multicloud. Des entreprises restent fidèles à Docker Swarm ou Nomad, c’est bien Kubernetes qui s’est imposé comme le standard de fait du marché pour orchestrer des conteneurs. Les fournisseurs l’ont bien compris en proposant des offres Kubernetes managées à l’image du français Scaleway, filiale cloud du groupe Iliad. Yann Lechelle, CEO de Scaleway souligne le succès immédiat de cette offre très attendue : « Nous venons de lancer Kubernetes Kapsule, une solution qui permet de déployer facilement des infrastructures selon le modèle Infrastructure-as-code. C’est une solution qui était très attendue et qui a été très bien reçue car nos clients se sont emparés de cette offre et ont fait exploser la consommation de ressources.»
L’architecture de l’infrastructure Anthos proposée par Microsoft
s’appuie sur les composants Google GKE et Google Cloud
Ingress for Anthos pour la partie Cloud public et Anthos GKE on-prem
pour le volet on-premise de l’infrastructure Google.
Kubernetes s’est imposé en tant qu’orchestrateur, pour aider les entreprises à opérer des infrastructures de conteneurs, mais pour passer au multicloud, sont apparus des stacks complets dédiées à ces nouvelles infrastructures Hyper-Cloud. Une surcouche nécessaire, selon Rachid Zarouali, ex-socker captain, Microsoft Azure MVP et fondateur de SevenSphere : « Si les conteneurs permettent de facto de ternir la promesse de faire s’exécuter une application sur n’importe quel Cloud, l’une des clés du succès d’une migration applicative vers le Cloud est de rendre tous les éléments de configuration de celle-ci le plus agnostique possible en intégrant dans le process de migration, l’utilisation de solutions d’infrastructure as code – exemple Hashicorp Terraform – et de configuration management – comme Red Hat Ansible – tout en s’appuyant sur ce qu’offrent les fournisseurs cloud pour fournir à l’application ce dont elle a besoin pour fonctionner.»
Google Anthos et Azure Arc, une vision du multicloud
Pour répondre à ce besoin, l’expert pointe deux solutions qui ont été lancées en 2019 : Google Anthos et Azure Arc de Microsoft. Google a été le premier à ouvrir le bal, dévoilant sa solution Anthos lors de l’événement Cloud Next 2019. « C’est un produit qui a été conçu afin de permettre à nos clients de construire une application une seule fois puis de l’exécuter dans leur datacenter, la déployer sur le Cloud Google ou tout autre fournisseur cloud sans changer une seule ligne de code, le faire de manière sûre et monitoré de façon 100% consistante », résumait ainsi Thomas Kurian CEO de Google Cloud. Anthos s’appuie sur des standards du marché, à savoir Kubernetes, Istio solution de service Mesh permettant un support des microservices et Knative, une brique logicielle destinée à supporter des fonctions Serverless. Elle apporte portabilité et agilité et fournit un jeu d’API ouvertes pour orchestrer des VM et des conteneurs. Si la capacité de faire tourner la solution chez plusieurs fournisseurs de Cloud public, l’objectif numéro 1 pour Google est de supporter des architectures hybrides on-premise/Google Cloud, notamment en aidant les entreprise à migrer leurs workloads logicielles avec son outil Migrate for Anthos. Face à Anthos et l’initiative prise par Google dans l’approche multicloud, Microsoft a répliqué quelques mois plus tard en dévoilant Azure Arc lors de la conférence Ignite en septembre 2019. La solution est disponible depuis quelques semaines, avec la capacité de géodistribuer une base de données ou une application sur des datacenters on-premise, Azure ou encore AWS. Erin Chapple, vice-président Azure Compute chez Microsoft soulignait lors du lancement : « Azure Arc va vous permettre d’apporter les innovations d’Azure dans votre datacenter et virtuellement n’importe où. La géoréplication permet de répliquer un datacenter on-premise sur un autre ou vers un datacenter Azure et même sur AWS. C’est une première dans l’industrie ! Azure Arc va unifier les opérations et apporter de la cohérence et de l’agilité entre tous ces datacenters.» Parmi les fonctionnalités présentées par Microsoft, l’extension des fonctionnalités Azure Data Services sur les infrastructures on-premise de l’entreprise déclarées dans Azure Arc et déployer des conteneurs Azure SQL Database ou Azure Database for PostgreSQL directement depuis la marketplace Azure en quelques clics seulement. D’autre part, l’administrateur a accès aux fonctions de sécurité d’Azure, notamment la détection de vulnérabilités, la génération d’alertes et l’application des règles de sécurité définies pour Azure. La gestion des mises à jour des composants logiciels est pilotée depuis les règles définies sur Azure de même qu’il est possible d’ajouter des nœuds de traitement pour faire face à une montée en charge. Kubernetes est lui aussi géré au travers du portail.
Le plan de migration graduel de la VM vers les conteneurs tel que le conçoit Google avec Migrate for Anthos.
VM et conteneurs vont cohabiter encore un certain temps dans les architectures.
L’indépendance vis-à-vis des fournisseurs cloud reste un défi
La limite de l’approche défendue par Google et Microsoft est que, si une infrastructure multicloud devient réellement possible via Anthos et Azure Arc, l’administration elle-même de cette infrastructure reste liée à l’un ou à l’autre de ces fournisseurs. Pour les entreprises qui souhaiteraient rester indépendantes en matière d’outils et rester indépendantes vis-à-vis de leurs fournisseurs cloud, Red Hat pousse sa plate-forme OpenShift. « Lorsqu’elle mène la modernisation de ses applications, l’entreprise doit pouvoir conserver sa liberté de choix en termes d’infrastructure. Elle ne doit pas se lier à l’infrastructure d’un fournisseur cloud, quel qu’il soit, en faisant appel à des services PaaS ou des fonctions serverless exclusives à ce fournisseur », rappelle Ramzi Ben Ouaghrem, CTO Cloud & Cognitive, IBM France. OpenShift est aujourd’hui une solution mature et la version 4.4 qui dispose de ce que Red Hat appelle des opérateurs qui permettent d’automatiser de multiples aspects de l’administration d’une plate-forme multicloud, mettre en place des mises à jour automatiques, une approche de type Infrastructure as a service. « L’intérêt des opérateurs, c’est aussi qu’ils sont transférables : un opérateur qui automatise la mise à jour de Kubernetes 1.7 vers 1.8 va pouvoir être utilisé sur d’autres clusters et la communauté peut mettre à profit des opérateurs développés par la communauté.» Parmi les dernières nouveautés apparues sur la plate-forme Red Hat figurent notamment Knative et Istio. Le responsable souligne que l’outil IBM multicloud Manager prend en charge tant les conteneurs que les bonnes vieilles VM, signe les applications réellement conteneurisées et capables de tirer profit de Kubernetes que vont devoir cohabiter encore quelque temps avec des applications classiques qui se contenteront de tourner sur des VM en attendant d’être modernisées.
Quelques mois après Google, Microsoft a lancé son stack
multicloud avec des choix techniques très proches de ceux
de son rival ou encore d’OpenShift 4.4. L’idée est bien pour
chaque acteur de se positionner en tant que pivot essentiel de
la stratégie multicloud des entreprises.
Tous les éléments se mettent en place pour qu’une approche logicielle véritablement multicloud soit une réalité avec des outils à la fois agnostiques vis-à-vis des fournisseurs qui vont permettre de rendre les architectures multicloud d’une part efficientes, mais aussi plus facilement maintenables sans devoir s’appuyer sur les effectifs d’Ops pléthoriques que seuls les géants de la Silicon Valley peuvent se permettre d’entretenir. Il reste sans doute de nombreux points à régler, notamment dans le domaine de la sécurité applicative. Néanmoins le temps où une application peut se déployer et se répliquer automatiquement en fonction de la charge, des temps de réponse mesurés auprès de chaque fournisseur cloud, de la consommation énergétique ou même en fonction des tarifs dynamiques de ces derniers, n’est plus tout à fait du domaine de la science-fiction.
Azure Arc à l’œuvre, avec la démonstration d’une application bancaire distribuée sur trois datacenters on-premise mais aussi répliquée sur Microsoft Azure et AWS dans des régions géographiques où l’entreprise ne dispose pas d’infrastructures, le tout géré à partir d’un point unique.
Avec son logiciel IBM MultiCloud Manager, IBM a enrichi la gestion de cluster
de Red Hat OpenShift (Advanced Cluster Management)
en lui donnant la capacité de gérer tant des VM que des conteneurs.
« La portabilité entre Cloud est une réalité, mais cela n’a rien de magique »
Ramzi Ben Ouaghrem, CTO Cloud & Cognitive IBM France
« La portabilité des applications d’un Cloud à l’autre est aujourd’hui une réalité. La plate-forme OpenShift peut être déployée sur n’importe quelle plate-forme cloud et nous ajoutons d’année en année de plus en plus d’automatisations pour que les migrations imposent un minimum d’interventions au niveau des applications. Mais cela n’a rien de magique : si une entreprise fait du Lift and Shift d’applications vers OpenShift et le Cloud IBM, elle bénéficiera de la résilience de l’infrastructure et le basculement de la charge d’un datacenter à un autre en cas d’indisponibilité mais pour véritablement tirer profit de Kubernetes, il faudra intervenir au niveau du code de l’application. Lorsqu’on va moderniser l’application, il faut que celle-ci tiennent compte des fonctionnalités que Kubernetes va lui fournir et indiquer par exemple comment tel ou tel conteneur doit redémarrer en cas d’incident.»
« Le vrai challenge de l’Hyper-Cloud reste la qualité de service »
Rachid Zarouali, fondateur SevenSphere
« Lorsqu’on parle de migration d’applications, il faut garder à l’esprit que les conteneurs et les solutions d’orchestration facilitent une migration d’une infrastructure on-premise vers un fournisseur de Cloud public. Les technologies actuelles le permettent, mais il faut surveiller deux points. D’une part, il peut être nécessaire d’adapter les applications à cette nouvelle architecture. Il faut donc s’assurer d’avoir accès au code source. D’autre part, il faut adresser la problématique de la persistance des données, pour que les données produites par l’application ne soient pas soumises au cycle de vie éphémère des conteneurs. Tous les Cloud providers fournissent des solutions de stockage déporté qui s’interfacent avec Kubernetes, la solution d’orchestration de conteneur de facto. Le vrai challenge de l’Hyper-Cloud ou le MultiCloud réside dans la façon dont on va distribuer l’application, tout en conservant sa qualité de service. Deux solutions développées par des Cloud providers tendent à répondre à ce besoin : Google Anthos et Azure Arc. D’autres solutions comme RedHat OpenShift, Konvoy, Kommander et Dispatch de D2IQ (ex: mésosphère), VMware vsphere7 ou encore Rancher cherchent à adresser la problématique du MultiCloud en offrant un niveau d’intégration plus ou moins poussé avec les différents Cloud providers supportés.»