Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (1/2) ?

12 juin 2024

Auteurs

Yannick Anselme

Cloud Architect, IBM Consulting France

Thomas Moiron

Cloud Architect, IBM Consulting France

Contrairement aux applications conçues et développées spécifiquement pour un environnement cloud, un parc applicatif « on premises » a généralement été bâti au fil du temps, avec des technologies datant d’époques différentes. Il est par nature plus ou moins hétérogène. Pour différentes raisons (par exemple la scalabilité horizontale et verticale de manière automatique en fonction du besoin, la réduction des coûts, la flexibilité, l’agilité, l’ajout de sécurité, le paiement à la demande, la réduction du temps de commercialisation, la modernisation et la rapidité de déploiement), l’entreprise décide de moderniser son parc avec un programme stratégique de migrer un parc applicatif dans un cloud. Ce type de migration doit être soigneusement préparé pour être efficace.

Nous allons présenter, dans cet article, la démarche que nous avons élaborée chez IBM Consulting et mise en œuvre dans le cadre de projets de migration réalisés chez nos clients. Nous porterons une attention particulière sur les actions qui sont réalisées en amont de la phase de migration technique. A noter que cet article ne traite pas des sujets de FinOps et TOM (Target Operating Model) qui sont également essentiels dans la stratégie cloud d’une entreprise.

Dans le contexte de nos interventions, et à la vue de la maturité des équipes techniques vis-à-vis des concepts du cloud chez nos clients, la création d’un Centre de Compétence Cloud (CCC) est essentielle. Les objectifs de cette équipe sont de préparer la migration cloud et de supporter la migration des applications jusqu’à la mise en service.

Bien entendu, cette organisation repose sur un travail de collaboration entre le CCC et les équipes applicatives, les uns apportant leurs connaissances des applications existantes, les autres leurs expériences du cloud et des migrations.

Les étapes amont de cette démarche sont :

  • Une première phase de pré-assessment technique global, afin de disposer d’une roadmap de migration pour l’ensemble du patrimoine applicatif de l’entreprise ;
  • Une deuxième phase d’assessment technique par application.

Plus nous avançons dans cette démarche industrielle, plus nous entrons dans le détail, pour aboutir à un ensemble de documents suffisants pour réaliser la migration de façon maitrisée.

Phase 1 : Pré-assessment technique par patrimoine applicatif

Le pré-assessment technique consiste à analyser l’ensemble des applications du patrimoine applicatif dans le but d’avoir une vue globale de la migration cloud et d’établir une roadmap cohérente. Les acteurs de cette phase sont le responsable d’application, l’architecte patrimoine, l’architecte cloud du CCC, le leader cloud et un responsable financier.

Voici les différentes étapes

1 – Calculer les dispositions cibles par application, en basant sur un modèle de type 7R d’AWS

  • Rehost (“Lift and Shift”)
  • Relocate (“Hypervisor-Level Lift and Shift”)
  • Replatform (“Lift and Reshape”)
  • Refactor (“Re-architect”)
  • Repurchase (“Drop and Shop”)
  • Retire
  • Retain (“Revisit”)

Le calcul peut être automatisé avec un arbre de décision propre à chaque contexte avec des critères précis et validé de tous. Des exemples de critères sont la criticité métier, le cloud readiness (capacité à migrer rapidement dans le cloud), l’obsolescence, le nombre de déploiements par an, le type d’application, l’existence d’un SAAS ou d’un conteneur et bien d’autres. Certains de ces critères sont calculés par un ensemble de questions et d’analyse de code dans certain cas.

Une fois les dispositions cible calculées, une revue manuelle doit être faite afin de valider la disposition cible finale.

2 – Sélectionner les zones d’atterrissage (Landing Zone) pour les applications

On peut avoir au final un mix de cloud privé, de cloud dédié et de cloud public avec des applications déployées en mode PaaS, IaaS et SaaS. Un des critères majeurs concerne les règles de sécurité imposées par les applications et des certifications nécessaires (SecNumCloud, FS Cloud, etc…).

3 – Établir une matrice de priorité en fonction en fonction des dépendances entre applications, du degré d’obsolescence, ou du quadrant magique avec la criticité métier et le cloud readiness

Par le dernier critère, on commencera à migrer les applications ayant le plus haut cloud readiness et la plus faible criticité métier.

4 – Estimer le coût de migration des applications par T-Shirt size (Simple, Moyen, Complexe, Très Complexe)

L’estimation prend en compte les éléments techniques de l’application (par exemple le langage de développement, le type de middleware, le nombre de VM, le nombre de batch, le type de base de données, le nombre de fichier échangé, le nombre d’interfaces, la volumétrie, etc..). Il s’agit d’un modèle d’estimation global, sa validité (démontrée par les opérations que nous avons déjà menées) réside sur le fait que l’on traite un grand nombre d’applications, il peut en revanche y avoir des écarts si on prend les applications individuellement.

5 – Finaliser la roadmap de migration

Après avoir identifié des options plus ou moins agressives en prenant compte la durée, la capacité des équipes et d’autres contraintes telles que les impératifs de décommissionnement applicatifs, une roadmap est proposée. Elle est par la suite validée par l’ensemble des partis prenants, tant au niveau technique que financier, afin de pouvoir la dérouler dans de bonnes conditions.

Une fois l’ensemble des applications analysées, nous allons faire une analyse détaillée des applications qui migreront dans le cloud dans l’ordre chronologique établi par l’option de la roadmap sélectionnée.

La phase 2 et la conclusion sera traité dans un autre article « Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (2/2) ».