MMNA analysiert 170 Produktionsanwendungen für Migration zu IBM WebSphere Liberty in Nordamerika; 90 von 110 Apps benötigen kaum Änderungen
So konnte Mitsubishi Motors 170 Java-Anwendungen für einen unterbrechungsfreien Wechsel zu IBM WebSphere Liberty zuordnen
Der IBM Application Modernization Accelerator analysierte 170 Produktionsanwendungen innerhalb von Stunden, was Mitsubishi Motors North America einen stufenweisen Weg zu WebSphere Liberty ermöglichte und gleichzeitig die Systeme schützte, die Händler, Mitarbeiter und Kunden täglich nutzen. Einige der Produktionsanwendungen von Mitsubishi Motors North America liefen zu diesem Zeitpunkt seit sechs Jahren, ohne neu kompiliert zu werden. Diese Stabilität war wertvoll, aber sie verbarg auch eine wachsende Lücke zwischen zuverlässigem Anwendungsverhalten und einer veralteten Grundlage. An diesem Standort wurden 170 Produktionsworkloads betrieben – 110 Geschäftsanwendungen und 60 Webdienste – auf Java 8, Windows Server 2016 und IBM WebSphere Application Server Network Deployment. Eine Änderung der gemeinsamen Laufzeitumgebung hätte sich auf den Händlerbetrieb, die Arbeitsabläufe der Mitarbeiter und die kundenorientierten Dienstleistungen in den Vereinigten Staaten, Kanada, Puerto Rico und Mexiko auswirken können. Mitsubishi Motors North America (MMNA) verwaltet mit Hauptsitz in Nashville, Tennessee, regionale Anwendungen und Infrastrukturen für den japanischen Automobilhersteller Mitsubishi Motors Corporation. Seine Webdienste empfangen auch Anfragen von Systemen in Europa und Asien. Die Architektur lässt sich mit IBM MQ, IBM Db2, IBM Mainframe- und IBM AS
400-Systemen sowie dem IBM Operational Decision Manager verbinden, sodass die Modernisierung die Java-Anwendungen nicht als isolierte Ebene behandeln konnte. Diese Abhängigkeiten mussten während der Migration weiterhin funktionieren. Der nordamerikanische Betrieb von MMNA wird vollständig in der IBM Hybrid Cloud ausgeführt, während Mitsubishi Motors Corporation weiterhin Mainframes lokal in Japan betreibt. Die zentrale Einschränkung bestand nicht einfach nur aus veraltetem Code. Ein Entwicklerteam mit begrenzter Bandbreite musste entscheiden, welche Anwendungen unverändert übernommen werden konnten, welche gezielte Änderungen erforderten und wie die Arbeit ohne aufwändige Neuentwicklung abgewickelt werden konnte. IBM Application Modernization Accelerator (AMA) 4.3.0 analysierte das gesamte Portfolio in Stunden anstatt über Monate, die eine manuelle Überprüfung in Anspruch genommen hätte. Die Ergebnisse zeigten, dass etwa 90 der 110 Anwendungen minimale oder keine Codeänderungen für IBM WebSphere Liberty benötigten. In diesem Beitrag untersuchen wir, wie die Bewertung auf Portfolio-Ebene eine unsichere Migration in einen schrittweisen Plan umgewandelt hat. Wir beschäftigen uns außerdem damit, wie die Zielarchitektur die Integrationen erhält und wie dieser Ansatz Risiken und die Gesamtbetriebskosten (TCO) kontrolliert. Das unmittelbare Ziel bestand darin, Risiken in Bezug auf Sicherheit und Unterstützbarkeit zu senken, ohne Anwendungen nur um der Veränderung willen zu ändern. WebSphere Network Deployment 9.0.5.22 bot eine unterstützte Laufzeit, die Java 8-Umgebung schränkte die Einführung neuerer Entwicklungsansätze wie Spring Boot jedoch ein. Liberty bot einen Weg zu Java 17, Jakarta EE und neueren Versionen mit Bereitstellungsoptionen in Form von virtuellen Maschinen und Containern. Container verpacken eine Anwendung zusammen mit ihren Laufzeitabhängigkeiten, sodass Teams sie konstant auf kompatibler Infrastruktur bereitstellen können. Die AMA ersetzte eine einheitliche Schätzung für das gesamte Portfolio durch anwendungsspezifische Nachweise. Sie erfasst den Bestand von Anwendungsinhalten und -strukturen, identifiziert gemeinsam genutzte Bibliotheken und Abhängigkeiten, kennzeichnet Migrationsprobleme und schätzt den Entwicklungsaufwand. Mitsubishi Motors nutzte diese Berichte, um Anwendungen, die mit geringem Aufwand migriert werden konnten, von Webdiensten zu trennen, die die Aufmerksamkeit der Entwickler erforderten. Durch diese Unterscheidung kann ein kleines Team zunächst kompatible Workloads migrieren, Spezialisten an echten Inkompatibilitäten arbeiten lassen und vermeiden, Budget für Code auszugeben, der nicht geändert werden muss. Durch die Ergebnisse des Webdienstes nahm die Umstellung ebenfalls konkrete Züge an. Etwa 95 % der Dienste nutzten bereits REST. Die übrigen SOAP-Dienste nutzten ältere Java-Schnittstellen und Bibliotheken, darunter JAX-RPC und JAXB. Die Bewertung identifizierte Kandidaten für Bibliotheksaktualisierungen und die Umstellung auf REST, anstatt die Entwickler diese Probleme erst während der Bereitstellung entdecken zu lassen. Das Architekturdiagramm wird von links nach rechts gelesen, beginnend mit dem aktuellen Betrieb. Die 170 Workloads laufen auf der WebSphere Network Bereitstellung mit Java 8 und Windows Server 2016. Der IBM HTTP Server bedient etwa 80 % der Anwendungen und leitet HTTP-Anfragen an die Anwendungsebene weiter. IBM Hybrid Cloud Hosting gewährleistet Kontinuität durch einen primären Standort in Dallas und einen zweiten Standort in Colorado. Neben dem im Diagramm gezeigten Migrationsfluss bietet IBM Instana Observability eine Ebene für die Observability des aktuellen WebSphere-Bestands. MMNA installierte den Instana-Host-Agenten auf jedem WebSphere-Knoten, einschließlich des Bereitstellungsmanagers (DMGR) – dem zentralen Prozess, der zur Verwaltung der WebSphere-Zelle verwendet wird – und benutzerdefinierten Knoten. Instana identifiziert automatisch die DMGR, Knoten, Anwendungsserver, Cluster, virtuelle Java-Maschinen (JVMs), bereitgestellte EAR (Enterprise Archive) und WAR (Web Application Archive) Pakete sowie Heap- und Garbage-Collection-Aktivitäten. Zur Transaktionsverfolgung integrierte MMNA den Instana Java-Sensor an jede WebSphere JVM und synchronisierte die Knoten. Diese Instrumentierung verfolgt Anfragen von Anfang bis Ende und legt die Ausführung auf Methodenebene, langsame Anfragen, Datenbankaufrufe und Aktivitäten des Java Message Service (JMS) offen. In der zweiten Phase werden Bestand- und Konfigurationsdaten an AMA 4.3.0 gesendet. Die Software erstellt Berichte auf Portfolio- und Codeebene, gruppiert Anwendungen nach Migrationskomplexität und identifiziert Aufgaben wie JAX-RPC, JAXB und SOAP-to-REST-Änderungen. IBM Rational Application Developer bleibt die primäre integrierte Entwicklungsumgebung, oder IDE, für den bestehenden Java-Workflow. Diese Erkenntnisse fließen in einen priorisierte Roadmap für die Migration ein, anstatt in eine automatische, abrupte Umstellung. Teams können zunächst die rund 90 kompatiblen Anwendungen migrieren, diese auf Liberty validieren und sich dann der Sanierung widmen. Für die älteren SOAP-Dienste kann der Plan Codeänderungen mit einer Neukompilation unter Java 17 kombinieren. Die dritte Stufe richtet sich an WebSphere Liberty, das über die IBM JSphere Suite für Java verfügbar ist. Liberty unterstützt modulare Serverfunktionen, moderne Java-Laufzeiten und die Bereitstellung auf virtuellen Maschinen oder in Containern. Containerisierung, Spring Boot-Einführung und eine Multi-Cloud-Strategie werden als zukünftige Optionen betrachtet, nicht als abgeschlossene Bereitstellungen. Diese Unterscheidung trennt die Laufzeit-Modernisierung von der Infrastrukturverlagerung: Das Team kann zunächst die Anwendungskompatibilität herstellen und dann entscheiden, wo und wie jede Workload ausgeführt werden soll. Die vierte Stufe behält die Systeme bei, die die Anwendung umgeben. IBM MQ setzt die asynchrone Nachrichtenübermittlung fort, bei der Produzenten und Konsumenten Nachrichten austauschen, ohne dass diese gleichzeitig ausgeführt werden müssen. Db2 und erweiterte Datenquellen liefern weiterhin Anwendungsdaten. IBM Mainframe und IBM AS
400-Systeme behalten weiterhin Kern- und Altlast-Verarbeitungsrollen. Der Operational Decision Manager setzt währenddessen weiterhin Business Rules über Decision Center und Decision Server um. Durch die Beibehaltung dieser Schnittstellen wird die Änderungsfläche begrenzt und das Geschäftsverhalten geschützt, während sich die Java-Laufzeitumgebung darunter ändert. Die Bewertung brachte bereits vor der ersten großen Migrationswelle einen praktischen Nutzen: Sie verringerte die Unsicherheit. Anstatt davon auszugehen, dass alle sechs Jahre alten Entwicklungen das gleiche Risiko bergen, erhielt das Team einen Überblick über Kompatibilität und Aufwand pro Anwendung. Die Feststellung, dass etwa 90 Anwendungen mit minimalen Änderungen oder ganz ohne Code verschoben werden konnten, senkte die prognostizierte Belastung durch die Sanierung und ermöglichte den Managern eine vertretbare Grundlage für Personal, Sequenzierung und Budgets. Für Entwickler verwandeln die Berichte eine vage Modernisierung in klar benannte Aufgaben. Teams können eine kompatible Anwendung auf Liberty testen, eine bestimmte Bibliothek bei Bedarf aktualisieren oder einen REST-Ersatz für einen älteren SOAP-Endpunkt planen. Die Migration in Kohorten schafft zudem wiederholbare Entwicklungs-, Test- und Rollback-Muster, bevor aufwändigere Dienste migriert werden. Dadurch wird die Verfügbarkeit der von Händlern, Mitarbeitern und Kunden genutzten Systeme sichergestellt und gleichzeitig der Feedback-Zyklus für jede neue Version verkürzt. Instana stellt jeder Migrationskohorte eine operative Ausgangslage sowie einen Kompatibilitätsbericht zur Verfügung. Teams können Antwortzeiten, Fehlerraten, JVM-Verhalten, Datenbankaufrufe und Messaging-Traces vor und nach einem Wechsel vergleichen. Anschließend können die Spezialisten herausfinden, ob eine Regression im Anwendungscode, in der Laufzeit, in einem Verbindungspool oder in einer nachgelagerten Abhängigkeit liegt. Dieses Feedback reduziert die Zeit für die Problembehebung und hilft, die Workflows von Händlern, Mitarbeitern und Kunden zu schützen, die von diesen Anwendungen abhängig sind. Die Architektur bewahrt zudem Optionen, ohne sie in die erste Phase zu zwingen. Liberty kann außerhalb von Containern laufen, sodass Teams die Laufzeit modernisieren können, bevor sie Mitarbeiter umschulen oder Abläufe rund um die Container-Orchestrierung umgestalten. Später unterstützen standardisierte Liberty-Workloads eine stärker automatisierte kontinuierliche Integration und kontinuierliche Bereitstellung, also die Praxis, Code durch wiederholbare Pipelines zu erstellen, zu testen und freizugeben. Diese Sequenzierung reduziert kurzfristige Störungen und ebnet gleichzeitig einen glaubwürdigen Weg zu schnelleren Releases und tragbareren Bereitstellungen. Mitsubishi Motors verwandelte die Frage nach Modernisierung von 170 Anwendungen in eine Reihe begrenzter Entscheidungen: Verlagerung kompatibler Workloads, Behebung identifizierter Ausnahmen und Beibehaltung bewährter Unternehmensverbindungen. AMA lieferte die notwendigen Belege, um unnötige Umschreibungen zu vermeiden, während WebSphere Liberty eine moderne Java-Laufzeit bereitstellte, die die schrittweise Einführung neuerer Entwicklungs- und Bereitstellungspraktiken unterstützt. Dieses phasenweise Design skaliert, indem es das gleiche Bewertungs-, Migrations- und Validierungsmuster über verschiedene Anwendungskohorten hinweg wiederholt, anstatt einen riskanten Übergang auszuweiten. Es schützt die tägliche Erfahrung von Händlern, Mitarbeitern und Kunden, bietet dem Entwicklungsteam eine überschaubare Warteschlange und ebnet ein klar definiertes Abwenden von Java 8 und veralteter Infrastruktur. Indem IBM seine Entwicklungszeit auf Anwendungen konzentriert, die tatsächlich Änderungen benötigen, hilft die Technologie von IBM Mitsubishi Motors dabei, das Migrationsrisiko und die Gesamtbetriebskosten zu reduzieren und gleichzeitig zukünftige Hosting-Optionen offen zu halten.