Migrer dans cloud : cinq méthodes…du plus simple au complexe

Migrer vers le cloud public est une problématique qui est à l’ordre du jour de tous les DSI. Outre les grands projets de « Move to cloud » des Veolia, Engie ou Carrefour, une récente étude IDC France montre que les PME et ETI se sont elles aussi engagées dans cette voie.

34 % des entreprises interrogées sont dans une approche « cloud also « . C’est-à-dire que le cloud est systématiquement analysé, mais pas privilégié : 23 % optent pour le cloud projet par projet et 15 % sont dans une approche « cloud first « . 14 % en approche « cloud last » : le cloud n’est retenu que s’il n’est pas possible de traiter le besoin en interne.

Seulement 14 % proscrivent encore totalement le cloud de leur environnement informatique. « La première question qu’un DSI doit se poser, c’est pourquoi aller vers le cloud », souligne Mohammed Sijelmassi, le CTO de Sopra Steria .
« Souvent, la raison n’est pas économique et le cloud peut être parfois plus coûteux qu’une approche on-premise. Il peut s’agir d’une volonté d’innovation afin de bénéficier de fonctionnalités disponibles dans le cloud. »

Ainsi, hormis une volonté stratégique d’aller vers le zéro datacenter, migrer une grosse application legacy en  » lift and shift » ne présente aucun véritable intérêt et peut induire des problématiques de performance, de latence et de coûts… À l’autre extrémité du spectre de l’innovation, pour le développement des nouvelles applications digitales, le cloud est la solution la plus évidente.

Pour Éric Salviac, Business Value Senior Consultant chez Cisco Appdynamics, un important travail préparatoire est indispensable à tout projet Move to cloud.
« Lorsque l’entreprise a détouré le périmètre applicatif qui doit basculer dans le cloud, il faut toujours passer par une étape d’inventaire et de diagnostic. Les applications legacy étant structurées par couches successives, il faut mener un mapping fonctionnel puis technique pour décider de la façon dont on va les migrer dans le cloud. Ou simplement la déplacer dans le cloud en l’état ou ne la redévelopper qu’en partie. » conseille-t-il.

Cinq méthodes : du simple au complexe

Dès 2010, le Gartner a défini le modèle des 5R, c’est-à-dire les cinq stratégies de migration vers le cloud : Rehost avec les projets de type « lift and shift », le Refactoring et la modernisation des architectures jusqu’au Rebuild et au remplacement pur et simple d’une application obsolète ne pouvant migrer vers le cloud. L’effort en termes d’ingénierie est bien évidemment croissant.

Les projets de « lift and shift » sont relativement simples à mener, la durée reste limitée et le risque faible. En contrepartie, l’application ne tire pas profit des capacités offertes par le cloud provider, notamment ses services cloud. D’autre part, l’application et son architecture ne sont pas optimisées pour le fonctionnement du cloud et un mode de facturation à l’usage. L’application va donc être plus coûteuse à l’exploitation qu’une application « cloud native « .

À l’inverse, une application réarchitecturée et redéveloppée va pouvoir bénéficier des capacités offertes par le cloud cible, notamment les services PaaS et Serverless.

L’approche présente des atouts certains en termes d’agilité et de productivité des DevOps.

En outre, une application conçue pour le cloud ne va consommer que les ressources strictement nécessaires à son fonctionnement, à l’inverse d’applications legacy qui vont demander de multiples instances en production 24 heures sur 24. La contrepartie de cette optimisation, c’est un important et coûteux travail d’ingénierie et des délais importants avant de pouvoir disposer d’une application réellement « cloud ready « .

La complexité des projets de rebuilt qui peuvent s’avérer extrêmement complexes. Il n’est pas étonnant que les programmes de « move to cloud » s’étalent sur plusieurs années.

Le choix du « lift and shift » : le plus simple

Bien souvent, les DSI doivent panacher avec ces différents modèles de déploiement, en fonction des contraintes technologiques de certaines applications. Le  » lift and shift » est un moyen de migrer assez rapidement un grand nombre de workloads dans le cloud et fermer les datacenters.

Cette approche que certains peuvent appeler  » quick and dirty  » est considérablement simplifiée par la présence d’outils de migration tels que ceux proposés par les fournisseurs cloud, comme cloudEndure chez AWS ou Azure Migrate chez Microsoft.

Depuis, le modèle 5R s’est enrichi, on parle désormais des 6R ou même des 7R. L’approche Relocate définit ainsi une migration de type  » lift and shiftt  » réalisée non plus au niveau de l’OS, mais de l’hyperviseur.

De facto, VMware, un acteur très présent dans les infrastructures on-premise a réussi à se poser en tant que pivot dans la migration de ces infrastructures virtualisées vers le cloud public.

Chaque fournisseur cloud majeur dispose d’une offre VMware. Qu’il s’agisse de VMware cloud on AWS, de Azure VMware Solution, de Google Cloud VMware Engine ou encore  de Oracle Cloud VMware Solution et de IBM Cloud for VMware Solutions, toutes ont pour vocation de faciliter le transfert de workloads du datacenter privé de l’entreprise aux infrastructures cloud public.

L’éditeur avance des chiffres éloquents, avec un coût de migration de 100 VM qui passe de 412 400 $ en approche cloud classique à seulement 178 500 $ via VMware cloud on AWS et des délais réduits de 46 %. Une approche qui peut rassurer les DSI habitués à gérer des infrastructures virtualisées.

Comment gérer les applications legacy ?

S’il est possible d’industrialiser la migration de workload en mode  » lift and shift « , profiter réellement des capacités de scaling automatique et de l’allègement des tâches d’administration des plateformes passe par une réarchitecturation plus ou moins profonde des applications, voire un redéveloppement des plus obsolètes.

Une récente étude menée par Vanson Bourne auprès de 1 104 développeurs, architectes et DSI dans 49 pays estime à plus de 800 milliards de lignes Cobol encore en production dans le monde.

Des applications dont beaucoup des concepteurs sont aujourd’hui à la retraite et qu’il sera extrêmement compliqué de porter sur des architectures modernes. Eric Salviac, Business Value Senior Consultant chez Cisco Appdynamics souligne : « Pour profiter des apports du cloud, il faut casser l’architecture de l’application, la porter en microservices et la conteneuriser, appeler les services Paas de la plateforme. Modifier ainsi une application legacy peut devenir rapidement très complexe : on va bouleverser l’architecture et l’effort à consentir devient comparable à redévelopper une application from scratch. »

Plutôt que de lancer des projets de redéveloppements aux coûts et délais pharaoniques, Mohammed Sijelmassi suggère plutôt d’ouvrir ces applications legacy généralement très silotées : « Le monde tend aujourd’hui à être de plus en plus transversal : l’utilisateur ne veut pas savoir que certaines opérations sont possibles sur le Web, mais pas sur mobile. Pour adopter une vision transverse, il faut être capable de donner de la valeur aux données produites au-delà des applications elles-mêmes. »

Après un « lift and shift « , le CTO conseille de passer par une autre phase :  « APIser » ces applications afin de pousser les données hors des applications et, à terme, mieux les exploiter.

Enfin, il faudra redévelopper certaines applications ou certains modules d’application si le projet peut dégager suffisamment de valeur ajoutée pour justifier un tel projet. Tout est alors question d’équilibre entre l’apport business de la transformation, le budget et l’effort que l’entreprise est prête à consentir, mais aussi le souci du DSI de ne pas laisser la dette technique s’accumuler dans son SI.