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 une application donnée.

Pour les responsables des applications patrimoniales, les applications natives pour le cloud constitue un vrai bouleversement. Pourtant les deux mondes ne sont finalement pas si éloignés : applications patrimoniales et ressources du cloud peuvent dialoguer.

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 - 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 vues 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.

Mais, les infrastructures IaaS (Infrastructure as a Service), tels 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 véritablement 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 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.

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 et l'ERP, 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, Zerto, Carbonite DoubleTake et Racemi assurent la réplication en continue des données et minimisent ainsi les interruptions de services lors de la migration.

A 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 inclut souvent des fonctionnalités telles que l'autoscaling, le load-balancing, le avec redémarrage automatique des applications et le versionning des applications avec possibilités de  rollback.

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.

Moderniser et « re-plateformiser »

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.

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é à un 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 approfondir sur Applications et services

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close