In questi anni, il processo di trasformazione digitale ha fatto evolvere in maniera molto rapida la tecnologia software: di conseguenza, nelle imprese, l’application modernization di applicazioni esistenti, spesso datate ma ancora valide e funzionanti, pur rappresentando in molti casi una strategia faticosa e rischiosa da attuare, è diventato un imperativo categorico per riuscire a mantenere le applicazioni stesse al passo con i tempi, e abilitarle a beneficiare delle nuove funzionalità e servizi resi disponibili dal cloud.
Cos’è la application modernization
Ciò premesso, fare application modernization significa sviluppare un progetto in grado di analizzare il parco delle applicazioni legacy aziendali, e poi di pianificare, di volta in volta, per ciascuna applicazione, la strategia di aggiornamento migliore per integrare le funzionalità più moderne e recenti: funzionalità che consentono alle organizzazioni d’innovare i propri servizi e di rispondere con più efficacia ed efficienza alle esigenze e richieste dei clienti, creando nuovo valore di business.
Il problema però è che i sistemi e applicazioni legacy, ancora largamente presenti nelle varie organizzazioni, sono spesso basati su un’architettura software monolitica, costosa da manutenere, poco flessibile, difficile e complessa da modificare e scalare, se non spendendo tempo e denaro in lavoro di riscrittura del codice. Fare application modernization oggi significa quindi, ove possibile, eliminare la rigidità di queste applicazioni legacy monolitiche, migrando verso strategie d’implementazione di applicazioni cloud-native, in grado di sfruttare gli intrinseci vantaggi di flessibilità e agilità nell’uso delle risorse IT che la nuvola è in grado di fornire, slegando il software dalla stretta appartenenza a un’infrastruttura hardware sottostante.
Per tecnologie cloud-native si intendono, parafrasando la definizione della Cloud Native Computing Foundation (CNCF), quelle che permettono di sviluppare e gestire applicazioni in ambienti IT moderni e dinamici, come i cloud privati, pubblici, ibridi: esempi di questo approccio, indica la CNCF, sono i container, la mesh di servizi, le architetture di microservizi, le API (application programming interface) dichiarative, l’infrastruttura immutabile (nella quale i server non vengono mai modificati dopo il loro deployment. Se qualcosa deve essere aggiornato, riparato o modificato in qualche modo, vengono forniti nuovi server creati da un’immagine comune con le modifiche appropriate per sostituire quelli vecchi. Dopo essere stati convalidati, vengono messi in uso e quelli vecchi vengono disattivati)
A cosa serve: trasformare applicazioni monolitiche
Evidenziando alcuni aspetti tecnici, emerge più chiaramente quale sia la funzione della application modernization oggi: essa, in qualità di approccio innovativo allo sviluppo software, ha un impatto sulla trasformazione digitale dell’intera attività di business di un’organizzazione e, come accennato, l’obiettivo chiave di trasformare, dove ciò sia praticabile, applicazioni caratterizzate da architettura monolitica in applicazioni cloud-native basate su microservizi.
Nelle applicazioni enterprise tradizionali, monolitiche, i diversi componenti (database, livello di presentazione, logica di business) risultano strettamente integrati tra loro in un singolo programma. Ad esempio, un’architettura monolitica per un’applicazione di commercio elettronico include vari componenti strettamente interconnessi e interdipendenti: l’interfaccia web per i clienti dello store online, i servizi di back-end per il controllo dei prodotti a magazzino, il sistema di autorizzazione e addebito dei pagamenti. Un altro classico esempio di applicazioni monolitiche legacy sono quelle scritte in linguaggio COBOL negli anni Settanta e Ottanta, costituite anche da milioni di linee di codice e installate nei sistemi mainframe per gestire operazioni e transazioni in ambito bancario e assicurativo.
Nelle architetture monolitiche il principale svantaggio è la stretta integrazione dei componenti, che rende difficile la manutenzione del software, perché, ad esempio, una modifica nel codice di un componente implica un aggiornamento, e test completo, dell’intera applicazione, prima della sua successiva distribuzione nell’ambiente di produzione. Ciò limita l’agilità dei servizi IT e la capacità di innovarli rapidamente. Un altro svantaggio è la difficoltà di scalare l’applicazione in rapporto a picchi di richieste, perché anche in questo caso occorre ridimensionare l’intera architettura. In aggiunta, bisogna anche considerare che, con l’approccio monolitico, il manifestarsi di un bug, un errore, in un singolo processo condiziona il funzionamento degli altri componenti e processi correlati, e ciò influisce negativamente sulla disponibilità dell’applicazione.
Perché i microservizi
Una strategia di application modernization indirizzata a far migrare l’applicazione verso un’architettura basata sui microservizi permette di scomporre l’applicazione stessa in componenti modulari e indipendenti. Ogni componente può eseguire un processo come servizio e ciascun servizio comunica con gli altri tramite API. Con questa architettura, quando eseguono aggiornamenti software, gli sviluppatori possono lavorare su singoli componenti e in ambiti ben definiti, riducendo i tempi di progettazione e velocizzando i cicli di rilascio dell’applicazione. I microservizi supportano anche le strategie di integrazione continua e distribuzione continua (CI/CD) del software, alla base del modello DevOps, che permettono d’innovare i progetti a ritmi non raggiungibili utilizzando il tradizionale paradigma di sviluppo ‘waterfall’.
Inoltre, ogni servizio può essere scalato in modo indipendente, e distribuito su più server e infrastrutture, in funzione delle necessità contingenti dell’organizzazione. Ancora, se si verifica un errore in un componente, questo non causa il rallentamento o il blocco dell’intera applicazione, come può succedere nei sistemi monolitici.
Application modernization: come fare, 4 approcci
Le vie possibili per modernizzare le applicazioni, e farle migrare verso il paradigma cloud, possono essere comunque differenti. Anche perché, quando occorre risolvere una sfida con un’applicazione legacy, il miglior approccio da seguire dipende dal problema che si sta cercando di risolvere, precisa la società di analisi di mercato Gartner, sottolineando che “la application modernization non è una ‘cosa’ “ e “la sostituzione non è la sola opzione”.
Ad esempio, nel caso di un’applicazione mainframe ancora funzionante, sviluppata molti anni fa in ambiente COBOL/CISCS, il problema è la carenza di competenze che si viene a creare con l’avvicendamento del personale destinato a supportarla: qui, la soluzione per modernizzare questa applicazione business-critical può essere farla migrare in un ambiente cloud, dove sono disponibili tecnologie e personale tecnico in grado di gestirla.
In tema di approcci alla application modernization, esistono diverse strade possibili da percorrere (encapsulation, rehosting, replatforming, refactoring, rearchitecting, rebuilding, replacement), spiega Gartner, precisando che la chiave è comprendere se il problema è causato dalla tecnologia, dall’architettura o dalle funzionalità dell’applicazione, e in che misura ciascun approccio di modernizzazione migliora tali aspetti.
Supponendo di dover modernizzare un’applicazione legacy che gira on-premise su server fisici o macchine virtuali (VM) installati nel data center aziendale, vale la pena soffermarsi su almeno quattro di questi approcci:
- Un primo approccio è il rehosting, conosciuto anche come “Lift and shift”, ossia una tecnica che consiste nel reimplementare un’applicazione, e i dati ad essa associati, su un’altra infrastruttura, fisica, virtuale, cloud, senza doverne ricompilare, alterare il codice, o modificare le caratteristiche e funzioni. Nell’esempio in questione, i server fisici o le VM esistenti on-premise possono essere ‘ri-ospitati’ utilizzando servizi IaaS (infrastructure as a service) di fornitori cloud.
- Un secondo approccio può essere il refactoring, cioè la ristrutturazione e ottimizzazione del codice esistente, senza alterare il comportamento esterno del sistema, per rimuovere il debito tecnico e migliorare le funzionalità e la struttura interna dell’applicazione: il refactoring può consentire di ridurre la complessità del codice, semplificandone la struttura e facilitandone la manutenibilità. Inoltre, esso permette all’applicazione di girare nel cloud e di sfruttare servizi cloud-native, come i database gestiti o le architetture serverless.
- Un terzo approccio è il rebuilding, ossia la riscrittura dell’applicazione da zero, conservandone le funzionalità e le specifiche. Ad esempio, è possibile riscrivere una tradizionale applicazione legacy monolitica, scomponendola in microservizi o architetture serverless, utilizzando i servizi cloud basati sul paradigma PaaS (platform as a service).
- Un quarto approccio è il replacement dell’applicazione esistente, cioè la sua sostituzione con un’altra, in grado di rispondere meglio ai nuovi requisiti e necessità aziendali e, ad esempio, fruibile in modalità SaaS (software as a service).
Servizi, strumenti e tecnologie di application modernization
Premesso che ciascuno degli approcci di modernizzazione applicativa illustrati porta con sé vantaggi e svantaggi, va comunque aggiunto che, considerando i benefici in termini di tempo, denaro, risorse risparmiate, e l’efficienza ottenuta nello sviluppo applicativo, le iniziative di application modernization non sono strategie accessorie, ma progetti indispensabili per trasformare le applicazioni legacy, e il modo in cui sono sviluppate e manutenute.
E qui, come si è visto, è possibile utilizzare servizi e strumenti di application modernization che spaziano dalle tecnologie cloud IaaS, a quelle PaaS, ai contenitori, agli orchestratori di container come Kubernetes. La ‘containerizzazione’ delle applicazioni legacy permette di renderle portabili e sicure, senza alterarne il codice. In aggiunta, i container permettono di sviluppare applicazioni cloud-native e di adottare i modelli di sviluppo DevOps e CI/CD. Ancora, i container costituiscono gli strumenti ideali per sviluppare singoli microservizi e la service mesh che li interconnette.
DataOps e la gestione collaborativa dei dati
Nell’ultimo decennio le organizzazioni hanno iniziato a sperimentare sistemi finalizzati a sviluppare, implementare e integrare una vasta gamma di soluzioni eterogenee atte a semplificare la trasformazione dei dati in modo da abilitare una business intelligence altamente funzionale ed efficace. Oggi le aziende raccolgono i frutti di tutte queste passate sperimentazioni. Ogni impresa, grande o piccola, con un gran team IT o presidiata da pochi esperti oggi è in grado di trasformare velocemente i dati in informazioni altamente scalabili.
Questa trasformazione del Big Data Management si deve a due fattori.
- Uno è l’evoluzione della mentalità Agile e la definizione di un framework a supporto dei dati che triangola e risolve approccio, implementazione e richieste mediante la DataOps.
- L’altro legato allo sviluppo di una serie di scoperte tecnologiche che rendono la gestione dei dati end-to-end non solo possibile, ma anche più sicura, più veloce e decisamente più utile.
Modellata sull’onda montante del DevOps, l’ascesa della DataOps è il risultato di una reingegnerizzazione della gestione dei dati incentrata sulla creazione di un valore aggiunto.
L’approccio Agile di DataOps, sovralimentato dalle potentissime piattaforme di ultima generazione e a strumenti di gestione dei dati, garantisce massimo beneficio dai dati.
Indipendentemente dalle loro dimensioni, oggi tutte le aziende hanno a disposizione la metodologia e la tecnologia necessarie per:
- trattare i dati su larga scala
- attivare le loro pipeline di dati
- offrire alle loro persone e alle imprese il vantaggio di una intelligenza che fa davvero la differenza
Gestire la transizione: trovare system integrator con competenze focalizzate
Come si è potuto comprendere in questo articolo, il processo di trasformazione digitale, attuabile attraverso una strategia di application modernization, non può compiersi semplicemente seguendo un percorso univoco di migrazione tecnologica, in quanto ciascuna organizzazione possiede un differente parco applicativo ed esigenze di business specifiche.
In questo viaggio è dunque importante avvalersi anche di system integrator con precise competenze, in grado di amministrare, in coordinamento con l’azienda utente, la delicata transizione che sposta il baricentro della direzione IT, dalla gestione della tradizionale complessità tecnologica all’interno del data center, verso il ruolo di esperto gestore dei contratti cloud, mano a mano che l’organizzazione in questione adotta i moderni paradigmi IaaS, PaaS e SaaS. System integrator, quindi, con capacità e competenze oggi ancora non ordinarie e diffuse, ma indispensabili per accompagnare e aiutare i manager dell’IT a compiere un cruciale ‘cambio di pelle’ nel processo di evoluzione delle proprie competenze professionali verso il modello cloud.
