architettura a microservizi

in Architetture Software, Informatica

Verso un'architettura basata su microservices

Reading Time: 3 minutes

Soluzioni software di grandi dimensioni (magari sviluppati nel corso di anni) richiedono un effort piuttosto elevato in termini di manutenzione. Utilizzando i nuovi paradigmi architetturali, come i microservices, in via teorica si dovrebbero raggiungere modelli moderni, flessibili e soprattutto scalabili.

Questo in teoria! Una conversione a microservizi è sicuramente molto costosa e, se introdotta in modo errato, può produrre risultati talvolta peggiori rispetto a quella dell’architettura originale.

Microservices e dipendenza

I microservices sono un paradigma architetturale piuttosto recente. Non entrerò nel merito delle considerazioni già fatte nei post precedenti.

Prima di partire dalle considerazioni legate alla suddisivione delle responsabilità dei singoli servizi, è necessario porre l’attenzione sui teams coinvolti nello sviluppo. Realizzando servizi, infatti, ogni singolo teams di sviluppo raggiunge il proprio grado di autonomia e di indipendenza molto piu’ rapidamente rispetto allo sviluppo tradizionale.

Questa indipedenza viene raggiunta solo se il software da realizzare è stato decomposto in base a specifici criteri funzionali. Immaginiamo il caso in cui siano presenti 3 teams:

  • team per lo sviluppo frontend
  • team per lo sviluppo backend
  • team per lo sviluppo funzionalità sul database

In questa situazione il team dedicato allo sviluppo frontend dovrà interfacciarsi con il team backend nel momento in cui dovranno essere sviluppate nuove funzionalità. Lo stesso discorso è valido tra il team di sviluppo backend ed quello per il database.

In questa struttura, l’implementazione di una nuova funzionalità coinvolge necessariamente i team coinvolti che sono dipendenti l’uno dall’altro.

I legami forti di accoppiamento e dipendenza sono dovuti alla scomposizione basata sui requisiti tecnici e non sui requisiti funzionali.

Requisiti funzionali

Un’analisi dei requisiti funzionali consente ad un team di essere responsabile di un modulo funzionale, attraversando tutti i livelli tecnici, partendo dall’interfaccia fino ad arrivare alla database.

Teoricamente, non dovrebbe essere particolarmente difficoltoso poter assegnare nuove funzionalità ad un team e al modulo oggetto dello sviluppo, se i moduli funzionali sono stati allocati correttamente.

Trasformazione di un monolite

Partendo da un software “monolite” la complessità maggiore riguarda la modalità di partizionamento dell’analisi funzionale. Le partizioni devo essere necessariamente stabili ed il piu’ possibile indipedenti tra loro. In questo scenario, il concetto di architettura a microservizi non fornisce nessuna reale soluzione. Solitamente la scomposizione di un monolite viene effettuata utilizzando strumenti di analisi estraendo tutte le componenti del progetto pilota. Successivamente, il team di sviluppo, definirà una serie attività legate al refactoring ordinandole in ordine di priorità. Solo una volta definiti ed analizzati i singoli componenti sui quali effettuare il refactoring, il lavoro sarà dedicato alla scomposizione funzionale e alla realizzazione dei singoli microservizi.

La scomposizione è basata sulla creazione di una serie di singole unità distinte, ma attenzione alla presenza di un nuovo elemento in termini di complessità: la distribuzione.

Al termine degli anni 2000, sono comparse le prime architetture orientate ai servizi. Queste architetture prendono il nome di architetture SOA. Questo tipo di implementazione ha portato alla realizzazione di sistemi in cui un servizio centrale comunicava con altre servizi, tramite l’utilizzo di un bus di servizio.

Questo tipo di approccio presenta lo svantaggio legato alla centralità dei servizi offerti: tutti i team di sviluppo che necessitano del servizio centrale non possono lavorare in maniera indipendente ma dovranno conoscerne l’implementazione. In pratica, si perde il concetto di individualità dei servizi.

Strutturare un’architettura

Al giorno d’oggi, diventa piuttosto difficile pensare di convertire un’architettura SOA in architetture a microservizi: ad esempio la conversione di servizi centralizzati per la gestione dei dati. In questo caso, ci si trova a dover implementare particolari accorgimenti e a realizzare soluzioni ibride: un mix tra SOA e microservizi.

A livello teorico, quindi, sono numerosi i vantaggi dell’adozione di architetture a microservizi. E’ però necessario analizzalizzare concretamente quelli che possono essere i costi (in termini effort, ecc…) per la migrazione di un servizio monolite.

Per la scomposizione di un sistema monolite in un sistema a microservizi, è prima necessario dividere i domini funzionali in sottodomini e trasferire questo tipo di organizzazione al codice sorgente.

Spesso la presenza di codice “riutlizzato” e la ricerca di architettura basate su microservizi sono degli ostacoli che devono essere superati nella fase di defizione dell’architettura.