Introduzione

Spesso quando si vuole realizzare una nuova applicazione o si vuole reingegnerizzarne una esistente si pensa a una architettura a microservizi. Questo tipo di soluzione è emersa negli ultimi anni come risposta a una serie di problemi come la scalabilità o la possibilità di consentire un processo di sviluppo più agile. La sua adozione porta con sé una serie di requisiti sia di processo che organizzativi che devono essere valutati in maniera approfondita. Lo scopo di questo articolo è fornire una panoramica dell’architettura a microservizi e dei requisiti per poterla utilizzare in maniera proficua.

Cos’è una architettura a microservizi?

Prima di approfondire le implicazioni legate alla realizzazione di una architettura a microservizi è opportuno darne una definizione per stabilire un “terreno comune”. Come già visto in un precedente articolo del blog, con il termine microservizi “si identifica un nuova tipologia architetturale con la quale progettare applicativi software”. Se si cerca una definizione più dettagliata, si vedrà che non ne esiste una univoca (cfr. Wikipedia) ma piuttosto si nota una visione condivisa.

A livello pratico, le principali caratteristiche che definiscono i microservizi sono:
• Comunicazione tramite protocolli di rete standard come per esempio http
• Rilascio e aggiornamento in maniera autonoma
• Realizzazione e raggruppamento per funzionalità applicative
• Realizzazione con tecnologie a seconda delle conoscenze/esigenze dei gruppi di lavoro
• Piccole dimensioni, gestione da parte di un solo gruppo di lavoro e rilascio in modo automatico (ovvero tramite software di continuos delivery)

Le architetture monolitiche

Per comprendere meglio gli impatti dell’architettura a microservizi è utile descrivere il modello di sviluppo di cui si vogliono risolvere i problemi, ovvero l’architettura monolitica.

Un prodotto monolitico è unico, rilasciabile con un processo e delle cadenze ben definite. L’approccio monolitico, che fino a qualche anno fa era considerato quello “di riferimento”, prevede una serie di rilasci cadenzati che avvengono secondo un piano ben preciso, di solito su base mensile o tempi ancora più lunghi. Il gruppo di lavoro pianifica le date dei rilasci e le funzionalità da realizzare. Se lo sviluppo di un componente non riesce a rispettare le scadenze il suo rilascio viene rimandato alla scadenza successiva.

Oltre ad avere delle date di aggiornamento fisse, l’architettura monolitica prevede un rilascio di tutto il software, non solo della parte modificata. Si consideri ad esempio un Internet Banking costruito in maniera monolitica: se si sviluppa una nuova funzionalità sui bonifici ( richiesta per esempio da un cambio di normativa fiscale) viene rilasciato tutto, comprese parti non interessate dalla modifica (per esempio la lista delle spese della carta di credito o i pagamenti F24 per i tributi). Volendo fare un paragone culinario, adottare una architettura monolitica è come ordinare al ristorante un tris di primi o una grigliata mista: il piatto viene servito solo quando tutte le pietanze sono pronte.

Un altro aspetto che caratterizza questo modo di sviluppare software è che eventuali problemi di prestazioni si ripercuotono su tutto l’applicativo. Per esempio, in concomitanza di una scadenza fiscale si può assistere ad un incremento notevole di invio di modelli F24; se si considera l’Internet Banking monolitico descritto in precedenza, quando il carico di lavoro supera le capacità elaborative disponibili l’impatto si ripercuote su tutto l’applicativo, impedendo agli utenti anche la consultazione dei movimenti o l’esecuzione dei bonifici. Un altro esempio potrebbe essere un sito di ecommerce che offre un prodotto molto richiesto ad un prezzo decisamente conveniente: se tantissimi utenti provano a ordinarlo saturando la capacità di risposta e il sito è realizzato con una architettura monolitica, l’impatto si ripercuote anche sugli utenti che stavano comprando altri prodotti.

Se si considera il processo di realizzazione del software come elemento base per rispondere sempre più velocemente ai picchi di carico, alle esigenze delle nuove normative, del mercato e degli utenti, gli aspetto critici delle architetture monolitiche appaiono chiari.

I vantaggi dei microservizi

In riferimento all’architettura monolitica, i vantaggi dei microservizi sono evidenti:
• ogni microservizio è indipendente dagli altri e quindi ha proprio un ciclo di sviluppo
• un microservizio ha dimensioni e complessità molto inferiori rispetto al monolite e quindi consente tempi di aggiornamento molto minori
• ogni microservizio è isolato dagli altri: un eccesso di carico sul singolo componente non influisce su tutti gli altri.

È importante sottolineare l’aspetto di indipendenza di un servizio dagli altri così come la sua dimensione. Due microservizi, per esempio, non possono condividere gli stessi dati sul database, in quanto in caso di malfunzionamento di quest’ultimo il disservizio non è isolato.
I riscontri dal punto di vista pratico sono innumerevoli e hanno consentito ai microservizi di imporsi come riferimento per le nuove soluzioni. Il successo della nuova architettura rischia però di mettere in secondo piano che cosa serve veramente per adottarla in maniera proficua.

Le implicazioni di una architettura software a microservizi

I microservizi sono una soluzione a una serie precisa di problemi, ma per essere adottati necessitano di un cambiamento che va oltre il reparto di sviluppo.

Si consideri, per esempio, un gruppo di lavoro che riceve il compito di reingegnerizzare prodotto esistente – realizzato in maniera monolitica – che ha necessità di:
• aggiornamenti frequenti, almeno una volta a settimana (se non una volta al giorno);
• gestire i picchi di carico, che si concentrano in particolari periodi dell’anno;
• rendere i gruppi di sviluppo più indipendenti fra di loro.
L’architettura a microservizi ha tutte le carte in regola per essere la soluzione e quindi il gruppo di lavoro si mette all’opera per modificare l’applicazione in modo che risponda ai requisiti elencati.

Se l’applicazione da monolitica viene divisa in 100 microservizi è possibile:
• aggiornare il singolo servizio senza coinvolgere gli altri;
• sviluppare più velocemente in quanto il singolo servizio ha dimensioni molto ridotto rispetto all’interno prodotto;
• dimensionare i server per microservizio.
In teoria è possibile soddisfare tutti i nuovi requisiti e quindi il gruppo di sviluppo avvia l’attività.

Nel momento in cui si cominciano i primi test cominciano le interazioni con gli altri gruppi ed il gruppo di sviluppo chiede a quello sistemistico di predisporre:
• l’hardware e le tecnologie software per ospitare i 100 microservizi
• le procedure affinché i microservizi possano essere rilasciati automaticamente in produzione
• le modifiche all’infrastruttura di rete affinché le chiamate che prima arrivavano al componente monolitico siano dirette ai nuovi servizi
• le modifiche all’infrastruttura di back-up per i nuovi requisiti di salvataggio dei dati.
Se i reparti sistemistici/di rete sono completamente a digiuno sulle architetture a microservizi, si troveranno di fronte ad una prospettiva di radicale cambiamento nel loro modo di lavorare e vorranno gestire tempi, modi e costi dell’operazione. Se il gruppo di sviluppo e quello delle infrastrutture hanno due responsabili diversi è molto probabile che sorga un conflitto di obiettivi creando ritardi al progetto.

L’esempio precedente, anche se un po’ estremizzato, dovrebbe aver reso l’idea che quando si parla di architettura a microservizi il cambiamento deve coinvolgere tutti i gruppi IT dell’azienda e quindi va adottato e portato avanti coinvolgendo tutti gli attori fin dall’inizio. La nuova soluzione deve essere abbracciata da diversi gruppi di lavoro fra cui:
• Progettazione/architettura software
• Realizzazione software
• Test
• Installazione del software
• Reti informatiche
• Project manager/Responsabili coinvolti

Check list di adozione

Una semplice checklist consente di effettuare una prima verifica se l’azienda è pronta per lo sviluppo di un prodotto a microservizi:
1. L’azienda ha adottato strumenti o procedure per il deploy automatico (a seguito di un commit sul repository dei sorgenti) degli applicativi nei vari ambienti (sviluppo, test, produzione)?
2. L’azienda ha adottato un processo di test automatico a supporto del processo precedente?
3. L’azienda ha adottato un processo che definisce le operazioni (test automatici, verifiche dei prerequisiti, etc) da eseguire per eseguire un deploy in produzione?
4. L’azienda ha adottato strumenti per configurare, gestire e monitorare centinaia o migliaia di applicativi (es. Docker e Kubernetes)?
5. Le persone in azienda sono formate sulle implicazioni di una architettura a microservizi come container, gestione di transazioni distribuite?

Nel caso le risposte siano tutte affermative è possibile procedere con l’adozione della nuova architettura, diversamente è necessario valutare gli impatti di ogni singolo punto.

Conclusioni

L’architettura a microservizi consente di ottenere degli applicativi scalabili, performanti e facilmente aggiornabili. Non può però essere vista solo come un nuovo modo di progettare/realizzare software, ma come un processo che coinvolge tutte le componenti IT dell’azienda. I cambiamenti richiesti dalla sua adozione vanno valutati attentamente in termini di processi, competenze e infrastrutture da potenziare/acquisire.