Migrer dans le Cloud, oui mais comment ? Ici nous allons parler de Lift and Shift ou de Replatforming mais avant d’aller plus loin il faut déjà connaître la différence entre Lift & Shift et Replatforming.
Dans le L&S rien de bien compliqué. On prend ce qu’on a On-Premise ou dans un autre Cloud et on le déplace tel quel dans le nouveau Cloud. On ne change absolument rien, c’est du 1 pour 1.
Au contraire, dans le Replatforming, nous allons essayer de tirer parti des services Cloud natifs pour se désengager de serveur d’infrastructure, comme par exemple le serveur AD, le serveur de sauvegarde (avec des solutions Backup as a Service), les serveurs de fichiers, …
Ce Replatforming peut également être l’occasion de déployer des services de bases de données managés pour ne plus avoir à gérer l’achat de licences liées à des solutions comme par exemple MS SQL ou Oracle.
Bien. Mais quelle est la bonne méthode ?
C’est parti, la décision de migrer vers le nouveau Cloud a été actée. Maintenant il ne reste plus qu’à savoir comment y aller. L’utilisation de telle ou telle méthode va surtout être prise en fonction du temps à accorder à la migration.
Avant même le début de la migration vous avez la pression, on vient de vous annoncer que le DataCenter historique doit être vide dans trois mois !
Dans ce cas le Lift and Shift s’impose car ce sera sans aucun doute la seule méthode pour respecter le délai. Le changement étant mineur (on passe d’une plateforme de virtualisation à une autre) l’exploitation de la nouvelle plateforme n’en sera que peut affectée. Le besoin en formation des équipes sera toutefois nécessaire mais dans une moindre mesure. Même si vous avez des délais prenez garde a ne pas confondre vitesse et précipitation.
Vous avez du temps ? Rien ne presse ? Ici le Replatforming s’impose. Nous allons pouvoir commencer à utiliser les services Cloud natifs, par exemple mettre des bases de données managées en lieu et place des anciens serveurs de BDD et ne plus utiliser nos anciens serveurs de sauvegarde et ainsi diminuer les coûts d’exploitation.
Cependant, au contraire du Lift and Shift, il faudra penser à former les différentes équipes aux nouveaux outils Cloud.
Cependant, que vous choisissez finalement de faire votre migration en Lift & Shift ou en Replatforming, la méthodologie ainsi que les étapes à suivre resteront sensiblement les mêmes, c’est pourquoi dans la suite de l’article il n’y aura que peu d’écart entre l’une ou l’autre des solutions.
L’équipe
La constitution de l’équipe de migration est un élément essentiel si on ne veut pas aller droit dans le mur !
L’équipe doit intégrer dès le début les responsables applicatifs, les experts techniques et l’architecte cloud, sans oublier bien évidemment les utilisateurs finaux, au moins un panel représentatif.
Pourquoi tant de monde ? La réponse est relativement simple : seule cette équipe pourra réellement valider le bon fonctionnement des workloads migrés aussi bien fonctionnellement que techniquement.
Le « packaging »
Tout est prêt, la méthode de migration a été définie. Ici peu importe que l’on parle de L&S ou de Replatforming, il va falloir définir les « packages de migration ».
Il s’agit de découper intelligemment les applications à migrer en se posant les bonnes questions. Mes bases de données sont-elles mutualisées ? Mes serveurs Web sont-ils dédiés par application ? …
Par exemple, dans le cas d’une forte adhérence entre deux applications, nous allons préférer les migrer ensemble. À l’inverse si n’y a aucune interaction entre deux applications ; nous allons plutôt les migrer séparément.
Les environnements
L’idéal dans une phase de migration est bien évidement d’identifier les environnements productifs et non productifs. Pourquoi ? La réponse est simple 😉
Il y a fort à parier que si les environnements de Qualification ou de Pré-Production ne posent pas de soucis lors de la migration, la Production n’en posera pas non plus. En effet, ces environnements sont censés être identiques (à la volumétrie près, et encore !).
À l’inverse s’il y a des soucis lors de la migration de ces environnements, le troubleshooting peut être fait sans impacter la production et pourra être reproduit sans tâtonnement lors de la migration de la Production.
Le calendrier
Nous y sommes presque, tout est quasiment réuni pour lancer les opérations de migration. Il reste à PLANIFIER !
Ce sera la phase la plus pénible à organiser en regard du nombre de personnes à mobiliser.
Il faut vraiment penser à ce que l’intégralité des personnes pertinentes soit pleinement mobilisée le jour J.
Surtout, éviter de migrer à une date donnée si l’équipe métier ne peut pas tester, ou si le support n’est pas totalement disponible.
Autre astuce, essayer de planifier les migrations des différents environnements dans une période assez courte. N’attendez pas 6 mois entre la migration de la Pré-Production et de la Production car l’expérience acquise sera vite oubliée ! De plus il y aura sans doute eu des changements sur les différentes plateformes, donc l’atterrissage « en douceur » de la Production ne pourra plus être garanti.
L’entraînement
Nous allons donc migrer notre première application dans le Cloud !
Enfin, plutôt la version non productive. Pas de panique, ici rien de méchant, il faut prendre son temps et surtout bien noter toutes les éventuelles actions correctives ou de reconfiguration des applications suite à un Replatforming (utilisation de bases de données managées par exemple).
C’est à ce moment que vous déciderez de migrer en production ou non. Il se peut, dans de très rares cas, que l’application migrée ne fonctionne pas dans son nouvel environnement Cloud.
Si tel est le cas, ce n’est pas la peine de prévoir dans l’immédiat la migration de la production. Il faudra tout d’abord comprendre ce qui a échoué et y remédier avant de retenter une migration.
Tout s’est bien passé ? Super, c’est bientôt le D-Day !
D-Day « Welcome to the Cloud » !
Si vous êtes arrivé jusqu’à cette étape sans encombre vous n’aurez aucun problème pour migrer votre PROD. Il reste qu’à appuyer sur le bouton (ou presque) !
C’est bon, l’application est maintenant dans son nouvel environnement Cloud.
Rassurez-vous l’aventure ne s’arrête pas là, il reste encore plein de choses à découvrir dans le Cloud et à mettre en place mais c’est une autre histoire 😉
En conclusion
Pour réussir votre migration garder à l’esprit ceci :
- Bien définir le choix de la migration en fonction des contraintes qui vous sont données.
- Lotir intelligemment vos packages de migration
- S’assurer d’avoir la bonne équipe !
- Dans la mesure du possible, migrer vos environnements non productifs en premier
- Et enfin, faire appel à METANEXT pour vous aider !!!!!!!
Frédéric CHAMPAGNE – Consultant Cloud