Microservizi

menu icon

Microservizi

L'architettura di microservizi è un approccio in cui una singola applicazione è composta da molti servizi più piccoli accoppiati in modo lasco e implementabili in modo indipendente.

Cosa sono i microservizi?

I microservizi (o architettura dii microservizi) sono un approccio architetturale nativo del cloud in cui una singola applicazione è composta da molti componenti, o servizi più piccoli accoppiati in modo lasco e implementabili in modo indipendente. Questi servizi di norma

  • hanno un loro stack di tecnologia, che comprende database e modello di gestione dei dati;
  • comunicano tra loro su una combinazione di API REST, streaming di eventi e broker di messaggi; e
  • sono organizzati in base alla capacità di business, con la linea che separa i servizi spesso indicata come contesto delimitato.

Mentre gran parte della discussione sui microservizi è ruotata intorno alle caratteristiche e alle definizioni architetturali, il loro valore può essere più comunemente inteso attraverso i semplici vantaggi di business e organizzativi:

  • Il codice può essere aggiornato più facilmente - nuove funzioni o funzionalità possono essere aggiunte senza mettere mano all'intera applicazione
  • I team possono utilizzare diversi stack e diversi linguaggi di programmazione per i diversi componenti.
  • I componenti possono essere ridimensionati indipendentemente l'uno dall'altro, riducendo gli sprechi e i costi associati alla necessità di ridimensionare intere applicazioni, poiché una singola funzione potrebbe dover gestire un carico eccessivo.

I microservizi possono anche essere compresi in base a quello che non sono. I due confronti effettuati più di frequente con l'architettura di microservizi sono l'architettura monolitica e SOA (service-oriented architecture).

La differenza tra i microservizi e l'architettura monolitica è che i microservizi formano una singola applicazione da molti servizi più piccoli e accoppiati in modo lasco, in contrapposizione con l'approccio monolitico di un'applicazione di grandi dimensioni e accoppiata in modo stretto

Per saperne di più sulle differenze tra microservizi e architettura monolitica, guarda questo video (6:37):

 

Le differenze tra microservizi e SOA possono essere un po' meno chiare. Sebbene sia possibile tracciare le differenze tecniche tra microservizi e SOA, soprattutto per quanto riguarda il ruolo dell'ESB (enterprise service bus), è più facile considerare la differenza come una questione di ambito. SOA è stato uno sforzo a livello aziendale per standardizzare il modo in cui tutti i servizi web in un'organizzazione comunicavano e si integravano tra loro mentre l'architettura di microservizi è specifica per le applicazioni.

Per ulteriori dettagli, consulta il post "SOA vs. Microservices: What's the Difference?".

In che modo i microservizi offrono dei vantaggi all'organizzazione

È 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 meglio un modello operativo desiderato. In un recente sondaggio condotto da IBM e rivolto a più di 1.200 sviluppatori e dirigenti del settore IT, l'87% degli utenti dei microservizi concordava che l'adozione dei microservizi vale la spesa e gli sforzi. Puoi esplorare ulteriori prospettive sui vantaggi e le sfide dei microservizi utilizzando lo strumento interattivo di seguito:

(Fonte: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

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 promettono alle organizzazioni un antidoto alla profonda frustrazione associata a modifiche di piccola entità che richiedono un enorme dispendio di tempo. Non è necessario un dottorato in informatica per vedere o capire il valore di un approccio che facilita meglio la velocità e l'agilità.

La velocità non è però il solo valore derivante dal progettare i servizi in questo modo. Un modello organizzativo emergente comune consiste nell'aggregare dei team interfunzionali intorno a a un servizio, un prodotto o un problema di business. Il modello di microservizi si adatta perfettamente a questa tendenza perché consente a 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 in modo lasco 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. Ciò si traduce in una pessima architettura, ed è frustrante per gli sviluppatori che sono costantemente consapevoli che è disponibile un modo migliore e più efficiente per creare 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 più contenute con una tecnologia più desiderabile man mano che diventa disponibile.

Ridimensionamento preciso

Con i microservizi, è possibile non solo implementare ma anche ridimensionare ogni singolo servizio separatamente. Il vantaggio che ne deriva è ovvio: eseguiti in modo corretto, i microservizi richiedono meno infrastruttura rispetto alle applicazioni monolitiche perché consentono un ridimensionamento preciso dei soli componenti che lo richiedono, invece dell'intera applicazione come è il caso con le applicazioni monolitiche.

Non mancano però anche le sfide

I notevoli vantaggi dei microservizi si accompagnano con notevoli sfide. Il passaggio da una struttura monolitica ai microservizi si traduce in molta più complessità di gestione - molti più servizi, creati da molti più team, implementati in molte più ubicazioni. 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ù opportunità 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 sfide.

Ciononostante, queste sfide non stanno impedendo a chi non ha ancora adottato i microservizi di procedere ad adottarli - né stanno impedendo a cui li ha già adottati di approfondire il loro impegno nei microservizi. I dati di un nuovo sondaggio di IBM evidenziano che il 56% degli attuali non utenti probabilmente o molto probabilmente adotterà i microservizi entro i prossimi due anni e il 78% degli attuali utenti di microservizi aumenterà probabilmente il tempo, le risorse economiche e gli sforzi che ha investito nei microservizi (vedi la figura 1).

Tre grafici a torta che mostrano il 56%, il 78% e il 59%

Figura 1: I microservizi sono qui per restare. Entro i prossimi due anni, il 56% dei non utenti adotterà probabilmente i microservizi, il 78% degli utenti aumenterà il suo investimento nei microservizi e il 59% delle applicazioni verrà creato con i microservizi. (Fonte: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

I microservizi consentono e al tempo stesso hanno bisogno di DevOps

L'architettura di microservizi è spesso descritta come ottimizzata per DevOps e CI/CD (continuous integration/continuous delivery) e, nel contesto dei piccoli servizi che possono essere implementati frequentemente, è facile comprendere perché.

Un altro modo però per guardare alla relazione tra microservizi e DevOps è che le architetture di microservizi in effetti hanno bisogno 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 accompagna i microservizi, sarebbe poco saggio approcciare i microservizi senza investimenti significativi nell'automazione di implementazione, monitoraggio e ciclo di vita.

Nel seguente video, Andrea Crawford ci offre un approfondimento di DevOps:

Tecnologie e strumenti abilitanti fondamentali

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 loro 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 fondamentali. 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.

Nel video "Kubernetes Explained," Sai Vennam ci offre una panoramica completa di tutto quanto riguarda Kubernetes:

 

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 stateless, 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 approccio di polling costante, di continua interrogazione dello stato, per tenere i servizi aggiornati semplicemente non è funzionale.

È 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, potrebbe essere 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.

Microservizi e servizi cloud

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 all'implementazione e al ridimensionamento dei componenti singolarmente. Anche se tali vantaggi persisterebbero in una certa misura nell'infrastruttura on-premises, è 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 fattore forse ancora più importante, un altro principale vantaggio dei microservizi è la capacità di ogni singolo componente di adottare lo stack ottimale per il suo specifico lavoro. La proliferazione di stack può portare a una complessità e a un sovraccarico gravosi, quando ti occupi personalmente della sua 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.

Pattern comuni

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 funziona con qualsiasi interfaccia ma che potrebbe ripercuotersi negativamente sulle prestazioni di frontend.
  • Pattern di entità e aggregato: un'entità è un oggetto distinto dalla sua identità. Ad esempio, su un sito di e-commerce, un oggetto Prodotto potrebbe 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.
  • Patten di rilevamento dei servizi: 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 pattern di rilevamento dei servizi servendosi dei controlli dello stato di integrità e dei malfunzionamenti dei servizi come elementi per innescare un ribilanciamento del carico.
  • Pattern di microservizi di 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 basa 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 saperne di più su questi pattern in "How to use development patterns with microservices (part 4)". IBM Developer fornisce anche molte informazioni se desideri saperne di più sugli altri pattern di codice dei microservizi.

Anti-pattern

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, riformulate come i "non" con i microservizi, sono indicate di seguito:

  • La prima regola dei microservizi è non creare microservizi: per esprimere il concetto in modo più accurato, non iniziare con i microservizi. I microservizi sono un modo per gestire la complessità una volta che le applicazioni sono diventate troppo grandi e difficili da maneggiare per essere aggiornate e gestite facilmente. 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 creare 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 ora estesa ed eterogenea infrastruttura, significa andarsi a cercare tanti problemi inutili. Risparmiati i problemi, così puoi dedicare il tuo tempo a preoccuparti dello stato.
  • Non creare troppi microservizi facendoli troppo piccoli: se ti spingi troppo oltre con il concetto di "micro" nei microservizi, ti potresti ritrovare 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 l'implementazione di modifiche sta cominciando a essere difficile e lenta, 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, sono entrambi interessati a creare 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 fa 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 a 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.

Tutorial: Sviluppa competenze nell'area nei microservizi

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:

Microservizi e IBM Cloud

I microservizi consentono uno sviluppo innovativo alla velocità del business moderno. Scopri come puoi sfruttare la scalabilità e la flessibilità del cloud implementando microservizi indipendenti negli ambienti cloud. Scopri come potresti modernizzare le tue applicazioni con l'aiuto di IBM. 

Passa alla fase successiva:

Inizia con un Account IBM Cloud oggi stesso.