Che cosa sono i microservizi?

I microservizi, o architettura a microservizi, sono un approccio architettonico cloud-native in cui una singola applicazione è composta da numerosi componenti o servizi più piccoli ad accoppiamento debole e distribuibili in modo indipendente.

Generalmente, i microservizi:

• Dispongono di un proprio stack tecnologico, che include il database e il modello di gestione dei dati.
  
• Comunicano tra di loro tramite una combinazione di API REST (Representational State Transfer), event streaming e broker di messaggi.
  
• Sono organizzati in base alle funzionalità aziendali. La linea che separa i servizi viene spesso definita contesto delimitato.

Sebbene gran parte del dibattito sui microservizi ruoti intorno alle definizioni e alle caratteristiche architetturali, il loro valore può essere più comunemente compreso attraverso vantaggi aziendali e organizzativi piuttosto semplici:

• Il codice può essere aggiornato più facilmente: è possibile aggiungere nuove funzioni senza toccare l'intera applicazione.
  
• I team possono utilizzare stack e linguaggi di programmazione diversi per componenti diversi.
  
• I componenti possono essere scalati indipendentemente l'uno dall'altro, riducendo gli sprechi e i costi associati alla necessità di scalare intere applicazioni perché una singola funzione potrebbe essere sottoposta a un carico eccessivo.

Per comprendere i microservizi, può essere utile confrontarli con due architetture di applicazioni precedenti: l'architettura monolitica e l'architettura orientata ai servizi (SOA).

La differenza tra microservizi e architettura monolitica è che, nel primo caso, una singola applicazione è costituita da molti servizi più piccoli ad accoppiamento debole, mentre un approccio monolitico è caratterizzato da un'applicazione di grandi dimensioni i cui componenti sono strettamente accoppiati.

Le differenze tra microservizi e SOA potrebbero essere un po' meno chiare. Sebbene microservizi e SOA si distinguano anche per degli aspetti tecnici, soprattutto per quanto riguarda il ruolo dell'enterprise service bus, è più facile considerare la differenza come una questione di campo di applicazione. La SOA è stata un'iniziativa a livello aziendale per standardizzare il modo in cui tutti i servizi web di un'organizzazione comunicano e si integrano tra loro, mentre l'architettura a microservizi è specifica per ogni applicazione.

È probabile che i microservizi siano apprezzati dai dirigenti e dai responsabili di progetto almeno quanto dagli sviluppatori. Questa è una delle caratteristiche più insolite dei microservizi, perché l'entusiasmo verso un'architettura è in genere riservato ai team di sviluppo software. Il motivo è che i microservizi riflettono meglio il modo in cui molti dirigenti aziendali desiderano strutturare e gestire i loro team e processi di sviluppo.

In altre parole, i microservizi sono un modello architetturale che consente di realizzare meglio il modello operativo desiderato. In un sondaggio IBM del 2021 condotto su oltre 1.200 sviluppatori e dirigenti IT, l'87% degli utenti di microservizi ha convenuto che l'adozione dei microservizi vale la spesa e l'impegno.

Questi sono alcuni dei vantaggi dei microservizi per le aziende:

Probabilmente, la caratteristica più importante dei microservizi è che, essendo i servizi più piccoli e distribuibili in modo indipendente, è molto meno complesso modificare una riga di codice o aggiungere una nuova funzione all'applicazione.

I microservizi promettono alle aziende di risolvere il problema legato alle piccole modifiche che richiedono enormi quantità di tempo. Il valore di questo approccio, che coniuga facilità e velocità, è ben chiaro anche ai non addetti ai lavori.

La velocità, tuttavia, non è l'unico valore di questa modalità di progettazione dei servizi. Un modello organizzativo emergente comune è quello di riunire team interfunzionali intorno a un problema aziendale, un servizio o un prodotto. Il modello di microservizio si adatta perfettamente a questa tendenza. Il modello consente a un'organizzazione di creare piccoli team interfunzionali attorno a un servizio o a una raccolta di servizi e di farli operare in modo agile.

L'accoppiamento debole dei microservizi permette inoltre un certo grado di isolamento degli errori e promuove una maggiore resilienza nelle applicazioni. Inoltre, le dimensioni ridotte dei servizi, combinate con i loro confini chiari e i pattern di comunicazione, rendono più facile per i nuovi membri del team comprendere la base di codice e contribuirvi rapidamente: un chiaro vantaggio sia in termini di velocità che di morale dei dipendenti.

Nei tradizionali pattern di architettura a livelli, un'applicazione in genere condivide uno stack comune, con un ampio database relazionale a supporto dell'intera applicazione. Questo approccio presenta diversi svantaggi evidenti, il più significativo dei quali è che ogni componente di un'applicazione deve condividere uno stack, un modello di dati e un database comuni, anche se per determinati elementi esiste uno strumento migliore e più adatto allo scopo. Questo va a discapito dell'infrastruttura, ed è frustrante per gli sviluppatori che sono pienamente consapevoli dell'esistenza di un modo migliore e più efficiente per creare questi componenti.

Al contrario, in un modello di microservizi, i componenti vengono distribuiti in modo indipendente e comunicano tramite una combinazione di REST, event streaming e broker di messaggi, quindi è possibile ottimizzare lo stack di ogni singolo servizio per tale servizio. La tecnologia cambia continuamente ed è molto più facile e conveniente aggiornare un'applicazione composta da diversi servizi più piccoli con una tecnologia migliore non appena è disponibile.

Con i microservizi, i singoli servizi possono essere distribuiti individualmente, ma anche essere scalati individualmente. Il vantaggio che ne deriva è evidente: se eseguiti correttamente, i microservizi richiedono meno infrastruttura rispetto alle applicazioni monolitiche, perché consentono di scalare in modo preciso solo i componenti che lo richiedono, anziché l'intera applicazione nel caso di applicazioni monolitiche.

Gli importanti benefici dei microservizi comportano anche delle sfide significative. Passare da un'architettura monolitica ai microservizi implica una maggiore complessità di gestione: molti più servizi, creati da molti più team, distribuiti in molti più luoghi. I problemi in un servizio possono causare o essere causati da problemi in altri servizi. La registrazione di log (utilizzata per il monitoraggio e la risoluzione dei problemi) è più complessa e può essere incoerente tra i diversi servizi. Le nuove versioni possono causare problemi di compatibilità con una versione precedente. Le applicazioni comportano più connessioni di rete, il che significa maggiori possibilità di problemi di latenza e problemi di connettività. Un approccio DevOps può risolvere molti di questi problemi, ma l'adozione di DevOps presenta ulteriori ostacoli.

Nonostante tutto, queste sfide non impediscono ai non adottanti di adottare i microservizi, né agli adottanti di intensificare i propri sforzi in materia i microservizi. I dati del sondaggio IBM già citati rivelano che il 56% degli attuali non utilizzatori avrebbe adottato probabilmente, o molto probabilmente, i microservizi nei due anni successivi. Di conseguenza, il 78% degli attuali utilizzatori di microservizi avrebbe aumentato probabilmente il tempo, il denaro e gli sforzi investiti nei microservizi.

L'architettura a microservizi viene spesso descritta come ottimizzata per DevOps e per le pratiche di integrazione continua o distribuzione continua, ed essendo costituita da piccoli servizi che possono essere distribuiti frequentemente, è facile capire perché.

Tuttavia, osservando da un'altra prospettiva la relazione tra microservizi e DevOps, emerge che le architetture di microservizi richiedono DevOps per avere successo. Sebbene le applicazioni monolitiche presentino una serie di svantaggi, già illustrati in precedenza in questo articolo, hanno il vantaggio di non essere un sistema distribuito complesso con più parti mobili e stack tecnologici indipendenti. Al contrario, dato il notevole aumento della complessità, delle parti mobili e delle dipendenze che derivano dai microservizi, sarebbe poco saggio approcciarsi ai microservizi senza investire in modo significativo nella distribuzione, nel monitoraggio e nell'automazione del ciclo di vita.

Rosalind Radcliffe offre un'analisi più approfondita di DevOps nel video:

Sebbene in un'architettura di microservizi sia possibile utilizzare quasi tutti gli strumenti o linguaggi moderni, vi sono alcuni strumenti che sono diventati essenziali e quasi imprescindibili per i microservizi:

Uno degli elementi chiave di un microservizio è che è piccolo. Non esiste una quantità arbitraria di codice che determina se qualcosa è o non è un microservizio, ma "micro" è proprio nel loro nome.

Quando Docker ha inaugurato l'era moderna dei container nel 2013, ha anche introdotto il modello di calcolo che sarebbe diventato più strettamente associato ai microservizi. Poiché i singoli container non hanno il sovraccarico del proprio sistema operativo, sono più piccoli e leggeri rispetto alle tradizionali macchine virtuali e possono essere attivati e disattivati più velocemente, il che li rende perfetti per i servizi più piccoli e leggeri che si trovano nelle architetture a microservizi.

Con la proliferazione di servizi e container, l'orchestrazione e la gestione di grandi gruppi di container è diventata rapidamente una delle principali sfide. Kubernetes, una piattaforma di orchestrazione dei container open source, è emersa come una delle soluzioni di orchestrazione più popolari perché svolge bene questo compito.

I microservizi spesso comunicano tramite API, soprattutto quando impostano il loro stato iniziale. Sebbene sia vero che client e servizi possono comunicare tra loro in modo diretto, gli API gateway rappresentano spesso un utile livello intermedio, soprattutto man mano che il numero di servizi in un'applicazione aumenta nel tempo. Un API gateway funge da proxy inverso per i client instradando le richieste, distribuendole su più servizi e fornendo sicurezza e autenticazione aggiuntive.

Esistono diverse tecnologie che possono essere utilizzate per implementare gli API gateway. Tra queste tecnologie ci sono le API management platform, ma se l'architettura dei microservizi viene implementata utilizzando contenitori e Kubernetes, il gateway viene in genere implementato utilizzando Ingress o, più recentemente, Istio.

Sebbene la best practice potrebbe essere quella di progettare servizi senza stato, lo stato esiste comunque e i servizi devono esserne a conoscenza. E sebbene una chiamata API possa essere un modo efficace per impostare lo stato iniziale di un determinato servizio, non è un modo efficace per rimanere aggiornati. Un approccio che si basa su continue verifiche per garantire l'aggiornamento di un servizio non è pratico.

Invece, è necessario abbinare le chiamate API per l'impostazione dello stato con la messaggistica o l'event streaming, in modo che i servizi possano trasmettere i cambiamenti di stato. In questo modo, le altre parti interessate possono recepire tali modifiche e adeguarsi di conseguenza. Questo compito è probabilmente il più adatto a un broker di messaggi generico, ma in alcuni casi una piattaforma di event streaming, come Apache Kafka, potrebbe essere la scelta giusta. Inoltre, combinando i microservizi con un'architettura basata su eventi, gli sviluppatori possono creare sistemi distribuiti, altamente scalabili, con elevata tolleranza ai guasti ed estensibili in grado di consumare ed elaborare grandi quantità di eventi o informazioni in tempo reale.

Le architetture serverless portano alcuni dei principali pattern di cloud e microservizi alla loro conclusione logica. Nel caso del serverless, l'unità di esecuzione non è un piccolo servizio, ma una funzione, che spesso può essere costituita da poche righe di codice. La linea che separa una funzione serverless da un microservizio è sfocata, ma le funzioni sono comunemente considerate persino più piccole di un microservizio.

Ciò che accomuna le architetture serverless e le piattaforme functions-as-a-service con i microservizi è il fatto che entrambi si focalizzano sulla possibilità di creare unità di distribuzione più piccole e di scalare esattamente in base alla domanda.

I microservizi non sono necessariamente pertinenti esclusivamente al cloud computing. Tuttavia, ci sono alcune ragioni importanti per cui vanno così spesso insieme: ragioni che vanno oltre il fatto che i microservizi sono uno stile di architettura popolare per nuove applicazioni e il cloud è una popolare destinazione di hosting per nuove applicazioni.

Tra i principali vantaggi dell'architettura a microservizi vi sono i benefici in termini di utilizzo e di costi associati alla distribuzione e alla scalabilità dei singoli componenti. Sebbene questi vantaggi siano ancora presenti in una certa misura con l'infrastruttura on-premise, la combinazione di componenti piccoli e scalabili in modo indipendente abbinati a un'infrastruttura on-demand e pay-per-use è il modo in cui è possibile trovare un'ottimizzazione reale dei costi.

Un altro, e forse ancora più importante, vantaggio dei microservizi è che ogni singolo componente può adottare lo stack più adatto al suo compito specifico. La proliferazione degli stack può portare a una notevole complessità e a un carico di lavoro significativo quando li si gestisce autonomamente, ma l'utilizzo dello stack di supporto come cloud service può ridurre drasticamente le sfide di gestione. In altre parole, sebbene non sia impossibile implementare la propria infrastruttura di microservizi, non è consigliabile farlo, soprattutto se si è alle prime armi.

All'interno delle architetture di microservizi esistono molti pattern di progettazione, comunicazione e integrazione comuni e utili che aiutano ad affrontare alcune delle sfide e delle opportunità più comuni, tra cui:

Questo pattern inserisce un livello tra l'esperienza utente e le risorse a cui l'esperienza fa riferimento. Ad esempio, un'app utilizzata su un desktop avrà dimensioni dello schermo, visualizzazione e limiti di prestazioni diversi rispetto a un dispositivo mobile. Il pattern BFF consente agli sviluppatori di creare e supportare un tipo di backend per interfaccia utente utilizzando le migliori opzioni per quell'interfaccia, anziché cercare di supportare un backend generico che funziona con qualsiasi interfaccia ma può influire negativamente sulle prestazioni del frontend.

Un'entità è un oggetto che si distingue per la sua identità. Ad esempio, in un sito di e-commerce, un oggetto "prodotto" potrebbe essere distinto per nome, tipo e prezzo. Un aggregato è una raccolta di entità correlate che devono essere trattate come una singola unità. Quindi, per il sito di e-commerce, un ordine sarebbe una raccolta (aggregato) di prodotti (entità) ordinati da un acquirente. Questi pattern vengono utilizzati per classificare i dati in modo significativo.

Questi aiutano le applicazioni e i servizi a trovarsi a vicenda. In un'architettura a microservizi, le istanze dei servizi cambiano dinamicamente a causa di scalabilità, aggiornamenti, guasti e persino cessazioni dei servizi. Questi pattern forniscono meccanismi di individuazione per far fronte a questa transitorietà. Il bilanciamento del carico può utilizzare dei pattern di individuazione dei servizi utilizzando controlli di integrità e guasti dei servizi come trigger per riequilibrare il traffico.

Possiamo paragonare i pattern adapter agli adattatori per le prese elettriche che si usano quando si viaggia in un altro paese. Lo scopo dei pattern adapter è quello di facilitare la traduzione delle relazioni tra classi o oggetti che altrimenti sarebbero incompatibili. Un'applicazione che si basa su API di terze parti potrebbe dover usare un pattern adapter per garantire che l'applicazione e le API possano comunicare.

Questi pattern consentono di gestire il refactoring di un'applicazione monolitica in applicazioni di microservizi. Il loro nome (strangler, strangolatore) si riferisce al modo in cui una pianta rampicante (che rappresenta i microservizi) riesce lentamente, con il passare del tempo, a sopraffare e "strangolare" un albero (un'applicazione monolitica).

Sebbene esistano molti pattern per realizzare al meglio i microservizi, esiste un numero altrettanto significativo di pattern che possono rapidamente mettere nei guai qualsiasi team di sviluppo. Alcuni di questi, riformulati come "cose da non fare" nei microservizi, sono i seguenti:

Per dirla in modo più preciso: non iniziare dai microservizi. I microservizi rappresentano un modo per gestire la complessità quando le applicazioni sono diventate troppo grandi e ingombranti per essere aggiornate e gestite facilmente. Solo quando le difficoltà e la complessità della struttura monolitica iniziano a farsi sentire, vale la pena considerare il refactoring dell'applicazione in servizi più piccoli. Finché non si avvertono queste difficoltà, non si ha nemmeno un monolite che necessita di refactoring.

Sviluppare microservizi significa sviluppare sistemi distribuiti, e i sistemi distribuiti sono difficili, e lo sono ancora di più se si fanno scelte che li rendono ancora più difficili. Tentare di creare microservizi senza un'adeguata automazione della distribuzione e del monitoraggio, o senza cloud service gestiti per supportare la nuova infrastruttura, che si presenta eterogenea e complessa, significa andare incontro a molti problemi inutili. Risparmiarsi questa inutile fatica significa avere maggior tempo per preoccuparsi dello stato.

Se si va troppo oltre con il "micro" nei microservizi, i costi generali e la complessità che ci si trova ad affrontare potrebbero facilmente superare i vantaggi complessivi di un'architettura di microservizi. È meglio orientarsi verso servizi più grandi e suddividerli solo quando iniziano a sviluppare le caratteristiche che i microservizi possono risolvere: ad esempio, la difficoltà e la lentezza nell'implementazione delle modifiche, l'eccessiva complessità di un modello di dati comune o diversi requisiti di carico/scalabilità delle diverse parti del servizio.

Microservizi e SOA sono spesso confusi tra loro, dato che, al loro livello più elementare, si focalizzano entrambi sul creare singoli componenti riutilizzabili che possano essere utilizzati da altre applicazioni. La differenza tra microservizi e SOA è che i progetti di microservizi in genere comportano il refactoring di un'applicazione in modo che sia più facile da gestire, mentre SOA si occupa di modificare il modo in cui i servizi IT funzionano a livello aziendale. Un progetto di microservizi che si trasforma in un progetto SOA probabilmente crollerà sotto il suo stesso peso.

Netflix è stato uno dei primi pionieri dell'architettura a microservizi a creare e gestire un'applicazione che rappresentava un terzo di tutto il traffico internet: una sorta di tempesta perfetta che ha richiesto la creazione di moltissimo codice e servizi personalizzati che non sono necessari per le applicazioni più comuni. È molto meglio iniziare con un ritmo gestibile, evitando di aumentare la complessità e utilizzando il maggior numero possibile di strumenti standard.

Se desideri maggiori informazioni su come utilizzare i microservizi o se hai bisogno di migliorare le tue competenze in materia di microservizi, prova uno di questi tutorial:

• Introduzione ai microservizi
  
• Quick lab: creare microservizi per applicazioni web altamente scalabili con Node.js
  
• Inizia con i microservizi Java utilizzando Spring Boot e Cloudant
  
• Crea, esegui e distribuisci microservizi Spring in cinque minuti
  
• Microservizi, SOA e API: amici o nemici?