La multiplication des objectifs métiers des entreprises tels que le raccourcissement des délais (Time to Market), la prise en compte des expériences utilisateurs ou tout autre enjeu à forte valeur ajoutée implique des transformations profondes dans l’architecture de leurs processus.
Quel leitmotiv pour la Transformation ?
Ces changements s’accompagnent aujourd’hui d’un usage intelligent des technologies qui n’ont cessé d’évoluer avec l’avènement de nouvelles architectures applicatives ou d’infrastructures.
Des métamorphoses culturelles accompagnent bien évidemment les transformations initiées ces dernières années par la mouvance DevOps et l’introduction de l’agilité à différentes échelles de l’entreprise. L’importance de la culture combinée à l’évolution technologique fournit un terrain adéquat aux chantiers de transformation ou de réhabilitation de la totalité ou d’une partie d’un système d’information.
Migration des applications Legacy, en avant toute !
Dans le cadre de ces évolutions, les entreprises entreprennent des migrations afin de maintenir une cohérence globale de leurs systèmes. Ces migrations représentent un double défi : d’une part créer de nouveaux services à fortes valeurs ajoutées et d’une autre part rattraper le retard technologique sur les anciennes briques du système.
Nul doute que tous ces défis s’accompagnent de réflexions globales sur le métier, les infrastructures, les applications et la culture pour assurer la cohérence totale des futurs processus créés.
Dans cet opus, nous allons nous intéresser à une partie de ces chantiers qui est la migration des applications Legacy.
La problématique est la suivante : comment migrer un immense parc applicatif vers un nouveau socle d’infrastructure dans le Cloud ? Telle est la question à laquelle nous essaierons de répondre dans cet article.
Nous nous intéresserons dans un premier lieu aux stratégies de migration. Ensuite, nous aborderons les critères d’évaluation pour déterminer le score technique d’une application. Enfin, nous nous attarderons sur les différentes stratégies de migration d’un actif applicatif vers son nouveau socle infrastructure.
La vision globale
Avant d’entamer un chantier de transformation d’une telle ampleur, la compréhension du besoin client est fondamentale pour une migration d’un bloc applicatif Legacy vers un nouveau socle d’infrastructure.
Le but de cette étape est de comprendre l’objectif et la trajectoire portés par la vision globale. Il s’agit aussi de recenser le portfolio d’applications, leurs contextes et leurs architectures cibles.
Finalement, nous allons identifier les personnes clés qui vont participer à la réalisation de ce projet durant ses différentes étapes que nous détaillerons ci-dessous :
- La première phase est celle de l’audit et de la récolte d’information. Le but est de se familiariser avec le contexte global de la migration :
- Identification des intervenants clés,
- Audit global du périmètre SI à migrer,
- Etude des documents d’architecture techniques et fonctionnels,
- Identification des autres transformations en cours (Agile at Scale, réorganisation d’équipes, Move to Cloud, …),
- Etude des risques globaux (délais, coûts, obsolescence de certaines briques du SI, contraintes métiers, fermeture de DC, …)
- La seconde phase est celle de l’audit approfondi d’un portfolio d’applications. Ici, nous allons :
- Déterminer les scores techniques des applications que nous aborderons lors du prochain paragraphe,
- Revoir les contraintes techniques et opérationnelles,
- Analyser les risques d’une manière plus détaillée pour chaque portfolio applicatif,
- Evaluer les points de blocage.
- Au terme de la deuxième phase, nous avons une vision détaillée de nos applications et pouvons les intégrer chacune dans une feuille de route personnalisée :
- Identification des trajectoires,
- Exposition de la stratégie de migration aux différents intervenants,
- Revue des aspects budgétaires, de planification et de formation.
- La quatrième phase est la plus importante : le Single Point Of Contact ou SPOC est au contact journalier des équipes applicatives et techniques. Le SPOC a pour rôle :
- Assurer le suivi du plan de migration,
- Apporter une assistance quotidienne aux équipes,
- Fluidifier les échanges avec les interlocuteurs de notre application,
- Être garant du cadre global de la transformation auprès des équipes.
Comme vu lors de la phase 2, pour déterminer quelle stratégie est la plus adéquate pour notre application, celle-ci sera évaluée et scrutée selon plusieurs critères qui nous permettront de lui donner un score.
Quels sont ces critères et comment les cerner ? C’est ce que nous allons essayer de démystifier dans le prochain paragraphe.
Les critères de la classification applicative
Afin de déterminer le score applicatif évoqué ci-dessus, chaque application va être évaluée suivant plusieurs critères dépendants du client. Parmi les critères évalués, nous pouvons citer les suivants :
- La criticité de l’application,
- Les technologies et Frameworks utilisés,
- Les besoins métiers futurs (les évolutions des processus),
- Les prérequis de l’infrastructure cible
- Les transformations globales en cours de réalisation (Agilité, conteneurisation ou autre évolution technique, changement d’infrastructure en cours, changement de Frameworks ou de librairies, …)
- L’estimation de l’effort de migration
- La conformité avec les standards de développement (Cloud Natifs, Twelve-Factors App, …)
Tous ces critères sont bien évidemment réévalués à de multiples reprises en les confrontant aux besoins clients et à chaque phase du projet.
Une fois ce score déterminé, chaque application entrera dans une deuxième phase de planification durant laquelle une feuille de route personnalisée sera créée.
Cette roadmap de migration prend en considération des spécificités plus larges comme l’adhérence avec d’autres applications, les prochaines échéances figurant sur la nouvelle roadmap métier et technique, la formation, etc …
Prenons l’exemple d’une application érigée suivant une architecture monolithique, développée majoritairement avec le langage Java et déployée sur un socle VMware.
Le schéma ci-dessous va nous aider à comprendre le processus global de notre migration du début de son audit jusqu’à son déploiement dans un environnement conteneurisé :
Les stratégies de migration
Lors du deuxième chapitre, nous avons intentionnellement évité d’évoquer la stratégie globale qui accompagne la transformation d’une application.
En effet, dans notre cas, il existe 3 techniques majeures pour migrer un/des élément(s) applicatif(s) d’un socle Legacy vers le Cloud :
- Le Lift & Shift(ou Re-Hosting) : Il s’agit de la réplication la plus fidèle de l’infrastructure d’origine vers le nouveau socle en effectuant le minimum de changements sur notre parc applicatif ou d’infrastructure.
- Le Re-Platforming: Cette méthode consiste à repenser et recréer une partie du socle d’infrastructure en profitant des services proposés par les différents CSP sans engendrer de grands changements au niveau de l’applicatif.
- Le Re-Factoring: Dernière technique de migration qui se base sur une réécriture partielle ou complète de notre application qui reposera sur un nouveau socle d’infrastructure totalement différent du socle original.
Chaque stratégie apporte son lot d’optimisations que ce soit sur le TCO (coût total de la possession) ou bien sur le ROI (Retour sur Investissement). La vision client nous aidera encore une fois à atteindre l’objectif à réaliser :
- Le Lift & Shift tend à optimiser le ROI sur le court terme en minimisant les coûts de migration qui restent assez faibles. Des économies seront réalisées sur les coûts d’infrastructures notamment lors de la migration vers des services Cloud.
- Les Re-Platforming ou Re-Factoring améliorent le TCO dans une vision plus long terme. Des efforts conséquents sont déployés tout au long de ces stratégies avec un retour sur investissement sur du long terme.
Stratégies de migration d’un actif applicatif – Source : AWS
La figure ci-dessus nous permet de mieux comprendre le choix entre ces 3 stratégies.
Nous avons omis volontairement d’évoquer le Re-Purchasing car notre volonté est de migrer les applications et non les transformer suivant une stratégie orientée SaaS par exemple. Néanmoins le Re-Purchasing reste une stratégie qui peut être demandée et portée par la vision client.
Pour résumer, le choix d’une stratégie ne dépend pas uniquement de son contexte technique mais surtout de son environnement global, de la vision du client et de son besoin.
Une application de notre portfolio applicatif se verra ainsi appliquée une des trois stratégies précédemment listées en prenant en considération son existant, ses prérequis métier et la trajectoire que l’on voudra lui donner à court à moyen ou à long terme.
En conclusion
Bien que ces transformations soient élaborées avec une planification minutieuse, elles sont sujettes à des changements fréquents et soumises à des contraintes externes aux équipes techniques et applicatives et parfois à l’organisation elle-même.
La migration d’un portfolio applicatif vers un nouveau socle d’infrastructure est un chemin long et méthodique. Dans la majorité des cas, ces projets mettent des années avant d’en récolter les fruits notamment dans le cas d’un Re-Platforming ou d’un Re-Factoring.
La méthode que nous venons de démontrer porte l’humain au cœur de la transformation car ce sont finalement les équipes qui vont être actrices de ces changements. Pour cela, nous devons nous assurer de leur compréhension fine et complète du projet.
Enfin, le rôle du SPOC dans ces projets est crucial car il va être aux côtés de ses équipes en leur apportant tout leur soutien en termes d’acculturation, de méthodologie et en facilitant le travail durant toutes les phases décrites plus haut.
Références :
https://cloud.netapp.com/blog/cloud-migration-strategy-challenges-and-steps
https://acloudguru.com/blog/business/what-is-cloud-migration
https://blog.turbonomic.com/lift-shift-vs-optimized-cloud-migration-strategy
Par Ahmed CHAARI, Architecte Solution
