Microservizi (Microservices): cosa sono e perché usarli?

Cosa sono i microservizi

I microservizi (microservices, in inglese), sono un approccio architetturale organizzativo allo sviluppo software, in cui il software è composto da piccoli servizi indipendenti che comunicano tramite API ben definite. Questi servizi sono indipendentemente distribuibili, disaccoppiati e di proprietà di piccoli team autosufficienti.
L'architettura a microservizi consente a un'organizzazione di consegnare applicazioni grandi e complesse in modo rapido, frequente, affidabile e sostenibile.

Microservizi e Cloud Native

I microservizi vengono spesso associati a un altro termine, Cloud Native, ma occorre fare una distinzione. I microservizi sono un’architettura di ingegneria del software, mentre il Cloud Native è un vero e proprio paradigma per creare applicazioni moderne. I metodi e gli strumenti Cloud Native permettono all’azienda di reagire in tempi rapidi al cambiamento delle richieste di mercato, adattando proattivamente i propri servizi IT.

Dal punto di vista operativo, le applicazioni Cloud Native sono applicazioni che possono essere eseguite su un cloud privato, pubblico o ibrido. L'approccio a microservizi è uno dei paradigmi per realizzare applicazioni Cloud Native. Al loro fianco troviamo i container, gli orchestratori di container (come Kubernetes) e l'utilizzo di API dichiarative, oltre alla metodologia Agile di sviluppo e alle pratiche DevOps basate su Continuous Integration e Continuous Delivery (CI/CD).

Un'architettura a microservizi trova nei container la tecnologia perfetta per esprimere le sue massime potenzialità. I container permettono l'esecuzione di un microservizio in maniera indipendente dall'infrastruttura sottostante.

PER APPROFONDIRE: 

• Cos'è l'orchestrazione dei container e come farla con Kubernetes
• Casi di successo: 3 aziende che li usano con successo i container
• Orchestration vs Choreography, quale usare? Pro e contro

Perché sono nati i microservizi?

I microservizi sono contemporaneamente l'evoluzione e lo sviluppo logico della storia dell'ingegneria del software. Il cammino è stato lungo e ha mosso i primi passi dalle applicazioni monolitiche.

 

Architettura monolitica

L'architettura dei monoliti prevede, semplificando il concetto, che l'interfaccia utente (il frontend)  e le interfacce per accedere e manipolare i dati (backend) siano contenuti in un singolo software indipendente, indivisibile e privo di modularità.

Un'applicazione monolitica deve contenere tutto ciò che è necessario per completare una particolare attività. Oggi questa prospettiva è potenzialmente superata: grazie all’impostazione modulare del software diventa possibile utilizzare, aggiornare o modificare una serie di piccole componenti in modo indipendente senza bisogno di distribuire o deployare l'intera applicazione.

Le applicazioni monolitiche sono funzionali a un ambiente circoscritto, come erano i primi mainframe e come sono stati a lungo anche i personal computer, e garantiscono un’integrazione delle funzioni in ambienti non standard.

Col tempo, però, la complessità dei problemi da risolvere e la potenza crescente dei computer ha portato alla realizzazione di applicazioni monolitiche sempre più grandi e pesanti. Tali strutture sono diventate molto costose da aggiornare in tempi rapidi e da mantenere correttamente: si può dire che abbiano superato la capacità dei programmatori di sfruttarne in maniera efficace le possibilità.

“As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.”

—  Edsger Dijkstra, informatico

Ecco che il mondo informatico ha dovuto identificare nuove metodologie di sviluppo e nuovi processi per migliorare la qualità del software e la sua gestione. Prima è nata la programmazione procedurale e orientata agli oggetti per gestire progetti di grandi dimensioni, complessi e con specifiche non definite nel dettaglio. Successivamente, con lo sviluppo e la crescente importanza di internet, sono nate varie architetture tra le quali la più usata è la SOA, Service-Oriented Architecture.

• PER APPROFONDIRE: Microservizi e applicazioni Cloud Native VS applicazioni monolitiche

SOA: Service-Oriented Architecture

Più che una rivoluzione, la SOA è considerata un’evoluzione delle pratiche di sviluppo esistenti che permette all’azienda di realizzare i propri applicativi con un approccio olistico e non rigido.

La SOA è un'architettura in cui alcuni componenti di un’applicazione forniscono servizi ai componenti di altre applicazioni grazie a un protocollo di comunicazione che opera in rete in maniera indipendente e non proprietaria. 

Più SOA, unite da un’infrastruttura hardware o software dedicata, possono diventare l'equivalente funzionale di una più grande e complessa applicazione monolitica, senza molti degli svantaggi connessi. La SOA incoraggia la condivisione delle singole componenti software e il loro riuso.

Nell'orientamento ai servizi - che è alla base della SOA - si intravede già quello che sarà lo sviluppo futuro dell’architettura. Parliamo chiaramente dei microservizi, che fanno dell'approccio modulare il proprio punto di forza.

Dalla SOA ai microservizi

Le differenze tra i due approcci sono numerose. Dal punto di vista architetturale la SOA è progettata per condividere delle risorse attraverso dei servizi, i microservizi invece sono servizi che funzionano in maniera indipendente. 

La SOA è organizzata su servizi più grandi e modulari rispetto ai microservizi che sono centrati su una singola funzione. Inoltre la Service-Oriented Architecture condivide lo spazio di archiviazione dei dati mentre ogni microservizio ha il suo data storage indipendente.

Come sistema di comunicazione la SOA utilizza gli ESB (Enterprise service bus) e i microservizi utilizzano le API; per i servizi remoti la SOA utilizza protocolli come SOAP e AMQP, i microservizi si basano invece su REST e JMS. 

Infine, mentre la SOA è più efficiente per progetti che prevedano un’integrazione su grande scala, i microservizi sono pensati per applicazioni web Cloud Native, più facili e veloci da progettare e mettere in produzione.

LEGGI ANCHE:

• Come realizzare un’applicazione Cloud Native
• Cos’è il serverless computing e quali sono i suoi vantaggi?

Come funzionano i microservizi?

Per comprendere come funzionano i microservizi, bisogna inserirli nel contesto in cui questi funzionano, ovvero le piattaforme di orchestrazione. Prendiamo come esempio Kubernetes, la piattaforma di orchestrazione di microservizi diventata ormai lo standard de facto. Possiamo sintetizzare il funzionamento dei microservizi analizzando quattro concetti fondamentali: discovery, comunicazione, osservabilità e runtime. 

• Per “discovery” intendiamo la capacità dei microservizi - e dell’orchestratore stesso - di poter comunicare e indicizzare attraverso un nome DNS i servizi in esecuzione. 
• Con “comunicazione” intendiamo la tipologia di protocollo che i servizi supportano per interagire tra di loro e con l’esterno (es: HTTP/HTTPS oppure MQTT/AMQP). Tutti gli orchestratori supportano anche le Network Policies che permettono di controllare il traffico tra i microservizi, garantendo la sicurezza e il controllo delle comunicazioni. 
• Con “osservabilità” ci riferiamo alla capacità di ciascun microservizio di poter esporre log, messaggi e contatti utili al monitoraggio del suo funzionamento e stato di salute.
• Infine “runtime”, il concetto che - oltre ad identificare la logica eseguita dal microservizio - rappresenta anche la possibilità di un cluster o di diversi microservizi di essere scritti in linguaggi diversi (poliglottismo), permettendo così di sfruttare il miglior stack tecnologico per un determinato compito.

Quali sono i vantaggi dei microservizi?

Realizzare un progetto basato su microservizi porta una serie di vantaggi:

• I microservizi permettono di ridurre la complessità architetturale di un’applicazione, destrutturandola in una serie di servizi puntuali più veloci da sviluppare e mantenere.
• Ogni singola funzionalità può essere fatta scalare velocemente ed essere distribuita su più ambienti in maniera indipendente dal resto.
• I tempi di sviluppo e quindi di messa in produzione dell'applicazione si riducono notevolmente, con impatto positivo sul time-to-market.
• L'applicazione è più resiliente perché i singoli servizi non impattano sul funzionamento dell'intera applicazione e le operazioni di manutenzione sono più veloci.
• I team di sviluppo sono più piccoli e molto specializzati su una singola parte dell'applicazione che ha una base di codice più piccola.
• Si possono usare in modo più facile la metodologia Agile e le pratiche di sviluppo DevOps, permettendo la collaborazione tra Developers e Operations con un approccio di Continuous Integration e Continuous Delivery.

Quando (non) scegliere i microservizi?

Non esiste un approccio allo sviluppo delle applicazioni “taglia unica” che risolva tutti i problemi. Per quanto i microservizi siano il nuovo standard del mercato, l’approccio monolitico potrebbe essere in realtà la soluzione più conveniente per alcune aziende. 

Ad esempio, è consigliabile optare per un’architettura tradizionale se:

• si dispone di poco tempo e budget per realizzare un MVP (Minimum Viable Product);
• si necessita di un'applicazione molto semplice, che non richiede particolari scalabilità e flessibilità;
• non si hanno le competenze necessarie per sviluppare a microservizi (e non si intende affidarsi a un partner specializzato, scelta comunque consigliata se si ha a che fare con tecnologie nuove e intrinsecamente complesse).

PER APPROFONDIRE: Come scegliere il partner tecnologico per la transizione verso il Cloud Native

Nella maggior parte dei casi, tuttavia, la scelta dei microservizi si rivela essere più adatta a soddisfare le richieste del business perché assicura più flessibilità, rapidità e scalabilità. 

La prova della crescente diffusione di questo approccio arriva anche dai dati. Ad esempio, le indagini di Statista condotte nel 2021 mostrano che il 71% delle aziende utilizza almeno parzialmente i microservizi. Dal sondaggio condotto nel 2020 da O’Reilly è emerso che il 28% dei partecipanti usa i microservizi da almeno 3 anni, mentre il 61% li utilizza da un anno o più. A livello di gradimento, il 92% ha espresso di aver ottenuto benefici dall’introduzione dei microservizi.

Architettura a microservizi: quali sono i migliori framework?

Utilizzare un framework per lo sviluppo a Microservizi porta una serie di vantaggi. Per prima cosa, fornisce una base di partenza comune e una community di riferimento. Inoltre, favorisce la manutenibilità del codice e determina la diminuzione dei tempi di sviluppo. Di seguito elenchiamo i framework più comuni in base al linguaggio di programmazione.

Node.js

• Express.js: Express.js è un framework web molto popolare per Node.js che può essere utilizzato per sviluppare microservizi. È flessibile e offre una vasta gamma di middleware per la gestione delle richieste HTTP.
• Nest.js: Un framework TypeScript per Node.js che si concentra sulla struttura scalabile e modulare dei microservizi. Offre un'architettura basata su moduli e una buona organizzazione del codice.

Go

• Gin: Un framework leggero e ad alte prestazioni per lo sviluppo di API e microservizi in Go. È noto per la sua velocità ed è molto popolare nella comunità Go.
• Echo: Un altro framework Go leggero e veloce per la creazione di API e servizi web. È progettato per essere semplice da usare ed estendibile.

Java

• Spring Boot: Uno dei framework più popolari per lo sviluppo di microservizi in Java. Offre una vasta gamma di funzionalità per la gestione dei servizi, la configurazione, la sicurezza e la comunicazione tra i microservizi.
• Micronaut: Un framework moderno e leggero per la creazione di microservizi Java. Micronaut è noto per le sue prestazioni eccezionali e il supporto nativo per il Cloud Native.
• Quarkus: Un altro framework Java progettato per applicazioni Cloud Native e microservizi. Quarkus si concentra sulla velocità di avvio ridotta e l'efficienza delle risorse.

C#

• ASP.NET Core: ASP.NET Core è un framework di sviluppo web di Microsoft che consente di creare microservizi in C#. Offre una vasta gamma di librerie e supporta il containerization, facilitando l'esecuzione di microservizi in container Docker.
• ServiceStack: Un framework C# open-source per lo sviluppo di servizi web e microservizi. Offre una serie di funzionalità per la gestione delle richieste HTTP, la serializzazione dei dati e altro ancora.

Sfide e complessità dei microservices

Al di là dei casi specifici, è importante valutare consapevolmente le sfide che i microservizi portano in azienda.

Un’architettura basata sui microservizi richiede un’infrastruttura di hosting differente da quella tradizionale per applicazioni monolitiche, che deve essere adatta alle esigenze dell'azienda, resa sicura e mantenuta. E funziona meglio per aziende che hanno bisogno di innovare in maniera rapida verso una base di utenti molto diversificata.

I microservizi hanno una complessità differente da quella delle applicazioni monolitiche, ma che non deve essere sottovalutata. Il punto centrale è la comunicazione tra singoli servizi dell'applicazione, che può includere da alcune decine a diverse centinaia di servizi diversi per i progetti di più grandi dimensioni. 

Inoltre, il debugging di una applicazione basata su microservizi è più complesso perché bisogna tracciare la sorgente di ogni singolo problema attraverso i log di decine o centinaia di piccole componenti. Ancora, la fase di test dell'integrazione dei microservizi presenta alcune difficoltà perché questi sono distribuiti in ambienti diversi e diventa complesso replicarli in un ambiente di test locale.

Infine, dal momento che il funzionamento di un'applicazione basata su microservizi si ottiene con l'utilizzo di API, bisogna prestare costante attenzione all'evoluzione di queste ultime. Se infatti vengono definite nuove versioni delle API, può essere molto complesso capire in quale modo impatteranno sui microservizi che le utilizzano.

Al netto di queste considerazioni, l'architettura a microservizi si rivela essere la scelta più innovativa e vantaggiosa per quelle aziende che sono in grado di affrontare la complessità aggiunta in virtù dei numerosi benefici che si possono ottenere. 

PER APPROFONDIRE: Applicazioni Cloud Native vs applicazioni tradizionali: il confronto

Da monolite a microservizi: le fasi di modernizzazione

I vantaggi dei microservizi rispetto all’architettura monolitica sono molti. Per questo sempre più aziende optano per i primi. Un progetto basato su microservizi può essere sviluppato da zero o, più probabilmente, sarà il frutto di una trasformazione che parte da un applicativo legacy, ne abbiamo parlato in questo articolo: Application modernization: cos'è e quali sono i vantaggi.

Le strategie di refactoring più diffuse per gestire la trasformazione da una applicazione monolitica a una basata su microservizi sono due: l'implementazione di tutte le nuove funzionalità come servizi e l'estrazione di singoli servizi dall'applicazione monolitica.

Il primo caso è il più semplice da affrontare in quanto non richiede di frammentare tutta l’applicazione legacy. E ha anche il vantaggio di mostrare la maggiore velocità nella messa in produzione del nuovo software rispetto al modello tradizionale monolitico.

Tuttavia l'unico modo per modernizzare del tutto l'applicazione monolitica è estrarre un modulo dopo l'altro dall'applicazione e convertirlo in servizio. Per farlo si procede con una fase di analisi preliminare e di mappatura: occorre definire i singoli servizi che sostituiranno i differenti moduli dell'applicazione monolitica. Seguono le fasi di sviluppo, test e messa in produzione così che il traffico venga reindirizzato verso i nuovi servizi. A questo punto è possibile rimuovere le funzionalità trasformate in microservizi dall'applicazione monolitica.

In conclusione, la migrazione di un'applicazione monolitica verso un’architettura basata sui microservizi richiede un’attività preliminare di analisi e poi di conversione delle singole componenti mappate in maniera iterativa.