À l'heure où la technologie évolue à une vitesse fulgurante, la migration des applications legacy vers le cloud n'est plus une option mais une nécessité. Malgré l'émergence du cloud-native dans les projets IT, de nombreuses entreprises continuent de s'appuyer sur des infrastructures et des applications dites "legacy". Ces plateformes, souvent maintenues en mode "best-effort", posent plusieurs problématiques majeures : incidents critiques, manque de résilience ou de mise à l'échelle, pas de gestion des dépendances de code, peu de documentation, moins de développeurs maitrisant la technologie d'origine, etc...
La transition vers le cloud, ou move-to-cloud, résout ces problèmes en utilisant, entre-autres, des services managés, infrastructure-as code, intégration, déploiement continu et observabilité.
Dans cet article, découvrez comment moderniser vos applications legacy avec une stratégie de replatforming et des services managés dans le cloud.
Choisir une stratégie
Le concept des 5 R's popularisé par Gartner dans les années 2000 a été le premier à proposer un modèle de stratégies de migration d'application dans le cloud avec une démarche à suivre pour chacune d'entre elles. Au fil des années, ce modèle a évolué afin d'aboutir au modèle des 7 R's d'AWS :
Ces stratégies nécessitent toutes un niveau plus ou moins grand d'effort pour arriver à l'objectif désiré : Retire (décommissionner), Retain (garder), Rehost (ré-héberger ou lift-and-shift), Relocate (déplacer), Repurchase (racheter), Replatform (déménager) ou Redesign/Refactor (redesigner)
Plutôt qu'un énième article basé uniquement sur ces stratégies, prenons un exemple concret de migration d'application...
Prenons l'exemple...
... d'une application de gestion de bibliothèques municipales et de médiathèques d'une grande ville. Cette application propose plusieurs fonctionnalités essentielles : modules de suivi des emprunts et des retours, gestion des stocks de livres, gestion des utilisateurs et utilisatrices, notifications de rappel pour les retours, etc...
Côté tech, il s'agit d'une application web Java avec une API, utilisant une base de données relationnelle, du stockage de fichiers (extraits de livres, livres numériques...) et un service d'envoi d'e-mails pour les notifications. Hébergée dans un datacenter de la ville sur un écosystème de machines virtuelles, les mises en production se font de manière semi-automatisée, ce qui n'est pas sans risque pour la disponibilité de la plateforme.
Cette architecture pose de sérieux défis à l'équipe IT : difficulté à gérer les pics de demande, maintenance complexe et coûteuse des serveurs, problèmes de fiabilité... De plus, une réduction des coûts opérationnels doit être opérée car la ville a décidé de réduire progressivement son infrastructure d'hébergement, la maintenance étant devenue trop coûteuse et complexe.
Bref, l'équipe va devoir "déménager" l'application vers un environnement plus moderne, plus sûr, mais comment va-t-elle s'y prendre ?...
Dans notre cas, les contraintes sont les suivantes :
- durée du projet : la migration doit être finalisée avant la rentrée prochaine
- resources limitées : petite équipe de développement, budget limité
- disponibilité : le site doit toujours être accessible, même lors des mises en production
- performance : l'interface doit répondre dans des délais garantis, les notifications envoyées à temps
- mise à l'échelle : l'application doit pouvoir augmenter sa capacité lors des pics de trafic (lors de la rentrée scolaire, par exemple)
En prenant en compte ces contraintes, nous excluons d'office la stratégie de faire un Redesign complet de la plateforme, trop coûteux en temps et en ressources par rapport à l'objectif visé. À défaut, la stratégie Rehost (ou "lift & shift") permettrait de migrer l'application telle quelle vers une infrastructure cloud plus rapidement. En revanche, pas vraiment de gain sur les performances ou sur la mise à l'échelle.
Les autres solutions ne correspondant pas au contexte, le choix se porte donc sur un Replatforming (ou "lift & reshape"). Cette stratégie implique un changement de plateforme technique pour tirer parti de services managés dans le cloud tout en optimisant l'existant. Cette solution est donc un premier pas afin de migrer l'application dans le cloud et l'optimiser à meilleur coût. Relativement peu d'adaptations dans le code seront nécessaires et le gain sera significatif sur les performances et la stabilité de la plateforme.
Choix de la plateforme
Le choix d'un cloud provider se fait souvent selon des critères dépendant généralement de la stratégie de l'organisation. Pour héberger son application, l'équipe projet fait le choix de migrer sur AWS, dont elle utilise déjà certains services pour d'autres applications.
Une proposition de solution pourrait mettre en oeuvre les composants suivants :
- Un Application Load Balancer (ALB) pour répartir le trafic entrant entre les machines dans différentes zones (disponibilité)
- Un Autoscaling group qui permettra de dimensionner automatiquement un ensemble de machines virtuelles EC2 en fonction de la charge (mise à l'échelle)
- Un cluster Amazon RDS avec le même moteur de base de données que l'application source (MySQL/MariaDB) : une variété de types de bases de données peuvent être gérées dans AWS. Le service RDS est celui qui conviendra le mieux pour migrer notre base source.
- Des buckets S3 pour le stockage des extraits de livres et des livres numériques
- Amazon SES pour l'envoi des e-mails aux utilisateurs
Une fois le choix du cloud provider et l'architecture cible réalisés (et bien documentés), passons au déploiement de la base de nos environnements, la landing zone ✈️.
La landing zone : le socle du déploiement
Pour déployer de nouveaux environnements d'applications dans un cloud public, on passe par la création d'une landing-zone qui représente le socle de notre architecture. Celle-ci comprend les éléments qui vont permettre d'héberger le projet : réseau, sécurité, utilisateurs et permissions, interconnexion vers l'infrastructure legacy pour la migration, services managés...
La construction de la landing-zone se fait au travers d'outils d'Infrastucture-as-Code devenus aujourd'hui indispensables pour industrialiser une application dans le cloud. Terraform (ou sa version open-source OpenTofu) est la référence dans le domaine, mais il en existe d'autres (CloudFormation (AWS), Pulumi...).
L'équipe projet voulant opter pour une approche cloud-agnostic, elle choisit de déployer sa landing-zone avec Terraform.
On déménage progressivement
... l'infrastructure
L'équipe infra développe ensuite des modules Terraform réutilisables pour déployer les différents environnements de l'application sur sa landing-zone. Chaque environnement se compose d'un ensemble de services nécessaires pour exécuter l'application : Instances EC2, Auto-scaling Groups, buckets S3, instance RDS, RDS proxy...
Suivre les bonnes pratiques de création d'un projet Terraform sur AWS pour structurer de manière efficace vos déploiements
... la base de données
Une fois les instances de bases de données déployées dans le cloud, les données devront être exportées de la base source, éventuellement transformées pour être adaptées au schéma cible, puis chargées dans la nouvelle base.
On utilise pour cela un outil de DMS (Database Migration Service) ou, s'il est nécessaire de transformer les données, un ETL (Extract-Transform-Load). Il existe tout un tas de solutions open-source ou propriétaires de ces deux types dont certains maintenus par les cloud providers eux-mêmes. Dans notre cas, le choix se portera sur AWS Database Migration Service, qui permet de migrer facilement la migration de bases de données MySQL legacy vers Amazon RDS.
... le code et la CI
La stratégie de replatforming ayant pour cible un déploiement sur machines virtuelles, peu d'adaptations du code seront nécessaires. Les modifications à apporter sont liées principalement aux services managés utilisés : connexion à la base de donnée RDS, gestion des fichiers stockés sur le S3, envoi des notifications via Amazon SES.
Le code source de l'application étant hébergé sur GitLab, l'équipe développe un pipeline gitlab-CI dédié pour construire ses artefacts, les tester et les déployer sur ses environnements.
- Scan des configurations IaC : (checkov, tflint)
- Détection de secrets dans le code (gitleaks)
- Mises à jour de dépendances automatisées (renovatebot)
- Scan de vulnérabilités (trivy)
Monitorer la consommation cloud, l'aspect FinOps
Le choix de partir sur un cloud public ne s'est pas fait par hasard : un chiffrage du projet de move-to-cloud ainsi qu'une analyse prévisionnelle des coûts d'exploitation lorsque la plateforme sera en production ont été réalisés au préalable.
Deux types d'outils peuvent être utilisés pour définir et suivre le budget d'exploitation d'une application cloud sur AWS :
- Pricing calculator : il permet, dans la phase d'avant projet, de guider la décision vers l'utilisation de solutions managées ou non. Il existe même des comparateurs pour vous aider à faire le choix d'un provider en fonction du budget de votre projet
- Budget monitor : permet de suivre la consommation des services cloud et de mettre en place des alertes sur l'utilisation de ces services et optimiser le cas échéant (limiter l'autoscaling, ajuster l'envoi de notifications...)
La dimension FinOps de tout projet de migration cloud est à anticiper au plus tôt afin qu'il n'y ait pas de déconvenue sur les dépenses liées à l'utilisation des services managés.
Point de vue
Migrer et moderniser une application legacy vers le cloud n'est pas toujours une balade de santé, mais heureusement pour nous, le procédé est éprouvé. Il existe différentes stratégies de migration qui pourront guider vos projets sur le chemin de la rénovation IT en fonction de votre contexte et de vos besoins. La clé est d'évaluer chacune des solutions et de déterminer laquelle, avec le minimum d'effort, aura le maximum d'impact. Même si le redesign d'une architecture est idéal pour coller le plus possible à une architecture cloud-native, il est néanmoins possible d'opter pour un rehosting ou un replatforming pour migrer dans un premier temps vers le cloud.
Ici, nous avons choisi de migrer la solution sur AWS, mais cette stratégie peut également se déployer sur d'autres cloud providers, avec le choix d'utiliser des services plus ou moins managés. Le tout dépendant de la charge de travail que vous souhaitez déléguer au provider une fois l'application en production.
Une grande diversité de services sont à votre disposition pour vous accompagner dans la migration de la Data, de l'Infra et du Code, qu'ils soient open-source ou propriétaires. Ne pas oublier que la migration d'une application est l'opportunité d'améliorer les gains de fiabilité et les performances tout en augmentant la longévité du produit. L'observation de la stabilité et le suivi du budget s'en trouveront également optimisés par l'utilisation d'outils dont il faudra tirer parti du plein potentiel.
En fin de compte, migrer vers le cloud, c'est un peu comme passer d'une bibliothèque poussiéreuse à une bibliothèque numérique : au début, ça peut sembler déroutant, mais une fois qu'on y est, on se demande comment on a pu s'en passer ! 📚➡️💻
