Migrazione da ESB Java Custom a Mule 4: una transizione efficace

Il nostro intervento si è inserito in un contesto simile: il progetto aveva l’obiettivo di migrare il vecchio ESB del cliente, Java-based, su un ESB basato su Mule 4. 

Azienda di tutela diritti d’autore

Azienda leader nel settore delle tecnologie avanzate è specializzata nella gestione e nella protezione dei diritti d'autore e delle licenze musicali. Con una lunga esperienza nel campo, offre soluzioni innovative per la raccolta e la distribuzione dei diritti, garantendo un'efficace compensazione per artisti e autori.

La sua piattaforma tecnologica all'avanguardia permette un monitoraggio preciso delle opere e una gestione trasparente delle transazioni. Con un forte impegno verso la digitalizzazione e l'ottimizzazione dei processi, questa azienda supporta il settore musicale e culturale attraverso servizi affidabili e personalizzati.

La sua rete globale di collaborazioni e partner permette di ampliare l'efficacia delle sue soluzioni a livello internazionale, promuovendo la giustizia e l'equità nel mondo dei diritti d'autore.

Il team Sensei

È utile portare l’attenzione sul metodo utilizzato per il rilascio di un sistema di tali dimensioni.

Anziché effettuare un rilascio “big-bang” che avrebbe sicuramente portato a un numero elevatissimo di disservizi, si è deciso di rilasciare ogni singola applicazione non appena avesse superato le fasi di test. Attraverso un reverse-proxy si è controllato il traffico spostandolo incrementalmente dal vecchio ESB al nuovo, dando così la possibilità alle applicazioni di continuare a essere monitorate in produzione e diminuendo la pressione sul team che ha effettuato il processo di bug-fixing.

Il progetto sviluppato

L’obiettivo del progetto era quello di migrare il vecchio ESB del cliente, implementato su un framework completamente custom basato su classi Java/Groovy, verso una nuova implementazione basata con Mule 4 che superasse i problemi sopra citati.

Anche le dimensioni del progetto erano decisamente significative: si trattava di migrare 25 API che nel complesso contavano circa 700 endpoint e gestivano più di 10 milioni di transazioni al mese.

Le fasi del progetto

Dopo un assessment iniziale e un’analisi architetturale completa, si è deciso di implementare i seguenti passi:

1. Definizione e formalizzazione dell’input e dell’output: attraverso un meticoloso e paziente lavoro di reverse-engineering si è arrivati alla redazione di uno o più documenti RAML per ciascuna API esposta, raggiungendo così l’obiettivo di documentare in maniera formale le API fornendo una base per il rifacimento dello ESB, ma anche quello di avere una documentazione che fosse riutilizzabile su nuovi progetti sia basati su mule che su altre tecnologie.
2. Revisione dei livelli architetturali: dove possibile, di concerto con il cliente, è stata fatta una ristrutturazione dell’architettura delle API in maniera che fossero conformi al paradigma API-Led connectivity, creando così dei moduli riutilizzabili anche da altre applicazioni.
3. Implementazione delle API con Mule 4: grazie a Mule 4 è stato possibile utilizzare dei pattern di integrazione standard che fossero consistenti nelle implementazioni delle diverse API; questa standardizzazione ha aumentato la governabilità e la facilità di manutenzione del sistema, favorendo la riusabilità dei componenti sviluppati. Avere utilizzato tale framework che oltre alla gestione del runtime è integrato con il suo API manager, ha sollevato, o quantomeno ha reso meno impegnativo per gli sviluppatori il doversi occupare di aspetti come ad esempio la gestione della sicurezza, o quanto relativo alla privacy in modo da essere conformi agli standard normativi.
4. Deploy su Anypoint Runtime Fabric: la scelta di utilizzare questo strumento basato su tecnologia a container ha portato enormi vantaggi in termini di scalabilità orizzontale, high availability, efficienza nello sfruttamento delle risorse e semplificazione del lavoro di gestione applicativa, mantenendo comunque i dati in casa del cliente per venire incontro ad una sua specifica esigenza.
5. Monitoraggio delle prestazioni: nella revisione del sistema di logging si è tenuto conto di annotare i tempi parziali delle fasi di elaborazione delle richieste, riuscendo così a implementare delle metriche che aiutassero a individuare e gestire i colli di bottiglia o le cause delle scarse performance degli endpoint. A titolo di esempio è stato rilevato in maniera distinta quanto tempo una chiamata spende nell’elaborazione delle sue logiche di business piuttosto che nell’attesa delle risposte dai sistemi legacy interfacciati; non è infatti raro la causa delle cattive performance sia imputata all’ESB, quando sono invece i sistemi remoti ad essere poco performanti.

Le tecnologie utilizzate

API-Led connectivity, Mule 4, API manager, Anypoint Runtime Fabric. Queste tecnologie, combinate, hanno assicurato una migrazione senza interruzioni e un'integrazione efficiente tra i sistemi legacy e le nuove architetture basate su Mule 4.

Il feedback dell’azienda

Grazie all’implementazione di regole di rewrite con una granularità a livello di endpoint e alla natura stateless delle API REST, è stato possibile effettuare il rollback verso il vecchio sistema dei singoli endpoint che hanno presentato problemi rendendo il tempo di disservizio praticamente nullo.