La modernizzazione del mainframe è un problema difficile e divertente da risolvere

Il titolo fa due affermazioni:

1. L'ammodernamento del mainframe è difficile.
2. L'ammodernamento Mainframe è divertente.

Il mio scopo in questo saggio è quello di giustificare queste affermazioni. Se ci riuscirò, spero di convincere un piccolo numero di persone tecniche che sono incoraggiate, piuttosto che scoraggiate, da enormi difficoltà ad unirsi a noi nella nostra ricerca.

Per iniziare, dovrei spiegare di cosa sto parlando.

Quando pensi a un mainframe, probabilmente immagina un terminale monocromatico a schermo verde. Da oltre quarant'anni, quel testo di fosforo splendente è stato il battito costante della finanza globale.

Essenzialmente, l'ammodernamento mainframe sta convertendo un'applicazione software o una suite di applicazioni in esecuzione su un mainframe in un moderno sistema distribuito, mantenendo il comportamento, la correttezza e le garanzie operative.

Cos'è un computer mainframe? Per IBM, il più grande fornitore di mainframe, “[essi] sono server di dati che sono progettati per elaborare fino a 1 trilione transazioni web al giorno con i più alti livelli di sicurezza e affidabilità.” Nonostante l'aumento del cloud computing, i mainframe continuano a svolgere un ruolo essenziale nell'infrastruttura IT, soprattutto nelle industrie più tradizionali che hanno un grande volume di transazioni critiche.

Sulla base di un recente rapporto IBM, “45 delle migliori 50 banche, 4 delle migliori 5 compagnie aeree, 7 dei migliori 10 rivenditori globali e 67 delle aziende Fortune 100 sfruttano il mainframe come loro piattaforma principale.” Quando si scorre una carta di credito a Londra o ritirare pesos a Bogotá, si sta interagendo con queste macchine.

Il perché

Allora, perché modernizzare? Se i mainframe sono così buoni, perché allontanarsi da loro? Le organizzazioni pretendono di avere una varietà di motivi. Ma se oggi vi trovate in una sala operativa di una banca importante, vedrete che si riduce a due punti fondamentali:

1. Agility. Il numero di persone che ancora conoscono COBOL e gli interni delle infrastrutture bancarie di 40 anni sta rapidamente diminuendo. Questo rende pericoloso cambiare questi programmi, causando parti di un business per congelare nel tempo. Un business che ristagna alla fine muore, e quindi l'agilità è l'anticedente alla sopravvivenza.
2. Costo. IBM detiene un quasi monopolio nel mercato mainframe. Operare un unico mainframe può costare milioni all'anno. Anche se non è un truffatore per tutti, molte imprese si sarebbero allontanate da costosi contratti IBM se ci fosse un percorso chiaro e a basso rischio per farlo.

Così, anche se non c'è nulla di sbagliato nei mainframeper se, le condizioni di mercato e lo stato del mondo creano forti venti di coda per modernizzare lontano da loro, con il mercato di modernizzazione mainframe stimato essere nelle centinaia di miliardi di dollari.

Ammodernamento mainframe è difficile

L'ammodernamento del mainframe è un problema malvagio perché è un'amalgama di alcuni dei problemi più difficili in tutta l'ingegneria informatica e software, tutto in una volta.

Dobbiamo trattare contemporaneamente questioni come lo stato condiviso implicito, il flusso di controllo non documentato, i confini transazionali non ovvi, i casi di bordo numerici che si sono accumulati nel corso di decenni, e la coerenza distribuita garantisce che il mainframe fornisce implicitamente. I sistemi distribuiti non lo fanno.

Questa è la realtà dell’eredità “schermo verde”: la modernizzazione del Mainframe affronta decenni di debito tecnologico in una lingua quasi nessuno sa (COBOL), scritta prima dell’avvento dell’ingegneria software moderna e della programmazione orientata agli oggetti. I modelli di progettazione sono assenti, la documentazione dolorosamente incompleta.

Considera qualcosa di semplice come i numeri.

COBOL utilizza comunemente formati decimali confezionati come COMP-3, che codificano la base-10 aritmetica direttamente in memoria per garantire precisione esatta. Se migrate quella logica a un tipo di punto galleggiante basato sul cloud-nativo, avete subito cambiato il comportamento matematico del sistema. I carri IEEE 754 sono approssimazioni base-2, e valori come 0.1 non possono essere rappresentati esattamente. Anche se ogni singola discrepanza è piccola, in un sistema bancario su milioni di calcoli giornalieri, i composti di errore.

Il sistema inizia a creare o distruggere involontariamente denaro.

In teoria, e in pratica a questa scala, nessuna analisi statica può caratterizzare pienamente il comportamento di un sistema questo grande e questo vecchio. Ci saranno sempre comportamenti che si rivelano solo sotto input reali, dati reali e tempistiche reali.

L'applicazione di destinazione deve catturare con precisione il “Ghost in the Shell” del mainframe, spesso compresi i suoi difetti e bug. Le applicazioni a valle potrebbero gestire bug noti in modi idiosincratici, e il fissaggio di questi bug noti può portare a impreviste catastrofi di ordine seconda e superiore.

Come abbiamo detto nel nostro post sull'Effetto Lindy, la storia è piena di insuccessi su larga scala della modernizzazione tradizionale focalizzata sull'uomo. Dobbiamo sforzarci di fare meglio.

Risolvere il problema difficile (è divertente)

Per modernizzare in modo sicuro, dobbiamo dimostrare, con precisione matematica, che il nostro nuovo sistema si comporta esattamente come quello vecchio. Ciò richiede la creazione di una sofisticata suite di test funzionale che funge da perfetto riflesso della realtà.

Per creare questo, dobbiamo considerare due obiettivi:

1. Il Customer View: Per tutti gli input di produzione, il sistema target genera lo stesso output della sorgente?
2. The Engineering View: Possiamo scrivere la suite di prova in un modo che crea una specifica inequivocabile e comprensibile per gli agenti AI da cui creare l'applicazione di destinazione?

Un umano può ragionare su un percorso di esecuzione alla volta. Questo problema richiede ragionamenti su milioni. Lo spazio di stato è troppo grande, le interazioni troppo sottili, e il loop di feedback troppo lento per l'intuizione umana da solo. Quello che ci serve non è più mani codice di scrittura, ma un sistema che può esplorare possibilità, assorbire vincoli, e iterare a una velocità nessun team di esseri umani può abbinare. Ma quel sistema è buono quanto la realtà è costretta a obbedire.

La frontiera

Questa è la frontiera in cui il ruolo dell’ingegnere passa dalla scrittura del codice alla progettazione dei vincoli che definiscono la realtà.

In Hypercubic, crediamo che questa – la capacità di limitare la realtà per l'intelligenza artificiale – sia la capacità di definizione del prossimo decennio di ingegneria del software.

Stiamo ancora scoprendo il modo giusto per costruire questi vincoli. Richiede ragionamenti su invarianti di alto livello come la conservazione dell'equilibrio, mentre anche tracciando comportamenti di basso livello come l'ordinazione di file I/O o retries di transazione. Esso copre l'analisi del codice statico, i grafici di flusso di dati dinamici e le transazioni di ordinazione attraverso i sistemi massicciamente distribuiti.

La maggior parte dell'ingegneria del software oggi comporta incollare insieme API ben documentate o pulsanti in movimento su uno schermo. È un lavoro prevedibile e sicuro.

La modernizzazione del Mainframe è l'opposto. Richiede impegnarsi direttamente con le basi caotiche e non documentate dell'economia globale.

Stiamo finalmente raggiungendo dietro quel glorioso schermo verde per tirare la logica alla luce del XXI secolo.

Se l'idea di risolvere problemi che sono teoricamente impossibile, ma praticamente necessario appelli a voi, vogliamo incontrarvi.

Referenze

1. https://www.ibm.com/think/topics/mainframe