Caratteristiche, funzionamento e vantaggi dell’Architettura a Microservizi in informatica

Architettura a Microservizi

In informatica, come sappiamo le applicazioni di tipo Enterprise sono generalmente costituite da tre componenti principali:

1. interfaccia lato client;
2. database;
3. applicazione lato server.

Operazioni come richieste http, l’esecuzione della logica di dominio, il recupero e aggiornamento dati dal database e l’invio delle informazioni all’interfaccia grafica vengono svolte internamente dall’applicazione lato server che per tali motivi riceve l’appellativo di monolite, cioè un applicazione che ingloba tutte le funzionalità del sistema in un singolo processo. In una situazione simile, se vogliamo apportare una modifica al nostro sistema dovremo necessariamente ogni volta riscrivere ed effettuare nuovamente il deployment di una nuova versione di tale applicazione. Naturalmente col crescere delle esigenze di mercato, fare in modo che la propria applicazione rimanga continuamente al passo con i tempi risulta sempre più difficile, controproducente e talvolta scoraggiante per i team di sviluppatori. Tali motivi hanno spinto molti verso la ricerca di processo di sviluppo sempre più agili, veloci ed in grado di far fronte in modo tempestivo ad eventuali cambiamenti e che impattassero al minimo sull’intero sistema, portando così alla nascita delle architetture a microservizi.
L’architettura a microservizi può essere definita come l’approccio allo sviluppo di un’applicazione composta da tanti piccoli servizi indipendenti che interagiscono e comunicano tra loro mediante scambio di messaggi. La gestione centralizzata dell’applicazione è ridotta al minimo indispensabile e perciò i suoi microservizi possono essere implementati usando diversi linguaggi di programmazione e diverse tecnologie di gestione dati, oltre ad essere messi in produzione in maniera indipendente dagli altri microservizi.

Non esiste un solo modo per definire i microservizi, ma varie definizioni a seconda della prospettiva da cui si analizzano. Ad esempio, se esaminiamo l’infrastruttura interna alla produzione, il microservizio dovrebbe essere quell’unità applicativa tale da poter essere sviluppata, distribuita e messa in produzione indipendentemente dagli altri microservizi.

Anche se le applicazioni progettate ed implementate a microservizi riguardano un aspetto recente, l’idea di avere funzionalità distribuite e di dimensioni ridotte ci riporta alla filosofia UNIX, la quale da enfasi a tre aspetti utili per ragionare a microservizi. Questi aspetti si possono sintetizzare cosi:

• un programma dovrebbe svolgere uno ed un solo compito, ma farlo estremamente bene;
• i programmi dovrebbero essere in grado di lavorare ed interagire insieme;
• si dovrebbe utilizzare un’interfaccia universale.

Da questi aspetti si ricavono i le basi per cercare di ottenere una buona applicazione a microservizi.
Nell’architettura a microservizi un aspetto fondamentale riguarda l’indipendenza di ciascun servizio, cosicchè in caso di guasto del servizio, non si verifichi il malfunzionamento dell’intero sistema.

Nelle architetture microservices ciascun microservizio possieda un proprio database che può essere condiviso con altri servizi o di uso personale.

Vantaggi e Svantaggi

Un’architettura a microservizi, presenta come tutti gli stili architetturali vantaggi e svantaggi. Uno dei primi vantaggi che rileviamo è che sono velocizzati i tempi di rilascio del software e si reagisce velocemente alle esigenze del mercato. In generale, nell’architettura a miscroservizi, ogni singolo servizio è autonomo rispetto agli altri, di conseguenza può raggiungere l’ambiente di produzione in modo indipendente dagli altri, senza che tale attività abbia effetti drammatici sul resto del sistema. Disporre di un processo di deployment snello e veloce consente di poter aggiungere o modificare funzionalità di un sistema software in modo efficace ed efficiente, rispondendo alle necessità di mercato ed utenti sempre più esigenti.
Nelle architetture a microservizi si nota un miglioramento delle performance grazie all’utilizzo di tecnologie ad hoc. L’utilizzo di linguaggi e tecnologie eterogenee consente di poter utilizzare gli stack più performanti per implementare specifiche funzionalità: ad esempio è possibile introdurre una particolare tipologia di base dati che risulta naturale per mappare un determinato dato, oppure eseguire un calcolo in un modo particolarmente efficiente.

In un’architettura a microservizi, quando un componente non funziona non è automatico che tutto il sistema software smetta di funzionare. In molti casi è possibile isolare il problema ed intervenire mentre il resto del sistema continua a funzionare, cosa che non è possibile in un’architettura monolitica(quindi resilenza). Va però sottolineato che l’architettura a microservizi, essendo un insieme di sistemi distribuiti, si espone ad una nuova fonte di problemi legati al disservizio di rete.
Visto che i microservizi sono formati da tanti servizi, è facile intervenire solo su alcuni di essi senza alterare gli altri, migliorando quindi la scalabilità.

Ancora, un altro vantaggio riguarda la facilità di deployment; modificando poche righe di codice su un sistema software monolitico di grandi dimensioni ed effettuare il deploy non è un’attività banale ed inoltre esponi a rischi significativi considerando l’impatto che tali modifiche possono avere. Quindi generalmente si raccolgono un certo numero di modifiche prima di avviare un’attività cosi onerosa e rischiosa. Con l’approccio a microservizi ogni singolo servizio può raggiungere l’ambiente di produzione in modo indipendente, così facendo se si verificasse un problema esso verrebbe facilmente isolato per poi intraprendere le dovute azioni.

Uno dei vantaggi più importanti è sicuramente la componibilità, nell’architettura a microservizi vi è la possibilità di riusare le funzionalità. Infatti è possibile che uno stesso servizio venga usato in modi differenti e per scopi diversi, ad esempio un sistema software che deve poter dialogare non solo con il mondo web, ma anche con applicazioni mobile.

Infine non possiamo non citare tra i vantaggi quello della sostituibilità, infatti sostituire un servizio con un altro più efficiente o rimuoverne uno inutile ha un costo banale.
Da quanto detto potrebbe sembrare che l’architettura a microservizi non presenta svantaggi, ma non è così. Infatti avendo a che fare con un sistema distribuito, visto che abbiamo tanti servizi che comunicano tra loro tramite la rete, è soggetto al teorema di Brewer, il quale affermache non si possono avere contemporaneamente Consistency, Availability e Partition Tolerance, ma occorre sceglierne due su tre. Il significato di questi aspetti è:

• Consistenza: ogni richiesta di lettura, riceve sempre il giusto messaggio oppure un
  errore;
• Disponibilità: ogni richiesta riceve comunque una risposta, senza alcuna garanzia che sia quella più recente e quindi correttamente aggiornata;
• Tolleranza di partizione: se vi è perdita di messaggi tra i microservizi e/o nodi della rete, il sistema continua a funzionare.

Come sappiamo è possibile che in un sistema distribuito ci possano essere problemi di rete, quindi l’ultima funzionalità è fondamentale e non può essere esclusa. Per questo motivo la scelta si riduce tra avere maggiore consistenza o maggiore disponibilità. Nel primo caso, se il microservizio ha la certezza che il messaggio sia quello più aggiornato, invia un messaggio di risposta corretto, in caso contrario, invece, invia un messaggio di errore. Nel secondo caso invece, l’elaborazione del messaggio viene comunque fatta e la risposta viene data a prescindere dal fatto che il messaggio sia aggiornato o meno.
Se il sistema distribuito funziona correttamente, lo scambio di messaggi avviene naturalmente privo di errori, ma comunque il teorema deve sempre essere tenuto in conto, poiché è molto utile in fase di progettazione.

Un altro svantaggio riguarda la maggiore complessità architetturale, che comporta un elevato costo di progettazione e produzione iniziale, cosa a cui è possibile porre rimedio solo pensando a lungo termine allo sviluppo di applicazioni.
Mentre un vantaggio chiave dell’architettura a microservizi è la sua capacità di orchestrazione snella, avere più servizi significa anche mantenere più flussi di distribuzione che vanno mantenuti corretti e coerenti per tutto il ciclo di vita dell’applicazione, quindi orchestrazione più snella ma anche più complessa. Per questo è necessario implementare un alto livello di automazione di tutti i processi.
Infine un altro svantaggio riguarda la comunicazione tra servizi, infatti servizi disaccoppiati hanno bisogno di un modo efficace per comunicare senza rallentare l’intera applicazione. Scambiarsi dati sulla rete introduce latenza e potenziali fallimenti, che possono interferire con l’esperienza dell’utente. Un approccio comune per ovviare a questo tipo di problemi e rendere più affidabili le comunicazioni, è quello di introdurre una coda di messaggi come un ulteriore livello di trasporto.