Modernizzazione dei sistemi legacy con Mia‑Platform

In un contesto Enterprise, spesso ci si ritrova ad avere in “eredità” sistemi legacy e soluzioni obsolete figlie di un’altra epoca tecnologica o di adattamenti, modifiche e forzature susseguitesi nel tempo; come se non bastasse, queste situazioni si incontrano spesso nell’ambito di quei sistemi IT cruciali per il business e per i quali le aziende storicamente sono più restie ad apportare cambiamenti.

Tuttavia, oggi modernizzare alcuni punti nevralgici dei sistemi IT aziendali può risultare determinante per una strategia di crescita e competitività a lungo termine: l’evoluzione continua dell’infrastruttura e delle tecnologie coinvolte è la chiave per garantire una reale efficienza dei processi e dei servizi offerti.

Le soluzioni di mercato

La risposta a questa esigenza di modernizzazione dei sistemi legacy arriva dal mercato: l’offerta di soluzioni sofisticate e all’avanguardia è sempre più ampia. Affidarsi a una soluzione di mercato comporta numerosi benefici – anche economici – di lungo periodo.

Il primo beneficio è indubbiamente l’opportunità di dotarsi di un sistema solido, affidabile ed evoluto che permette di migliorare prestazioni e governance dell’offerta di prodotti e servizi aziendali.

Inoltre, spicca il vantaggio di poter usufruire degli ultimi aggiornamenti tecnologici: le piattaforme di orchestrazione di servizi e applicazioni garantiscono l’accesso alle più moderne tecnologie, spesso amministrate in modalità open source. In questo modo, l’azienda avrà accesso alle tecnologie più performanti sul mercato, garantite da aggiornamenti e manutenzione costanti.

Per quanto riguarda il beneficio economico, si tratta sicuramente di un investimento iniziale considerevole, ma che permette di risparmiare sul lungo periodo in termini di costi di realizzazione di nuove applicazione e servizi, time to market degli stessi, e manutenzione dell’architettura applicativa.

Infine, la possibilità di far evolvere in modo semplice e rapido la propria architettura al crescere e al mutare delle esigenze di business, permette all’azienda di rispondere in maniera efficace alle necessità in continua evoluzione dei clienti.

Un esempio di successo: la trasformazione di una grande assicurazione

In qualità di principali abilitatori digitali, Mia‑Platform si è trovata ad affrontare la migrazione del sistema IT di un importante gruppo assicurativo italiano.
L’azienda, già cliente di Mia‑Platform da alcuni anni, ha presentato la necessità di migrare i propri sistemi IT con l’obiettivo di migliorarne la manutenibilità, la governance e la robustezza nel lungo periodo.

Il progetto, avviato nel giugno 2020 e concluso nel settembre dello stesso anno, riguarda il processo di gestione delle scatole nere per i clienti assicurati. I processi coinvolti vanno dalla vendita e l’installazione dei dispositivi, al recupero delle metriche rilevate dagli stessi.

Nello specifico, il nostro obiettivo è permettere ai vari sistemi coinvolti di passare da una comunicazione asincrona, basata su scambio di flussi batch, ad una comunicazione via API REST ed event-based. La natura del particolare prodotto assicurativo erogato attraverso tale sistema richiede che l’asincronicità della comunicazione tra il provider delle scatole nere e le agenzie assicurative venisse mantenuta, pur dismettendo la vecchia infrastruttura basata su scambio di file in FTP.

La soluzione che abbiamo messo in atto si divide in due parti: da un lato introdurre Apache Kafka nell’infrastruttura del progetto, mentre dall’altro trasformare l’intera codebase da monolite a microservizi, che si interfacciano con i vari touchpoint via API REST.

Per illustrare meglio la soluzione adottata, descriviamo di seguito uno dei flussi principali del progetto migrato, cioè quello della vendita delle scatole nere.

Il flusso di vendita

Gli attori coinvolti nel flusso di vendita sono tre :

• Le agenzie che si occupano della vendita delle polizze ai clienti
• Il fornitore delle scatole nere che si occupa di gestire l’installazione e il recupero delle metriche di guida dei clienti.
• Il CRM per il monitoraggio dell’intero processo di vendita

Il ruolo di Mia-Platform in questo contesto è quello di mediare la comunicazione tra i tre attori e salvare su un database MongoDB tutti gli scambi che avvengono tra le parti coinvolte.

Il flusso legacy consisteva nei seguenti passaggi:

• L’agenzia invia una richiesta di creazione di contratto a seguito della vendita di una nuova polizza;
• Il fornitore riceve a fine giornata, tramite flussi FTP, l’elenco di tutti i contratti venduti per quel giorno;
• Per ogni contratto, il fornitore, dopo aver verificato la correttezza dei dati, comunica l’identificativo della relativa scatola nera attraverso un nuovo flusso FTP;
• Il fornitore avvia il processo di installazione delle scatole nere e comunica i vari stadi dell’installazione;
• Ogni comunicazione tra il fornitore e le agenzie viene notificata al CRM.

Nella vecchia soluzione il ruolo di mediazione consisteva nel fornire le API REST alle agenzie di vendita e nello schedulare i jobs per processare i file scambiati via FTP.

Il nuovo flusso, invece, si articola come segue:

• L’agenzia invia una richiesta di creazione di contratto a seguito della vendita di una nuova polizza;
• Il fornitore riceve in real-time la richiesta per ogni singolo contratto, rispondendo immediatamente con un segnale Acknowledge che indica la presa in carico della richiesta;
• Per ogni contratto, il fornitore, dopo aver verificato la correttezza dei dati, comunica all’agenzia l’identificativo della relativa scatola nera attraverso una nuova chiamata REST;
• Per ognuna di queste comunicazioni via API viene prodotto un evento su Kafka che verrà consumato da un servizio che si occupa esclusivamente di notificare il CRM.

L’utilizzo di un message broker come Kafka ci permette di:

• Trasformare il sistema di notifiche al CRM da un insieme di script schedulati a fine giornata ad un sistema real-time basato su eventi;
• Automatizzare la gestione degli errori, togliendo ai tecnici IT l’onere di controllare manualmente a fine giornata il corretto allineamento dei sistemi coinvolti;
• Centralizzare il passaggio delle informazioni del sistema in un unico punto, con la naturale conseguenza di poter agevolmente collegare strumenti di monitoring che permettono la consultazione delle intere transazioni asincrone;

I principali vantaggi di passare dalla comunicazione a flussi FTP a quella ad API REST sono:

• Aumentare la reattività del sistema fornendo sempre un feedback immediato ai client, anche per quelle operazioni che seguono un percorso asincrono;
• Utilizzare dati in formato JSON che permettono di evitare il parsing di file CSV, riducendo di molto la complessità del codice.

Strategia di migrazione

La modernizzazione di sistemi legacy è, solitamente, un progetto molto delicato in quanto coinvolge alcuni componenti critici per il business dell’azienda. La sostituzione improvvisa e tutta in una volta del vecchio sistema introdurrebbe, quindi, un rischio operativo inaccettabile. D’altre parte, più è grande la portata dell’intervento, maggiore è la probabilità di introdurre dei malfunzionamenti, con ripercussioni più o meno gravi sull’intero processo coinvolto.

Di conseguenza, i sistemi legacy devono essere migrati in modo incrementale: inizialmente il sistema è costituito interamente da codice legacy; man mano che l’incremento viene implementato, testato e rilasciato in produzione, la percentuale di codice legacy diminuisce progressivamente fino alla fine della migrazione.

Una buona strategia di migrazione deve garantire che il sistema resti completamente funzionante durante tutto lo sforzo di modernizzazione.

Nella fase iniziale di analisi è fondamentale riuscire a scomporre in più parti il sistema, così da poter definire e programmare gli incrementi. Nel caso in esame, ad esempio, la prima macro-divisione individuata è quella tra la parte di vendita delle scatole nere e la reportistica dei sinistri rilevati. All’interno di queste due aree di business abbiamo ulteriormente suddiviso il dominio: per la parte di vendite, ad esempio, distinguiamo il flusso di creazione di un contratto da quello degli aggiornamenti del suo stato.

Una volta scomposto a dovere il dominio applicativo, si può iniziare a pianificare la strategia di migrazione. Il caso di studio ci ha portati a fare una separazione logica importante tra le operazioni di lettura e quelle di scrittura.

In definitiva, la strategia di migrazione scelta è la seguente:

• Per ogni incremento, abbiamo mantenuto in produzione sia il sistema vecchio sia quello nuovo;
• In fase di scrittura, entrambi i sistemi sono funzionanti;
• Le operazioni di lettura continuano ad avvenire sul vecchio sistema durante tutto il periodo di collaudo;
• Al termine del collaudo il vecchio sistema viene spento e sia le operazioni di lettura sia quelle di scrittura avvengono sul nuovo sistema.

Questa metodologia di migrazione ci consente di collaudare in produzione il nuovo sistema in modo silente, diminuendo drasticamente il rischio per il business.

L’architettura a microservizi ed API proposta da Mia-Platform ha abilitato l’implementazione di questa strategia.

A livello tecnico, infatti, abbiamo implementato un microservizio generico, chiamato requests-duplicator, da cui far passare tutte le richieste di scrittura. Questo componente, leggendo una configurazione in input, duplica le richieste http in ingresso, inoltrandole a più di un sistema (due nel nostro caso: il sistema legacy e la sua versione modernizzata).

Il requests-duplicator restituisce al client la risposta del sistema master (indicato nella sua configurazione) ignorando le risposte degli altri sistemi.

Un altro grosso vantaggio di questo approccio è quello di poter cambiare il sistema master con un semplice flag di configurazione, rendendo più agevoli sia la promozione a master del nuovo sistema, sia eventuali rollback.

Il modello dati

Come accade in quasi tutti i progetti di modernizzazione dei sistemi legacy, anche noi abbiamo dovuto rivedere il modello dati. Infatti, se la tecnologia resta la stessa (MongoDB), la struttura del modello dati cambia.

Questo ci mette di fronte a due ulteriori problemi:

• mantenere invariate le interfacce delle API esposte verso le agenzie;
• migrare i dati contenuti nelle collezioni della vecchia base dati su quella nuova.

Il primo problema è risolvibile implementando dei microservizi che mappano il vecchio modello sul nuovo in fase di scrittura e viceversa in fase di lettura.

Per il secondo problema, invece, abbiamo scelto di utilizzare delle pipeline automatizzate che popolano la nuova base dati a partire dalla vecchia. Il vantaggio principale di utilizzare una pipeline per questo tipo di operazioni è quello di poterla collaudare in ambiente di pre-produzione, cambiando solo variabili d’ambiente come la stringa di connessione al database.

Conclusione

Come abbiamo visto, i progetti di migrazione dei sistemi legacy sono complessi e articolati e presentano alcune criticità da tenere in considerazione. Per questo, noi di Mia‑Platform prediligiamo un approccio incrementale, che permette di mantenere l’operatività del sistema in tutte le fasi della migrazione.

Nel caso appena raccontato, ad esempio, la particolare natura del prodotto e il ruolo indispensabile dei sistemi richiedevano un’attenzione ancora maggiore per garantire il funzionamento continuo di tutte le parti del sistema e assicurare la continuità del servizio.

L’utilizzo dell’ecosistema di prodotti e strumenti di Mia‑Platform ha permesso al team, composto da sole 4 persone non impegnate sul progetto a tempo pieno, di accelerare notevolmente i tempi di migrazione e sviluppo, mantenendo al contempo una visibilità completa e una governance chiara dei processi.

In particolare, gli strumenti Mia‑Platform che si sono dimostrati particolarmente vantaggiosi in questo progetto sono:

• Mia-Platform Marketplace, un Service Catalog che offre un’ampia gamma di template da cui partire per implementare nuovi microservizi che si interfacciano con Kafka. L’utilizzo di questi template semplifica notevolmente l’implementazione dei consumer e dei producer;
• L’API Gateway che consente di integrare velocemente i nuovi microservizi in un progetto già esistente, e risulta particolarmente utile per configurare il componente request-duplicator;
• Mia-Platform Console, un’Internal Developer Platform che permette di ridurre ulteriormente i tempi di sviluppo fornendo una comoda interfaccia grafica da cui creare i nuovi servizi, configurare le varie rotte e impostare una suite di test e2e.

Alla conclusione del progetto, abbiamo consegnato nelle mani del cliente un sistema moderno, efficiente, veloce e sicuro, che potrà essere facilmente gestito e controllato dagli operatori dell’azienda, grazie all’utilizzo della Suite di strumenti di Mia‑Platform.

Articolo scritto da Nastassja Bellisario, Full Stack Expert, e Luca Scannapieco, Solutions Architect di Mia‑Platform.