I microservizi (o architettura a microservizi) sono un approccio architettonico nativo del cloud in cui una singola applicazione è composta da molti componenti, o servizi, più piccoli, debolmente accoppiati e distribuibili in modo indipendente. Questi servizi di norma
- hanno il proprio stack tecnologico, compreso il modello di gestione dei dati e del database;
- comunicano tra loro tramite una combinazione di API REST, streaming di eventi e message broker; e
- sono organizzati in base alla capacità di business, con la linea che separa i servizi spesso indicata come contesto delimitato.
Nonostante vi sia un gran numero di riflessioni sui microservizi che ruotano intorno alle definizioni e alle caratteristiche architettoniche, il loro valore può essere più facilmente compreso attraverso i benefici aziendali e organizzativi che determinano:
- Il codice può essere aggiornato più facilmente, è possibile aggiungere nuove caratteristiche o funzionalità senza toccare l'intera applicazione
- I team possono utilizzare diversi stack e diversi linguaggi di programmazione per i diversi componenti.
- I componenti possono essere scalati indipendentemente l'uno dall'altro, riducendo così gli sprechi e i costi associati alla necessità di scalare intere applicazioni solo perché una singola funzione dovrà gestire un carico superiore.
Cosa non sono i microservizi
I microservizi potrebbero anche essere considerati come in contrasto con due precedenti architetture applicative: l'architettura monolitica e la SOA (Service-Oriented Architecture).
La differenza tra i microservizi e l'architettura monolitica è che i microservizi formano una singola applicazione partendo da molti servizi più piccoli, debolmente accoppiati, in contrapposizione con l'approccio monolitico che prevede un'applicazione di grandi dimensioni, accoppiata in modo rigido
Le differenze tra microservizi e SOA possono risultare un po' meno evidenti. Mentre si possono distinguere delle differenze tecniche tra i microservizi e la SOA, specialmente per quanto riguarda il ruolo dell'Enterprise Service Bus (ESB), è più facile pensare che la differenza dipenda dal campo di applicazione. SOA era una risposta di livello aziendale per standardizzare il modo in cui tutti i servizi web in un'organizzazione parlano e si integrano tra loro, mentre l'architettura dei microservizi è specifica per l'applicazione.
La pubblicazione "SOA vs. Microservices: What's the Difference?" fornisce ulteriori dettagli.
Per saperne di più sulle differenze tra microservizi e architettura monolitica, guarda questo video:
È probabile che i microservizi siano popolari tra i dirigenti e i responsabili di progetto almeno quanto lo sono tra gli sviluppatori. Questa è una delle caratteristiche più insolite dei microservizi perché l'entusiasmo architetturale è di solito riservato ai team di sviluppo software. Il motivo è che i microservizi riflettono meglio il modo in cui molti business leader vogliono strutturare e portare avanti i loro team e processi di sviluppo.
In altre parole, i microservizi sono un modello architetturale che facilita l'applicazione di un modello operativo desiderato. In un recente sondaggio condotto da IBM e rivolto a più di 1.200 sviluppatori e dirigenti del settore dell'IT, l'87% degli utenti dei microservizi concordava che l'adozione dei microservizi valesse la spesa e gli sforzi.
Ecco solo alcuni dei vantaggi aziendali dei microservizi.
Implementabili in modo indipendente
Forse la singola caratteristica più importante dei microservizi è che poiché i servizi sono più piccoli e implementabili in modo indipendente, non è più necessario un iter lungo e complesso per modificare una riga di codice o aggiungere una nuova funzione in un'applicazione.
I microservizi offrono alle organizzazioni un antidoto alle frustrazioni viscerali associate a quei piccoli cambiamenti che richiedono enormi quantità di tempo. Non è necessario un dottorato in informatica per vedere o capire il valore di un approccio che agevola velocità e agilità.
Ma la velocità non è il solo valore derivante dal progettare i servizi in questo modo. Un modello organizzativo emergente comune consiste nell'aggregare dei team interfunzionali intorno a un servizio, un prodotto o un problema di business. Il modello di microservizi si adatta perfettamente a questa tendenza perché consente a un'organizzazione di creare piccoli team interfunzionali intorno a un servizio o una raccolta di servizi e di farli lavorare in modo agile.
L'accoppiamento debole dei microservizi sviluppa anche un certo grado di isolamento dei malfunzionamenti e una migliore resilienza nelle applicazioni. Le piccole dimensioni dei servizi, poi, combinate con i loro chiari confini e pattern di comunicazione, consentono ai nuovi membri del team di comprendere più facilmente la base di codice e di apportarvi il loro contributo rapidamente, un chiaro vantaggio in termini sia di velocità che di morale dei dipendenti.
Lo strumento giusto per il lavoro
Nei tradizionali pattern architetturali a più livelli, un'applicazione di norma condivide uno stack comune con un database relazionale di grandi dimensioni che supporta l'intera applicazione. Questo approccio presenta diversi ovvi inconvenienti e quello più significativo è che ogni componente di un'applicazione deve condividere uno stack, un modello di dati e un database comuni, anche se esiste un chiaro strumento che si presta meglio al lavoro per determinati elementi. È una cattiva architettura, ed è frustrante per gli sviluppatori, consapevoli che è disponibile un modo migliore e più efficiente per costruire questi componenti.
In un modello di microservizi, invece, i componenti sono implementati in modo indipendente e comunicano su una combinazione di REST, streaming di eventi e broker di messaggi, il che rende possibile l'ottimizzazione del relativo stack per ogni singolo servizio. La tecnologia cambia di continuo ed è molto più facile e meno costoso migliorare un'applicazione formata da più servizi di dimensioni contenute con una tecnologia più interessante man mano che diventa disponibile.
Ridimensionamento preciso
Con i microservizi, è possibile non solo implementare ma anche ridimensionare ogni singolo servizio separatamente. Il beneficio che ne deriva è ovvio: eseguiti correttamente, i microservizi richiedono meno infrastrutture rispetto alle applicazioni monolitiche perché permettono di scalare soltanto i componenti che lo richiedono, invece dell'intera applicazione nel caso delle applicazioni monolitiche.
Non mancano però le sfide
I notevoli vantaggi dei microservizi si accompagnano a notevoli sfide. Passare da monoliti a microservizi significa molta più complessità di gestione, molti più servizi, creati da molti più team, distribuiti in molti più posti. I problemi in un servizio possono causare, o essere causati da, problemi in altri servizi. I dati di registrazione (utilizzati per il monitoraggio e la risoluzione dei problemi) sono più voluminosi e possono essere incoerenti tra i servizi. Le nuove versioni possono causare dei problemi di compatibilità con le versioni precedenti. Le applicazioni coinvolgono più connessioni di rete, il che significa più possibilità di problemi di latenza e connettività. Un approccio DevOps (come leggerai di seguito) può affrontare molti di questi problemi, ma l'adozione di DevOps comporta per sua natura delle difficoltà.
Tuttavia queste sfide non impediscono a coloro che non adottano i microservizi di sceglierli, o a coloro che li adottano di approfondire i propri sforzi in materia di microservizi. I recenti dati del sondaggio IBM rivelano che il 56% degli attuali non utenti di microservizi è probabile o molto probabile che li adotti entro i prossimi due anni, e il 78% degli attuali utenti di microservizi probabilmente aumenterà il tempo, il denaro e lo sforzo che ha investito nei microservizi.
L'architettura di microservizi è spesso descritta come ottimizzata per DevOps e CI/CD (continuous integration/continuous delivery) e, vista la possibilità di implementare frequentemente piccoli servizi, è facile comprendere perché.
Un altro modo però per guardare alla relazione tra microservizi e DevOps è che le architetture di microservizi in effetti necessitano di DevOps per avere successo. Se da una parte presentano una serie di inconvenienti di cui si è discusso in precedenza in questo articolo, dall'altra le applicazioni monolitiche presentano il vantaggio di non essere un sistema distribuito complesso con più parti mobili e stack tecnologici indipendenti. D'altro canto, tenuto conto del notevole aumento della complessità, delle parti mobili e delle dipendenze che accompagnano i microservizi, sarebbe poco saggio approcciarli senza investimenti significativi nell'automazione di implementazione, monitoraggio e ciclo di vita.
Nel seguente video, Andrea Crawford ci offre un approfondimento su DevOps:
Anche se è vero che in un'architettura di microservizi è possibile utilizzare praticamente qualsiasi strumento o linguaggio moderno, ci sono alcuni strumenti di base che sono diventati essenziali per i microservizi e che praticamente li definiscono:
Container, Docker e Kubernetes
Uno degli elementi chiave di un microservizio è che è generalmente piuttosto piccolo. (Non c'è una quantità arbitraria di codice che determina se qualcosa è o non è un microservizio, ma "micro" è proprio lì nel nome).
Quando Docker ha segnato l'inizio dell'era moderna dei container nel 2013, ha introdotto anche il modello di calcolo che sarebbe diventato quello più strettamente associato ai microservizi. Poiché i singoli container non hanno il sovraccarico di un proprio sistema operativo, sono più piccoli e leggeri delle tradizionali macchine virtuali ed è possibile avviarli e fermarli più rapidamente, il che li rende una risposta perfetta ai più piccoli e leggeri servizi presenti nelle architetture di microservizi.
Con la proliferazione di servizi e container, l'orchestrazione e la gestione di gruppi di container di grandi dimensioni è diventata rapidamente una delle sfide principali. Kubernetes, una piattaforma di orchestrazione dei container open source, si è affermata come una delle soluzioni di orchestrazione di più ampio utilizzo grazie al suo elevato livello di efficienza.
Gateway API
I microservizi spesso comunicano tramite API, soprattutto quando stabiliscono inizialmente lo stato. Anche se in effetti i client e i servizi possono comunicare tra loro direttamente, i gateway API sono spesso un utile livello intermedio, in particolare con il crescere del numero di servizi in un'applicazione nel corso del tempo. Un gateway API funge da proxy inverso per i client instradando le richieste, distribuendole su più servizi e fornendo ulteriore sicurezza e autenticazione.
Sono tante le tecnologie che possono essere utilizzate per implementare i gateway API, comprese le piattaforme di gestione di API, ma se l'implementazione dell'architettura di microservizi sta avvenendo servendosi di container e Kubernetes, il gateway viene di norma implementato utilizzando Ingress o, in tempi più recenti, Istio.
Messaggistica e streaming di eventi
Mentre la best practice potrebbe consistere nel progettare dei servizi senza stato, lo stato esiste comunque e i servizi devono esserne a conoscenza. E mentre una chiamata API è spesso un modo efficace per stabilire inizialmente lo stato per un determinato servizio, non è un modo particolarmente efficace per restare aggiornati. Un polling costante, un approccio del tipo "è arrivato il momento?" per mantenere i servizi aggiornati semplicemente non è pratico.
È invece necessario associare le chiamate API che servono a stabilire lo stato alla messaggistica o allo streaming di eventi in modo da consentire ai servizi di trasmettere le variazioni di stato e alle altre parti interessate di venirne a conoscenza e adeguarsi di conseguenza. Questo lavoro è probabilmente più adatto a un broker di messaggi per usi generici, ma ci sono casi in cui una piattaforma di streaming di eventi, come Apache Kafka, possa rivelarsi una buona scelta. Combinando poi i microservizi con un'architettura basata sugli eventi, gli sviluppatori possono creare dei sistemi distribuiti, altamente scalabili, estensibili e a tolleranza d'errore che possono utilizzare ed elaborare ampie quantità di eventi o informazioni in tempo reale.
Serverless
Le architetture serverless portano alcuni dei pattern di cloud e microservizi fondamentali alla loro conclusione logica. Nel caso di serverless, l'unità di esecuzione non è solo un piccolo servizio ma una funzione, che spesso può consistere in solo qualche riga di codice. La linea di demarcazione tra una funzione serverless e un microservizio non è netta, ma per funzione si intende di solito qualcosa di dimensioni ancora più contenute di un microservizio.
Un punto di affinità comune tra architetture serverless e piattaforme FaaS (Functions-as-a-Service) consiste nell'interesse di entrambe a creare unità di implementazione più piccole ed eseguire un ridimensionamento che risponda in modo preciso alla domanda.
I microservizi non sono necessariamente pertinenti in modo esclusivo al cloud computing ma esistono diversi e importanti motivi per cui vanno così spesso di pari passo, motivi che vanno oltre l'ampia diffusione dei microservizi come stile architetturale per le nuove applicazioni e l'ampio utilizzo del cloud come destinazione di hosting per le nuove applicazioni.
Tra i principali vantaggi dell'architettura di microservizi vanno annoverati quelli in termini di utilizzo e costi associati alla possibilità di implementare e ridimensionare i componenti singolarmente. Anche se tali vantaggi persisterebbero in una certa misura nell'infrastruttura on-premise, è la combinazione di piccoli componenti ridimensionabili indipendentemente con un'infrastruttura on-demand e con pagamento a consumo che offre una vera ottimizzazione dei costi.
In secondo luogo, e questo è forse più importante, un altro vantaggio primario dei microservizi è che ogni singolo componente può adottare lo stack più adatto al suo lavoro specifico. La proliferazione di stack può portare a una complessità e a un sovraccarico gravosi, quando ti occupi personalmente della loro gestione, ma l'utilizzo dello stack di supporto come servizi cloud può ridurre drasticamente le sfide di gestione. In altre parole, pur non essendo impossibile, non è consigliabile implementare una tua infrastruttura di microservizi, soprattutto quando sei all'inizio.
All'interno delle architetture di microservizi esistono molti utili pattern comuni di design, comunicazione e integrazione che aiutano a rispondere ad alcune delle sfide e opportunità più frequenti, comprese le seguenti:
Pattern BFF (Backend-for-frontend). Questo pattern inserisce un livello tra l'esperienza utente e le risorse che tale esperienza richiede. Ad esempio, un'app utilizzata su un desktop avrà dimensioni dello schermo, visualizzazione e limiti di prestazioni differenti rispetto a un dispositivo mobile. Il pattern BFF consente agli sviluppatori di creare e supportare un singolo tipo di backend per ogni interfaccia utente utilizzando le migliori opzioni per tale interfaccia, invece di cercare di supportare un backend generico che funzioni con qualsiasi interfaccia ma che potrebbe ripercuotersi negativamente sulle prestazioni di frontend.
Entità e pattern aggregati. Un'entità è un oggetto distinto in base alla sua identità. Ad esempio, su un sito di e-commerce, un oggetto Prodotto può essere distinto per nome prodotto, tipo e prezzo. Un aggregato è una raccolta di entità correlate che deve essere trattata come un'unica unità. Quindi, per il sito di e-commerce, un Ordine è una raccolta (aggregato) di prodotti (entità) ordinati da un acquirente. Questi pattern sono utilizzati per classificare i dati in modi significativi.
Pattern di rilevamento del servizio. Questi pattern aiutano le applicazioni e i servizi a trovarsi reciprocamente. In un'architettura di microservizi, le istanze di servizio variano dinamicamente a causa del ridimensionamento, degli upgrade, dei malfunzionamenti dei servizi e anche della terminazione dei servizi. Questi pattern forniscono meccanismi di rilevamento per far fronte a questa transitorietà. Il bilanciamento del carico può utilizzare i modelli di rilevamento del servizio utilizzando i controlli dello stato di integrità e dei malfunzionamenti dei servizi come dei trigger per riequilibrare il traffico.
Pattern di microservizi dell'adattatore. Pensa ai pattern di adattatore come pensi agli adattatori delle prese che usi quando viaggi in un altro paese. Lo scopo dei pattern di adattatore è quello di aiutare a tradurre le relazioni tra classi od oggetti che sono altrimenti incompatibili. Un'applicazione che si basi su API di terze parti potrebbe aver bisogno di utilizzare un pattern di adattatore per garantire che l'applicazione e le API possano comunicare.
Pattern di applicazione Strangler. Questi pattern aiutano a gestire il refractoring di un'applicazione monolitica in applicazioni di microservizi. Il nome colorito (strangler significa strangolatore) si riferisce al modo in cui una pianta rampicante (i microservizi) lentamente e nel corso del tempo prende il sopravvento su un albero e lo strangola (un'applicazione monolitica).
Puoi trovare ulteriori informazioni su questi modelli in "How to use development patterns with microservices (part 4)". IBM Developer fornisce anche molte informazioni se si desidera conoscere altri pattern di codice di microservizi.
Se da una parte esistono molti pattern per creare dei microservizi validi, dall'altra ne esiste un numero altrettanto importante che può mettere rapidamente in difficoltà qualsiasi team di sviluppo. Alcune delle cose da evitare con i microservizi sono indicate di seguito:
La prima regola dei microservizi è, non effettuare il build dei microservizi. Più precisamente, non iniziare dai microservizi. I microservizi sono un modo per gestire la complessità una volta che le applicazioni sono diventate troppo grandi e difficili da aggiornare e gestire. Solo quando cominci ad avvertire l'insinuarsi della fatica e della complessità dell'applicazione monolitica vale la pena prendere in considerazione in che modo potresti eseguire il refactoring di tale applicazione in servizi più piccoli. Finché non avverti questa fatica, in verità non hai neanche un'applicazione monolitica di cui è necessario eseguire il refactoring.
Non eseguire i microservizi senza DevOps o servizi cloud. Creare microservizi significa creare sistemi distribuiti e i sistemi distribuiti sono difficili da gestire (e lo sono ancora di più se fai delle scelte che complicano ulteriormente tale gestione). Provare a creare dei microservizi senza a) un'adeguata automazione dell'implementazione e del monitoraggio o b) dei servizi cloud gestiti per supportare la tua infrastruttura ormai estesa ed eterogenea, significa andarsi a cercare tanti problemi inutili. Risparmiati i problemi, così puoi dedicare il tuo tempo a preoccuparti dello stato.
Non creare troppi microservizi rendendoli troppo piccoli. Se ti spingi troppo oltre con il concetto di "micro" nei microservizi, potresti ritrovarti facilmente di fronte a un sovraccarico e una complessità che superano i vantaggi complessivi di un'architettura di microservizi. È meglio orientarsi verso servizi più grandi e quindi suddividerli solo quando iniziano a sviluppare le caratteristiche che i microservizi risolvono, ossia se l'implementazione di modifiche sta cominciando a essere difficile e lenta, se un modello di dati comune sta diventando troppo complesso o parti diverse del servizio hanno requisiti di carico e dimensioni differenti.
Non trasformare i microservizi in SOA. I microservizi e SOA (service-oriented architecture) sono spesso confusi tra loro dato che, al loro livello più basilare, entrambi creano dei singoli componenti riutilizzabili che possono essere utilizzati da altre applicazioni. La differenza tra i microservizi e SOA è che i progetti di microservizi di norma 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 collasserà sotto il suo stesso peso.
Non provare ad essere Netflix. Netflix è stato uno dei primi pionieri dell'architettura di microservizi quando si è impegnata nella creazione e nella gestione di un'applicazione che rappresentava un terzo di tutto il traffico su Internet, una sorta di tempesta perfetta che l'ha obbligata a creare tanto codice e tanti servizi personalizzati che non sono necessari per un'applicazione media. È molto meglio se inizi a un ritmo che puoi gestire, evitando le complessità e utilizzando quanti più strumenti pronti all'uso possibile.
Se sei pronto a saperne di più su come usare i microservizi, o se hai bisogno di sviluppare le tue competenze nell'area dei microservizi, prova uno di questi tutorial:
Implementa cluster Kubernetes completamente gestiti e altamente disponibili per le tue applicazioni containerizzate con un singolo clic
Distribuisci e gestisci applicazioni containerizzate in modo coerente su ambienti on-premise, edge computing e con cloud pubblico di qualsiasi fornitore
Esegui immagini di container, processi batch o codice sorgente come carichi di lavoro serverless, senza necessità di dimensionamento, distribuzione, networking o scaling.
DevOps velocizza la fornitura di software di qualità superiore combinando e automatizzando il lavoro dei team di sviluppo software e di operazioni IT.
I container sono unità eseguibili di software che impacchettano il codice dell'applicazione insieme alle dipendenze delle sue librerie e possono essere eseguiti ovunque, sia sul desktop che sull'IT tradizionale o sul cloud.
Kubernetes è una piattaforma di orchestrazione dei container open source che automatizza l'implementazione, la gestione e la scalabilità delle applicazioni containerizzate.