Décrire l’infrastructure de migration Azure
Avant de pouvoir commencer à migrer les charges de travail locales de Tailwind Traders vers Azure, vous devez envisager de créer un plan de migration. Le plan doit identifier les charges de travail à migrer et les services ou outils appropriés à utiliser pendant la migration. Dans l’idéal, votre plan doit également inclure des détails sur la façon d’optimiser les services migrés.
L’infrastructure de migration Azure peut vous aider à développer votre plan et à procéder à la migration. L’infrastructure se compose de quatre phases : Évaluer, Migrer, Optimiser et Superviser.
Phase 1 : Évaluer votre environnement local
Lors de la première étape, vous évaluez l’environnement local actuel :
- Identifiez vos applications, ainsi que les serveurs, les services et les données associés, qui se trouvent dans l’étendue de la migration.
- Commencez à impliquer les parties prenantes, telles que le service Informatique et les groupes métier pertinents.
- Créez un inventaire complet et une carte des dépendances des serveurs, des services et des applications que vous prévoyez de migrer.
- Estimez les économies réalisées à l’aide de l’Outil de calcul du coût total de possession (TCO) Azure.
- Identifiez les outils et services appropriés que vous pouvez utiliser pour mettre en œuvre les quatre phases.
Modèles de stratégie de migration
Il existe cinq modèles généraux de stratégie pour migrer des charges de travail vers le cloud, généralement appelés les cinq R de rationalisation : Réhéberger, refactoriser, rearchitecturer, régénérer et remplacer. La stratégie que vous adoptez dépend des facteurs qui pilotent votre activité et des objectifs de la migration. Vous pouvez envisager d’adopter plusieurs modèles. Vous pourriez choisir de réhéberger des applications simples ou des applications qui ne sont pas essentielles à votre activité, et de réarchitecturer les applications plus complexes et vitales pour l’entreprise.
Réhéberger : le réhébergement est souvent appelé migration lift-and-shift. Cette stratégie ne nécessite pas de modification du code, et vous permet de migrer rapidement vos charges de travail existantes vers Azure. Chaque charge de travail est migrée en l’état, sans les risques et les coûts associés aux modifications du code.
Refactoriser : la refactorisation est souvent appelé repackaging (ré-empaquetage). La refactorisation nécessite des modifications minimales des applications pour qu’elles puissent se connecter à Azure PaaS (Platform as a Service) et utiliser les offres cloud. Vous pouvez migrer des applications existantes vers Azure App Service ou AKS (Azure Kubernetes Service). Vous pouvez également refactoriser des bases de données relationnelles et non relationnelles en d’autres options. Refactorisez en Azure SQL Managed Instance, Azure Database pour MySQL, Azure Database pour PostgreSQL et Azure Cosmos DB (si votre application peut facilement être ré-empaquetée pour fonctionner dans Azure).
Réarchitecturer : la réarchitecture pour la migration porte principalement sur la modification et l’extension des fonctionnalités et de la base de code de l’application, avec comme objectif d’optimiser l’architecture de l’application pour la scalabilité du cloud. Vous pouvez décomposer une application monolithique en un groupe de microservices qui fonctionnent ensemble et sont facilement mis à l’échelle. Vous pouvez également réorganiser les bases de données relationnelles et non relationnelles en une solution de base de données complètement managé Réarchitecturez vers Azure SQL Managed Instance, Azure Database pour MySQL, Azure Database pour PostgreSQL et Azure Cosmos DB.
Recréer : la recréation va encore plus loin en recréant complètement une application au moyen des technologies du cloud Azure. Vous pouvez créer des applications entièrement nouvelles avec des technologies natives Cloud comme Azure Functions, Azure AI, Azure SQL Managed Instance et Azure Cosmos DB.
Remplacer : Implémentez des solutions à l’aide des meilleures technologie et approche du moment. Parfois, les applications SaaS (Software as a service) peuvent fournir toutes les fonctionnalités nécessaires à vos applications hébergées. Ensuite, une charge de travail peut être planifiée pour le remplacement, en la supprimant de l’étendue de la migration.
Le tableau suivant liste les scénarios d’utilisation des quatre modèles.
| Réhéberger | Refactoriser | Créer une nouvelle architecture | Regénérer | Replace |
|---|---|---|---|---|
| Déplacer rapidement des charges de travail vers le cloud Déplacer une charge de travail sans la modifier Pour les applications conçues afin de tirer parti de la scalabilité d’Azure IaaS après la migration Quand des charges de travail sont importantes pour votre activité, mais que vous n’avez pas besoin de modifications immédiates des fonctionnalités des applications |
Appliquer des pratiques DevOps innovantes fournies par Azure Implémenter une stratégie de conteneur DevOps pour des charges de travail Prendre en charge la portabilité de votre base de code existante et des compétences de développement disponibles |
Vos applications ont besoin de révisions majeures pour incorporer de nouvelles fonctionnalités Vos applications ont besoin de révisions majeures pour fonctionner efficacement sur une plateforme cloud Utiliser les investissements d’applications existants Répondre aux exigences de scalabilité Appliquer des pratiques DevOps innovantes Réduire l’utilisation des machines virtuelles |
Développement rapide Prendre en charge les applications existantes avec des fonctionnalités et une durée de vie limitées Accélérer l’innovation métier à l’aide des pratiques DevOps Recréer avec de nouvelles technologies natives du cloud comme Azure Blockchain Recréer des applications héritées en tant qu’« applications sans code » ou « applications à code faible » dans le cloud |
Normaliser les meilleures pratiques du secteur Accélérer l’adoption des approches basées sur les processus d’entreprise Réallouer des investissements de développement qui assurent une longueur d’avance ou procurent d’autres avantages sur la concurrence Remplacer des solutions existantes pour des offres SaaS |
Phase 2 : Migrer vos charges de travail
Une fois l’évaluation terminée, vous pouvez commencer le processus de migration de vos applications ciblées et de leurs services et données associés. La phase de migration implique généralement les efforts suivants :
Déployer les cibles de l’infrastructure cloud. Avant de pouvoir migrer les charges de travail de Tailwind Traders, vous devez créer les cibles d’infrastructure cloud requises. Selon les outils que vous utilisez pour effectuer la migration, vous devrez peut-être créer les ressources Azure requises avant de commencer la migration. Certains outils, tels qu’Azure Migrate et Azure Database Migration Service, peuvent créer les ressources Azure cibles pour vous.
Migrer des charges de travail. Il est judicieux de piloter la migration de vos charges de travail et de choisir une application non critique pour le pilote. Cette approche vous permet de vous familiariser avec les outils, d’acquérir de l’expérience avec les processus et les procédures, et de réduire les risques lors de la migration de charges de travail volumineuses ou complexes.
Désactivation de l’infrastructure locale : une fois que vous êtes satisfait du succès de la migration de vos bases de données et applications sources, vous devez désactiver les charges de travail sources. Envisagez de conserver les sauvegardes des charges de travail sources et des données archivées. Ces données peuvent s’avérer utiles, car elles fournissent une archive historique. Vous pouvez stocker ces sauvegardes et archives dans Stockage Blob Azure.
Phase 3 : Optimiser vos charges de travail migrées
Pour la phase d’optimisation, vous devez vous concentrer sur trois principaux efforts pour votre planification :
- Analyser les coûts de migration pour vos charges de travail
- Passer en revue les recommandations pour réduire vos coûts
- Identifier les options pour améliorer les performances de vos charges de travail
Vous pouvez utiliser Microsoft Cost Management (anciennement Azure Cost Management and Billing) dans le portail Azure pour analyser les coûts de vos charges de travail. Cet outil est disponible pour le groupe de ressources Azure qui contient vos charges de travail migrées. Vous trouverez l’outil dans la section Analyse des coûts>Gestion des coûts. La capture d’écran suivante montre l’analyse des coûts pour la dernière période facturable pour le groupe de ressources ContosoResourceGroup. Les résultats montrent les coûts répartis par nom de service, région et ressource. Vous pouvez personnaliser l’affichage des résultats pour répondre à vos besoins.
Pour aider à réduire vos coûts, vous pouvez utiliser les fonctionnalités d’Azure Advisor en choisissant Recommandations Advisor. Après avoir analysé vos coûts actuels et passé en revue les recommandations, vous pouvez déterminer les options à votre disposition pour améliorer les performances de vos charges de travail.
Phase 4 : Superviser vos charges de travail
Vous pouvez utiliser Azure Monitor pour capturer des informations d’intégrité et de performances à partir de vos machines virtuelles Azure. Installez l’agent Journaux Azure Monitor (anciennement Log Analytics) sur les machines virtuelles cibles, puis configurez les alertes et les rapports.
Notes
Vous pouvez installer l’agent Journaux Azure Monitor sur des machines exécutant Windows ou Linux.
Vous pouvez configurer des alertes basées sur une variété de sources de données :
- Valeurs métriques spécifiques telles que l’utilisation du processeur
- Texte spécifique dans les fichiers journaux
- Mesures d’intégrité
- Métriques de mise à l’échelle automatique