A 60 anni dalla loro invenzione, i mainframe mantengono alta la propria bandiera continuando a rappresentare un punto fermo della tecnologia, in grado di gestire carichi di lavoro critici e ad alta intensità di transazioni.
In uno studio di Forrester Research del 2020, quasi tre quarti dei decisori in ambito IT statunitensi interpellati hanno dichiarato che i mainframe hanno una validità a lungo termine come piattaforma strategica. Un chiaro segnale di generale fiducia che non esclude però la voglia di abbandonare il “big iron” manifestata da alcuni. Un’intenzione che nasce dai costi di mantenimento, a volte, oppure dalle difficoltà di reperimento di personale in grado di comprendere linguaggi e database legacy.
A tutto ciò si deve aggiungere anche l’attrattiva del cloud computing come ambiente IT flessibile e moderno che inevitabilmente spinge molti aderenti ai mainframe a spostare almeno una parte delle loro applicazioni e dei loro dati verso alternative as-a-service.
Quello che si sta considerando è un processo per nulla banale, ma affrontabile. La migrazione del mainframe è infatti un compito complicato che richiede un’attenta pianificazione e una valutazione delle opzioni lucida. Le scelte includono il trasferimento dell’intero ambiente mainframe a un fornitore di servizi di hosting o il refactoring di un’applicazione mainframe per la distribuzione in un cloud pubblico o in un’altra piattaforma.
Qualunque sia il metodo adottato, la transizione resta un passo fondamentale per i centri IT che contano ancora sulla potenza di calcolo del mainframe. “Il mainframe è la spina dorsale di queste organizzazioni: in genere è il motore delle transazioni che fanno funzionare queste aziende” afferma Ken Marr, CTO di FNTS, un fornitore di servizi IT gestiti con sede a Omaha, Neb. “È un grosso problema spostare queste applicazioni e riscriverle”.
Le cinque fasi di una migrazione efficace
Le aziende che pianificano una migrazione mainframe devono tener conto di una miriade di fattori, tra cui i tempi di realizzazione del progetto, il budget, le competenze necessarie per riscrivere le applicazioni mainframe e la loro criticità per l’azienda.
Ecco le fasi principali del percorso di migrazione dei mainframe.
Step 1: Considerare le opzioni di rehosting del mainframe
Un’organizzazione decisa ad abbandonare i mainframe, ma con poco tempo a disposizione, potrebbe prendere in considerazione il rehosting. Tale approccio è disponibile in diverse varianti: mainframe as a service, outsourcing ed emulazione, per citarne alcune. Tutte consistono nello spostare l’applicazione mainframe dal data center on-premise dell’azienda al cloud di un service provider.
Il rehosting, in quanto migrazione lift-and-shift, non richiede un’estesa riscrittura del software. Questo lo rende più veloce e meno costoso di altri metodi di migrazione. “Piace a chi cerca un ambiente cloud per i propri carichi di lavoro mainframe senza riscriverli – spiega Juan Orlandini, CTO della filiale nordamericana di Insight Enterprises, un fornitore di servizi IT con sede a Chandler, Ariz – ci si libera dell’onere on-premise che di solito si ha con il mainframe, spostandolo in una sede diversa”.
Il rehosting aiuta anche a rispettare le scadenze. Quando un’organizzazione decide di abbandonare il mainframe, può avere un anno o 18 mesi per farlo prima che l’hardware e il software on-premise vengano rinnovati. Questi tempi risultano quasi sempre insufficienti a smistare il patrimonio mainframe e trasformare le applicazioni, ma le aziende riescono comunque a guadagnare un po’ di tempo, mettendo le basi per una più consistente modernizzazione. “Fornisce loro la pista di decollo necessaria per la razionalizzazione e la trasformazione delle applicazioni” fa osservare Marr.
FNTS, che offre il proprio cloud per l’hosting di mainframe IBM serie Z, è uno dei fornitori di servizi che offrono l’outsourcing di mainframe. Altri sono Ensono, una società di consulenza tecnologica e MSP di Downers Grove, Ill, e IBM, il produttore stesso di mainframe. IBM ospita i mainframe attraverso la sua IBM Z compute Virtual Server Instance che viene eseguita in un cloud privato virtuale IBM.
Step 2: Rifattorizzare? Iniziare con una valutazione dell’applicazione
Alcune aziende potrebbero scegliere di migrare i carichi di lavoro mainframe. Questa opzione prevede il refactoring del codice, ossia la riscrittura di tutta o parte dell’applicazione, per sfruttare al meglio i servizi cloud. È un passaggio più lungo e costoso dell’hosting, ma ha un maggiore potenziale di trasformazione.
“Il modello di refactoring dà all’applicazione una nuova vita” precisa Oliver Presland, vicepresidente del portafoglio di servizi di consulenza globale di Ensono. “Un’applicazione rifattorizzata può integrarsi più facilmente nei servizi cloud-native ed eventualmente evolvere in un’architettura a microservizi“.
In tal caso bisogna procedere con una valutazione dell’applicazione o dell’insieme di applicazioni mainframe da migrare. “C’è un elemento tecnico che consiste nel comprendere la base di codice, le dipendenze e le interazioni con le interfacce e i sistemi esterni” afferma Presland. “Se non si dedica tempo a questa fase di valutazione, per capire come trasformare l’applicazione, si corre il rischio che il progetto incontri qualche difficoltà lungo il percorso”.
Orlandini sottolinea poi l’importanza di maturare subito una conoscenza approfondita del sistema mainframe da migrare: “serve capire veramente che cosa ogni applicazione fa, quale logica aziendale sta codificando e come ricodificarla in modo più efficiente”.
Secondo Marr, questa fase di razionalizzazione delle applicazioni aiuta le organizzazioni a determinare cosa è realmente possibile. Con questa conoscenza, un’azienda può definire la propria strategia per spostare i carichi di lavoro dal mainframe o, in alternativa, decidere di mantenere l’applicazione sul mainframe o di ritirarla.
Rimanere con il mainframe
La migrazione al mainframe non è sempre la risposta migliore. “I mainframe vanno benissimo per lo scopo per cui sono stati costruiti in origine” afferma Orlandini. “Una volta compiuta la transizione, risulta difficile passare da qualcosa che è materialmente buono a qualcosa che potrebbe non essere migliore”.
I progressi della serie Z dei mainframe IBM, che includono la capacità di elaborare carichi di lavoro AI e di eseguire il rilevamento delle frodi, forniscono per esempio un ampio argomento a favore della permanenza sulla piattaforma. Le aziende che possono gestire tali funzioni in modo nativo sul mainframe, senza dover riscrivere lo stack applicativo, potrebbero ritardare la migrazione, come osserva Orlandini: “continuiamo a vedere persone che investono nella serie Z”.
Presland afferma che spesso le aziende hanno un nucleo di applicazioni che è meglio collocare sui mainframe, a causa del volume delle transazioni o della gravità dei dati. In questi casi, le offerte basate su API e le interfacce di virtualizzazione dei dati semplificano l’accesso, il consumo e l’interazione con i dati mainframe da parte degli sviluppatori cloud.
Step 3: Attenzione alle parti più “hard”
Coloro che optano per il refactoring devono dedicarsi a un’analisi della complessità, per identificare i potenziali ostacoli alla migrazione. Gli strumenti automatici aiutano a convertire le tecnologie mainframe più comuni, come i file di dati COBOL, PL/1 e VSAM, in linguaggi e formati di dati moderni. Offerte del genere potrebbero però non esistere per il codice più “oscuro” che risiede sul mainframe.
“Sebbene sia possibile spostare la maggior parte delle applicazioni e dei dati con una serie di soluzioni, trovare un modo per gestire alcune delle tecnologie più esotiche può diventare piuttosto impegnativo” afferma infatti Presland. Un’applicazione potrebbe contenere, per esempio, codice molto specifico per un particolare scopo aziendale o un plugin di terze parti specializzato. Inoltre, la retrocompatibilità degli ambienti mainframe IBM significa che il vecchio codice e i sistemi arcaici possono ancora funzionare sull’hardware più recente.
Presland cita l’esempio del Model 204, un sistema di gestione di database degli anni Settanta. Secondo le sue stime, Ensono ha condotto tre trasformazioni del Model 204 di notevole entità. “È molto difficile trovare le competenze e il personale necessario” aggiunge.
Il personale costituisce effettivamente un problema: molti esperti in sistemi mainframe sono andati in pensione. “Queste applicazioni possono avere 40 o 50 anni – osserva Marr – l’avere qualcuno che conosce bene il codice non è scontato”.
In generale, le applicazioni coinvolte nell’elaborazione di transazioni a basso volume risultano le più problematiche. “Le parti ad alto volume non sono un problema perché tendono a essere scritte in linguaggi comuni – precisa Presland – quelle a basso volume ma più critiche all’interno del portafoglio di applicazioni sono davvero fondamentali. Sono state scritte molto tempo fa e bisogna essere in grado di trasformarle”.
Individuare in anticipo i problemi di conversione del codice più difficili aiuta a pianificare il progetto di migrazione.
Step 4: Pianificare il progetto
Una valutazione approfondita dell’applicazione e un’analisi della complessità confluiscono nel piano del progetto di migrazione. “Questo getta le basi per dire: ‘Ho capito il business case e ho capito il percorso tecnologico’ – spiega Presland – Il risultato è la prevedibilità della tempistica del progetto, del prezzo, del metodo di gestione dei componenti complessi e del piano dei requisiti e delle risorse”.
Sempre Presland spiega anche come la pianificazione del progetto di Ensono offra un paio di strade: una transizione immediata alla migrazione dei carichi di lavoro mainframe, oppure un proof of concept con migrazione completa a seguire. Quest’ultima prevede la conversione della prima sezione dell’applicazione da migrare. La conversione di una sezione dà la possibilità di testare ed eseguire il progetto, il che aumenta la fiducia.
Altri approcci alla migrazione potrebbero iniziare con solo alcuni moduli di codice, per dimostrare che il processo è in grado di generarne di buona qualità. Ma questa dimostrazione non fornisce sempre un sistema funzionante che possa essere poi anche testato.
Step 5: Copertura del codice
Il refactoring richiede la conversione del codice da vecchi linguaggi a linguaggi moderni, come Java, C# o COBOL 6.0. “I dati gestiti in file flat o in formati non relazionali vengono convertiti in un formato di database relazionale, spesso un database PaaS” spiega Presland.
I fornitori di servizi IT specializzati nella conversione dei mainframe utilizzano set di strumenti per automatizzare l’attività di conversione. Marr stima che i tool per il codice mainframe raggiungono una percentuale di accuratezza della conversione intorno ai 90 anni. La conversione del 92-93% del codice può avvenire piuttosto rapidamente, ma quella del codice rimanente e necessario per far funzionare l’applicazione richiede tempo, secondo Marr. “Si tratta comunque di un grande progetto, ma molto più veloce della riscrittura totale di un’applicazione in C#, C++ o Java”.
Le aziende possono estrarre singole transazioni da un’applicazione per ridurre l’onere della conversione. Una banca, per esempio, potrebbe concentrarsi solo sulla funzione di check-balance di un’applicazione mainframe rivolta agli utenti, migrando quel pezzo, anziché l’intero sistema. Secondo Marr, infatti, “la maggior parte delle aziende considera la situazione transazione per transazione”.
