Architettura, vantaggi e problematiche nell’approccio a microservizi in informatica

Approccio a microservizi

Il modello di architettura a microservizi nasce per superare le limitazioni imposte dall’approccio monolitico. Il concetto di modularità già presente già nelle applicazioni monolitiche, viene ulteriormente accentuato: servizi individuali, di dimensioni ridotte ed interconnessi, sostituiscono i moduli del servizio monolitico.

Tipicamente, un microservizio gestisce un’area funzionale, cioè un insieme di funzionalità logiche tra loro attinenti. Queste funzionalità sono esposte agli altri micorservizi attraverso una API REST o altri meccanismi di comunicazione. Quindi, un micorservizio può consumare le API offerte da altri micorservizi e offrire a sua volta una propria API. Si dice che i microservizi di un’applicazione sono tra loro debolmente accoppiati (loosely coupled): un microservizio può dipendere da una API offerta da un altro microservizio, ma non dalla sua implementazione. Quindi, l’implementazione di un microservizio può essere completamente alterata senza conseguenze sugli altri, fintanto che l’API esposta non varia.

In aggiunta alle funzionalità di back end, anche un’applicazione web che svolge la funzionalità di interfaccia utente diventa un microservizio a sé stante, in grado di scambiare dati con i microservizi di back end attraverso le API da loro esposte. Anche per l’interfaccia utente può aver senso, in alcuni casi, la suddivisione delle funzionalità in più microservizi. Se ci sono diverse classi di utenti, che hanno accesso a funzionalità del tutto diverse dell’applicazione,

può risultare opportuno che ognuno abbia un servizio di front end ad essa dedicato.

In un’ipotetica applicazione di e-commerce, una possibile architettura a microservizi è quella illustrata nella figura seguente. Nel diagramma è rappresentato anche un API Gateway che costituisce un unico punto di ingresso per le API offerte dai vari microservizi di back end. In questo esempio, esso è impiegato per gestire i client mobili, ma in generale un API Gateway può essere adoperato per molteplici scopi.

Una importante caratteristica delle architetture a microservizi è la relazione tra l’applicazione e i dati. Invece di avere un unico database centralizzato, infatti, ogni microservizio è dotato di un proprio database autonomo, nel quale sono archiviati i dati ad esso relativi. Questo comporta una inevitabile duplicazione di dati che sono di interesse di più microservizi, ma è necessario per garantire l’accoppiamento lasco che caratterizza i microservizi. Se, infatti, più microservizi dovessero accedere allo stesso database, una modifica allo schema da parte di uno avrebbe impatto su tutti gli altri. Un ulteriore beneficio derivante dall’avere database esclusivi del singolo microservizio è che ogni microservizio può essere progettato per usare il DBMS più adatto ai propri requisiti e alle funzionalità che deve offrire. Si ha, perciò, quella che viene definita persistenza poliglotta.

Scalabilità e architetture a microservizi

Con il termine scalabilità si definisce la capacità di un servizio ad adattarsi all’aumentare della mole di lavoro aggiungendo risorse. Secondo il modello del Cubo della Scalabilità, un’applicazione può essere scalata lungo tre assi.

L’asse X è quello della duplicazione orizzontale. Questo tipo di scalabilità si può realizzare anche con applicazioni monolitiche e consiste nel replicare l’applicazione in più istanze dietro un load balancer. Questo ha il compito di smistare il traffico tra le varie copie dell’applicazione in modo da distribuire il carico. Questo tipo di scalabilità è semplice e veloce da realizzare, ma, come accennato nei paragrafi precedenti, tutte le copie dell’applicazione devono poter accedere a tutti i dati. Ciò comporta un costo notevole dovuto alla necessità di replicare i dati. Inoltre, non si ha scalabilità dal punto di vista organizzativo, l’applicazione resta monolitica.

L’asse Y è quello della decomposizione funzionale. Consiste nel suddividere le funzionalità dell’applicazione per verbi, cioè casi d’uso, oppure per nomi, cioè entità. L’utilizzo di architetture a microservizi è essenzialmente un’applicazione di questo tipo di scalabilità.

L’asse Z, infine, rappresenta il partizionamento dei dati. È simile alla scalabilità lungo l’asse X, con più repliche della stessa applicazione. La differenza è che il carico di lavoro è diviso in base ai dati, poiché ogni copia gestisce uno specifico sottoinsieme dei dati. Il load balancer deve quindi smistare le richieste in base ai relativi dati. Questo tipo di scalabilità è generalmente usato per le basi di dati.

Spesso le applicazioni usano una combinazione dei tre approcci per ottenere scalabilità, in quanto i singoli microservizi possono essere duplicati o anche partizionati.

Vantaggi delle architetture a microservizi

Oltre ai benefici in termini di scalabilità discussi nel paragrafo precedente, le architetture a micorservizi offrono diversi vantaggi. La maggior parte delle limitazioni e degli svantaggi dell’approccio monolitico dipendono dalla complessità che le applicazioni possono raggiungere al crescere delle funzionalità. Impiegando un’architettura a microserivizi, il problema della complessità viene superato suddividendo l’applicazione in pezzi più piccoli e quindi più semplici da gestire individualmente. In questo modo si garantisce la modularità e si risolvono molti dei problemi delle grandi applicazioni monolitiche.

La dimensione ridotta di ciascun microservizio rende il codice più semplice da comprendere e, di conseguenza, da modificare. Anche il testing di ciascun microservizio risulta più semplice, ma non il testing end-to-end.

I tempi di compilazione e di avvio sono ridotti e questo facilita la distribuzione continua, alla base dello sviluppo agile.

Aumenta anche la capacità di isolamento dei guasti. Infatti, un eventuale bug introdotto in un microservizio ha effetto solo sulle funzionalità che questo offre, invece di rendere potenzialmente inutilizzabile l’intera applicazione.

Suddividendo l’applicazione in microservizi, diventa possibile suddividere anche il lavoro degli sviluppatori in team indipendenti. Fintanto che i contratti tra i servizi sono fissati, ciascun team può lavorare autonomamente e indipendentemente dagli altri.

Infine, si ha un’elevata flessibilità nello scegliere le tecnologie e i linguaggi da utilizzare. Ogni team può progettare ed implementare il proprio microservizio con le tecnologie che ritiene più adatte, senza essere legato alle scelte altrui. Anche se un team decide di riprogettare il proprio microservizio usando nuove tecnologie, ciò può avvenire indipendentemente dal resto dell’applicazione.

Problematiche delle architetture a microservizi

Come qualsiasi altra tecnologia, le architetture a microservizi non sono una soluzione perfetta, bensì presentano degli svantaggi e gli sviluppatori che scelgono di adottarle devono affrontare una serie di problematiche.

La principale fonte di problemi nelle architetture a microservizi è la natura distribuita. Quando i moduli di un’applicazione diventano ciascuno un servizio a sé stante, bisogna affrontare il problema della comunicazione tra diversi processi, stabilendo degli appositi meccanismi. Inoltre, l’applicazione deve essere in grado di gestire l’eventualità di fallimenti parziali, ad esempio quando non si riesce a comunicare con un particolare microservizio. In contrapposizione all’approccio monolitico, dove si ha a che fare con semplici invocazioni tra diversi moduli della stessa applicazione, questo rappresenta sicuramente uno scenario più complesso da gestire.

Oltre che tecnico, il problema è anche organizzativo, in quanto è necessaria coordinazione tra i vari team. Specialmente nel caso in cui si devono aggiungere funzionalità ad un’applicazione esistente, e queste coinvolgono più microservizi tra loro dipendenti, è necessario pianificare e coordinare correttamente queste operazioni in modo da accertarsi che il deployment dell’aggiornamento di un microservizio avvenga solo dopo l’aggiornamento dei microservizi da cui esso dipende.

L’implementazione di operazioni che coinvolgono più microservizi è più complessa, specialmente considerando che ognuno di essi mantiene il proprio database e si vuole mantenere una certa consistenza tra i dati distribuiti.

Sebbene il testing individuale di ciascun microservizio sia facilitato dalle dimensioni ridotte, il testing end-to-end dell’intera applicazione, quindi delle interazioni tra i vari microservizi, è sicuramente più complesso.

Infine, le architetture a microservizi sono meno efficienti dal punto di vista del consumo di memoria. Visto che ogni servizio è un’applicazione isolata, eseguita in un un proprio container o in una propria virtual machine, molte delle dipendenze risultano replicate.

Nessuna di queste problematiche rappresenta un ostacolo insormontabile ed esistono soluzioni comprovate e pronte da essere adottate. Tuttavia, è opportuno tenere presente che gli innegabili benefici di questo tipo di architettura vengono ad un costo che la rende conveniente solo per applicazioni complesse e in costante evoluzione.

Considerazioni sull’adozione di architetture a microservizi

Le architetture a microservizi offrono una serie di benefici che le hanno rese molto popolari nel corso degli anni. Le problematiche introdotte dall’uso di microservizi, dovute principalmente alla natura distribuita, sono molteplici, ma comuni a tutte le applicazioni che implementano questa architettura. Sono quindi state sviluppate soluzioni ai principali problemi, ma la loro adozione comporta un costo in termini di complessità non indifferente. Pertanto l’uso di architetture a microservizi risulta conveniente solo per applicazioni molto grandi, dove l’approccio monolitico diventa impossibile da gestire.