Microservices Analisi

in Architetture Software, Informatica

Architettura Microservices – Analisi

Reading Time: 2 minutes

Riprendendo il progetto che è stato convertito da un’architettura monolitica ad una più moderna a microservices, sono state analizzate le tematiche legate ai pro ed i contro del nuovo approccio.

Nell’articolo precedente abbiamo fatto una breve panoramica delle architetture monolitiche e quelle basata sui servizi.

L’analisi dei costi sia in termini economici, sia in termini di risorse, è sicuramente una componente fondamentale nella decisione di approcciare la nuova architettura. Si tratta, infatti, di una vera migrazione, molto volte irreversibile.

Uno degli articoli che forse meglio rappresenta l’architettura basata sui microservices, è sicuramente quello di Martin Fowler.

Come già scritto più volte, nel nuovo modello di architettura i singoli componenti sono indipendenti, e comunicano tra loro attraverso un “bus” dedicato oppure tramite Web API.

In un sistema ben progettato, la modifica di un singolo servizio non dovrebbe impattare su tutti gli altri: una singola funzionalità dovrebbe essere indisponibile solo per un lasso di tempo limitato (tipicamente il tempo di deploy).

Passiamo quindi in rassegna i vantaggi e gli svantaggi dell’architettura a microservices.

Vantaggi

  • ogni microservice, se ben definito, è piccolo e rappresenta una funzionalità specifica
  • lo sviluppo per il team può avvenire in maniera separata: tutto il ciclo di sviluppo non ha infatti impatto sul lavoro degli altri membri del team
  • sono facilmente scalabili
  • ciascun microservice utilizza una propria porzione dei dati (anche se il database sottostante potrebbe essere comune)
  • la loro mantenibilità è semplice, e tipicamente affidata a team di poche persone
  • possono essere facilmente distribuiti nel cloud, utilizzando un modello di Continuous Integration
  • potrebbero anche essere sviluppati con linguaggi di programmazione differenti

Svantaggi

  • un sistema distribuito tipicamente è molto più complesso di un sistema monolitico
  • dovendo gestire la comunicazione tra i vari servizi, aumentando lo scambio dei dati, aumenta anche l’overhead delle richieste
  • se non ben progettato si potrebbe produrre del codice ridondato

Nel nostro caso specifico, dovendo effettuare operazioni R/W sul database, abbiamo deciso di destinare ciascun microservice alla gestione di una singola porzione del db.

E’ stato utilizzato, comunque, un singolo database relazionale.

Per facilitare le operazioni di lettura/scrittura è stata implementata un’unica libreria condivisa: questa soluzione si è dimostrata vincente per evitare di riscrivere codice.

Abbiamo anche valutato la possibilità di utilizzare un “service bus” dedicato, ma per ragioni di tempo non è stato possibile creare i presupposti per la realizzazione.