Migration des applications legacy vers le cloud : les clés d’une bonne stratégie
Toutes les applications patrimoniales ne sont pas compatibles avec le cloud. Dans une migration, l’un des enjeux consiste justement à identifier le meilleur moyen d’y parvenir pour chaque application.
La première étape consiste à comprendre de quoi est fait le cloud. Nombre de fournisseurs IT – surtout les équipementiers – mettent souvent en avant les défaillances du cloud – ses mauvaises performances, le comportement aléatoire des applications ou l’explosion des coûts. Et ce, pour semer le doute quant à la migration des applications en place. Mais en réalité, le succès d’Amazon Web Services (AWS) et d’autres fournisseurs est là pour montrer que cela est possible. On peut imaginer ces applications critiques dans le cloud. Par exemple, American Airlines a déplacé certaines de ses applications les plus en vue, vers le cloud d’IBM. General Electric a fermé des dizaines de centres de données pour transférer des milliers d’applications sur AWS.
Concernant les problématiques de cybersécurité, les fournisseurs s’en sortent généralement mieux que les gestionnaires d’infrastructures sur site. Or beaucoup de ces aspects sont de la responsabilité des clients. Il y a donc un gros travail de formation à anticiper, avant de migrer des applications critiques vers le cloud. Les fournisseurs peu coopératifs en la matière (refus de donner les derniers résultats de tests d’intrusion, certificats peu détaillés, etc.) se font plus rares. Dans d’autres cas, il est possible de migrer ces applications legacy vers des instances cloud privées ou des services cloud souverains, si le risque d’exposition des données et des propriétés intellectuelles est perçu comme trop important. À noter que, de plus en plus, les équipementiers tentent de reproduire les capacités du cloud public en offrant le même niveau de différenciation entre les services.
Avec quels services déployer les applications legacy dans le cloud ?
Les infrastructures IaaS (Infrastructure as a Service), telles que AWS Elastic Cloud Compute (EC2), ne représentent qu’un type de destination cloud. Certaines entreprises utilisent quant à elles des applications SaaS qui clonent ou reproduisent les caractéristiques de l’ancien ERP ou de la gestion de la relation client (CRM). Par exemple, Oracle et Salesforce ont convaincu les grandes entreprises de migrer leurs processus vers le SaaS.
Il convient d’évaluer à la fois le type d’applications à migrer et la catégorie de services cloud à adopter.
Il convient donc d’évaluer à la fois le type d’applications à migrer et la catégorie de services cloud à adopter. Au-delà de la hiérarchie des services cloud, certains types d’applications fonctionnent mieux sur certains services. Le IaaS convient parfaitement à l’infrastructure bâtie sur des VM, des bases de données SQL et NoSQL ou des applications personnalisées reposant sur des composants Open Source.
D’autres technologies comme les DBaaS ont fait leur apparition dans le but de simplifier la gestion et le déploiement des bases de données dans le cloud. L’introduction du serverless doit également simplifier la gestion des charges de travail intermittentes ou des processus éphémères.
Les applications Web ou mobiles, les applications personnalisées Java et d’autres applications d’entreprise sont quant à elles davantage éligibles à une migration vers une plateforme PaaS.
Le SaaS reste privilégié pour les applications métiers, comme le CRM ou les outils de productivité, de communication et de collaboration.
Refactoriser pour le cloud ou « Lift-and-Shift »
Une migration d’applications patrimoniales est généralement unique, tout comme l’est chaque entreprise. Toutefois, deux catégories de migration peuvent se dégager : la technique de « Lift-and-Shift » (on migre les VM sans aucune modification) ou la refactorisation. Le premier implique peu ou pas de changements à l’application sous-jacente et est un processus plus court. En revanche, elle n’exploite pas pleinement les spécificités du cloud.
EC2, Elastic Block Store et Simple Storage Service (S3), trois services d’AWS, ne sont finalement que des versions cloud des machines virtuelles, des volumes de stockage et des partages de fichiers réseau, compatibles avec les applications virtualisées. Les migrations Lift-and-shift déplacent généralement les images d'applications Linux ou Windows vers des VM dans le cloud, sur EC2 ou Microsoft Azure, et fonctionnent sans modification du code. Pour faciliter ce type de migration, il est nécessaire d’utiliser un outil d’automatisation de migration d’images et de données. Par exemple, CloudEndure (racheté par AWS), Zerto (HPE), Carbonite DoubleTake et Racemi assurent la réplication en continu des données et minimisent ainsi les interruptions de services lors de la migration.
À l’inverse d’une ferme de serveurs privés, les entreprises n’ont pas, avec le cloud, un choix illimité en matière de version d’OS déployée sur les instances. Par exemple, Azure supporte bien Windows Server 2003 et les versions ultérieures, mais pas les versions antérieures à Windows Server 2008 R2. Les utilisateurs ne peuvent pas télécharger d’images prétestées depuis Azure Marketplace.
La situation est plus confortable pour les images Linux. AWS, Azure et Google Cloud Platform offrent différentes distributions et configurations.
Des PaaS comme Azure Web App Service ou Google App Engine sont appropriés pour les applications Java, .NET, Node.js ou Python. Ceux-ci fournissent des moteurs et un environnement d’exécution qui incluent souvent des fonctionnalités telles que l’autoscaling, le load-balancing, le redémarrage automatique des applications et le versionning des applications avec possibilités de rollback.
Le passage au SaaS est recommandé quand le système legacy est trop ancien pour être migré ad hoc dans le cloud, ou que l’apport de la version SaaS du logiciel est jugé rentable.
La migration d’applications plus communes (comme les serveurs de messagerie, les applications de collaboration, comme SharePoint, ou les outils de conférence Web, le CRM et l’ERP) est plus facile avec un SaaS. Les options SaaS fournissent généralement la dernière version de l’application sur un abonnement, avec des mises à jour continues, des contrôles de sécurité, un suivi des performances et une scalabilité inhérente. La plupart des entreprises peuvent assurer une transition des utilisateurs vers le SaaS, sans trop de résistance et avec aucune perte de données – si toutefois, l’entreprise n’a pas fortement personnalisé l’application existante.
Il faut prendre en compte le processus de mise à jour de l’éditeur, qui, même s’il est automatique, peut entraîner des contretemps. Soyons clairs, dans ce mode de consommation à l’usage, les versions majeures et mineures ne disparaissent pas réellement. Le changement de modèle économique peut également causer une perte de valeur par rapport aux systèmes spécifiques en place, sans oublier le moindre contrôle sur les données désormais externalisées. Le passage au SaaS est donc recommandé quand le système legacy est trop ancien pour être migré ad hoc dans le cloud, ou que l’apport de la version SaaS du logiciel est jugé rentable financièrement et fonctionnellement.
Moderniser et « re-plateformiser »
De manière plus générale, pour que les applications patrimoniales soient vraiment compatibles avec le cloud, il faut modulariser leur architecture – généralement monolithique – de manière à faciliter l’intégration des services cloud en natif. L’approche de type « Lift-and-Shift » convient aux applications qui ne peuvent pas être réarchitecturées, comme les applications commerciales achetées sur étagère. Elle est souvent utilisée lors d’une première phase de migration.
Même s’il s’agit d’une modification relativement mineure, comme le repartitionnement du code, tout ajustement pour le cloud des applications internes peut améliorer les performances et réduire les coûts.
Parmi ces ajustements, on peut citer la séparation de la base de données et de la logique métier afin que l’application puisse utiliser un service cloud (comme AWS Relational Database Service, Azure SQL Database ou Cloud SQL de Google), associé à une PaaS. Cela peut également porter sur la modularisation du code monolithique sous la forme de composants indépendants qui fonctionnent sur un service de containers (AWS EC2 Container Service ou Google Container Engine). Pour tirer le meilleur parti des offres des fournisseurs, il est même possible de déployer le SGBD sur un cloud et les applications sur un autre, comme ce que proposent Microsoft Azure et Oracle.
Tous ces efforts de migration, puis de modernisation, demandent d’établir un plan prenant en compte l’ensemble des critères qui font du cloud (surtout public) l’espace de choix pour héberger l’IT de l’entreprise. Si le cloud est synonyme d’une gestion technique et financière plus commode, il n’est pas moins cher, ni forcément meilleur qu’un datacenter. Il implique un changement d’organisation, la mise en place de nouvelles pratiques. L’idée est d’éviter de coûteux retours en arrière.
