Ce prototype apporte de la haute disponibilité, permet une gestion beaucoup plus simplifiée du cloud, faisant alors gagner un temps précieux pour la DSI.
Pour faire face aux nouveaux défis du multi-cloud, la capacité à développer des applications nativement multi-cloud apparaît comme une solution efficiente. Dominique Clairac, Leader Architecte Cloud chez onepoint à Toulouse, nous en dit plus.
Qu’est-ce que le cloud computing ?
En quelques années seulement, le cloud a totalement bouleversé les systèmes d’informations des entreprises en leur offrant une performance technique novatrice, sans limite de taille, de frontière ou de nombre d’usagers.
De manière générale, “le cloud computing est un ensemble de solutions permettant de fournir différents services à la demande, au moyen d’Internet” nous explique Dominique Clairac. Les principaux domaines ayant été révolutionnés par l’utilisation du cloud sont la communication, avec notamment les applications de messagerie, d’appels audio et vidéo mais aussi le stockage de données accessibles sur n’importe quel support, le développement et l’utilisation d’applications et la création de jeux vidéo.
Il existe trois types de cloud ; le public, le privé et l’hybride et chaque cloud peut être instancié de différentes manières (on premise, Cloud Services Provider, …). L’utilisation de plusieurs instances en simultané, appelée multi-cloud, s’est rapidement imposée aux entreprises désireuses d’obtenir de meilleures performances et une disponibilité plus importante. Une infrastructure multi-cloud comprend donc au moins deux instances de cloud différentes. Il peut par exemple s’agir d’un cloud privé et d’un cloud public ou bien de plusieurs clouds du même type. Ce système, quand il est bien géré, s’avère très efficace puisqu’il permet d’être flexible quant au choix des prestataires les plus performants, de sécuriser les données et de diminuer les ruptures de services.
Pourquoi faire le choix d’une stratégie multi-cloud ?
Pour Dominique, “La volonté de disposer d’une capacité de débordement est souvent la première raison citée, elle implique une hybridation entre le cloud privé de l’entreprise et un cloud provider externe. Il est aussi fréquent de retenir plusieurs clouds providers car chacun présente des avantages sur des services spécifiques (un cloud provider pour la data, un autre pour l’IA…). De manière moins fréquente, on trouve la volonté de disposer d’un PRA (Plan de Reprise d’Activité) à l’échelle d’un fournisseur, car, même si les clouds providers proposent aujourd’hui des zones de disponibilités, une panne totale d’un service n’est pas à écarter.”
Dans tous les cas, la mise en place d’une stratégie multi-cloud représente un investissement potentiellement important pour les entreprises. La gestion de plusieurs cloud providers, l’outillage nécessaire pour leur gestion, leur supervision et les différentes approches de déploiement imposent à l’entreprise une gymnastique souvent coûteuse. Cet investissement visant à maintenir plusieurs plateformes cloud pour faire « atterrir » les applications n’a pas de sens si les applications elles-mêmes ne sont pas prévues pour passer rapidement d’un provider à un autre sans surcoût ni délai. On retombe alors dans le vieux paradigme des serveurs d’applications, où les coûts de migration d’une application étaient souvent supérieurs aux économies de licence du serveur concurrent.
Pour toutes ces raisons, la stratégie multi-cloud doit être réfléchie de manière globale, en identifiant les bénéfices attendus (sécurité, PRA, services, usages, coûts, …) afin de pouvoir valider qu’ils seront suffisants pour compenser les coûts de mise en œuvre et de gestion. Une stratégie multi-cloud ne doit pas devenir une réponse « passe partout » censée éliminer tous les problèmes. Son ROI doit être soigneusement évalué.
Le rôle des applications dans une stratégie multi-cloud
Aussi paradoxal que cela puisse paraître, les applications jouent un rôle très important dans les stratégies Cloud, et à plus forte raison dans celles multi-cloud.
“Vous pouvez automatiser tout ce que vous souhaitez et disposer des plus grandes ressources au monde, si votre application ne sait pas les gérer, cela ne servira à rien.” explique Dominique.
Pour permettre l’absorption de la charge, l’amélioration de la performance ou encore la résilience d’une application, il existe de nombreuses méthodes, mais chacune de ces méthodes repose invariablement sur les deux mêmes prérequis :
- Un sous-jacent fiable, élastique et automatisable
- Une architecture applicative adaptée à ce sous-jacent
L’application doit pouvoir être instanciée plusieurs fois sans que cela ne pose de problèmes, elle doit pouvoir remonter les métriques nécessaires à l’anticipation du dimensionnement du sous-jacent … Pour toutes ces raisons, le travail autour des applications doit être initié en même temps que la stratégie cloud, voir même bien avant, dans l’idéal.
Pour Dominique : “Chez onepoint, lorsque nous accompagnons les entreprises dans leur stratégie Cloud, nous veillons à nous assurer que ces points sont bien pris en compte. Il est également très important de trouver un équilibre entre les Ops, qui devront prendre une position de fournisseur de service et les Devs, qui ne devront pas attendre que toutes les problématiques soient réglées par le sous-jacent.”
Dans cet exercice, les applications, et plus largement les équipes de développement, se placent en client et les Ops en fournisseurs de service. Pour que cela fonctionne, il faut impérativement que les services proposés soient en adéquation avec les besoins des développeurs. Il est donc inutile et contre-productif d’essayer de « forcer » les choses en imposant des verrous ou des parcours non adaptés aux attentes. Du côté applicatif, une vraie réflexion sur les enjeux est nécessaire, afin de pouvoir donner le plus de visibilité possible sur les attentes, et non les solutions. Les applications doivent donc établir leurs besoins, en fonction du contexte et des attentes des clients, et le rôle de l’ensemble des équipes est de fournir les outils permettant de répondre à ce besoin.
Les principaux écueils rencontrés
Tout est histoire d’équilibre entre les équipes, et comme souvent dans ce cas, il existe de nombreuses façons d’échouer à la mise en œuvre d’une stratégie cloud / multi-cloud. Dominique rencontre le plus souvent :
-
L’absence d’accompagnement à la conduite du changement
Lorsque l’on explique à un client l’importance de l’accompagnement au changement, dans les phases amont des projets, il y a très souvent un consensus, mais lorsque cet accompagnement se matérialise par un budget, il est fréquent de le voir « disparaître » de l’équation. C’est à la fois dommage et dommageable. Comme expliqué dans les précédents points, le rôle et la posture des équipes vont devoir changer, et cela s’accompagne généralement de changement sur les technologies, les processus… Tous ces changements entraînent des risques de dérive et le rôle d’une bonne conduite du changement est justement d’empêcher de tomber dans ces travers. Tous les exemples de facteurs d’échec présentés plus loin pourraient facilement être évités avec un accompagnement au changement par des équipes spécialisées, sous réserve de prendre au sérieux et de suivre leurs recommandations.
Le déséquilibre côté OPS peut se présenter de plusieurs manières. La plus fréquente consiste à imposer les plateformes et outils, sous couvert de sécurité, de raisons techniques et ou historiques. Cela peut se manifester par un refus de modifier l’existant, ou parfois en se substituant aux développements afin de proposer des solutions qu’ils estiment nécessaires. De nombreuses raisons peuvent expliquer ce comportement (peur du changement, volonté de conserver ou accroître le contrôle…) mais au final, cela génère de la frustration, une plateforme inutilisée car non adaptée et la création de shadow IT.
Le déséquilibre côté développement est souvent lié aux capacités cloud et au partage. Les développeurs peuvent facilement voir ce que les autres font grâce aux nombreux partages réalisés sur internet. Il devient très simple de tester des solutions en faisant abstraction de toute contrainte. Au final, il est courant que l’expression du besoin, en termes de plateforme, soit plus une expression de solution. Cette approche est aussi dangereuse que la précédente car elle place les OPS dans un rôle d’exécutant et ne permet pas la prise en compte de tout le contexte (sécurité, maintenabilité…). Ce n’est pas parce qu’une solution a été réalisée avec succès dans une entreprise qu’elle conviendra aux autres, et il est toujours préférable de co-construire une solution plutôt que de tenter de passer en force en ignorant les alertes.
La mise en place d’une stratégie cloud implique de prendre de nombreuses décisions et arbitrages, avec une grande partie des équipes. Chaque équipe dispose de ses contraintes et de ses objectifs et il est fréquent de rencontrer des divergences d’opinion dans la stratégie à mettre en œuvre. C’est là que doit normalement intervenir la gouvernance, comme un arbitre, qui après avoir pesé le pour et le contre, va poser un choix, le communiquer, et s’assurer qu’il soit suivi de tous. Malheureusement, il est fréquent de ne pas trouver de gouvernance (absence de choix) ou que celle-ci soit défaillante (choix non communiqués ou non suivis). On se retrouve alors dans un projet de transformation qui stagne, ou dans une entreprise où chaque équipe, service, application avance dans sa propre direction, supprimant toute capacité de mutualisation ainsi que de nombreux surcoûts.
-
Perte de vue des objectifs
Dans les grands projets d’entreprise, il est important de toujours conserver les objectifs en tête afin de ne pas s’en éloigner. Cela arrive pourtant assez souvent. On peut citer l’exemple des entreprises qui forment des experts absolus sur une technologie plutôt que de s’appuyer sur un éditeur ou une entreprise de service. Bien que ce choix puisse parfois se justifier, il est souvent préférable de gérer la technologie par un pool mutualisé et de concentrer ses ressources sur les spécificités métier apportant une réelle plus-value. Un autre exemple de perte de vue des objectifs, dans le monde de la stratégie cloud, consiste à vouloir passer 100% des applications en cloud-native, voire multi-cloud. Premièrement, toutes les applications ne sont pas compatibles avec ces approches et cela peut représenter un budget conséquent de les réécrire, mais surtout, il arrive que cela n’ait aucun sens ni aucun intérêt pour certaines applications. Il convient donc d’identifier les différentes typologies d’applications et de déterminer la place de chaque application au cas par cas, en résistant à la tentation de vouloir les placer toutes dans la case la plus haute.
Les différentes catégories d’applications cloud
Les différentes catégories sont propres à chaque entreprise, en fonction de leurs contraintes et de leurs attentes. Mais Dominique explique qu’on retrouve généralement les catégories suivantes :
- No cloud : Ne pouvant être déployées dans un cloud
- Cloud Ready : Compatible avec le cloud mais n’en tirant pas de bénéfice particulier
- Cloud Native : Conçue pour le cloud (scalable, automatisable, métriques adaptés…)
- MultiCloud : Conçue pour un déploiement à cheval sur plusieurs clouds
Toutes les catégories ne sont pas toujours présentes et les conditions d’appartenance à l’une ou l’autre varie fréquemment en fonction de l’entreprise, de son contexte et de sa maturité face au cloud.
Les applications multi-cloud
Le principe fondamental d’une application multi-cloud est sa capacité à gérer la perte d’un cluster/cloud complet. Le système est en fait déployé sur plusieurs clouds, sans que cela ait un impact ou soit perceptible par l’utilisateur final. Concrètement, l’application peut être installée à cheval sur Google Cloud Platform et Amazon Web Services mais les utilisateurs ne voient qu’une simple application.
Au-delà de répondre parfaitement aux questions de débordement cloud, cette application multi-cloud présente un réel intérêt côté coûts. En étant installée sur plusieurs providers, il devient alors possible d’augmenter le nombre d’instances sur chaque provider en ayant la capacité de passer d’un provider à un autre. Elle offre aussi une capacité de gestion des débordements totalement invisible pour l’utilisateur final.
En outre, cette approche apporte plusieurs bénéfices à l’entreprise. Tout d’abord, le fait de posséder une capacité de panne plus importante augmente la résilience du produit et donc sa qualité. Puis, grâce à une gestion du multi-cloud simplifiée, le débordement d’un cloud à l’autre se fait automatiquement et participe à introduire plus de souplesse. Enfin, le pilotage par les coûts devient possible, il permet de définir le pourcentage de requête judicieux à diriger vers tel ou tel provider, ouvrant ainsi grand la voie vers le FinOps.
Bien entendu, tout cela à un coût. Un coût applicatif puisqu’il est nécessaire de répondre aux trois principaux enjeux du multi cloud (le routage global, l’architecture et les données), mais aussi au niveau de l’infrastructure puisqu’il sera nécessaire de maintenir des composants sur plusieurs cloud, utilisant potentiellement des technologies différentes.
Dominique nous partage sa vision sur ces sujets
”Onepoint m’a rapidement permis de travailler sur des sujets autour du cloud et/ou de la conteneurisation. En 2017, j’ai pu remarquer que les plateformes d’orchestration de conteneurs étaient souvent sous utilisées (peu d’utilisation des capacités de self–service, pas ou peu de cloud Hybride) et présentaient une complexité d’utilisation pour un public non technique. J’ai alors pu travailler, avec d’autres collègues et Red Hat, sur un démonstrateur MultiPaaS, qui proposait de déployer de manière simple les projets à base de conteneurs, sur plusieurs plateformes PaaS. Les équipes pouvaient créer des templates de projet, avec par exemple un front angular et un back java. Le démonstrateur offrait une interface qui permettait de saisir :
- Le nom du projet.
- Le template du projet (type de projet)
- Le pipeline CI/CD (nombre d’environnements et règles de promotion)
- Pour chaque environnement du pipeline : La plateforme K8S à utiliser
Le dépôt git du projet était alors créé, sur la base du template et les différents environnements de build et de déploiement étaient automatiquement générés dans les différentes plateformes K8S, avec les règles de promotion automatiques. En 3 étapes, visuelles, graphiques et simples, tout l’environnement de déploiement du projet était créé et il ne restait plus qu’à commencer le développement. Les différentes plateformes K8S pouvant être déployées sur plusieurs cloud providers, il était possible de faire le développement et les builds sur AWS et de déployer la production on premise.
Dans la poursuite de cet exercice, j’ai eu l’occasion de travailler en 2019/2020 avec Red Hat et Træfik Labs autour du multi cloud. Nous avons pu mettre en place différentes plateformes OpenShift sur plusieurs cloud provider et déployer une application à cheval sur ces environnements. Cette expérimentation nous a permis de mieux appréhender les enjeux du multi cloud et les complexités pour sa mise en œuvre. Bien que très intéressant d’un point de vue technique, cette expérimentation dans le monde du multi-cloud m’a laissé une impression de travail inachevé. Elle répond aux problématiques techniques d’exploitation d’une telle application, mais nous avons perdu en cours de route la simplicité de déploiement et de génération qu’avait apporté MultiPaaS.
La technologie des plateformes K8S a bien évolué depuis 2019 et utiliser MultiPaaS comme nous le faisions à l’époque n’aurait pas vraiment de sens, mais mon prochain challenge pour les mois qui viennent consiste à fusionner ces 2 approches afin d’offrir une solution de self-service applicatif, simple à utiliser, évolutive, mais surtout compatible avec les différentes typologies de déploiements cloud et/ou multi-cloud.
Les questions à se poser pour définir une stratégie multi-cloud efficace
Analyser son aptitude au multi-cloud :
La première chose à savoir est si l’on souhaite se doter d’une capacité à faire du multi-cloud. Si oui, il sera alors important de définir le meilleur niveau de cloud, IAAS, PAAS ou SAAS. Dans le cas d’un cloud privé, le fournisseur et le consommateur étant souvent la même entreprise, cette différenciation est moins souvent utilisée. Elle existe parfois tout de même, notamment dans le cas de services différents, ou lorsque le cloud privé est externalisé de l’entreprise.
Du point de vue de la sécurité, de la performance et des coûts, la DSI doit se poser trois questions essentielles :
- Est-ce que je suis capable de gérer plusieurs plateformes de cloud ?
- Est-ce que je peux migrer d’un provider à un autre ?
- Est-ce que je maîtrise la sécurité informatique ?
Puis, elle doit identifier quels sont ses objectifs en matière de résilience, de coûts, de disponibilité de l’application, de gouvernance, de RSE, et tous autres critères pertinents à son activité.
À ce stade, il convient de faire un audit du parc applicatif afin de désigner les différentes applications et leur niveau de maturité. L’intégralité de ce parc ne pourra pas être multi-cloud natif et il convient donc de définir plusieurs niveaux (multi-cloud native, cloud ready, etc.) et d’y placer les applications, au cas par cas.
Ces premiers points permettent de déterminer si une stratégie multi-cloud a un intérêt ou non pour l’entreprise. Si tel est le cas, il est possible d’avancer vers cette transformation, en prenant bien soin de ne pas tomber dans les différents travers cités plus tôt dans cet article :
- Accompagner les équipes au changement
- Mettre en place une gouvernance et lui donner les moyens d’appliquer sa politique
- Créer des synergies de travail entre les équipes en s’assurant que chacune trouve sa place et sa nouvelle posture
- Vérifier régulièrement que l’on ne s’éloigne pas des objectifs
C’est un chantier complexe, qui prend du temps mais qui représente à long terme un véritable gain pour l’entreprise.
En accompagnant les entreprises dans la bonne résolution de ces étapes, tant au niveau technique qu’humain, onepoint se positionne comme un partenaire proactif des stratégies multi-cloud. Pour les collaborateurs du groupe, il est important de participer à la bonne intégration du passage à ce modèle par l’ensemble des équipes car c’est le secret d’une transformation réussie.
