4 façons d’éviter les problèmes de migration d’applications cloud

Une fois que les entreprises décident d’exécuter leurs applications critiques dans le cloud, il est peu probable qu’elles se tournent vers un autre fournisseur. L’une des principales raisons à cela est qu’ils sont souvent enfermés dans l’écosystème du fournisseur qu’ils ont choisi. Le coût de la migration est tout simplement trop élevé, déclare Sid Nag, vice-président de la technologie des services cloud chez Gartner. « Mais avec une bonne planification, vous ne devriez pas avoir à migrer vos applications », explique-t-il.

Pablo Del Giudice, partenaire du studio d’opérations cloud et de cybersécurité de la société de services professionnels Globant, ajoute que la migration est possible si vous positionnez correctement votre organisation. Et lui et son équipe y parviennent avec succès. « La clé est d’adopter stratégiquement des plates-formes et des cadres ouverts et de reléguer les fournisseurs de cloud au rôle de couche d’infrastructure. Cette approche nécessite une courbe d’apprentissage abrupte mais offre des résultats plus favorables à moyen et long terme », ajoute-t-il. « La clé est d’avoir un architecte logiciel indépendant de la plate-forme. »

Jamie Holcomb, CIO de l’Office américain des brevets et des marques, adopte un point de vue légèrement plus nuancé. L’entreprise souhaite garder ses options ouvertes pour la migration d’applications entre fournisseurs de services cloud et mène actuellement des études de marché sur tous les principaux fournisseurs. Mais cela nécessite une planification précoce avant de déplacer les applications vers le cloud pour la première fois.

Minimiser le risque de blocage

Les compromis doivent être soigneusement étudiés lors de l’utilisation des services cloud natifs de chaque fournisseur. « Choisir de ne pas exploiter les services natifs d’un fournisseur de cloud afin de rester agnostique éliminera de nombreux indicateurs de rentabilité tels que « meilleur, moins cher, plus rapide ». « Nous allons le perdre », a déclaré Holcomb. « Tout comme il y a un coût à être dépendant d’un fournisseur, il y a un coût à être agnostique. »

Del Giudice classe la dépendance vis-à-vis du fournisseur de cloud sous trois formes. Le verrouillage de la plate-forme se produit lorsque la configuration cloud sous-jacente (regroupement de ressources, politiques, RBAC, connectivité hybride, surveillance, conformité, etc.) est terminée, et il est difficile de recréer l’ensemble sur une nouvelle plate-forme. difficile de migrer vers une autre plateforme.

Le verrouillage architectural se produit lorsqu’une application dépend de plusieurs services gérés d’un fournisseur de cloud. Dans ce cas, vous devrez repenser votre application avant de migrer.

Et puis il y a le verrouillage légal. C’est à ce moment-là que vous vous engagez dans un contrat de services d’entreprise pour une période de temps prédéterminée. « De tels engagements sont difficiles à annuler et rendent la migration difficile », dit-il.

La dépendance vis-à-vis d’un fournisseur est parfois inévitable, même si le DSI s’efforce de l’éviter. Les DSI souhaitent généralement procéder à une consolidation, mais les coûts sont souvent trop élevés pour être justifiés. Les DSI souhaitent généralement procéder à une consolidation, mais les coûts sont souvent trop élevés pour être justifiés. Dans la plupart des cas, explique Nag, les DSI maintiendront un modèle multicloud.

Mais les organisations peuvent avoir de bonnes raisons de migrer entre fournisseurs IaaS malgré les obstacles, explique Del Giudice. Les plus courantes sont l’amélioration du rapport coût entre valeur et OPEX pour profiter des remises agressives des fournisseurs de services cloud concurrents, et des architectures multicloud lorsque les organisations souhaitent améliorer la fiabilité.

Planifier une future migration

Mais vouloir migrer des applications clés entre fournisseurs de cloud, ce que Gartner appelle le « rapatriement du cloud », est souvent le résultat d’une mauvaise planification, explique Nag. En plus des déploiements lift-and-shift vers le cloud, Nag a décidé d’utiliser des middlewares et des outils de développement natifs et cloud abordables, avec l’intention de déplacer les applications vers un cloud privé sur site une fois terminé. où il y a

Il recommande d’utiliser les services d’un MSP ou d’un intégrateur système pour vous aider à planifier et choisir les bonnes applications à migrer vers le cloud. « Une fois que vous passez au cloud, vous êtes enfermé dans cette plateforme. »

La société de services financiers USAA a soigneusement sélectionné quatre fournisseurs de services cloud pour héberger chacune de ses charges de travail et applications métier habituelles, a déclaré Jeff Karusinski, vice-président directeur et directeur technique. « Nous avons aligné les fournisseurs de cloud sur les services commerciaux et technologiques qu’ils maîtrisent le mieux. »

La stratégie multi-cloud de l’agence repose sur des principes qu’elle qualifie d’« open by design ». « En utilisant des normes ouvertes là où elles existent, nous réduisons le risque de dépendance envers un fournisseur », dit-il, mais il ajoute qu’il existe des propositions de valeur convaincantes qui doivent être mises en balance avec la possibilité de dépendance. Il reconnaît qu’il existe également des propositions de valeur intéressantes. services natifs qu’il fournit.

Les principes de conception ouverte présentent également des limites en termes de potentiel de verrouillage, explique Nag. En effet, même si vous utilisez le dernier service, la mise en œuvre diffère selon la plateforme. Par exemple, l’infrastructure EC2 d’Amazon fait la même chose que GCP de Google, mais les applications qui s’exécutent sur EC2 ne fonctionneront pas sur GCP sans une refonte coûteuse. De plus, bien que Kubernetes soit une norme industrielle, les implémentations telles qu’Azure Communication Services et Google Kubernetes Engine ne fonctionnent pas de la même manière.

« Mais plusieurs couches d’abstraction émergent entre les fournisseurs de cloud et les applications », a déclaré Del Giudice. Ces services peuvent simplifier la migration même lorsque vous utilisez les services d’un fournisseur de cloud natif. « Ces services, tels que la pub/sub, les appels de service, la gestion des secrets et la gestion de l’état, sont des composants abstraits d’une application, quel que soit le fournisseur de cloud. Certaines choses doivent être faites avant de passer à un nouveau fournisseur de cloud. »

Les exigences en matière de données sont un autre domaine qui nécessite une planification minutieuse. « Déplacer une application entre les cloud coûte cher car vous devez également migrer les données associées », explique Nag.

C’est pourquoi vous devez planifier à l’avance, ajoute Holcomb. « Ne vous inscrivez pas auprès d’un fournisseur à moins d’avoir un accord écrit en place pour savoir comment extraire vos données et comment répliquer vos services logiciels ailleurs. »

Cependant, même si une stratégie ETL appropriée garantirait que les données peuvent être migrées entre les fournisseurs de manière structurée et dans les formats disponibles, Dell note qu’un tel plan n’existe souvent pas, explique Judith. « Alors que les fournisseurs de services cloud mettent l’accent sur l’utilisation de plates-formes ouvertes et de protocoles d’accès aux données théoriquement faciles à utiliser, les restrictions réseau et la sécurité de l’accès à ces services sont souvent négligées. « 

Les organisations n’ont peut-être pas le choix lorsqu’elles décident quels services cloud natifs utiliser. La sécurité est un bon exemple. « Si vos besoins en matière de sécurité sont élevés, la cybersécurité générale n’est peut-être pas suffisante », déclare Holcomb. Plus les besoins sont spécifiques, plus le service sera difficile en termes de dépendance vis-à-vis du fournisseur. De plus, les entreprises ayant des opérations gourmandes en données sont confrontées à des problèmes de stockage et de bande passante, et les fournisseurs PaaS et IaaS utilisent les deux comme différenciateurs concurrentiels, a-t-il déclaré. « Si vous essayez de profiter de hautes performances en utilisant les deux, c’est difficile. »

Holcomb suit ce qu’il appelle une approche « épinette noire » en matière de personnalisation à l’aide de services natifs. Tout comme l’épinette noire garde ses branches près de son tronc, l’USPTO tente de rendre sa personnalisation la plus « fine » possible. Cela réduit non seulement le verrouillage, mais élimine également ce qu’il appelle « les passes de versionnage excessives et coûteuses ».

Karusinski adopte une approche similaire. « La plupart des PaaS ont des fonctionnalités de base et des fonctionnalités auxiliaires. Nous limitons le nombre de fonctionnalités auxiliaires et nous concentrons sur le noyau. »

Il en va de même pour les applications basées sur SaaS, que son équipe a suivies après être passée de Remedy à ServiceNow et Salesforce. « Il s’agit de ne pas trop personnaliser et de pouvoir changer les choses lorsque vous en avez besoin. Nous n’étions pas liés à Salesforce et ServiceNow était une bonne plate-forme sur le plan architectural, mais je pense qu’elle est sur-optimisée. Je reste coincé. »

Mais cette fois, Karusinski adopte une approche différente. « Avec les plates-formes SaaS, les entreprises ne voient pas suffisamment de différenciation dans les capacités des fournisseurs et la probabilité de changement est faible, elles adoptent donc la plate-forme chaque fois que cela est possible. »

Évitez les douleurs de transition potentielles

Il est clair que la migration entre fournisseurs de cloud présente une multitude de défis. Ceux-ci incluent des problèmes de compatibilité, des problèmes de sécurité, la nécessité d’une reconfiguration approfondie des applications et la gestion d’images basées sur des systèmes d’exploitation plus anciens et des piles technologiques obsolètes qui ne peuvent pas être intégrées de manière transparente dans de nouveaux environnements. La migration de grandes quantités de données peut entraîner des temps d’arrêt et une perte potentielle de données. Il est donc essentiel de garantir des performances et une évolutivité constantes pendant la migration. « La gestion de ces défis nécessite une planification minutieuse, des tests approfondis et une stratégie de retour en arrière clairement définie », explique Del Giudice.

Les principaux points d’échec des migrations PaaS incluent le fait de ne pas répondre aux attentes en matière de coûts et d’affaires, de compétences insuffisantes en matière de ressources, de manque d’infrastructure de normalisation et de sécurité et d’exploitation des capacités natives du cloud. Il existe des inquiétudes concernant la sécurité et la conformité, ainsi que l’incapacité à adopter un modèle d’exploitation cloud.

Del Giudice recommande une approche en six étapes aux organisations qui envisagent de migrer entre fournisseurs de cloud. Tout d’abord, évaluez votre modèle d’abonnement et assurez-vous qu’il correspond à vos objectifs de retour sur investissement. Adoptez une approche cloud hybride. Utilisez des solutions indépendantes du cloud autant que possible pour étendre vos futures options de migration. Lorsque vous utilisez des services cloud natifs, concevez des applications à l’aide de couches d’abstraction. Investissez dans des stratégies de planification, de test et de sauvegarde de la migration des données pour réduire les risques. Examinez et ajustez les contrats de licence si nécessaire.

réfléchissez attentivement à vos options

Lorsqu’on envisage une migration vers un fournisseur de cloud, Karusinski affirme que les coûts de migration et la propriété des données doivent toujours être pris en compte.

Et lorsqu’il s’agit d’équilibrer l’utilisation de services cloud natifs qui augmentent le verrouillage et le fait de rester agnostique, il s’agit simplement de choisir ce qui convient le mieux à votre organisation et à sa mission. Non, dit Holcomb. La question est de savoir si les applications basées sur le cloud correspondent à la mission d’une organisation et offrent la meilleure valeur pour y parvenir sur le long terme. « Si vous mettez en place une infrastructure de coûts trop complexe, vous ne pouvez pas la modifier lorsque votre modèle économique change », dit-il, ajoutant que des options telles que l’architecture multi-cloud de l’USPTO peuvent, dès leur conception, élargir les options.  » il ajouta. « Ma principale raison est de créer une concurrence entre les prestataires de services », explique-t-il.

Del Giudice affirme qu’il est important de garder à l’esprit les modèles de tarification lors de l’élaboration d’une stratégie de migration vers le cloud. « Envisagez des plans d’économies potentiels et tenez compte des coûts de transfert de données », dit-il. « Cette approche est essentielle pour éviter les pics inattendus de coûts opérationnels du cloud et garantir la cohérence avec les contraintes budgétaires. Deux autres facteurs doivent être pris en compte lors de la mise en œuvre d’une stratégie de migration. Premièrement, quels services votre fournisseur de services cloud propose-t-il pour faciliter votre migration, tels que des microservices ou sans serveur ? Vous devez décider d’utiliser une solution personnalisée ou les services gérés de votre fournisseur de cloud. Cependant, cela crée un risque de dépendance vis-à-vis du fournisseur. Deuxièmement, les fournisseurs de cloud peuvent proposer des programmes d’incitation à la migration d’applications, avec des réductions importantes disponibles pour les grandes entreprises. migrations à grande échelle. Applicable. « 

De par sa nature même, la migration vers le cloud comporte des risques. Cependant, les DSI qui planifient à l’avance et persévèrent dans ce processus verront des services cloud et des modèles de tarification plus rentables, une évolutivité et une allocation des ressources améliorées, ainsi qu’une performance et une réactivité accrues. « Réduire la dépendance vis-à-vis d’un fournisseur favorise l’agilité et l’innovation », déclare Del Giudice. « En fin de compte, le passage au cloud entraînera une compétitivité, une innovation et une efficacité accrues. »