Pour un move to cloud ... sans casse :)

le 25/03/2024 par Imane Ryane

Tags: Cloud & Platform, Bonne Pratique, Architecture, Stratégie, Transformation

Un projet de migration vers le Cloud ne se résume pas uniquement à une évolution technologique, mais implique également des changements humains, culturels et organisationnels. Pour OCTO, une transformation Cloud s’envisage dans une approche holistique des équipes, du mindset et des pratiques, et ce au niveau de la DSI et du Métier. Une migration vers le Cloud représente un vrai momentum pour une entité, car elle oblige de se remettre en question, de se réinventer et de lancer une puissante dynamique d’amélioration ou de rationalisation.

D'abord, pourquoi le Cloud ?

Nos clients partagent souvent des défis communs qui ont motivé leur migration vers le Cloud :

Des délais significatifs pour le provisionnement des environnements ;
Des coûts élevés associés à l'achat et à la gestion du matériel informatique ;
Des exigences de sécurité ou réglementaires difficiles et coûteuses à implémenter sur un environnement on-premise ;

Ainsi, la transition vers le Cloud est désormais inévitable pour de nombreuses entreprises qui cherchent à :

Améliorer leur efficacité opérationnelle,
Innover et proposer facilement et rapidement de nouveaux services,
Renforcer leur agilité en accélérant l’adoption de nouvelles fonctionnalités,
Être plus attractive en favorisant la montée en compétences de ses collaborateurs,
Réduire leurs coûts.

Un point d’attention est à soulever ici par rapport à la réduction des coûts. Certes, c’est le premier argument brandi par les fournisseurs Cloud, mais devient vite une illusion en absence d’une stratégie Finops. On parlera bientôt Finops sur le blog Octo.

Tout est question de démarche…

Quels sont les ingrédients d’une transformation Cloud réussie ? Il n’y a pas de recette miracle, mais au fil de nos missions, nous avons consolidé un certain nombre de critères qui structurent la démarche :

Partir des enjeux métiers, techniques et culturels pour construire la migration Cloud. Il peut s’agir par exemple de roadmap agressive ou de pressions pour réduire le TTM.
Identifier les problématiques auxquelles on souhaite répondre et les leviers à activer pour le faire, en tenant compte de leur priorité : la capacité, la scalabilité, la résilience, la fiabilité, le coût de l’exploitation IT…,
Penser les applications “ Cloud Native”,
Planifier une communication et une conduite du changement adaptées,
Construire des équipes pluridisciplinaires tech et métier.

La démarche OCTO s’articule ainsi autour de 5 piliers :

Définir la stratégie : La première étape cruciale consiste à définir une stratégie claire pour la migration vers le Cloud. Cela implique de comprendre les enjeux du Cloud, d'identifier les foyers de valeurs pour l'entreprise et d'établir des objectifs clairs et mesurables.
Étudier le périmètre : Une analyse approfondie du périmètre de la migration est essentielle pour identifier les aspects techniques, commerciaux, organisationnels, de sécurité, de conformité réglementaire et de gouvernance à prendre en compte.
Mapper l’architecture cible et la gouvernance : Il est crucial de définir la topologie cible de l'infrastructure Cloud ainsi que les mécanismes de gouvernance qui garantiront une utilisation efficace et sécurisée des ressources Cloud.
Préparation de la landing zone* & premier business case : La création d'une landing zone bien préparée et la définition d'un premier business case solide sont des étapes initiales essentielles pour assurer le succès de la migration.
Migration et mesure : Une fois la migration lancée, il est important de mettre en place des mécanismes de mesure pour évaluer les performances et l'impact de la migration et s’en servir régulièrement pour s'adapter et optimiser le processus.
Passer à l’échelle : Une fois que les premières migrations répondent au besoin, il est temps de passer à l'échelle en itérant sur de nouveaux business cases, tout en tirant parti de l'expérience et des apprentissages acquis. En effet, avec le premier business case, nous avons appris, et avons désormais une mine d'informations à partager pour éviter de reproduire les mêmes erreurs. Cela implique d'adapter et d'optimiser les processus de migration en fonction des leçons apprises, afin de garantir une expansion efficace et réussie.

* Une "landing zone" est un environnement cloud initial sécurisé et bien structuré pour accueillir des charges de travail.

Une symphonie à cinq temps !

Concrètement, un passage sur le Cloud se déroule en 5 étapes : initiation, préparation, migration, validation et décommissionnement.

Dans la phase d'initiation, il s’agit de découvrir, évaluer et planifier. La découverte consiste à créer un inventaire des applications et des serveurs ainsi qu’un mapping entre les applications et les infrastructures sous-jacentes. Le but de l'évaluation est d’analyser chaque application afin de décider du :

Modèle de service (IaaS/PaaS/SaaS) et de l'hébergement (public/privé) ;
Chemin de migration selon les 6 R : Renegociate / Rehost / Replatform / Refactor / Remain / Retire ;
Famille de migration : il s’agit d’un groupement haut niveau des applications étroitement liées. Ce groupement se fait selon 6 critères : confidentialité des données manipulées, utilisation de données soumises à des réglementations, nature du couplage : fort ou faible, nombre d’interfaces en jeu, contraintes de latence et enfin, dépendance à des composants communs.

Ci-après un exemple de livrable, produit à l’issue de cette étape, pour l’un de nos clients, où on a défini les familles d’application ainsi que les chemins de migration :

Par application de référence, on désigne l’application la plus importante/stratégique de la famille.

Enfin, la planification de la migration va principalement aboutir à un plan de migration. Là, on va parler de migration par vagues, dans le sens où on planifie la migration de groupement d’applications et non les applications de façon unitaire. C’est une phase aussi où il faut estimer le chiffrage et le budget, ainsi que déterminer l’ensemble des prérequis à la migration.

Maintenant qu’on a une idée plus précise de l’existant ainsi que de la cible, les phases de préparation et de migration vont permettre entre autres de :

Provisionner la plateforme cible,
Migrer les applications selon le chemin de migration arrêté dans la phase d’initiation. On commence par l’environnement de développement, puis la préprod et enfin la production.
Tester.

Après la phase de validation, où on a vérifié que tout fonctionne parfaitement sur le nouvel environnement Cloud, commence le décommissionnement ou la phase de garantie, où on va supprimer toutes les ressources non nécessaires tournant sur l’ancien environnement.

Les 6 R, quesako ?

Nous avons dit précédemment, que la migration d’une application se fait selon les 6 R : Renegociate, Rehost, Replatform, Refactor, Remain et Retire. Dans le tableau suivant, nous expliquons à quoi correspond chacune de ces actions ainsi que leurs cas d’usage les plus adaptés :

	Description	Exemple	Effort/bénéfice
RENEGOCIATE	Remplacement de la solution existante (hébergée on-premise) par une autre solution du même éditeur en mode SaaS. Ce type de transformation permet de faire évoluer l’application sur des environnements Cloud managés et de bénéficier d’un meilleur temps de mise sur le marché des évolutions éditeur et de ne pas avoir à gérer l’infrastructure sous-jacente.	Une application sous forme de progiciel exploitée on-premise est remplacée par son équivalent en mode SaaS, proposé par l’éditeur de ce progiciel (exemple SAP, Jira, Sharepoint, etc.)	Temps + Coût +++ Agilité* ++++
REHOST	Migration de l’application existante sur un hébergement Cloud en reproduisant son architecture d’infrastructure et de services. Le système d’exploitation, les composants intermédiaires et applicatifs sont conservés. Le comportement de l’application n’est pas modifié. Les actions d’adaptation à réaliser sont minimes.	L’image d’une machine virtuelle s’exécutant dans un environnement VMware on-premise est transférée dans une instance IaaS du fournisseur de Cloud (ex. instance EC2 chez AWS). Les caractéristiques de la machine virtuelle restent similaires.	Temps ++ Coût ++ Agilité* +
REPLATFORM	Migration de l’application en conservant son architecture fonctionnelle tout en opérant des modifications de complexité faible sur des composants applicatifs éligibles afin de bénéficier de fonctionnalités managées offertes par l’infrastructure Cloud.	Une application s’exécutant sur des machines virtuelles on-premise est redéployée sous forme de containers dans l’infrastructure Cloud. La base de données est migrée dans son équivalent en service managé.	Temps +++ Coût +++ Agilité* +++
REFACTOR	Transformation qui va amener une restructuration de l’application afin qu’elle puisse s’adapter et bénéficier pleinement du nouvel environnement. Cela peut nécessiter la modification d’une grande partie du code ou le remplacement du logiciel existant pour être en mesure de profiter des fonctionnalités natives du Cloud.	Une application monolithique est découpée en un groupe de microservices et de fonctions Serverless qui fonctionnent ensemble et sont facilement mis à l’échelle. La base de données est ré-architecturée pour utiliser une solution complètement managée.	Temps ++++ Coût ++++ Agilité* ++++
REMAIN	L’application n’est pas transformée, elle est conservée en l’état. Certains facteurs sont incompatibles avec un positionnement dans le Cloud ou bien le bénéfice de transformation est jugé insuffisant par rapport aux coûts et aux efforts de migration.	L’application nécessite un composant hardware spécifique ou elle a des exigences fortes de latence pour des échanges de données avec d’autres composants du SI.	NA
RETIRE	L’étude d’éligibilité Cloud a fait ressortir que l’application n’est plus nécessaire ou fait doublon. Le choix du décommissionnement est décidé.	L’application compte peu d’utilisateurs et elle a des coûts de licences élevés. Une application plus moderne et offrant les mêmes fonctionnalités est déjà utilisée dans le SI et est en mesure d’accueillir ces utilisateurs.	NA

*Le gain en agilité concerne le temps de mise sur le marché de nouvelles fonctionnalités, l’exploitation et le maintien en condition opérationnelle de l'application, ainsi que le modèle de facturation et de licensing à l’usage.

Avant de se quitter…

Dans cet article, nous avons présenté un aperçu des pratiques éprouvées par les OCTOs pour une migration vers le Cloud. C’est un virage conséquent qui, une fois réussi, sera un levier de croissance à plusieurs niveaux pour l’entreprise. Personnellement, j’ai vécu l’époque où il fallait attendre des jours pour un téraoctet de stockage en plus, et où l’arrivée d’un nouveau serveur en salle machine est vécue comme un accouchement avec son lot de stress et de préparation. Je me suis même blessée dans une salle machine parce qu’une dalle manquait au sol :) Depuis que j’ai découvert le Cloud et la liberté qu’il offre, je trouve qu’ il serait dommage de ne pas en profiter dans des contextes qui s’y prêtent. Comme vous avez pu le voir avec notre démarche, une migration vers le Cloud touche des aspects structurels importants de votre SI, mais aussi de votre travail avec le métier, votre organisation et culture. Se faire accompagner d’experts qui ont déjà traversé ces chantiers ambitieux augmentera vos chances de réussite ! Nous donnerons bientôt la parole à nos OCTOs pour venir raconter leur REX de mission et les enseignements tirés, stay tuned ;)

Envie d’aller plus loin ?