Cos’è l’architettura a microservices?

I microservizi sono una tipologia di architettura delle applicazioni. La differenza fondamentale rispetto alle architetture più tradizionali e monolitiche è la suddivisione delle funzionalità in piccoli pacchetti (servizi) tra di loro indipendenti.

Oggi questa tecnologià è già ampiamente utilizzata. Pensa ad esempio ad un classico e-commerce nel quale la ricerca dei prodotti è un servizio, l’aggiunta al carrello è un’altro e il pagamento è un’altro ancora, e così via.

L’archiettura SOA (Service-Oriented Architecture), è alla base dell’approccio microservices. Spesso però nelle architetture SOA i servizi sono comunque parte di una singola unità di compilazione e durante le fasi di test e di deploy, si va ritorna ad utilizzare un approccio monolitico. Con i microservices, che ne rappresentano una evoluzione, il disaccoppiamento è maggiore, in quanto ogni singolo componente deve essere stateless, indipendente dallo stato precedente, testabile singolarmente e deve terminare solo con un commit (successo) o un abort (insuccesso).

Gli Enterprise Service e Bus sono tool che integrano tra di loro i servizi. In particolare con l’utilizzo di linguaggi come BPEL (Business Process Execution Language) i servizi sono espressi tramite una semplice azioni e sono presenti strutture per esprimere loop, if-then-else, esecuzioni concorrenti o sequenze di operazioni. BPEL è quindi adatto a modellare una saga o un workflow completamente automatizzato.

I vantaggi nell’utilizzo di questo approccio sono molteplici:

  • Maggiore scalabilità. Mano mano che aumenta la domanda di servizi questi possono essere distribuiti su più server e può essere gestito meglio il numero di processi worker associato a ciascuno
  • Ciclo di sviluppo più breve. Aggiornamenti e deployment più agili.
  • Resilienza. Ogni servizio è indipendente e non influisce sugli altri.L’errore di un componente non blocca l’intera applicazione
  • Libertà. Gli sviluppatori possono scegliere con quale linguaggio e tecnologia sviluppare ogni singolo componente
  • Manutenzione. I servizi più piccoli permetto un controllo più puntuale e sono più semplici da aggiornare. Il deployment avviene per singolo componente ed è anch’esso semplificato.

Tra le problematiche ricordiamo che non è sempre facile debuggare il singolo componente, risulta molto importante il test di integrazione e la scelta della tecnologia di ESB e di monitoring.