Mitsubishi Motors North America migre 170 workloads Java vers WebSphere Liberty dans le cloud hybride d’IBM; 90 apps peu modifiées
Comment Mitsubishi Motors a mappé 170 applications Java pour une migration à faible interruption vers IBM WebSphere Liberty
IBM Application Modernization Accelerator a analysé 170 applications de production en quelques heures, offrant ainsi à Mitsubishi Motors North America une transition progressive vers WebSphere Liberty tout en protégeant les systèmes utilisés quotidiennement par les concessionnaires, les employés et les clients. Certaines applications de production de Mitsubishi Motors North America avaient fonctionné pendant six ans sans être recompilées. Cette stabilité était précieuse, mais elle masquait aussi un fossé grandissant entre le comportement dépendant des applications et une infrastructure vieillissante. Le domaine a exécuté 170 workloads en production, dont 110 applications métier et 60 services web, sur Java™ 8, Windows Server 2016 et IBM WebSphere Application Server Network Deployment. Une modification de l’environnement d’exécution partagé pourrait affecter les opérations des concessionnaires, les workflows des employés et les services en contact avec les clients aux États-Unis, au Canada, à Porto Rico et au Mexique. Basé à Nashville, dans le Tennessee, Mitsubishi Motors North America (MMNA) gère les applications et l’infrastructure régionales du constructeur automobile japonais Mitsubishi Motors Corporation. Ses services web reçoivent également des appels provenant de systèmes situés en Europe et en Asie. L’architecture se connecte aux systèmes IBM MQ, IBM Db2, IBM mainframe et IBM AS
400 ainsi qu’à IBM Operational Decision Manager, de sorte que la modernisation ne pouvait pas traiter les applications Java comme une couche isolée. Ces dépendances ont dû continuer à fonctionner pendant la migration. L’infrastructure nord-américaine de MMNA fonctionne entièrement dans le cloud hybride d’IBM, tandis que Mitsubishi Motors Corporation continue d’exploiter des mainframes sur site au Japon. La contrainte principale n’était pas simplement l’ancien code. Une équipe de développement à bande passante limitée devait déterminer quelles applications pouvaient être déplacées telles qu’elles étaient écrites, celles qui nécessitaient des modifications ciblées et comment séquencer le travail sans aucune réécriture perturbatrice. IBM Application Modernization Accelerator (AMA) 4.3.0 a analysé l’ensemble du portefeuille en quelques heures plutôt qu’en plusieurs mois, ce qu’un examen manuel aurait pu nécessiter. Les résultats ont montré qu’environ 90 des 110 applications métier nécessitaient peu ou pas de modifications de code pour IBM WebSphere Liberty. Dans cet article, nous verrons comment l’évaluation au niveau du portefeuille a fait d’une migration incertaine un plan progressif. Nous découvrirons également comment l’architecture cible préserve les intégrations d’entreprise et comment cette approche contrôle le risque et le coût total de possession (TCO). L’objectif immédiat était de traiter les risques liés à la sécurité et à la prise en charge sans modifier les applications dans le seul but d’apporter des modifications. WebSphere Network Deployment 9.0.5.22 fournissait un environnement d’exécution provisoire compatible, mais l’environnement Java 8 a limité l’adoption de nouvelles approches de développement, telles que Spring Boot. Liberty a proposé une transition vers Java 17, Jakarta EE et les versions plus récentes avec des choix de déploiement qui incluent des machines virtuelles et des conteneurs. Les packs de conteneurs regroupent une application avec ses dépendances d’exécution afin que les équipes puissent la déployer de manière cohérente sur une infrastructure compatible. L’AMA a remplacé une seule estimation de la taille d’un portefeuille par des preuves spécifiques à l’application. Il recense le contenu et la structure de l’application, identifie les bibliothèques partagées et les dépendances, signale les problèmes de migration et estime l’effort de développement. Mitsubishi Motors a utilisé ces rapports pour séparer les applications pouvant être déplacées avec peu de modifications des services web nécessitant l’intervention des développeurs. Cette distinction permet à une petite équipe de migrer d’abord les workloads compatibles, de laisser les spécialistes gérer les véritables incompatibilités et d’éviter de dépenser du budget sur du code qui n’a pas besoin d’être modifié. Les résultats de l’analyse des services web ont également permis de concrétiser le retard accumulé en matière de résolution. Environ 95 % des services utilisaient déjà REST. Les services SOAP restants utilisaient d’anciennes interfaces et bibliothèques Java, notamment JAX-RPC et JAXB. L’évaluation a identifié des candidats pour les mises à jour de la bibliothèque et la conversion vers REST au lieu de laisser les développeurs découvrir ces problèmes lors du déploiement. Le diagramme d’architecture se lit de gauche à droite en commençant par le parc actuel. Les 170 workloads s’exécutent sur WebSphere Network Deployment avec Java 8 et Windows Server 2016. IBM HTTP Server gère environ 80 % des applications, acheminant les requêtes HTTP vers la couche applicative. L’hébergement cloud hybride d’IBM offre une continuité entre un site principal à Dallas et un site de colocation dans le Colorado. En plus du flux de migration présenté dans le diagramme, IBM Instana Observability fournit une couche d’observabilité pour le parc WebSphere actuel. MMNA a installé l’agent hôte Instana sur chaque nœud WebSphere, y compris le gestionnaire de déploiement (DMGR), le processus central utilisé pour administrer la cellule WebSphere, et les nœuds personnalisés. Instana identifie automatiquement le DMGR, les nœuds, les serveurs d’applications, les clusters, les machines virtuelles Java (JVM), les packages EAR (archive d’entreprise) et WAR (archive d’application web) déployés, ainsi que l’activité de collecte de mémoire et de déchets. Pour le traçage des transactions, MMNA a connecté le capteur Instana Java à chaque JVM WebSphere et synchronisé les nœuds. Cette instrumentation suit les requêtes de bout en bout et expose l’exécution au niveau des méthodes, les requêtes lentes, les appels de base de données et l’activité du service de messagerie Java (JMS). La deuxième étape envoie le stock et les données de configuration à AMA 4.3.0. Le logiciel génère des rapports sur les portefeuilles et au niveau du code, regroupe les applications par complexité de migration et identifie les tâches telles que les changements JAX-RPC, JAXB et SOAP-to-REST. IBM Rational Application Developer reste le principal environnement de développement intégré (IDE) pour le workflow Java existant. Ces résultats alimentent une feuille de route de migration hiérarchisée plutôt qu’une transition automatique. Les équipes peuvent d’abord déplacer les quelque 90 applications métier compatibles, les valider sur Liberty, puis traiter l’ensemble de résolution plus petit. Pour les services SOAP plus anciens, le plan peut associer les modifications de code à la recompilation sous Java 17. La troisième étape vise WebSphere Liberty, disponible via IBM JSphere Suite for Java. Liberty prend en charge les fonctionnalités modulaires des serveurs, les environnements d’exécution Java modernes et le déploiement sur des machines virtuelles ou dans des conteneurs. La conteneurisation, l’adoption de Spring Boot et une stratégie multi-cloud sont considérées comme des choix futurs, et non comme des déploiements achevés. Cette distinction permet de séparer la modernisation de l’exécution de la relocalisation de l’infrastructure : l’équipe peut d’abord établir la compatibilité de l’application, puis décider où et comment chaque workload doit être exécuté. La quatrième étape conserve les systèmes entourant l’application. IBM MQ poursuit la messagerie asynchrone, où les producteurs et les consommateurs échangent des messages sans avoir à s’exécuter au même moment. Db2 et les sources de données étendues continuent de servir les données d’application. Les systèmes mainframe IBM et IBM AS
400 conservent leurs rôles de traitement de base et hérités. Operational Decision Manager continue d’exécuter les règles métier via le Decision Center et le Decision Server. La préservation de ces interfaces limite la surface de modification et protège le comportement métier pendant que l’environnement d’exécution Java sous-jacent évolue. Cette évaluation a apporté un avantage concret avant la première grande vague migratoire : elle a réduit l’incertitude. Au lieu de partir du principe que toutes les versions vieilles de six ans présentaient un risque égal, l’équipe a obtenu une vue de la compatibilité et des efforts déployés par chaque application. Le fait de constater qu’environ 90 applications pouvaient être déplacées avec peu ou pas de modifications de code a permis de réduire la charge de résolution prévue et a donné aux responsables une base solide en matière de personnel, de séquençage et de budgets. Pour les développeurs, ces rapports transforment des travaux de modernisation vagues en tâches clairement identifiées. Une équipe peut tester une application compatible sur Liberty, mettre à jour une bibliothèque spécifique si nécessaire ou planifier le remplacement d’un ancien point de terminaison SOAP par une application REST. La migration par cohortes permet également de créer des modèles de construction, de test et d’annulation reproductibles avant le déplacement des services nécessitant davantage d’efforts. Cela garantit la disponibilité des systèmes utilisés par les concessionnaires, les employés et les clients, tout en raccourcissant le cycle de feedback pour chaque version. Instana fournit à chaque cohorte de migration une base opérationnelle ainsi qu’un rapport de compatibilité. Les équipes peuvent comparer les temps de réponse, les taux d’erreur, le comportement des JVM, les appels de base de données et les traces de messagerie avant et après une migration. Les spécialistes peuvent alors déterminer si la régression se situe dans le code de l’application, l’environnement d’exécution, un pool de connexions ou une dépendance en aval. Ces commentaires réduisent le temps de dépannage et contribuent à protéger les workflows des concessionnaires, des employés et des clients qui dépendent de ces applications. L’architecture préserve également les options sans les imposer dès la première phase. Liberty peut fonctionner en dehors des conteneurs, ce qui permet aux équipes de moderniser l’environnement d’exécution avant de former à nouveau le personnel ou de repenser les opérations autour de l’orchestration de conteneurs. Par la suite, les workloads standardisés Liberty peuvent prendre en charge une intégration continue et une livraison continue plus automatisées, c’est-à-dire la pratique consistant à construire, tester et publier du code via des pipelines reproductibles. Ce séquençage réduit les perturbations à court terme tout en créant une voie crédible vers des sorties plus rapides et des déploiements plus mobiles. Mitsubishi Motors a transformé une question de modernisation de 170 applications en une série de décisions circonscrites : déplacer les workloads compatibles, corriger les exceptions identifiées et conserver les connexions d’entreprise éprouvées. AMA a fourni les preuves nécessaires pour éviter des réécritures inutiles, tandis que WebSphere Liberty propose un environnement d’exécution Java moderne capable de soutenir l’adoption progressive de nouvelles pratiques de développement et de déploiement. Cette conception progressive évolue en répétant le même schéma d’évaluation, de migration et de validation sur plusieurs cohortes d’applications au lieu d’étendre une transition à haut risque. Elle protège l’expérience quotidienne des concessionnaires, des employés et des clients, offre à l’équipe de développement une file d’attente gérable et trace une voie définie pour s’éloigner de Java 8 et d’une infrastructure vieillissante. En co