Comme bon nombre de mes contacts Linkedin, que je salue au passage, j’interviens auprès de clients autour de différentes thématiques, notamment celle du Cloud Computing.
Parmi les nombreuses problématiques, les Entreprises/DSI qui font le choix de s’orienter vers le Cloud Public, rencontrent régulièrement des difficultés à définir les enjeux, les méthodologies, les séquencements pour parvenir à migrer en minimisant un maximum les impacts qui en découlent.
Aujourd’hui, mon post porte sur la migration dans le Cloud aussi connue sous les termes plus accrocheurs : Transformation Digitale, Journey to the Cloud … Je vais tenter d’apporter de l’eau à votre moulin pour vous préparer au mieux, tout en évitant/contournant les pièges que vous pourriez rencontrer.
Nous n’aborderons pas ici le choix d’un fournisseur de services par rapport à un autre, leurs avantages et inconvénients, ainsi que le socle technique qui hébergera les futures VMs/services (Fera l’objet un post dédié). Je considère que ces études ont déjà été réalisés. Néanmoins, si votre choix n’est pas acté, vous trouverez ci-contre, un lien très utile, vous permettant de comparer leurs services : http://comparecloud.in/ ainsi qu’un très bon article de Johnny Da Silva Quel modèle de Cloud Computing pour réussir la transformation de son DC ?
Avant d’aller plus loin, essayons d’identifier les raisons qui poussent les entreprises vers le Cloud. Peut être trouverez-vous ce qui vous a poussé, ce qui vous pousse ou ce qui vous poussera dans les prochains mois :
Les Mauvaises Raisons :
- Le PDG de votre entreprise/groupe l’exige
- Tout le monde y va, pourquoi pas moi.
Les Bonnes Raisons :
- Des dépenses flexibles, paiement à l’usage
- Réduction de votre emprunte sur l’environnement
- Fermeture/Mutualisation d’un DC
De Meilleures Raisons :
- Améliorer la scalabilité
- Améliorer la sécurité
- Rapprocher les données/charges de travail des partenaires/clients
- Simplifier les opérations d’exploitation
Les Meilleures Raisons :
- Augmenter l’agilité et la flexibilité de votre business
- Moderniser votre stratégie Applicative
- Étendre son activité à l’étranger/l’international
- Pour être le Maître du monde (Personne ne peut vous empêcher d’y croire :))
Un projet aussi important qu’une migration, doit être un élément fédérateur. Chaque intervenant doit être impliqué dès le début, afin qu’il puisse comprendre les enjeux, mais aussi et surtout, se projeter dans l’évolution de son métier, qui est inéluctable, et il doit s’y être préparé.
Pour ce type de projet d’envergure, nous planifions des sessions de présentations aux équipes du client, des fournisseurs de services, la méthodologie qui sera utilisée, les éléments qui seront attendus, et c’est souvent à ce moment, que certaines questions apparaissent :
- Que ferais-je demain si l’ensemble de mon activité : administration systèmes, réseaux, Infrastructure, … est déportée dans le Cloud ?
Ton métier va évoluer, l’administration existera toujours, tu n’auras plus à gérer l’infrastructure, en revanche tu auras la possibilité de monter en compétences sur d’autres briques, comme des services managés, qui ont une plus grande valeur ajoutée, que remplacer un FAN ou un bloc d’alimentation.
- Pourquoi fait-on le choix d’aller dans le Cloud, alors que nous avons les équipes et les équipements localement ?
Retour au point ci-dessus : Quelle est la raison qui oriente mon entreprise vers le Cloud ?
- Avez-vous des retours d’expérience sur des entreprises qui ont fait ce choix ?
Évidemment, et certaines entreprises n’ont pas toujours fait des choix forcément judicieux, ce qui peut provoquer des réactions épidermiques face au Cloud (Non suivi des coûts, pas de mise en place de sécurité, aucun garde fou, …).
On ne s’improvise pas du jour au lendemain Expert Cloud. « Y en a qui ont essayés, ils ont eus des problèmes ».
Mais la plupart du temps les entreprises sont assez positives sur les REX.
- Moi je suis très bien comme cela !
Quelque soit le domaine d’activité, on sera toujours confronté à des personnes réfractaires aux changements. L’idée est d’accompagner les collaborateurs au mieux dans cette évolution, ou alors, trouver un projet qui corresponde d’avantage à leurs attentes, que cela soit en interne ou en externe.
- Le Cloud ça marchera jamais, on en reviendra dans quelques années !
On dit souvent que l’IT fonctionne en cycle. Peut être qu’on en reviendra, mais un cycle peut durer 1 jour, 6 mois ou 20 ans … donc attention à bien l’estimer pour ne pas être très/trop vite dépassé par ses concurrents et devoir prendre des décisions lourdes de conséquences sur le personnel ou pour la survie de l’entreprise.
Cela arrive régulièrement, non pas de ne pas avoir fait de choix technologies forts, mais surtout de ne pas avoir anticiper les besoins, les enjeux de ses clients : changements de mentalité, rapidité, simplicité, besoins éphémères, prix attractifs …
L’entreprise, doit faire son possible pour que la migration remporte, en interne, le plus de suffrage possible, mais elle a aussi le devoir d’accompagner les plus frileux à l’idée du changement.
Dès lors, il devient nécessaire d’avoir une structure suffisamment robuste pour aborder un tel changement ou à défaut, se faire accompagner par un partenaire dont c’est le métier.
Une migration réussie, passe par une bonne préparation des équipes, qui s’articulent autour de plusieurs axes essentiels. Pour moi, il y en a 4 qui ne peuvent être occultés sous peine d’avoir un projet qui dure dans le temps et qui ne rencontre pas le succès tant recherché : La Gouvernance Cloud, la Découverte du patrimoine applicatif, la Migration en tant que telle et enfin l’Optimisation et toutes ces étapes sont liées entre elle par un peu, beaucoup, à la folie d’amélioration continue.
La Gouvernance Cloud :
Établir une Gouvernance Cloud permet d’établir les premières bases solides du succès de votre migration. Pilotée par une Team Cloud, celle-ci doit être composée d’une équipe pluridisciplinaire : Réseaux, Systèmes, Intégrateur, Exploitation, Finance, …. Elle aura pour but d’anticiper, de lever les bonnes questions, d’établir les jalons, de définir les règles d’utilisation du Cloud mais aussi de définir les procédures à suivre.
Ci-dessous quelques liens pour approfondir vos connaissances sur le sujet :
- https://www.gartner.com/webinar/3306919/player?commId=204745&channelId=5500&srcId=null&webinarType=UpcomingEvent
- https://www.gartner.com/webinar/3410418/player?commId=219883&channelId=5500&srcId=1-4730952011&webinarType=ondemand
La constitution de votre Gouvernance Cloud, est une occasion supplémentaire, pour vous faire accompagner par un partenaire, de profiter de son expertise et surtout des différents retours d’expériences de ses propres clients, afin d’adopter rapidement les bonnes pratiques.
Votre Gouvernance Cloud clairement définie, transmise à l’ensemble des intervenants du projet, doit être diffusée en interne afin que les métiers soient sensibilisés et adoptent rapidement le réflexe de s’orienter vers le bon interlocuteur en matière de questions/besoins sur le Cloud.
Gardez en têtes que les métiers ont déjà probablement adopté le Cloud, ce qui peut générer des problématiques en terme de sécurité ou de confidentialité des données, et vous devez leur démontrer rapidement que cette Team est incontournable pour tous les sujets orientés Cloud.
Par la suite, les premiers services/applications migrés avec succès seront votre plus belle vitrine en interne et apporteront forcément du crédit et de nouveaux défis à relever.
Une fois la Gouvernance définie, ne reste plus qu’à lui ajouter un zeste d’amélioration continue, et vous pouvez sereinement passer à la prochaine phase.
La Découverte / L’Assessment :
La phase de découverte est cruciale et incontournable.
Celle-ci conditionnera les prochaines étapes de votre migration et devra donc être réalisée avec le plus grand soin. Elle va permettre :
- D’identifier l’ensemble de votre patrimoine applicatif, au travers de solutions d’inventaires/d’audits. Voici quelques outils qui peuvent vous aider dans votre démarche : Cloudamize, Turbonomic, Cast Highlight, Azure Migrate, …
- De vérifier l’éligibilité de vos machines existantes (Physiques ou virtuelles) à une migration dans le Cloud (OS supporté, type de répartiteur de charge, base données, …), mais aussi la cible souhaitée : de la machine virtuelle (IaaS), du service managé (PaaS), ou une solution clé en main (SaaS)
- D’identifier les flux de communication entrants/sortants pour établir les futures matrices de flux dans le Cloud. A la fois les communications entre les serveurs dans le Cloud, mais aussi avec les machines On-Premise pour celles qui ne sont pas éligibles.
- De rencontrer les différentes équipes techniques et responsables d’applications pour en apprendre d’avantage sur les services/applications, et, qui ne sont pas documentées (criticité, cycle de vie, cycle de déploiement, populations utilisatrices, accès public/privé, …)
L’ensemble des informations récoltées, vont permettre de définir un planning de migration qui s’appuient sur différents critères :
- Complexité du service/application
Une application composée d’un seul serveur qui héberge le front, l’applicatif, et la BDD, ne nécessite pas autant d’efforts, qu’une application redondée, multi-tiers, hébergée sur plusieurs serveurs, avec des synchronisations entre les différentes BDD.
- Criticité du service/application
Un service/application utilisé par la DSI pour l’inventaire du parc, n’a pas la même criticité qu’une application e-commerce qui génère du CA.
- Disponibilité des équipes métiers pour effectuer les phases de recettes fonctionnelles
Ce sont les équipes qui connaissent le mieux leurs services/applications, c’est donc naturellement à eux d’effectuer les phases de recettes, avec le support des équipes techniques si nécessaire.
- Priorisation des migrations
Si des évolutions sont prévues sur un service/application, ou une mise en production planifiée, il ne faut pas que la migration intervienne à ce moment précis et ainsi prendre ce type d’informations en considération.
- Des périodes de gel de mises en production
La présence de période de gel en entreprise (Fin d’année, avant les congés ou fin de mois pour la comptabilité), doit également être gérée dans le planning de migration.
- Souhaits d’évolutions du service/application
Aujourd’hui l’application utilise une BDD locale gérée en interne mais suite à une évolution de l’application, le client envisage l’utilisation d’un service managé, pour se concentrer sur le développement de son application. On peut donc profiter de la migration pour effectuer cette transformation
- …
Comme mentionné précédemment, cette étape est essentielle pour la suite car en fonction des éléments récoltés, vous allez définir le planning à dérouler, mais surtout identifier la cible du service/application : IaaS, PaaS et SaaS.
La Migration :
Une fois l’étape précédente finalisée, vient la phase de migration.
Comme nous aurons identifié la cible (IaaS, PaaS et SaaS) et surtout les efforts à réaliser pour y parvenir, nous savons exactement comment vont se dérouler les migrations ainsi que leurs cadences.
Prenons quelques minutes pour rappeler les différents « chemins » de migration vers le Cloud :
- Re-host (Lift and Shift) :
Le service/application est migré en l’état chez le fournisseur, cela peut être du V2V ou P2V. Cela permet d’aller vite. On peut envisager l’utilisation de services managés du fournisseur dans un second temps une fois le service/application migré (hors projet de migration).
Ex : Une VM hébergée sur un hyperviseur VMware/HyperV/Xen est basculée à l’identique chez le fournisseur.
- Re-platform :
Le service/application est migré en apportant quelques évolutions.
Ex : Upgrade d’un OS RHEL 6 vers RHEL 7
- Re-factor
Le service/application est migré en apportant des modifications majeures
Ex : Changement d’OS (AIX vers Linux), changement de moteur de base de données (Oracle vers SQL)
- Re-purchase
Le service/application est abandonné au profit d’une nouvelle solution
Ex : Abandon de son client de messagerie local, ou de son ancien ERP, pour une solution SaaS.
- Retain :
Le service/application n’est pas migré et gardé en l’état.
Ex : Le service/application est hébergé sur un OS non supporté chez le fournisseur (AS400), ou alors un service critique qui doit être au plus près des utilisateurs (Accès aux locaux, caisse du restaurant d’entreprise, …) ou alors avec un coût financier trop important.
- Retire :
Le service/application est décommissionné, car plus utilisé ou remplacé par une autre service/application.
Ces différents « chemins » sont régulièrement présentés via le schéma ci-dessous qu’on pourrait apparenter à une carte du métro :
La vigilance est évidemment de mise, car selon le « chemin » emprunté, le temps de migration diffère.
Si on peut facilement automatiser une migration en mode Re-host, à l’inverse une migration en mode Re-factor sera manuelle et sera plus énergivore en terme de temps, en terme d’équipes impactées, et évidement d’un point de vue purement financier.
Quelque soit votre décision, toutes ces étapes doivent, impérativement, être accompagnées de phases de recettes techniques et fonctionnelles !
Le but n’est pas de migrer pour migrer mais d’obtenir un service/application fonctionnel, avec à minima un niveau de service équivalent à celui déjà en place. (On-Prem ou Cloud si vous changez de fournisseur Cloud).
On ne peut pas parler migration sans évoquer quelques outils à utiliser :
Solutions de migrations :
- AWS Server Migration Service : https://aws.amazon.com/fr/server-migration-service/
- Azure Site Recovery : https://docs.microsoft.com/fr-fr/azure/site-recovery/migrate-tutorial-on-premises-azure
- Cloudendure : https://www.cloudendure.com/
- Zerto : https://www.zerto.com
- …
Solutions de déploiements Infrastructure As Code (IaC) :
- AWS Cloudformation : https://aws.amazon.com/fr/cloudformation/
- Azure ARM Template : https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-quickstart-create-templates-use-the-portal
- Terraform : https://www.terraform.io/
- …
Solutions de gestionnaires de configurations :
- Ansible : https://www.ansible.com/
- Chef : https://www.chef.io/chef/
- Puppet : https://puppet.com/fr
- …
En combinant certains de ces outils, vous pourrez faire du DevOps, (Cool), et ainsi être en mesure de créer votre propre usine de migration, à votre image et selon vos besoins, qui vous permettra d’une part d’automatiser/industrialiser une partie de la migration, mais aussi de maintenir les ressources migrées.
/!\ : N’oubliez pas, au cours de cette étape, de remettre en place/adapter vos outils existants pour continuer à veiller au bon fonctionnement de vos serveurs/services, voire d’utiliser les outils/services natifs de votre fournisseur pour les opérations de Supervision, Gestion des logs, Sauvegarde et Restauration, Alertes …
L’Optimisation :
Une fois votre patrimoine applicatif et vos charges de travail basculés dans le Cloud, il est temps de pousser un ouf de soulagement car nous y sommes arrivés, mais le travail d’amélioration continue ne fait que continuer.
De nouvelles tâches apparaissent (n’oubliez pas, les métiers évoluent), qui seront assurées par le Cloud Manager, les équipes d’exploitation, les équipes réseaux et sécurité, …
A défaut, vous pourriez-être confrontés aux effets négatifs du Cloud : explosion de votre facture, niveau de sécurité pour vous et vos clients qui s’érode avec le temps, performances qui s’étiolent, non utilisation des services récents, …
Bref, voici une liste, non exhaustive que vous pouvez adapter/compléter selon votre contexte, des actions qui doivent être continuellement taguées In Progress dans votre To Do list :
- Suivi de la facturation de votre consommation Cloud :
Il est toujours désagréable de payer plus que ce ce qu »on avait prévu, alors pour éviter les dérives, une attention toute particulière doit être portée à ce sujet.
De nombreux fournisseurs proposent des offres qui vous permettent naturellement de faire des économies, si vous faites du BYOL (OS, BDD, …). Autre possibilité, l’utilisation des Instances Réservées, en général, vous vous engagez pour une durée de 1 à 3 ans pour bénéficier de réduction entre 20% et 50% (A utiliser uniquement sur des services/applications avec une certaine longévité)
Les économies, pourraient être réinvesties ou non dans le Cloud pour utiliser d’autres services ou améliorer ceux déjà en place.
- Audit de sécurité :
Le fait de définir une politique de sécurité à un moment donné n’est pas gage que celle-ci reste inviolable et impénétrable.
Planifiez régulièrement des audits de sécurité / tests de pénétrations et surtout, apportez les actions correctives avant que les failles puissent être exploitées par des pirates sanguinaires assoiffés par l’appât du gain facile ! (Jack Sparrow ?)
- Suivi des performances de vos services/applications :
Tout comme vos serveurs On-Premise, il faut suivre les performances des services/applications que vous avez migré.
Identifiez les goulots d’étranglements au travers des services mis à disposition par votre fournisseur, analysez les logs systèmes et applicatifs.
Si nécessaire, rappelez vous, que vous pouvez à tout moment augmenter/diminuer les ressources (CPU, Mémoire, Disques) associées à vos services mais aussi que cela joue directement sur le prix.
N’hésitez pas non plus à mettre en place du scheduling sur les VMs hors production, un sou est un sou.
Ex : Si vous avez trop dimensionnez une VM et que celle-ci est sous utilisée, diminuez les ressources CPU/Mémoire et celle-ci vous coutera moins chère à la fin du mois.
- Veille technologique :
Vous le faites déjà, ou sinon vous devriez le faire mais, il faut dorénavant assurer une veille technologique sur le fournisseur sélectionné, et pourquoi pas les autres ?!
Des centaines de nouveaux services et de mises à jours sont effectuées chaque année, il serait donc intéressant d’être informé, de les tester et pourquoi pas les adopter. Voici quelques liens officiels que j’utilise pour les 3 principaux fournisseurs, à vous de les compléter :
AWS :
Azure :
GCP :
…
Rappelez-vous, l’amélioration continue, est un travail de tous les jours, prévoir cette charge de travail supplémentaire est la meilleure préparation aux besoins qui apparaitront par la suite, et vous apportera une réactivité supplémentaire pour les demandes de vos clients internes/externes.
Elle permet également de garder vos sens en éveil et de comparer/tester/valider ou non, les différentes offres présentes sur le marché.
/!\ : Ce n’est pas parce qu’un service/application que vous avez testé il y a quelques semaines/mois et qui n’a pas été satisfaisant, qu’il faut tirer un trait définitif. Le Cloud progresse très vite et les services, comme les prix, évoluent continuellement :
Merci à la concurrence acharnée que se livrent les différents fournisseurs, car au final c’est le client qui en bénéficie, donc nous !
J’espère que ces quelques lignes vous permettront d’avoir un fil conducteur pour mener une migration, mais il est évident que d’autres points s’ajouteront en fonction de votre domaine d’activité (Santé, Bancaire, …).
Et bien sur, chaque migration est différente d’une autre, vous allez rencontrer des problématiques mais c’est aussi ce qui fait l’intérêt d’une migration, sinon on s’ennuierait.
Gardez en tête que le meilleur moyen d’éviter les pièges sont, la préparation, l’anticipation et pour ceux qui le souhaitent l’accompagnement par un partenaire dont c’est le métier.
