Migrer vers le cloud n’a rien de trivial. Selon la taille de votre infrastructure existante, la complexité de l’opération pourra devenir rapidement ingérable si elle n’est pas menée intelligemment. Nous exposerons dans cet article les meilleurs moyens de réussir sa migration vers le cloud, tirés de mon expérience en tant qu’architecte infrastructure sur plusieurs missions de migration vers le cloud AWS ou Azure.
Un inventaire exhaustif avant la migration vers le cloud
Toute migration vers le cloud doit commencer par un inventaire exhaustif des applications à migrer et de toutes les dépendances et éléments sur lesquels elles reposent. Dans un déménagement, vous commencez par faire vos cartons. C’est un peu pareil pour une migration vers le cloud. Si vous partez bille en tête dans la migration, vous allez au devant de très désagréables surprises qui apparaîtront peu à peu et vous forceront bien souvent à des retours-arrière très consommateurs en temps et en ressources.
Vous pouvez réaliser cette phase avec votre CMDB interne et la liste des applications correspondantes. Ou vous pouvez également vous reposer sur un outil proposé par les fournisseurs de cloud, permettant d’effectuer un inventaire exhaustif et complet avant de migrer votre application, ainsi qu’une évaluation du coût, comme Azure Migrate.
Informations à regrouper pour la migration vers le cloud
La liste des informations nécessaires à la migration doit inclure les points suivants les points suivants :
- Nom de l’application.
- Nom ou identifiant du lot associé (voir au chapitre “une migration des applications par lot”).
- Le ou les serveurs et services concernés.
- Pile des technologies propulsant l’application (Linux/PHP/MySQL par exemple).
- Cette application fait-elle partie d’une famille d’applications qui doit obligatoirement être migrée toutes ensemble ? Si oui précisez le nom de la famille.
- Nom et contact du responsable de l’application à prévenir.
- Temps d’arrêt possible de l’application pour effectuer la migration.
- La supervision devra-t-elle être modifiée lors de la migration ? Si oui, prévenir le service chargé de la supervision.
- Comment tester le bon fonctionnement de l’application ? Cela inclut-il de contacter une équipe qui se charge de ces tests ? Si oui, les inclure dans la migration pour le lot en question.
- Informations techniques dans le but de la migration :
- Comment couper l’arrivée de nouvelles requêtes vers l’application.
- Comment arrêter l’application.
- Comment migrer les données.
- Comment redémarrer l’application.
- Comment déclencher l’arrivée de nouvelles requêtes vers l’application une fois migrée.
Ces informations ne doivent pas être exhaustives et ont uniquement comme but de fournir toutes les informations nécessaire pour migrer aux équipes techniques chargées de la migration.
L’évaluation du coût de la migration vers le cloud et du futur coût de fonctionnement
Il est souvent ignoré, mais migrer vers le cloud a un coût. Direct, sous forme de volumétrie de données à envoyer vers le cloud mais surtout indirect, par le temps passé par vos techs sur le sujet. Ce coût ne pourra être effectué bien sûr qu’à partir de l’inventaire préalablement réalisé.
La partie la plus délicate va consister à estimer également le futur coût de fonctionnement de votre infrastructure dans le cloud. Pour cela vous devez lister l’ensemble des éléments d’infrastructure que vous allez créer et leur associer un coût.
Heureusement pour nous, les plateformes de cloud proposent des calculettes permettant de réaliser ces estimations. Par exemple AWS Pricing Calculator pour AWS de Amazon et Azure Pricing Calculator pour Azure de Microsoft.
Une migration des applications lot par lot
Avoir l’infrastructure en place ne suffit pas à réussir une migration. J’ai travaillé sur certaines plateformes avec une cinquantaine d’applications internes. Il vous faut un process de migration étape-par-étape pour chaque application ou famille d’application si elles utilisent les mêmes éléments techniques et concernent les mêmes personnes. On va donc migrer les applications une à une, on emploiera le terme de “lot”.
Parfois il est nécessaire de migrer plusieurs applications conjointement. Il faudra alors prévoir des familles de lots et le temps d’arrêt associé pour migrer la famille de lots dans son ensemble.
La migration par lot unique sera à privilégier la majorité du temps, même si elle amène un inconfort temporaire de gestion pour les équipes applicatives, car il reste beaucoup plus facile de migrer un lot isolé que plusieurs lots d’un coup.
Les erreurs pouvant résultées d’une migration de plusieurs lots d’un coup sont aussi plus difficiles à identifier, ainsi que le retour arrière parfois nécessaire en cas de dysfonctionnement constaté pendant la phase de tests post-migration.
Les étapes de la migration d’un lot applicatif
Les informations de chaque lot doivent identifier les points suivants et se dérouler dans l’ordre suivant :
- Prévenir le responsable de l’application à migrer.
- Vérifier le bon fonctionnement de l’application avant de procéder.
- Couper la supervision.
- Couper l’arrivée de nouvelles requêtes vers l’application. Si cela n’est pas possible, arrêter l’application.
- Lancer l’application dans le cloud.
- Migrer les données.
- Couper l’application sur l’ancienne plateforme si cela n’a pas été déjà fait. Désactiver définitivement le redémarrage automatique.
- Vérifier le bon fonctionnement de l’application sur la nouvelle plateforme.
- Redémarrer la supervision.
- Activer l’arrivée des nouvelles requêtes sur l’application migrée.
- Prévenir le responsable du bon déroulement de la migration.
Bien sûr cette liste peut être constituée au fil de l’eau, lot par lot. Je le recommande même, afin de ne pas entrer dans une phase de regroupement d’informations longues et fastidieuses. Elle permet aussi de poser les jalons des réunions à faire avec les équipes chargées des applications pour les sensibiliser à la migration et obtenir leur savoir sur le sujet.
Mais le lot d’information concernant l’application à migrer doit toujours être faite à l’avance de la migration, en amont, afin de réduire les frictions le jour de la dite migration.
Votre migration ainsi organisée lot par lot (ou par famille de lots) apparaîtra ainsi beaucoup plus facile à réaliser, découpées étape par étape, avec un process identifié, possible à gérer et à faire avancer par un chargé de projet.
Conclusion
Nous avons abordé les principaux prérequis à une migration réussie vers le cloud. Les phases d’inventaire et de prise d’informations pour les lots sont les plus importantes. Ne pas regrouper les informations nécessaires à la migrations, le plus complètement possible, expose vos équipes techniques à de lourds problèmes le jour de la migration du lot concerné, qui bien sûr exposera à son tour toute l’entreprise surtout sur des applications critiques.
Pris un par un, le découpage par lots de migration permet d’itérer d’égrainer un à un ces lots constituant une migration complète d’un système d’information complet rendu complexe par le nombre d’applications à migrer, qui sera donc abordé sereinement avec un process identifié et dont l’avancement peut être tracé dans un reporting régulier à destination de la direction de l’entreprise.
Me suivre sur les réseaux sociaux
Carl Chenet, architecte infrastructure onpremise et cloud (AWS et Azure). N’hésitez pas à me suivre directement sur mes différents sociaux :
- Mastodon : @carlchenet
- Twitter : @carl_chenet
- LinkedIn : Carl Chenet