Architettura basata su Microservices

in Architetture Software, Informatica

Architettura Microservices

Reading Time: 2 minutes

Il passaggio dallo sviluppo di un  software “tradizionale” ad un software basato su un’architettura basata su microservices risulta, almeno inizialmente, non proprio semplice.

Negli ultimi 4 mesi ho trascorso un pò di tempo nello studio e nell’implementazione di una soluzione basata sui microservices.

L’idea alla base di questo tipo di struttura non è completamente nuova, ma possiamo pensarla come un’evoluzione dell’architettura SOA (Service Oriented Application): si tratta infatti di una serie di piccoli servizi (micro appunto)  indipendenti tra loro e ciascuno focalizzato su particolare ruolo all’interno del business.

L’insieme di questi microservices consente di soddisfare strutture di business più complesse.

Docker, il progetto open-source che consente la distribuzione di applicazione all’interno di container (e che probabilmente affronteremo in qualche post), è sicuramente un elemento importante per la creazione e la distribuzione di microservices. Docker consente di realizzare applicazioni snelle e soprattutto scalabili senza dover replicare l’intera infrastruttura sistemistica (non è necessario creare un macchina virtuale per ogni servizio!).

L’approccio alla programmazione tradizionale, o almeno l’approccio che ha caratterizzato il mondo della programmazione per la mia generazione, è sempre stato quello di realizzare applicazione più o meno “monolitiche” dove il codice è contenuto in uno o comunque pochi progetti (nella fattispecie i project di Visual Studio).

Questo tipo di approccio è sicuramente quello utilizzato per lo sviluppo di applicazioni piccole, dove il codice è raggruppato all’interno di librerie di modeste dimensioni. Inoltre, è anche molto utilizzato all’interno di soluzioni gestionali, dove il team di sviluppatori è concentrato sulle singole funzionalità piuttosto che sull’architettura dell’intero applicativo. Al giorno d’oggi, lo studio di un software, non può più essere pensato in un’ottica monolitica per la quale si evidenziano notevoli problemi in termini di sviluppo, mantenibilità e soprattutto testing.

Nel nostro caso specifico, dopo essere entrati a far parte del team a cui è stato dato il gravoso compito di re-ingegnerizzare, abbiamo dovuto in prima battuta impare il funzionamento dell’intera applicazione implementando test che andavano a coinvolgere tutto il ciclo di vita del processo applicativo.  E’ stata sicuramente una parte importante per il nuovo sviluppo, ma senza questo tipo di approccio non sarebbe stato possibile implementare la nuova architettura.

Scomposizione dell’applicazione

I passi che sono stati compiuti per la re-ingegnerizzazione sono stati:

  • scomposizione funzionale dell’applicativo, realizzando l’analisi degli aspetti “logici” dell’applicazione. Questo passo è stato fondamentale per poter concentrare il team di sviluppo su micro-aree ben delimitate
  • realizzazione grafo delle funzionalità,  a partire dalla scomposizione funzionale del passo precedente, abbiamo realizzato un grafo di funzionalità basate sul livello business dell’applicativo. Questo tipo di analisi, ha permesso al team di focalizzarsi allo sviluppo dei singoli servizi, piuttosto che alle singole funzionalità. Siamo quindi giunti all’organizzazione per così dire SOA, una sorta di insieme di servizi interoperanti tra loro.

SOA tende però a far interagire un numero N di applicazioni, mentre nell’architettura microservices si tende a far interagire N servizi indipendenti tra loro. Il principio fondamentale nello sviluppo con microservices è infatti quello per cui ciascun servizio sia indipendente dagli altri, impostando il grado di responsabilità a ciascun servizio.

A questo punto, un’ulteriore passaggio di raffinamento ha permesso di separare in maniera atomica i singoli servizi.

Rimane ancora da definire il sistema di comunicazione tra i microservices, in modo da permetterne l’interoperabilità. Ma di questo ne parleremo nei prossimi post.