Cos’è l’architettura dei microservizi

I microservizi sono un paradigma di programmazione che costruisce applicazioni come un insieme di servizi che lavorano insieme. Ogni servizio esegue un processo unico e comunica con altri servizi attraverso un’API ben definita, tipicamente usando HTTP con JSON.

In questo modello, ogni servizio è responsabile di una singola funzione all’interno dell’applicazione. In questo modo, è più facile mantenere il codice senza influenzare l’intero sistema quando è necessario aggiornare o correggere qualcosa. Il modello di architettura a microservizi scompone grandi app complesse in componenti indipendenti più piccoli che possono essere sviluppati, testati e distribuiti indipendentemente l’uno dall’altro.

Origini e cenni storici sull’architettura a microservizi

Il concetto di microservizi esiste da decenni, ma non è stato fino al 2011 che Martin Fowler ha scritto di “microservizi” come nome per lo stile architettonico che ha usato nello sviluppo del software

Il termine Microservices (conosciuto anche come Microservice Architecture) è stato applicato per definire un metodo di sviluppo e distribuzione di applicazioni in cui l’applicazione è costruita come una collezione di piccoli servizi. L’idea dietro i microservizi è di suddividere grandi progetti software in servizi più piccoli che possono essere sviluppati indipendentemente da team separati. Ogni microservizio può essere costruito usando lo stesso o diversi linguaggi di programmazione o framework e può essere distribuito senza impatto sugli altri microservizi o sull’intero sistema.

Benefici e svantaggi

I microservizi hanno una vasta gamma di benefici, tra cui i seguenti:

• Allineamento organizzativo. L’architettura a microservizi si allinea naturalmente con le organizzazioni strutturate intorno a piccoli team autonomi. Inoltre, permette ai team di selezionare i migliori strumenti per il loro particolare servizio, piuttosto che avere tutti i team costretti ad usare lo stesso stack tecnologico.
• Facilità di distribuzione. I servizi possono essere distribuiti indipendentemente, dato che non ci sono interdipendenze tra loro. I deployment possono essere eseguiti continuamente.
• Isolamento dei guasti. Un guasto in un servizio non influenza gli altri servizi o l’intera applicazione. Questo implica che non c’è bisogno di un rollback completo dell’applicazione a causa di un guasto di un servizio.

Gli svantaggi dei microservizi includono:

• Complessità: Mantenere più applicazioni piccole e lavorare con diversi linguaggi, framework e piattaforme spesso aumenta la complessità all’interno dei team di sviluppo.
• Test: Ogni microservizio deve essere testato individualmente prima di essere integrato in applicazioni o sistemi più grandi. Questo significa che gli sviluppatori devono testare più codice in tempi più brevi. Questo può aumentare il rischio che i bug sfuggano ai controlli.

Architetture alternative ai microservizi: web service e SOA

Come spiegato nel blog UniverseIT, i microservizi sono una tecnica di sviluppo del software, una variante dello stile architettonico SOA (service-oriented architecture) che struttura un’applicazione come una collezione di servizi liberamente accoppiati. In un’architettura a microservizi, i servizi sono a grana fine e i protocolli sono leggeri. Il vantaggio di decomporre un’applicazione in diversi servizi più piccoli è che migliora la modularità. Questo rende l’applicazione più facile da capire, sviluppare, testare e diventa più resistente all’erosione dell’architettura. Parallelizza lo sviluppo permettendo a piccoli team autonomi di sviluppare, distribuire e scalare i rispettivi servizi in modo indipendente. Permette anche all’architettura di un singolo servizio di emergere attraverso il refactoring continuo. 

In conclusione

L’architettura dei microservizi è un esempio di mantenere il processo di sviluppo del software semplice, ma ancora altamente funzionale. Permette agli sviluppatori di lavorare su componenti più piccoli, o microservizi individuali, e poi orchestrarli insieme in un’app più grande. Questo, a sua volta, rende più facile per i diversi team responsabili della creazione di singoli prodotti o funzionalità di farlo in modo indipendente. In definitiva, questo porta a una maggiore flessibilità quando si tratta di gestire le app software legacy nel lungo periodo e le rende più adattabili alle mutevoli tendenze attuali.