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.
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.
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.
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 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.
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.