Cloud

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

Share this post:

Dans notre article « Comment bien préparer la migration d’un parc applicatif dans le cloud avec IBM Consulting (1/2) ? », nous avons présenté les différentes étapes du pré-assessment technique qui consiste à analyser l’ensemble des applications du patrimoine applicatif. Dans cette seconde partie, nous allons détailler l’assessment technique à réaliser pour chacune des applications.

 

Phase 2 : Assessment technique par application

Ainsi, pour chaque application, l’objectif de l’assessment technique est de préparer les opérations de migration dans le Cloud. Les acteurs de cette phase sont le responsable d’application, l’architecte de l’application, l’architecte cloud du CCC, le développeur leader de l’application, le développeur leader qui fera la migration cloud, le chef de projet, le responsable de l’équipe de test, un architecte sécurité et l’équipe DevOps.

Voici les différentes étapes :

1 – Connaître l’application et confirmer les hypothèses prises lors du pré-assessment technique. Pour cela, il convient de commencer par une compréhension des fonctionnalités à travers ses es cas d’usage de l’application, et via une démonstration de l’application par son responsable Ensuite, nous allons regarder son architecture existante avec l’architecte de l’application.

2 – Construire l’architecture cible en regardant la disposition cible, la liste des frameworks et middlewares utilisés, la liste des flux (interne et externe), la gestion des fichiers, la base de données cible et l’ordonnanceur cible pour gérer les batchs. Cette permet devra notamment répondre à un certain nombre de questions.

  • Est-ce possible de conteneuriser l’application ?
  • Dans le cas d’une application basé sur un serveur d’application, faut-il le conserver ou migrer vers de l’open source ou une technologie cible de l’entreprise ?
  • Est-il possible d’effacer la dette technique sans réécrire l’application ?
  • Dans le cas d’une application gérant des fichiers, comment migrer vers un service de stockage cloud ?
  • Dans le cas d’une application avec une base de données propriétaire, faut-il la conserver ou migrer vers une base de données open source ?
  • Dans le cas d’une application avec batch, doit-on migrer l’ordonnanceur vers le cloud ou le remplacer par un mécanisme natif du cloud ?

3 – Etudier les remédiations sécurité qu’il faut mettre en place (par exemple un coffre-fort gérant la PKI, les mots de passes statique ou dynamique, la sécurisation des échanges avec du chiffrement et de la signature, ou la mise en place de protocoles sécurisés entre applications), le nombre d’environnement et de couloirs de tests nécessaires, la validation de la performance de l’application migrée et l’organisation des tests de pénétrations dans la nouvelle landing zone avant la mise en service.

4 – Préparer la toolchain DevOps. Cette activité est primordiale pour accélérer le processus de livraison Elle doit prend en compte l’ensemble du cycle de l’application : comment automatiser le provisionning des environnements (par exemple avec Terraform) ; les pipelines CI/CD (par exemple avec Jenkins) à mettre en place avec ses différentes étapes de validation concernant l’écriture du code (par exemple avec Sonar) ; et  la sécurité applicative (par exemple avec Nexus IQ, Fortify, Sysdig Secure). En fonction de la maturité de l’équipe responsable de l’application, cette étape peut prendre plus ou moins d’importance. Un framework pour les pipelines CI/CD est un accélérateur en cas de modification des étapes de façon centralisée.

5 – Préparer l’exécution des tests unitaires, des tests d’intégration, des tests de recette (en privilégiant la solution d’automatisation de ces tests, par exemple avec Sélenium) et des tests de résilience avec une mise à jour de la stratégie de tests.  Les rapports de tests existants devront être demandés avant la migration afin de s’assurer que la migration ne génère pas de régression. Les tests de recettes permettront de valider la fin de la migration.

6 – Préparer l’exploitation de l’application dans la nouvelle landing zone. Il s’agit d’étudier la manière d’intégrer les outils d’observabilité (dont la consultation des logs de manière centralisé), de gestion des alertes et de performance en temps réel mise à disposition par le cloud provider.

7 – Préparer le décommissionnement de l’application sur le legacy une fois l’application migrée. Cette étape doit être réalisée le plus rapidement après la migration afin de ne pas supporter des coûts inutiles. Il s’agit d’identifier l’ensemble des opérations à effectuer pour que le décommissionnement de l’existant soit effectif.

8 – Affiner le modèle de coût de migration d’application par T-Shirt size en fonction ce qui a été consommé.

Un assessment technique devra produire 3 livrables au minimum :

  • Le document d’architecture cible qui permettra aux équipes en charge de la migration d’implémenter la nouvelle architecture applicative
  • La matrice des flux cibles qui permettra de faire les ouvertures de flux lors de la phase de migration
  • Le workflow de provisionning qui permettra de bâtir les différents environnements de façons automatisé lors de la phase de migration

Le résultat de ces travaux sont présentés et partagés dans un meeting de clôture de l’assessment technique avec l’ensemble des partis prenants, qui marque la séparation entre la préparation (par le CCC et le patrimoine) et la réalisation de la migration.

 

Conclusion

Une fois la première phase réalisée au global et la deuxième phase réalisée pour une application, on peut commencer la migration proprement-dite. Dans le cadre des projets de migration chez nos clients, le but étant souvent de migrer un maximum d’applications dans un laps de temps donné, nous recourons à une usine de migration qui a la charge d’apporter aux applications les modifications de code nécessaires à la prise en compte de la nouvelle architecture et des contraintes applicatives liées à un déploiement dans le cloud. Le temps de montée en compétences de l’usine sur les applications existantes est amorti par le nombre d’applications à traiter.

L’expérience que nous avons derrière nous montre la réelle valeur ajoutée de la démarche que nous avons mis en place.

Pour finir, cette démarche est agnostique de la technologie cloud utilisée. Elle est applicable pour toutes les entreprises qui souhaitent industrialiser leur migration du patrimoine applicatif dans le Cloud.

 

Si le sujet vous intéresse, n’hésitez pas à nous contacter pour un retour d’expérience détaillé et envisager une migration de vos applications.

Cloud Architect, IBM Consulting France

Thomas Moiron

Cloud Architect, IBM Consulting France

More Cloud stories
3 juillet 2024

Intégration par design : la clé de la réussite de la transformation cloud

La transformation cloud est un processus complexe qui nécessite une planification méticuleuse et une exécution soignée pour réussir. Alors que les organisations se lancent dans la transformation du cloud, elles se concentrent souvent sur la migration des applications et des données vers le cloud, négligeant un aspect critique : l’intégration. L’un des défis majeurs que […]

Continue reading

14 juin 2024

Gestion de l’obsolescence logicielle : véritable enjeu pour la DSI et le business

Dans le paysage numérique actuel, les applications logicielles sont le pilier des entreprises modernes. Cependant, avec l’évolution rapide de la technologie, l’obsolescence logicielle est devenue un défi majeur pour les organisations. Les logiciels obsolètes peuvent entraîner des vulnérabilités de sécurité, des crashes système et une productivité réduite, affectant ainsi la performance commerciale et la compétitivité. […]

Continue reading

12 juin 2024

Simplifier les déclarations liées à la CSRD grâce aux nouvelles fonctionnalités d’IBM®Envizi™

IBM a le plaisir d’annoncer la prise en compte de la directive européenne (CSRD) dans le module « sustainability reporting manager » d’IBM® Envizi™. Cette considération aidera les entreprises à répondre aux exigences de reporting de la directive européenne (CSRD). La CSRD impose aux entreprises de fournir des informations et des indicateurs définis via les […]

Continue reading