Una delle ragioni che potrebbero inibire l’adozione dell’approccio Saga Pattern - che abbiamo approfondito in questo articolo - è lo sforzo aggiuntivo causato dalla necessità di implementare il sistema che ne deriva, essendo quasi assenti librerie e componenti ready-to-use per questo proposito.
Per questo motivo in Mia‑Platform abbiamo deciso di implementare un componente generico che potesse fungere da orchestratore ed essere configurato in modo semplice ed intuitivo in base al progetto specifico in cui deve essere utilizzato.
Quale approccio abbiamo scelto
Prima di parlare dell’approccio scelto è importante introdurre brevemente le variabili che hanno influito e determinato la scelta, ovvero ciò di cui avevamo bisogno.
In fase di analisi iniziale del progetto abbiamo disegnato un automa a stati finiti piuttosto complesso, che rappresentava esattamente tutti i possibili flussi che la nostra saga poteva avere, ovvero tutti i modi in cui avrebbe potuto evolversi.
A partire da tale automa abbiamo identificato i vari step del flusso della saga e gli attori (nel nostro caso i microservizi) necessari a eseguirli per portare avanti la saga.
A questo punto gli approcci a disposizione erano due:
- Events/Choreography: i microservizi si chiamano tra loro;
- Commands/Orchestrator: i microservizi comunicano con un orchestratore e non si conoscono tra loro.
Sulla scelta hanno influito diversi fattori e necessità:
- sapevamo che il flusso della saga non sarebbe stato troppo statico, ma si sarebbe evoluto nel tempo. Serviva quindi un modo per effettuare tali modifiche in modo rapido e pulito;
- volevamo che un unico attore avesse accesso in scrittura ai dati;
- volevamo che i microservizi coinvolti fossero estranei tra loro;
- generalmente premiamo l’adozione di soluzioni riutilizzabili, quindi abbiamo ragionato anche sul capire quale dei due approcci fosse più indicato.
Dati i requisiti accennati, la scelta è stata semplice. Abbiamo optato per l’approccio Commands/Orchestration e, poiché sul web non abbiamo trovato implementazioni ready-to-use di un orchestratore, abbiamo deciso di arricchire la piattaforma sviluppando un nuovo componente: il Flow Manager.
La soluzione che abbiamo scelto consiste in un microservizio che gestisce le saghe seguendo il flusso imposto da un event-driven finite-state machine, ovvero un automa a stati finiti in cui le transizioni sono innescate da messaggi. Tali messaggi sono di tipo evento e sono scambiati in modo asincrono tramite un event bus (es. Kafka).
Mia-Platform mette a disposizione sulla propria piattaforma questo componente quale orchestratore di saga facilmente deployabile e configurabile, e pienamente integrato con le altre funzionalità della piattaforma.
Utilizzare il Flow Manager di Mia‑Platform permette infatti di configurare la saga in pochi semplici passaggi. In questo modo è possibile risparmiare tempo rispetto a sviluppare una soluzione customizzata; inoltre, offre notevoli vantaggi in termini di gestione della logica di business, debugging e flessibilità in caso di evolutive o cambi di requisiti.
L’orchestratore centrale è stato sviluppato come servizio generico di piattaforma
I vantaggi sono subito evidenti. Per soddisfare le specifiche necessità di progetto è sufficiente definire il diagramma a stati finiti che descrive i possibili flussi di interazioni, e tradurlo in un semplice file di configurazione.
Inoltre, è possibile ottenere una soluzione semplice e pulita, in cui l’intera logica di business è concentrata non solo nel codice di un unico servizio - vantaggio intrinseco dell’approccio con orchestratore - ma persino in un unico file.
Aver utilizzato un componente già pronto ad essere configurato e rilasciato ci ha permesso di risparmiare notevolmente sulle tempistiche di progetto. Sviluppare da zero un microservizio che gestisca la comunicazione con gli altri componenti, porti avanti il flusso della saga e garantisca la necessaria robustezza ha un costo notevole: due mesi in più rispetto alla durata del progetto, secondo le nostre stime.
Oltre al risparmio di risorse in fase di sviluppo, un altro vantaggio che è emerso in fase di UAT è stata la flessibilità del sistema in caso di modifica dei requisiti.
Con il nostro approccio, se le specifiche di business variano, cambiare il flusso, una volta predisposti gli attori coinvolti, comporta poche modifiche e adattamenti, ovvero:
- modificare la logica isolata del servizio / dei servizi coinvolti;
- modificare il file di configurazione dell’orchestratore
In caso di sola modifica al flusso, senza impattare la logica, potrebbe essere sufficiente anche modificare il solo file di configurazione, senza entrare nel codice.
Questo evita quindi di dover entrare nel codice dell’orchestratore, ricomporre il flusso preesistente, applicare la modifica e gestire esplicitamente gli aspetti di comunicazione con gli altri servizi: operazioni che sarebbero state necessarie se avessimo utilizzato un orchestratore implementato ad-hoc per gestire lo specifico flusso.
Ad esempio, se si volesse aggiungere una fase nella saga - poniamo la verifica dei dati dell’utente - l’approccio classico richiederebbe di entrare nel codice, verificare dove inserire questo nuovo passaggio e modificare l’intero flusso.
Diversamente, con l’approccio proposto in Mia‑Platform, una volta predisposti gli attori coinvolti dalla modifica, è sufficiente cambiare un file di configurazione aggiungendo il nuovo step.
Questo approccio propone una semplificazione degli interventi di modifica richiesti, con un notevole risparmio di tempo e risorse.
Quanto è semplice configurare la nostra saga?
Con il flow-manager, tutto ciò che serve per orchestrare la nostra saga è:
- aggiungere il plugin flow-manager:
- descrivere il flusso nell’apposito file di config map:
Per saperne di più sul Flow Manager consulta la nostra documentazione ufficiale e scopri come configurare il file json dell’automa a stati finiti.
Conclusioni
Con il progressivo abbandono dell’approccio monolitico e il passaggio al mondo dei microservizi, talvolta caotico, si fa sempre più pressante l’esigenza di mantenere il controllo e la visibilità su tutto ciò che accade.
In Mia-Platform abbiamo affrontato questa tematica anche nell’ambito dell’aggiornamento dei dati, della loro consistenza in un sistema distribuito e della loro completa gestione anche in caso di errori, scoprendo ed utilizzando il Saga Pattern come soluzione ottimale per gestire il problema e arricchire la piattaforma.
Articolo scritto da Francesco Francomano, Senior Full Stack Developer, e Giuseppe Manzi, Full Stack Specialist.
© MIA s.r.l. Tutti i diritti riservati