The Doppler Quarterly (FRANÇAIS) Printemps 2018 - Page 22

La détermination de la compatibilité avec le cloud et du modèle de migration exige la création et la définition de cette compatibilité, puis une analyse soigneuse des caractéristiques de l’application au travers d’objectifs et de moyens qualitatifs. Facteur n° 3 : plan de migration prescriptif avec prise en compte des détails Lorsqu'une analyse de l'application détermine que celle-ci est adaptée à la migra- tion, et que ses modèles de migration sont connus, vous devez élaborer un plan de migration détaillé. Outre l’objectif global de la migration, un plan de migration doit inclure les détails de l’exécution, y compris toutes les tâches et tous les propriétaires de la migration. Les détails du niveau d'exécution sont variables selon le modèle de migration choisi. Un modèle Rehost, par exemple, comprendra principalement des tâches d’infra- structure incluant quelques modifications de configuration des applications, ainsi qu’un plan de test et de validation. Une migration fondée sur le modèle Refactor, en revanche, devra prévoir les détails de chacun des éléments à modifier, y compris leur état actuel et futur, les fonctionnalités, le code d’accompagnement, les détails du déploiement, ainsi que les plans de test et de validation. Il convient que le plan de migration contienne au minimum les éléments suivants : • • • • • • • • • Vecteurs et attentes en matière d'activité Fonctionnalités Architecture à l’état actuel et à l'état futur Modèles et approche Liste des ressources et dépendances Configurations ou modifications souhaitées Outils (migration, déploiement, surveillance, journalisation) Tâches de migration détaillées, plans de déploiement avec RACI Niveau de préparation, test, validation, mise en service et plans opérationnels Pour que les efforts de migration permettent d'atteindre la vitesse et l’échelle désirées, le plan de migration appliqué lors de l’exécution doit être très prescriptif. De plus, les approches et artefacts réutilisables, ainsi que les approches en libre-ser- vice destinées à une multiplicité de parties prenantes, sont de nature à réduire gran- dement le temps de latence. Lors de la création d'un plan de migration détaillé, il importe de prendre en compte les approches susceptibles de raccourcir les temps d’immobilisation nécessaires au basculement durant la phase de migration. Pour viser une interruption de service quasi-nulle lors de la migration d’applications, vous pouvez appliquer différentes options telles que des déploiements « bleu/vert », la réplication incrémentielle, un environnement isolé pour le test et la validation avant le basculement, ou encore des enregistrements DNS temporaires aux fins de test. Vous pouvez par exemple élaborer des listes de contrôle de migration standard pour chacun des modèles, que vous pourrez ensuite répercuter sur l'ensemble des appli- cations. Bon nombre d’organisations disposent d'un ensemble d’outils de test et de validation communs. Par conséquent, l'usage d'un ensemble de tests commun à tous les modèles est utile pour permettre à l’équipe des opérations d'intégrer les applica- tions suivant le rythme souhaité. 20 | THE DOPPLER | PRINTEMPS 2018