Che cosa sono i microservizi?

È 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 una survey IBM del 2021 condotta 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:

Distribuibili in modo indipendente

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 dei microservizi si adatta perfettamente a questa tendenza perché consente a un'organizzazione di creare piccoli team interfunzionali intorno 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.

Lo strumento giusto per ogni lavoro

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.

Scalabilità precisa

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.

I microservizi, tuttavia, presentano anche delle criticità:

Gli importanti vantaggi 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 le versioni precedenti. 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 della survey IBM già citata rivelavano che il 56% degli attuali non utilizzatori avrebbe adottato probabilmente, o molto probabilmente, i microservizi nei due anni successivi, mentre 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 effettivamente 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:

I microservizi non sono necessariamente rilevanti per il cloud computing, ma ci sono alcune ragioni importanti per cui sono così frequentemente associati, ragioni che vanno oltre il fatto che i microservizi e il cloud siano rispettivamente uno stile architetturale e una destinazione di hosting popolare per le 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 servizi cloud 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:

Pattern backend for frontend (BFF)

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.

Pattern di entità e aggregati

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.

Pattern di individuazione dei servizi

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.

Pattern di microservizi adapter

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.

Pattern di applicazioni strangler

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:

Non creare microservizi

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.

Non realizzare microservizi senza DevOps o servizi cloud

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 servizi cloud 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. 

Non creare troppi microservizi rendendoli troppo piccoli

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.

Non trasformare i microservizi in SOA

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.

Non cercare di essere Netflix

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?