Stratégie

Migration vers le cloud : 4 pistes pour réduire votre dépendance aux fournisseurs

---

L'utilisation de services cloud natifs débouche sur certains avantages, mais ont aussi une face obscure : la dépendance au fournisseur ou lock-in. Voici comment les DSI peuvent planifier efficacement la migration de leurs applications vers le cloud sans se retrouver pieds et poings liés.

PublicitéUne fois que les entreprises ont mis en production des applications critiques dans le cloud, elles changent rarement de fournisseur. L'une des principales raisons de cette stabilité est qu'elles sont souvent enfermées dans l'écosystème dudit fournisseur. Le coût de la migration est tout simplement trop élevé, explique Sid Nag, vice-président des services et technologies cloud chez Gartner. « Mais si vous planifiez correctement votre migration, vous ne devriez pas avoir à déplacer vos applications », ajoute-t-il.

Pablo Del Giudice, partenaire au sein du studio cloudops et cybersécurité de la société de services Globant, ajoute que la migration implique de positionner correctement son organisation. Ce à quoi son équipe et lui ont veillé. « La stratégie clef est d'adopter des plateformes et des frameworks techniques ouverts, reléguant le prestataire de cloud au rôle de fournisseurs d'une couche d'infrastructure », explique-t-il. Bien que cette approche implique, pour la DSI, d'en passer par une courbe d'apprentissage plus raide, elle donne des résultats plus favorables à moyen et à long terme, selon lui. « La clé est de faire appel à un architecte logiciel indépendant de toute plateforme, capable de délimiter les frontières de l'entreprise et de créer des solutions qui sont moins liées à un fournisseur spécifique. »

Jamie Holcombe, DSI de l'Office américain des brevets et des marques (US Patent and Trademark Office ou USPTO), a un point de vue un peu plus nuancé : il veut garder des options ouvertes pour déplacer les applications entre les fournisseurs de cloud, et continue à mener une veille technologique active sur les principaux d'entre eux. Mais pour ce faire, avant de transférer une application dans le cloud pour la première fois, il faut planifier avec soin sa feuille de route.

1) Comprenez les risques de verrouillage et réduisez-les

Exploiter les services cloud-natifs de chaque fournisseur revient à évaluer le compromis que cela suppose. « Si vous choisissez de ne pas utiliser les services cloud natifs d'un fournisseur afin de rester agnostique, vous allez reculer sur un grand nombre d'indicateurs de rentabilité, de type 'meilleur, moins cher, plus rapide', explique Jamie Holcombe. L'indépendance a un coût, tout comme l'enfermement dans la plateforme d'un fournisseur en a un ».

Pablo Del Giudice distingue trois formes de lock-in. D'abord, le verrouillage à la plateforme associé à une configuration de base complète (groupement de ressources, politiques, contrôles d'accès, connectivité hybride, monitoring, conformité, etc.) qui rend la migration vers un autre fournisseur difficile en raison de la complexité à recréer ce socle sur une nouvelle plateforme. Ensuite, le verrouillage architectural lorsque l'application repose sur plusieurs services managés par le fournisseur de cloud. Dans ce cas, il faut réarchitecturer l'application avant d'envisager sa migration. Enfin, il y a le verrouillage juridique, qui consiste à s'engager dans un accord de service pour une durée prédéterminée. « Ces engagements sont difficiles à résilier et compliquent les migrations », explique-t-il.

Publicité
Jamie Holcombe, DSI de l'Office américain des brevets et des marques (USPTO) : « Ne signez pas avec un fournisseur si vous n'avez pas d'accord vous permettant de savoir comment sortir vos données de sa plateforme. » (Photo : D.R.)

Parfois, le lock-in survient malgré les efforts déployés par le DSI pour l'éviter. Les fusions et acquisitions laissent souvent les organisations avec des architectures multicloud, observe Sid Nag, et bien que les DSI veuillent généralement consolider, le coût est souvent trop élevé pour être justifié. La plupart du temps, ces DSI décident alors de conserver le modèle multicloud contraint et forcé. « Vous êtes pris au piège, pour de bon », résume l'analyste au Gartner.

Mais les entreprises peuvent avoir de bonnes raisons de migrer d'un fournisseur IaaS à l'autre, malgré les obstacles, explique Pablo Del Giudice. Les raisons les plus courantes visent à obtenir un meilleur rapport entre la valeur et l'opex, à profiter d'une remise agressive d'un fournisseur concurrent ou à tirer parti d'une architecture multicloud lorsque l'entreprise souhaite améliorer sa résilience.

2) Anticipez les potentielles migrations futures

La volonté de déplacer des applications clés entre fournisseurs de cloud, ce que Gartner appelle le "rapatriement de cloud", est généralement le résultat d'une mauvaise planification, selon Sid Nag. Il voit ce type d'opérations dans les déploiements de type "lift and shift" vers le cloud, mais aussi lorsque les entreprises décident d'utiliser des middlewares et des outils de développement cloud-natifs à un prix abordable avec l'intention de déplacer l'application vers un cloud privé lorsqu'elle sera prête à passer en production.

Il recommande de faire appel aux services d'un MSP ou d'un intégrateur pour bien planifier les migrations et s'assurer que celles-ci ciblent bien les bonnes applications. « C'est important parce qu'une fois que vous les avez transférées, vous acceptez d'être verrouillé sur la plateforme. »

La société de services financiers USAA a soigneusement choisi lequel de ses quatre fournisseurs de cloud hébergerait chacun de ses services et applications commerciales. « Nous avons aligné les fournisseurs sur les services métiers ou techniques qu'ils maîtrisent le mieux », explique Jeff Calusinski, vice-président et directeur de la technologie de la société basée au Texas. La stratégie multicloud de l'institution est fondée sur ce qu'il appelle ses principes "open by design". « Nous utilisons des normes ouvertes, lorsqu'elles existent, ce qui réduit le risque de lock-in », explique-t-il, tout en admettant que certains services cloud-natifs sont associés à une proposition de valeur convaincante qui doit être mise en balance avec le risque de verrouillage.

En outre, les principes d'open design ne vous règlent pas toutes les problématiques de verrouillage, observe Sid Nag, car même lorsque vous utilisez des services modernes, la mise en oeuvre sur chaque plateforme diffère. Par exemple, le substrat EC2 d'Amazon fait la même chose que le GCP de Google, mais une application fonctionnant sur EC2 ne fonctionnera pas sur GCP sans un travail de remaniement très coûteux. Et bien que Kubernetes soit un standard de fait dans l'industrie, ses implémentations, telles que Azure Communication Services et Google Kubernetes Engine, ne fonctionnent pas de manière identique.


Pablo Del Giudice, partenaire au sein du studio cloudops et cybersécurité de Globant : « certaines couches d'abstraction sont apparues entre les fournisseurs de cloud et les applications ». (Photo : D.R.)

« Toutefois, certaines couches d'abstraction sont apparues entre les fournisseurs de cloud et les applications », note Pablo Del Giudice, et elles peuvent simplifier les migrations même quand des services natifs de fournisseurs sont utilisés. « Ces services, tels que pub/sub (pour publish-suscribe, mécanisme de publication de messages et d'abonnement à ces derniers, NDLR) , l'invocation de services, la gestion des secrets, la gestion des états, etc., agissent comme une forme d'abstraction pour les composants de l'application quel que soit le fournisseur de cloud ». Grâce à ces leviers, selon lui, « vos options restent ouvertes, même si certains travaux restent nécessaires pour passer d'un fournisseur de cloud à un autre ».

La question des données nécessite également une planification minutieuse. « Déplacer une application d'un nuage à l'autre est coûteux car vous devez également déplacer les données associées, et la sortie des données d'une plateforme cloud est une opération très coûteuse », rappelle Sid Nag. Il faut donc s'y préparer, ajoute Jamie Holcombe : « Ne signez pas avec un fournisseur si vous n'avez pas d'accord vous permettant de savoir comment sortir vos données de sa plateforme et comment répliquer ces services logiciels ailleurs ».

Selon Pablo Del Giudice, si une stratégie ETL adéquate permet de transférer les données d'un fournisseur à l'autre de manière structurée et dans un format utilisable, ces plans sont souvent inexistants dans les entreprises. « Bien que les fournisseurs de cloud mettent l'accent sur l'utilisation de plateformes ouvertes et de protocoles d'accès aux données, qui sont en théorie faciles à utiliser, les entreprises négligent les questions liées au réseau et à la sécurité dans l'accès à ces services. »

Lorsqu'il s'agit de choisir les services cloud-natifs à utiliser, les entreprises n'ont parfois pas le choix. La sécurité en est un bon exemple. « Si vos besoins en matière de sécurité sont élevés, une cybersécurité générique peut ne pas suffire », explique le DSI de l'Office américain des brevets et des marques (USPTO). Plus vos besoins sont spécifiques, plus le service devient rigide et plus le lock-in se renforce. Les entreprises dont les activités sont gourmandes en données sont confrontées à des problèmes de stockage et de bande passante, ajoute-t-il, précisant que les fournisseurs de PaaS et d'IaaS utilisent ces deux facteurs pour se différencier de la concurrence. « Si vous essayez d'obtenir des performances élevées sur ces deux plans, vous serez vite verrouillés à un fournisseur. »

Jamie Holcombe suit ce qu'il appelle l'approche "black spruce" (épicéa noir) pour les personnalisations qui exploitent les services cloud-natifs. Tout comme l'épicéa noir garde ses branches près du tronc, l'USPTO garde ses personnalisations aussi limitées que possible, dit-il. Cela permet non seulement de réduire le lock-in, mais aussi de s'assurer que l'organisation ne va pas se trouver confrontée à ce qu'il appelle un versioning surchargé et coûteux. Jeff Calusinski (USAA) adopte une approche similaire. « La plupart des options PaaS ont une capacité principale et un ensemble de fonctionnalités auxiliaires. Nous limitons l'usage de ces dernières et nous nous concentrons sur l'essentiel. »

Il en va de même pour les applications basées sur le SaaS, ajoute Jamie Holcombe (USPTO est par exemple passée de Remedy à ServiceNow et Salesforce). « Ne personnalisez pas beaucoup et soyez en mesure de changer quand vous en avez besoin », résume le DSI. « Nous ne sommes pas dépendants de ces fournisseurs et c'est structurellement une bonne base. Mais si ces plateformes sont surchargées d'optimisations, vous êtes coincés. » Sur ce terrain, le directeur de la technologie de USAA aborde les choses différemment. « Avec les plateformes SaaS, nous adoptons autant que possible la plateforme parce qu'en tant qu'entreprise, nous ne voyons pas assez de différenciation entre les capacités des différents fournisseurs, et la probabilité de migration est faible. »

3) Prévenez les éventuelles difficultés liées aux migrations

La migration entre fournisseurs de cloud présente une myriade de défis. Problèmes de compatibilité et de sécurité, nécessité d'une reconfiguration approfondie des applications, gestion d'images maîtres basées sur d'anciens systèmes d'exploitation, adaptations de piles technologiques obsolètes qui ne s'intégreront pas de manière transparente dans le nouvel environnement, etc. Le transfert de grandes quantités de données peut également entraîner des temps d'arrêt et des pertes de données potentielles, et il est essentiel de garantir des performances et une évolutivité constante pendant la transition. « La gestion de ces défis nécessite une planification méticuleuse, des tests approfondis et une stratégie de retour arrière bien définie », énumère Pablo Del Giudice.


Jeff Calusinski, directeur de la technologie de USAA : « La plupart des PaaS ont une capacité principale et un ensemble de fonctionnalités auxiliaires. Nous limitons l'usage de ces dernières. » (Photo : D.R.)

Les principaux facteurs d'échec des migrations PaaS résident dans le non-respect des coûts ou des attentes des métiers, dans le manque de compétences, dans l'absence de normalisation et de définition des fondamentaux en matière de sécurité, dans le fait de ne pas tirer parti des fonctions cloud-natives, dans des lacunes en matière de conformité, ou encore dans la non-adoption d'un modèle d'exploitation adapté au cloud.

Pablo Del Giudice recommande une approche en six étapes à toute organisation qui envisage de passer d'un fournisseur à un autre. Tout d'abord, évaluez le modèle d'abonnement pour vous assurer qu'il correspond à vos objectifs de retour sur investissement. Adoptez une approche hybride. Dans la mesure du possible, utilisez des solutions agnostiques afin de garder ouvertes vos options de migration future. Lorsque vous utilisez des services cloud-natifs, concevez vos applications avec des couches d'abstraction. Investissez dans la planification de la migration des données, les tests et les stratégies de sauvegarde pour atténuer les risques. Enfin, passez en revue les accords de licence et adaptez-les si nécessaire.

4) Évaluez soigneusement vos alternatives

Selon Jeff Calusinski (USAA), il faut toujours tenir compte des coûts de transition et des questions relatives à la propriété des données lorsque l'on envisage de changer de fournisseur de cloud. Et lorsqu'il s'agit de trouver un équilibre entre l'utilisation de services cloud-natifs qui augmentent le lock-in et le recours à des technologies permettant de rester agnostique, il n'y a pas de bonne réponse, ajoute Jamie Holcombe (USPTO). Seulement une réponse optimale pour votre organisation et sa mission. La question, dit-il, est de savoir si l'application cloud est alignée sur la mission de votre organisation et offre la meilleure valeur pour l'accomplir au fil du temps. « Si vous avez une infrastructure de coûts trop complexe, vous ne pourrez pas la modifier lorsque le modèle économique de votre entreprise évoluera », dit-il, ajoutant qu'il faut garder des options ouvertes, comme l'a fait l'USPTO avec une architecture multicloud. « Ma principale motivation était de faire jouer la concurrence entre les fournisseurs de services », explique-t-il.

Lors de l'élaboration d'une stratégie de migration vers le cloud, il est important de tenir compte des modèles de tarification, explique Pablo Del Giudice. « Examinez les plans d'économie potentiels et tenez compte des coûts de transfert de données. Cette approche est essentielle pour éviter les hausses inattendues des dépenses d'exploitation du cloud et pour garantir un bon alignement sur vos contraintes budgétaires. » Lors de la mise en oeuvre d'une stratégie de migration, il convient de prendre en compte deux autres facteurs, ajoute-t-il. « Tout d'abord, quels sont les services - tels que les microservices ou le serverless - disponibles auprès des fournisseurs de cloud pour faciliter la migration ? Vous devrez décider entre l'utilisation de solutions personnalisées ou de services managés par le fournisseur, qui génèrent des risques de lock-in. Deuxièmement, le fournisseur de cloud peut proposer des programmes d'incitation à la migration des applications, avec des remises qui peuvent être substantielles pour les projets importants. »

Par nature, les migrations vers le cloud peuvent être risquées. Mais les DSI qui planifient à l'avance et qui sont suffisamment persévérants pour bien piloter ce processus peuvent bénéficier de services et de modèles de tarification plus rentables, d'une meilleure évolutivité et d'une meilleure allocation des ressources, ainsi que de performances et d'une réactivité accrues. « La réduction de la dépendance vis-à-vis des fournisseurs favorise l'agilité et l'innovation, selon Pablo Del Giudice. En fin de compte, la migration vers le cloud peut améliorer la compétitivité, l'innovation et l'efficacité d'une organisation. »

Article rédigé par

Robert Mitchell, CIO (adapté par Reynald Fléchaux)

Partager cet article