Qualche tempo fa vi abbiamo dato la notizia che a Zurigo, ormai conclamata fucina di innovazione tecnologica, LzLabs offriva un mainframe software defined. Unendo due grandi concetti, la società tigurina è riuscita ad attirare l’attenzione su di sé. Ma anche i dubbi, la necessità di chiarimenti, sul concetto e sulle modalità. Non ci siamo lasciati sfuggire l’occasione di chiederli direttamente al chairmand di LzLabs, Thilo Rockman.
Quando avete iniziato a pensare a un mainframe software-defined e perché?
Abbiamo lavorato sullo sviluppo di un mainframe software-defined per cinque anni. Volevamo realizzare una soluzione che potesse liberare i clienti dalle applicazioni Cobol che rallentano l’innovazione It e il cui mantenimento costa milioni di dollari, senza per forza doversi imbarcare nel lungo e complesso processo di ricompilare queste applicazioni.
Quanto avete impiegato a sviluppare una soluzione implementabile?
Ci sono serviti circa tre anni per arrivare a una soluzione implementabile che, dopo aver condotto qualche test su potenziali clienti, abbiamo scelto di sviluppare ulteriormente e infine portare sul mercato.
A chi lo avete proposto e quali feedback avete ricevuto?
Ci siamo inizialmente concentrati su clienti che operavano su workload in modalità batch, perché più immediati da segmentare e di conseguenza da migrare. La soluzione ha riscosso commenti molto positivi e ha mostrato la solidità della tecnologia, ma ci siamo subito accorti che c’erano ulteriori opportunità in tema di database e applicazioni online, che siamo andati velocemente ad integrare.
Come funziona, schematicamente?
Il software-defined mainframe opera liberando le applicazioni proprietarie dei clienti dalle interfacce di programmazione applicativa (API) datate, con un passaggio naturale dal mainframe a piattaforme Linux x86, senza dover cambiare nemmeno una riga di codice applicativo. Il processo di migrazione non richiede modifiche o ricompilazione dei formati di dati o del linguaggio di controllo, ed è in grado di trasferire tutti i principali standard applicativi proprietari, compresi online, batch e database. Questa soluzione software basata su container è l’unica che riesce a ricreare fedelmente gli ambienti primari online, batch e database, assicurando una compatibilità senza uguali e performance eccezionali e riducendo in modo sensibile i costi IT. In questo modo, siamo in grado di risolvere il classico problema dei CIO di mantenere attive le applicazioni, migliorando al tempo stesso la loro capacità di innovare.
Quali differenze ci sono con le proposte di de-mainframizzazione che vengono fatte da molti anni e che si attuano sempre con il software e la virtualizzazione?
I tradizionali strumenti di migrazione software-based presentano la necessità di ricompilare il codice COBOL in modo da poter operare su altri sistemi, come Linux, Unix. Il software-defined mainframe consente di trasferire l’applicazione senza che sia necessaria nessuna ricompilazione di codice, eliminando di fatto i rischi legati a questo processo. Storicamente, il rischio è uno dei motivi per cui le migrazioni mainframe non hanno raggiunto il successo desiderato. C’è una dose considerevole di rischio nel modificare un’applicazione in modo che possa funzionare su piattaforme diverse, quando non c’è la possibilità di accedere alle competenze di chi quell’applicazione l’ha concepita e scritta. Allo stesso modo, se si possono portare le applicazioni su nuove piattaforme, si concede alle organizzazioni la possibilità di ridurre significativamente il loro costo di possesso, e di mettersi nella posizione di far evolvere le applicazioni in modo più efficiente e di supportare le iniziative IT legate ad attività di business emergenti, come cloud e open source.
Meglio migrare in un datacenter privato o in un cloud? E che cloud? Public o hybrid?
Non è nostro compito indicare alle organizzazioni strategie IT e di business. Quello che ci interessa maggiormente è che le aziende abbiano la possibilità di scegliere dove e come intendono collocare le loro applicazioni e i loro dati. Permettiamo che questo tipo di discussione strategica abbia luogo anche in organizzazioni che sono state tradizionalmente limitate dalla tecnologia mainframe.
Quanto costa gestirlo e quanto costa usufruirne?
Il costo dell’implementazione e della gestione varia a seconda delle dimensioni e della complessità della migrazione, ma possiamo dire che gli utenti software-defined mainframe potranno sperimentare una riduzione dei costi di un ordine di grandezza.
Il mainframe storicamente è uno strumento delle banche. Vuol dire che le banche passeranno i loro dati sensibili al cloud?
È assolutamente vero che il mainframe ha una tradizione molto forte nel mercato bancario. Dopo tutto, il 70% delle transazioni commerciali al mondo vengono effettuate tramite mainframe. Si può affermare che il settore bancario nello specifico sia stato a lungo dipendente dal mainframe stesso, che è il motivo per cui tante grandi banche ancora dedicano miliardi di euro a manutenere ed a sviluppare nuove tecnologie mainframe. Ora che esiste la possibilità di migrare in modo semplice i carichi di lavoro dal mainframe su hardware standard pronto all’uso, oltre che nel cloud, le banche hanno la possibilità di prendere in esame un’infrastruttura IT molto più efficiente in termini di costi.
Vediamo una forte evoluzione della percezione del cloud in ogni mercato, compreso quello finanziario. Questo è particolarmente interessante per noi, perché il cloud comprende molte delle funzionalità RAS, ovvero reliability, availability e serviceability, che hanno definito i sistemi mainframe nel corso degli anni. Non pretendiamo che i clienti passino al cloud, ma questa sarà un’alternativa assolutamente fattibile per loro ora, come risultato del software-defined mainframe.
Poiché il software-defined mainframe non richiede modifiche al codice applicativo, il rischio legato alla ricompilazione del codice viene virtualmente azzerato. In abbinamento coi sistemi di sicurezza gestiti dai principali cloud provider, come ad esempio Microsoft Azure, le banche possono ora decidere in modo molto più consapevole se il cloud può essere un’opzione fattibile per ospitare i loro workload, cosa che in assenza di rischio, rappresenta un’opzione che non è mai stata disponibile in passato in nessun momento della storia. Le banche possono anche scegliere se operare le loro applicazioni su hardware standard basato su open source. Si tratta di libertà di scelta – avere la possibilità di liberarsi da un sistema proprietario tradizionale e, vista la differenza sostanziale nei costi di gestione se si vanno a confrontare tecnologie mainframe, cloud o hardware standard, ci aspettiamo un dibattito intenso da parte dei CIO delle banche proprio su questo tema – dibattito che finalmente ha tutti gli elementi per avere luogo.
