Come Mitsubishi Motors ha mappato 170 applicazioni Java per una migrazione a basso impatto verso IBM® WebSphere Liberty
IBM® Application Modernization Accelerator ha analizzato 170 applicazioni di produzione in poche ore, offrendo a Mitsubishi Motors North America un percorso graduale verso WebSphere Liberty e proteggendo i sistemi che concessionari, dipendenti e clienti usano quotidianamente.
Alcune applicazioni di produzione di Mitsubishi Motors North America erano in funzione da sei anni senza essere mai state ricompilate. Quella stabilità era preziosa, ma nascondeva anche un divario sempre più ampio tra un comportamento affidabile delle applicazioni e una base invecchiata.
Il complesso ha eseguito 170 carichi di lavoro in produzione (110 applicazioni aziendali e 60 servizi web) su Java 8, Windows Server 2016 e IBM® WebSphere Application Server Network Deployment. Una modifica al tempo di esecuzione condiviso potrebbe avere ripercussioni sulle attività dei concessionari, sul workflow dei dipendenti e sui servizi rivolti ai clienti negli Stati Uniti, in Canada, a Porto Rico e in Messico.
Con sede a Nashville, Tennessee, Mitsubishi Motors North America (MMNA) gestisce applicazioni e infrastrutture regionali per la casa automobilistica giapponese Mitsubishi Motors Corporation. I suoi servizi web ricevono chiamate anche da sistemi in Europa e in Asia.
L'architettura si collega ai sistemi IBM® MQ, IBM® Db2, IBM® mainframe e IBM® AS/400, così come IBM® Operational Decision Manager, quindi la modernizzazione non poteva trattare le applicazioni Java come un livello isolato. Queste dipendenze dovevano continuare a funzionare durante la migrazione. L'infrastruttura nordamericana di MMNA è interamente basata su IBM® Hybrid Cloud, mentre Mitsubishi Motors Corporation continua a utilizzare mainframe on-premise in Giappone.
Il vincolo centrale non era semplicemente il vecchio codice. Un team di sviluppo con larghezza di banda limitata doveva determinare quali applicazioni potevano essere spostate come scritte, quali richiedevano modifiche mirate e come sequenziare il lavoro senza una riscrittura dirompente.
IBM® Application Modernization Accelerator (AMA) 4.3.0 Ho analizzato l'intero portfolio in ore invece dei mesi che una revisione manuale avrebbe potuto richiedere. I risultati mostrarono che circa 90 delle 110 applicazioni aziendali necessitavano di modifiche minime al codice o addirittura di nessuna modifica per IBM® WebSphere Liberty.
In questo articolo esamineremo come la valutazione a livello di portfolio abbia trasformato una migrazione incerta in un piano a fasi. Scopriremo anche come l'architettura target preserva le integrazioni aziendali e come questo approccio controlla il rischio e il costo totale di proprietà (TCO).
L'obiettivo immediato era affrontare il rischio di sicurezza e supportabilità senza modificare le applicazioni solo per motivi di cambiamento. WebSphere Network Deployment 9.0.5.22 forniva un tempo di esecuzione intermedio supportato, ma l'ambiente Java 8 limitava l'adozione di nuovi approcci di sviluppo come Spring Boot.
Liberty offriva un percorso verso Java 17, Jakarta EE e nuove versioni con scelte di distribuzione che includevano macchine virtuali e container. I container impacchettano un'applicazione con le sue dipendenze di tempo di esecuzione in modo che i team possano implementarla in modo coerente su infrastrutture compatibili.
L'AMA ha sostituito una singola stima di dimensione portfolio con evidenze specifiche di applicazione. Inventaria i contenuti e la struttura delle applicazioni, identifica librerie e dipendenze condivise, segnala problemi di migrazione e stima lo sforzo di sviluppo. Mitsubishi Motors ha utilizzato questi report per separare le applicazioni che potevano essere spostate con poche rielaborazioni dai servizi web che richiedevano l'attenzione degli sviluppatori. Questa distinzione permette a un piccolo team di migrare prima i workload compatibili, riservare gli specialisti per le incompatibilità reali ed evitare di spendere budget su codice che non necessita di modifiche.
I risultati del servizio web hanno anche reso concreto il backlog di correzione. Circa il 95% dei servizi utilizzava già REST. I restanti servizi SOAP utilizzavano interfacce e librerie Java più vecchie, tra cui JAX-RPC e JAXB. La valutazione ha individuato i candidati per l'aggiornamento delle librerie e la conversione a REST, evitando che gli sviluppatori scoprissero questi problemi durante la fase di implementazione.
Il diagramma dell'architettura si legge da sinistra a destra, a partire dalla proprietà corrente. I 170 workload vengono eseguiti su WebSphere Network implementazione con Java 8 e Windows Server 2016. IBM® HTTP Server gestisce circa l'80% delle applicazioni, indirizzando le richieste HTTP al livello di applicazione. L'hosting IBM Hybrid Cloud garantisce continuità attraverso un sito principale a Dallas e un sito di colocation in Colorado.
Oltre al flusso di migrazione mostrato nel diagramma, IBM® Instana Observability fornisce un livello di observability per l'attuale patrimonio di WebSphere. MMNA ha installato l'agente host Instana su ogni nodo WebSphere, incluso il gestore di distribuzione (DMGR), ovvero il processo centrale utilizzato per amministrare la cella WebSphere, e sui nodi personalizzati. Instana identifica automaticamente il DMGR, i nodi, i server applicazioni, i cluster, le macchine virtuali Java (JVM), i deployer EAR (archivio aziendale) e WAR (archivio delle applicazioni web) distribuiti, nonché le attività di heap e garbage-collection.
Per il monitoraggio delle transazioni, MMNA ha collegato il sensore Instana Java a ogni JVM WebSphere e ha sincronizzato i nodi. Questa strumentazione segue le richieste end-to-end ed espone l'esecuzione a livello di metodo, richieste lente, chiamate al database e attività del Java Message Service (JMS).
La seconda fase invia i dati di inventario e configurazione ad AMA 4.3.0. Il software genera report a livello di portfolio e di codice, raggruppa le applicazioni in base alla complessità della migrazione e identifica interventi quali modifiche a JAX-RPC, JAXB e SOAP-to-REST. IBM® Rational applicazione Developer rimane l'ambiente di sviluppo integrato principale, o IDE, per il workflow Java esistente.
Questi risultati alimentano una roadmap di migrazione prioritaria piuttosto che un cutover automatico. I team possono prima spostare le circa 90 applicazioni aziendali compatibili, convalidarle su Liberty e poi risolvere il set di correzione più piccolo. Per i servizi SOAP più vecchi, il piano può abbinare le modifiche al codice alla ricompilazione su Java 17.
La terza fase si rivolge a WebSphere Liberty, disponibile tramite IBM JSphere Suite per Java. Liberty supporta caratteristiche modulari dei server, runtime Java moderni e implementazione su macchine virtuali o in container. La containerizzazione, l'adozione di Spring Boot e una strategia multi-cloud sono considerate scelte future, non implementazioni completate. Questa distinzione mantiene separata la modernizzazione in tempo di esecuzione dal trasferimento dell'infrastruttura: il team può prima stabilire la compatibilità dell'applicazione, poi decidere dove e come ogni workload deve funzionare.
Il quarto stadio mantiene i sistemi che circondano l'applicazione. IBM® MQ continua la trasmissione di messaggi asincroni, dove produttori e consumatori scambiano messaggi senza dover essere eseguiti contemporaneamente. Db2 e le fonti dati estese continuano a fornire dati di applicazione.
I mainframe IBM e i sistemi IBM® AS/400 mantengono ruoli di elaborazione core e legacy. Operational Decision Manager continua a eseguire le Business Rules tramite Decision Center e Decision Server. Preservare queste interfacce limita la superficie di modifica e protegge il comportamento aziendale mentre il tempo di esecuzione Java sottostante subisce delle modifiche.
La valutazione ha fornito un beneficio pratico prima della prima grande ondata migratoria: ha ridotto l'incertezza. Invece di presumere che tutte le build vecchie di sei anni comportassero lo stesso rischio, il team ha ottenuto una visione per applicazione della compatibilità e dell'impegno. Scoprire che circa 90 applicazioni aziendali potevano muoversi con modifiche minime o nessuna modifica al codice ha ridotto il carico di correzione previsto e ha fornito ai manager una base difendibile per il personale, il sequenziamento e i budget.
Per gli sviluppatori, i report trasformano i vaghi lavori di modernizzazione in attività chiaramente definite. Un team può testare un'applicazione compatibile su Liberty, aggiornare una libreria specifica dove necessario o pianificare una sostituzione REST per un endpoint SOAP più vecchio. La migrazione nelle coorti crea anche pattern ripetibili di build, test e rollback prima che i servizi di maggiore sforzo si spostino. Ciò protegge la disponibilità dei sistemi utilizzati da concessionari, dipendenti e clienti riducendo al contempo il ciclo di feedback per ogni versione.
Instana fornisce a ogni gruppo di migrazione una baseline operativa e un report di compatibilità. I team possono confrontare i tempi di risposta, i tassi di errore, il comportamento della JVM, le chiamate al database e le tracce di messaggistica prima e dopo uno spostamento. Successivamente, gli specialisti possono isolare se una regressione si trova nel codice di applicazione, nel tempo di esecuzione, in un pool di connessione o in una dipendenza a valle. Questo feedback riduce i tempi di risoluzione dei problemi e aiuta a proteggere i workflow di rivenditori, dipendenti e clienti che dipendono da queste applicazioni.
L'architettura preserva anche le opzioni senza forzarle nella prima fase. Liberty può essere eseguito all'esterno dei container, in modo che i team possano modernizzare il tempo di esecuzione prima di riqualificare il personale o riprogettare le operazioni relative all'orchestrazione dei container. Successivamente, i workload Liberty standardizzati possono supportare un'integrazione continua e una distribuzione continua più automatizzate, la pratica di creare, testare e rilasciare codice attraverso pipeline ripetibili. Questa sequenza riduce le interruzioni a breve termine creando al contempo una via credibile verso rilasci più rapidi e implementazioni più portatili.
Mitsubishi Motors ha trasformato una modernizzazione di 170 applicazioni in una serie di decisioni circoscritte: spostare workload compatibili, risolvere le eccezioni identificate e mantenere le connessioni aziendali collaudate. AMA ha fornito le prove necessarie per evitare riscritture inutili, mentre WebSphere Liberty offre un tempo di esecuzione Java moderno che può supportare l'adozione graduale di nuove pratiche di sviluppo e implementazione.
Questa progettazione a fasi si basa sulla ripetizione dello stesso schema di valutazione, migrazione e convalida per diverse coorti di applicazioni, anziché sull'implementazione di un unico passaggio ad alto rischio. Protegge l'esperienza quotidiana di rivenditori, dipendenti e clienti, offre al team di sviluppo una coda gestibile e crea un percorso definito per allontanarsi da Java 8 e dall'infrastruttura obsoleta.
Concentrando il tempo degli ingegneri sulle applicazioni che necessitano realmente di modifiche, la tecnologia IBM aiuta Mitsubishi Motors a ridurre il rischio di migrazione e il costo totale di proprietà (TCO), mantenendo al contempo aperte le opzioni di hosting future.