Planification des vagues

Dans le cadre de la planification des vagues, un groupe de dépendances est un ensemble d'applications et d'infrastructures présentant des dépendances techniques et non techniques impossibles à résoudre. En raison de ces dépendances, les applications et l'infrastructure d'un groupe de dépendances doivent être migrées en même temps ou à une date précise. Par exemple, une application exécutée sur une machine virtuelle et une base de données exécutée sur une machine virtuelle distincte, soumises à des exigences de faible latence ou à des volumes de trafic élevés et à des requêtes complexes, sont susceptibles d'être migrées ensemble plutôt que d'utiliser un composant dans le cloud et l'autre sur site. De même, les applications indépendantes qui interagissent via une API présentant des exigences similaires en matière de faible latence seront également migrées en même temps.

Les vagues de migration s'étendent généralement sur 4 à 8 semaines et peuvent contenir un ou plusieurs événements migratoires. Les groupes de dépendance sont combinés en vagues afin qu'une vague puisse contenir un ou plusieurs groupes de dépendance. La vague contient également d'autres activités nécessaires à la migration. Cela inclut la configuration de AWS l'infrastructure (telle que la zone d'atterrissage, la sécurité et les opérations), les outils de migration et les activités de migration telles que la réplication des données, la planification de la transition, les tests et le support après la migration.

Pour mesurer le succès et suivre les progrès, les vagues doivent être alignées sur les résultats et les moteurs commerciaux. Cela influencera également la durée des vagues et les groupes de dépendance qu'elles contiennent. L'achèvement d'une vague doit être le reflet d'un résultat mesurable. La planification d'une vague peut également combiner d'autres facteurs, tels que des principes directeurs techniques. Par exemple, les vagues peuvent être définies par environnement (par exemple, développement, test, production) ou par stratégie de migration (par exemple, vague de rehost, vague de replateforme).

Pour créer des plans de vague de migration efficaces et fiables, vous devez obtenir une vue complète du portefeuille d'applications, de l'infrastructure associée (calcul, stockage, réseaux), du mappage des dépendances et de la stratégie de migration.

La section consacrée à l'établissement d'une base de référence pour le portefeuille d'applications décrit quatre catégories de dépendances techniques. Ces dépendances contribuent à la création de vagues de migration et à la définition de groupes de dépendance. Les groupes de dépendance seront déterminés en fonction de l'importance de la dépendance. En outre, les dépendances non techniques doivent être prises en compte. Par exemple, les calendriers de lancement des applications, les fenêtres de maintenance et les dates commerciales clés telles que le traitement de fin de mois ou de fin de trimestre influenceront le plan de vague.

Déterminez si la dépendance est souple ou dure. Une dépendance souple est une relation entre deux actifs ou plus, ou entre un actif et une contrainte, qui ne dépend pas de l'emplacement des composants. Par exemple, deux systèmes fonctionnant sur le même réseau local (ou la même infrastructure) peuvent être séparés en déplaçant l'un de ces systèmes vers le cloud tandis que l'autre reste sur site. Un autre exemple est un système qui peut être migré pendant une fenêtre de maintenance sans impact sur les activités de maintenance.

Une dépendance stricte est une relation entre deux actifs ou plus, ou entre un actif et une contrainte, qui dépend de l'emplacement. Par exemple, deux systèmes qui fonctionnent sur le même réseau local et qui sont fortement tributaires d'une faible latence pour la communication entre le serveur d'applications et le serveur de base de données ont une forte dépendance. Le transfert d'un seul de ces systèmes vers le cloud entraînerait des problèmes de fonctionnalité ou de performance impossibles à résoudre. De même, des raisons non techniques, telles que la disponibilité des ressources (par exemple, l'équipe chargée de la migration) ou des contraintes opérationnelles, telles que les fenêtres de maintenance pendant lesquelles deux systèmes ne peuvent être migrés que dans un intervalle de temps donné, peuvent créer une forte dépendance pour ces actifs.

Pour créer un plan de migration, déterminez vos groupes de dépendances en analysant les dépendances, idéalement à partir d'une source de données hautement fiable telle que des outils de découverte spécialisés, et combinez ces informations avec les critères de priorisation de vos applications et les circonstances opérationnelles. Les applications figurant en haut du classement par ordre de priorité doivent être ciblées en fonction de vos vagues de migration initiales. Déterminez la capacité des vagues (le nombre d'applications qu'une vague peut contenir) en fonction de la disponibilité des ressources, de la tolérance au risque, des contraintes commerciales et techniques, de l'expérience et des compétences. Envisagez de travailler avec des services AWS professionnels ou des partenaires de compétences en matière de AWS migration, qui peuvent fournir des spécialistes pour vous aider tout au long du processus.

Les critères de priorisation sont une première indication de l'ordre dans lequel vous allez déplacer vos applications vers le cloud. Cependant, les groupes de dépendance seront le véritable déterminant des applications qui seront déplacées à un moment donné. Cela est dû au fait que les applications classées comme hautement prioritaires peuvent être fortement dépendantes des applications situées au milieu ou au bas du classement.

La stratégie migratoire influencera également la composition d'une vague. Par exemple, une application hautement prioritaire qui nécessite une stratégie de refactorisation susceptible de nécessiter plusieurs semaines ou plusieurs mois d'analyse, de conception, de test et de préparation sera probablement placée dans une vague ultérieure.

Création d'un plan de vagues

Les données du portefeuille d'applications et l'évaluation détaillée du groupe d'applications qui seront migrées au cours de la vague sont des conditions préalables à la migration d'une vague d'applications. L'évaluation détaillée doit inclure la liste des applications incluses dans la vague, les détails de l'infrastructure associée, une conception cible et une stratégie de migration pour chaque application.

L'établissement de la propriété et de la gouvernance des vagues est essentiel pour gérer et suivre le travail des vagues, les dépendances entre les programmes, la gestion du changement, les problèmes et les risques. Assurez-vous qu'un cadre de gouvernance est en place pour gérer le plan.

Pour définir le plan de vagues, commencez par une construction de vague par défaut. Que se passe-t-il au sein d'une vague ? Une fois l'entrée initiale définie, la vague peut commencer. En règle générale, les activités seront les suivantes :

La durée de chacune de ces activités dépendra de la complexité de la portée, de la capacité des vagues, des personnes impliquées et de votre situation particulière. Dans la mesure du possible, des vagues plus petites sont préférables, car cela réduira l'impact des retards ou des blocages de migration. Déterminez, avec vos équipes, la durée par défaut d'une vague.

Procédez ensuite à l'analyse des dates pour créer une structure initiale de haut niveau composée de vagues vides (aucune application n'ayant encore été assignée). Posez-vous les questions suivantes :

En tenant compte de ces considérations, tracez les vagues dans un plan. Pour accélérer le processus de migration, nous recommandons de superposer les vagues dans la mesure du possible. La clé du chevauchement des vagues est de définir et de prendre en compte ce qui se passe au sein d'une vague. Généralement, les activités de déploiement, la validation de l'infrastructure cible et la synchronisation des données ont lieu au cours de la première moitié d'une vague. Le second semestre se concentrera sur la migration proprement dite, les tests et le transfert opérationnel. Cela signifie que différentes équipes sont impliquées dans chaque moitié du processus et que vous pouvez gagner en efficacité. Par exemple, dès que l'équipe impliquée dans la préparation de l'infrastructure cible aura terminé son travail, elle pourra commencer à travailler sur les exigences de la prochaine vague. En général, il est préférable que la plupart des vagues aient une longueur et une structure similaires afin de faciliter une approche industrielle des migrations. Cependant, au cours du processus de planification des vagues, la taille d'une vague donnée peut être étendue pour répondre aux dépendances ou aux exigences opérationnelles.

Ensuite, en fonction des groupes de dépendance identifiés, déterminez la taille maximale d'une vague en termes de nombre de groupes de dépendance qu'elle peut contenir. La taille des vagues est généralement dictée par l'appétit pour le risque (par exemple, dans quelle mesure les changements parallèles peuvent être tolérés) et par la disponibilité des ressources (par exemple, dans quelle mesure les changements parallèles peuvent être effectués avec les ressources, les compétences et le budget disponibles). Toutefois, lors de la planification initiale, ne vous limitez pas aux besoins en ressources et à la disponibilité. Les ondes qui contiennent plusieurs groupes de dépendance peuvent être décomposées en vagues plus petites lors des prochaines itérations.

Une fois que les groupes de dépendance pour une vague donnée ont été confirmés, passez en revue les ressources nécessaires à la migration de la vague. Envisagez d'ajuster la taille de la vague (le nombre de groupes de dépendance qu'elle contient) en fonction des besoins en ressources. Cela peut entraîner des vagues plus ou moins grandes. Répétez le plan de vagues selon les besoins jusqu'à ce que toutes les vagues aient été définies.

Gérer le changement

Le portefeuille d'applications et l'infrastructure associée évolueront au cours du cycle de vie des programmes de migration. Les programmes de migration de longue durée coexistent avec l'évolution et le changement normaux de l'entreprise. Les applications continuent d'évoluer en attendant d'être migrées. Des serveurs sont ajoutés ou supprimés, une nouvelle infrastructure est déployée sur site. On s'attend à ce que la portée d'une vague ou d'un groupe de dépendance doive être modifiée. Des modifications sont nécessaires, en particulier lorsque, à l'approche de la date de migration, une dépendance précédemment inconnue est identifiée ou qu'un nouveau serveur est inclus dans l'inventaire. Cela peut parfois se produire au cours de la migration elle-même.

Les modifications du champ d'application affectent les groupes de dépendance et les vagues. Pour gérer le changement et en minimiser l'impact, il est important de mettre en place un mécanisme de contrôle de la portée. Un mécanisme de contrôle des modifications du champ d'application nécessite la définition d'une source fiable unique pour le champ d'application. Il peut s'agir d'un outil de gestion du périmètre, d'un fichier .csv, d'une feuille de calcul ou d'une base de données, tel que défini par la gouvernance du programme de migration. Vous devez identifier les changements, analyser leur impact et communiquer les changements aux parties prenantes concernées afin qu'elles puissent prendre des mesures. Le plan de vagues sera donc itéré.