Home

topics

microservices

Che cosa sono i microservizi?
Crea con i microservizi e IBM Registrati per ricevere gli aggiornamenti cloud
Immagine che mostra come l'architettura di microservizi scompone un'applicazione monolitica in piccoli servizi distribuibili
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.

Cosa non sono i microservizi

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.

Ottieni flessibilità sul posto di lavoro con DaaS

Scopri in che modo il Desktop as a Service (DaaS) consente alle aziende di raggiungere lo stesso livello di prestazioni e sicurezza della distribuzione delle applicazioni on-premise.

Contenuti correlati Registrati per la guida sulla modernizzazione delle app
I vantaggi dei microservizi per un'organizzazione

È 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.

I microservizi consentono e richiedono un approccio DevOps

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 principali strumenti e tecnologie per l'attuazione

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:

Container, Docker e Kubernetes

Uno degli aspetti fondamentali dei microservizi è che sono in genere piuttosto piccoli. 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.

API gateway

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, comprese le API management platform, ma se l'architettura di microservizi viene implementata utilizzando dei container e Kubernetes, il gateway viene in genere implementato utilizzando Ingress o, più recentemente, Istio.

Messaggistica ed event streaming

Sebbene la scelta ideale 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 particolarmente efficace per rimanere aggiornati. Un approccio che si basa su continue verifiche per garantire l'aggiornamento di un servizio non è affatto 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 e le altre parti interessate possano recepire tali cambiamenti e adattarsi 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.

Serverless

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.

Microservizi e cloud service

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.

Pattern comuni

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).

Anti-pattern

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.

Tutorial: sviluppare competenze sui microservizi
Soluzioni correlate
Red Hat® OpenShift® on IBM Cloud®

Distribuisci cluster di Kubernetes ad alta disponibilità e completamente gestiti per le tue applicazioni containerizzate con un solo clic.

Scopri Red Hat OpenShift su IBM Cloud
IBM cloud satellite

Distribuisci e gestisci applicazioni containerizzate in modo coerente negli ambienti on-premise, di edge computing e cloud pubblico di qualsiasi fornitore.

Esplora IBM cloud satellite
IBM® Cloud Code Engine

Esegui immagini di container, processi batch o codice sorgente come workload serverless, senza necessità di dimensionamento, implementazione, rete o scalabilità

Esplora IBM cloud code engine
Risorse Cos'è DevOps?

DevOps accelera la distribuzione di software di qualità superiore combinando e automatizzando il lavoro dei team di sviluppo software e delle operazioni IT.

Cosa sono i contenitori?

I contenitori sono unità eseguibili di software che impacchettano il codice dell'applicazione insieme alle relative dipendenze delle librerie e possono essere eseguiti ovunque, sia su desktop, IT tradizionale o cloud.

Cos'è Kubernetes?

Kubernetes è una piattaforma open source di orchestrazione del contenitore che automatizza distribuzione, gestione e scalabilità delle applicazioni containerizzate.

Oltre le tendenze: una breve storia dei pattern di microservizi

Esplora l'impatto degli schemi di progettazione software del passato sulla creazione di microservizi.

Sfide e vantaggi dello stile architetturale a microservizi, parte 1

Esplora le insidie e le sfide associate all'utilizzo dei microservizi.

Fai il passo successivo

Red Hat OpenShift on IBM Cloud offre agli sviluppatori un modo rapido e sicuro per containerizzare e implementare i carichi di lavoro aziendali nei cluster Kubernetes. Delega attività noiose e ripetitive che coinvolgono la gestione della sicurezza, la gestione della conformità, la gestione dell'implementazione e la gestione continua del ciclo di vita.

Scopri Red Hat OpenShift su IBM Cloud Inizia gratuitamente