L’architettura a microservizi permette di strutturare un'applicazione web come una collezione di piccoli servizi accoppiati in maniera non rigida.

Il termine nasce ufficialmente nel 2005, originariamente come “Micro-Web-Services". Nonostante non esista una definizione unica di microservizi, gli obiettivi e le modalità di funzionamento di questa architettura sono chiari. L'approccio modulare permette di sviluppare in maniera indipendente una serie di servizi, ciascuno con una specifica funzione e in grado di comunicare con gli altri via API.

Questo approccio trasforma quindi l’applicazione in un’aggregazione di unità funzionali più piccole e indipendenti in cui una componente e i suoi dati vengono considerati un’unità singola con il minimo possibile di dipendenze esterne.

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: 

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.

 

microservizi applicazione cloud native

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.

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

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.

La modernizzazione inizia dalla tecnologia

Scopri gli strumenti IT più innovativi per la Cloud Transformation

Scarica l'ebook gratuito

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.

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

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.

cloud-native assessment