Les plateformes de cloud public sont aujourd’hui incontournables pour les entreprises qui souhaitent accélérer leur transformation numérique.
Les nombreux avantages offerts ne sont plus à démontrer, et il peut être parfois tentant de céder à l’apparente simplicité.
Pourtant migrer ses actifs sur le cloud ne peut se faire sans avoir au préalable réalisé un état des lieux minutieux et établit une feuille de route claire et réaliste pour soutenir la transition. Cela nécessite une approche pragmatique, multidimensionnelle et unifiée qui tient aussi bien compte des opportunités que peut offrir le cloud, que des risques qui peuvent résulter d’un défaut de planification.
Introduction
Il existe plusieurs stratégies de migration pour accompagner cette transition vers le cloud. Chacune répond à des besoins et des situations qui diffèrent selon les entreprises. Le choix de l’une ou l’autre de ces stratégies sera, entre autres, dicté par le résultat de votre état des lieux préliminaire et par vos objectifs : croissance, optimisation, modernisation, coûts, performance, sécurité, innovation…
Stratégie 1 : Rehost
Appelée également Lift and Shift, cette stratégie consiste à migrer vos charges de travail telles quelles, c’est à dire avec peu voire pas de modifications, depuis vos infrastructures sur site vers le cloud. Quelques optimisations peuvent être nécessaires mais elles ne modifieront pas fondamentalement vos charges de travail qui s’exécuteront de la même manière mais dans un environnement différent. L’objectif de ces éventuelles modifications est avant tout de permettre à vos applications de rester opérationnelles dans leur nouvel environnement.
Ce type de stratégie présente plusieurs avantages :
elle est idéale lorsque les modifications à apporter sont minimes voire inexistantes et permettent simplement à vos charges de travail de fonctionner correctement sur l’environnement cloud cible;
elle est rapide à opérer lorsque le cadrage est correctement réalisé;
les risques sont réduits et maîtrisés;
vos équipes ne perdent pas le bénéfice de leurs compétences et expertises et l’effort d’adoption est minime.
Le principal inconvénient d’une telle stratégie réside néanmoins dans le fait que vos charges de travail ne sont pas cloud native, et ne peuvent donc pas toujours tirer le meilleur parti des plateformes cloud.
Cette stratégie s’avère la plus utile lorsque :
vos charges de travail ne nécessitent pas ou peu d’optimisations;
vous entamez votre transformation numérique à travers le cloud : migrez d’abord ces charges de travail afin de garder le contrôle sur votre migration et maîtriser les éventuels risques;
vous ne pouvez pas transformer, réécrire ou refactoriser certaines de vos charges de travail. Les migrer telles quelles est votre seule solution.
vous devez migrer vos charges de travail à court terme.
Exemple : la migration de votre base de données MySQL ou Postgres vers Cloud SQL, ou encore vos clusters Hadoop vers Cloud Dataproc.
Stratégie 2 : Replatform
Cette approche s’applique lorsque vous ne pouvez pas migrer vos charges de travail en l’état et que certains efforts d’optimisation et de modernisation sont indispensables pour réellement tirer parti des plateformes cloud.
Ici, il ne s’agit pas simplement de maintien opérationnel, c’est aussi l’occasion de rendre ses applications cloud native et de mieux profiter des effets de synergie offerts.
Ce type de stratégie trouve son sens dans les différents cas suivants :
lorsque l'architecture ou l'infrastructure actuelle de votre application ou de vos charges de travail n'est pas compatible avec l'environnement cible, qu’une stratégie Lift & Shift est insuffisante, mais qu’il n’est pas nécessaire de procéder à une refonte totale de vos charges de travail;
lorsque vous devez redimensionner vos charges de travail pour mieux correspondre à vos cas d’usage;
lorsque vous devez déprécier certaines anciennes versions de votre stack technologique et que vous devez la faire partiellement évoluer;
En revanche, il est indispensable de garder à l’esprit les points suivants :
les migrations Improve and Move prennent plus de temps que les migrations Lift and Shift en raison des efforts supplémentaires nécessaires à la migration;
la nécessité d’évaluer le temps et les efforts supplémentaires requis pour maîtriser et réussir la migration;
la nécessité de réaliser un cadrage clair et de délimiter le scope de la migration pour ne pas se laisser emporter par la tentation de tout vouloir refactoriser;
la nécessite d’un engagement plus important de la part des équipes quant à l'apprentissage et l’acquisition de nouvelles compétences.
Exemple : modifier votre application pour quelle fonctionne sur des containers plutôt que sur des VMs, puis de migrer ces containers vers Google Kubernetes Engine.
Stratégie 3 : Refactor
La stratégie Rebuild ou Refactoring est plus longue et plus complexe que les précédentes. Elle consiste à revoir l’architecture et à réécrire entièrement vos applications ou charges de travail qui seront mis hors service et remplacés par des applications cloud native. C’est la stratégie qui permet de bénéficier au mieux des avantages du cloud.
Recourir à cette stratégie est tout indiqué si :
la migration via les approches mentionnées précédemment s'avèrent insuffisantes, trop coûteuses et ne répondent pas à vos objectifs (scalabilité, performances, évolutivité, coûts, sécurité…);
vos charges de travail sont incompatibles en l’état avec le cloud provider;
elles sont obsolètes mais indispensables pour vos activités et qu’il est impératif de revoir la stack technique et de la moderniser.
Du fait de sa complexité, les éléments suivants doivent être pris en considération :
cette stratégie est plus longue mais aussi plus coûteuse à mettre en oeuvre. Lorsqu’elle est réalisée dans les règles de l’art, elle génère un ROI important et procure un véritable avantage concurrentiel;
elle ne convient pas aux applications standards, puisqu’il est ici nécessaire de réécrire de l'application. Dans le cas d’applications ou charges de travail standards, évaluez d’abord les opportunités offertes par les précédentes stratégies;
elle nécessite une planification ainsi qu’une mise en oeuvre rigoureuses;
elle nécessite également l’acquisition de nouvelles compétences qui peuvent parfois ralentir l’adoption du cloud et augmenter les risques d’une migration non maîtrisée.
Exemple : le passage d’une architecture en monolithe vers une architecture en microservices est l’exemple le plus représentatif de ce type de migration.
Et les 6R dans tout ça?
Effectivement, il existe 6 grandes stratégies de migration vers le cloud que l’on appelle communément les 6R. Les 3 que l’on a vu précédemment auxquelles viennent s’ajouter les 3 suivantes :
Retire : cette approche implique le retrait ou la désactivation de charges de travail ou d’applications qui ne sont plus utiles ou essentielles aux besoins de l'entreprise.
Retain : cette stratégie de migration implique essentiellement que les charges de travail ou applications ne pouvant être migrées, refactorisées ou désactivées soient conservées sur site.
Repurchase : il s’agit ici d’abandonner totalement vos applications sur site et de les remplacer par une solution Saas.
Comme on peut le constater, il n’y a pas de migration vers le cloud au sens propre du terme. En revanche, il n’en est pas moins utile de les connaître et de les comprendre car elles seront sans aucun doute évoquées et discutées lors de la phase de diagnostic préliminaire.
Conclusion
Toutes ces stratégies sont utiles et s’appliquent dans divers cas de figures. Vous aurez probablement besoin de toutes les implémenter durant votre projet de migration.
De manière générale, il faut procéder graduellement et commencer par les applications les plus rapides à migrer, c’est à dire par celles ne nécessitant pas de modifications et pour lesquelles le Rehost est la stratégie la plus indiquée. Il faudra recourir aux stratégies suivantes à mesure que le niveau de modifications nécessaires augmente.
Migrer ses actifs sur le cloud s’inscrit dans le temps mais n’a cependant rien d’une démarche linéaire. C’est un processus itératif avec un fort impact sur l’ensemble des aspects organisationnels de l’entreprise. Audelà des considérations purement techniques, technologiques et financières, il est important de documenter les processus et d’accompagner les personnes afin de faciliter l’adoption et la transition vers le cloud.