Qu'est-ce que la migration vers le cloud ?

Qu'est-ce que la migration vers le cloud ?

La migration vers le cloud consiste à déplacer des applications, des données et des charges de travail d'un environnement à un autre, le plus souvent de serveurs sur site vers un cloud public comme AWS, Azure ou Google Cloud. Elle couvre aussi les déplacements entre clouds et le retour vers l'infrastructure interne (rapatriement). Une migration peut être le simple déplacement d'un serveur ou une refonte de l'application pour utiliser des services cloud managés.

Les 7 R de la migration vers le cloud

AWS décrit sept stratégies de migration, appelées les 7 R. On en choisit une par application, pas une pour tout le parc.

• Rehost (lift and shift). Déplacer l'application telle quelle, sans modification.
• Replatform (lift, tinker and shift). La déplacer en y apportant quelques optimisations, par exemple passer d'une base de données auto-gérée à une base managée.
• Refactor ou ré-architecture. La repenser pour tirer parti des fonctions natives du cloud. La plus complexe et la plus coûteuse des sept.
• Relocate. Déplacer des serveurs ou instances vers la version cloud de la même plateforme, ou vers un autre compte, VPC ou région, sans changer l'architecture.
• Repurchase (drop and shop). Remplacer l'application par un SaaS ou un produit plus récent.
• Retire. Éteindre les applications dont personne n'a besoin. AWS cite par exemple les applications sans connexion entrante depuis 90 jours.
• Retain. La laisser où elle est, par exemple pour la résidence des données, du matériel spécialisé, un mainframe ou un achat de matériel récent.

Pour les grandes migrations, AWS recommande de commencer par rehost, relocate ou replatform et de moderniser ensuite, car refactoriser pendant le déplacement est le plus difficile à piloter.

Les phases d'une migration

1. Évaluer et planifier

Recensez applications, dépendances, flux de données, besoins réseau et licences. Regroupez les applications en vagues et choisissez une stratégie pour chacune. Notez les performances actuelles, car ce sera votre référence ensuite.

2. Construire la landing zone

Mettez en place comptes, réseau, identité, journalisation et contrôle des coûts avant tout déplacement. La définir en code avec l'infrastructure as code la rend reproductible. Voir la gouvernance cloud pour les règles à fixer tôt.

3. Vague pilote

Déplacez d'abord quelques applications à faible risque pour éprouver la landing zone, les étapes de bascule et le plan de retour arrière.

4. Vagues de migration

Chaque vague a une méthode de synchronisation des données, un plan de bascule DNS, un plan de retour arrière et une supervision. Testez avant la bascule, pas après.

5. Optimiser et exploiter

Ajustez la taille des instances, supprimez les ressources inutilisées, examinez les coûts de transfert de données et modernisez ce qui a été migré tel quel. Suivez le résultat avec la supervision cloud.

Exemple

Une entreprise exploite une boutique en ligne sur deux serveurs internes avec une base MySQL auto-gérée. Elle choisit le replatform : l'application passe sur des machines virtuelles dans le cloud et la base sur un service MySQL managé. Avant la bascule, elle lance un test de charge au pic attendu sur le nouvel environnement et compare temps de réponse et taux d'erreurs avec les valeurs relevées sur les anciens serveurs. Elle ne change le DNS que lorsque le nouvel environnement égale ou dépasse ces valeurs, et garde les anciens serveurs pendant une durée définie comme voie de retour.

Erreurs courantes en migration vers le cloud

• Tout rehoster et s'arrêter là. Le déplacement est rapide, mais sans ajustement de taille ni nettoyage, vous payez des machines surdimensionnées.
• Sauter la référence. Sans mesures de l'ancien environnement, impossible de savoir si la version cloud est plus lente.
• Ne pas tester sous charge. Les chemins réseau, le débit de stockage, les limites des services managés et les appels d'identité se comportent autrement que dans l'ancien centre de données.
• Ignorer les coûts de transfert. Le trafic entre zones, entre régions et vers Internet est facturé, donc l'emplacement des données compte.
• Traiter l'identité en dernier. Les dépendances d'annuaire et d'authentification unique bloquent souvent la bascule.
• Aucun garde-fou de coûts. Budgets, étiquettes et alertes doivent exister avant l'arrivée de la première charge.
• Éteindre trop tôt l'ancien environnement. Gardez-le jusqu'à ce que le retour arrière n'ait pas servi pendant une durée convenue.
• Imposer un refactoring dans le déplacement. Découper un monolithe en microservices pendant la migration ajoute du risque. Migrez d'abord, modernisez ensuite.

Valider une migration par les tests et la supervision

L'étape la plus souvent sautée est la preuve que l'application migrée tient la charge. Lancez un test de charge sur le nouvel environnement au trafic de pointe attendu et comparez avec votre référence. La plateforme de load testing LoadFocus exécute des tests JMeter et k6 depuis 25 régions cloud, ce qui permet de générer du trafic depuis les zones de vos utilisateurs. Après la bascule, la supervision d'API vérifie de façon planifiée les codes de statut, les corps de réponse et le temps de réponse, et vous alerte en cas d'échec. Pour le volet test de la décision, lisez cloud vs on-premise load testing (en anglais).

Questions fréquentes : migration vers le cloud

Combien de temps dure une migration vers le cloud ?

Cela dépend du nombre d'applications, de leurs dépendances et de la stratégie retenue. Un rehost de quelques serveurs simples peut prendre quelques semaines, alors qu'un grand portefeuille se planifie en vagues sur des mois ou des années. Considérez tout chiffre isolé comme une estimation tant que l'évaluation n'est pas terminée.

Quelle différence entre rehost et replatform ?

Le rehost déplace l'application sans modification. Le replatform la déplace avec quelques optimisations, comme le passage à une base managée, sans repenser l'application.

Faut-il migrer toutes les applications ?

Non. Certaines sont retirées et d'autres conservées pour des raisons de conformité, de matériel spécialisé ou d'investissement récent. Les 7 R incluent les deux options pour cette raison.

Qu'est-ce que le rapatriement depuis le cloud ?

Ramener des charges de travail du cloud vers l'infrastructure interne ou un centre de colocation. Les équipes le font pour le coût, la conformité ou des charges prévisibles qui ne profitent pas d'une capacité élastique.

Comment tester une migration avant la bascule ?

Relevez temps de réponse et taux d'erreurs de l'ancien environnement comme référence, lancez un test de charge au pic attendu sur le nouveau, comparez les résultats et répétez le retour arrière. Ne basculez le trafic que lorsque les chiffres concordent.