In giro per il web è facile trovare articoli sui microservizi.
Tuttavia, non è sempre facile comprenderli.
Spesso, se non si è del settore, se ne esce più confusi di prima.
Per questo abbiamo deciso di prendere le nostre conoscenze, semplificarle all’osso e metterle qui a disposizione di chi non ha ancora ben chiaro il concetto di microservizio.
Questo non sarà un articolo infarcito di tecnicismi complicati, perché il nostro obiettivo non è quello di fornire una conoscenza a 360 gradi sui microservizi, bensì di renderli immediatamente comprensibili.
Partiamo dalle basi: “microservizio” è composto da “micro” + “servizio”, il che, molto banalmente, significa “un servizio molto piccolo”.
A COSA SERVE QUESTO SERVIZIO MOLTO PICCOLO? PER COSA SI USA E DOVE SI TROVA?
I microservizi vengono utilizzati nello sviluppo di applicazioni.
Pensiamo all’applicazione come ad un alveare, in cui ogni singola ape corrisponde ad un microservizio. Ogni ape opera in modo indipendente, ma con l’obiettivo di contribuire a costruire, mantenere e sviluppare l’intero alveare.
Proprio come le api di un alveare, ogni microservizio ha un ciclo di sviluppo e distribuzione isolato, autonomo e indipendente.
Se ad un’ape si rompe un’ala, l’intero alveare crolla o si blocca perché lei non può più volare? No: continua a funzionare lo stesso.
Ciò significa che ogni microservizio costituisce una singola funzione del software che, interagendo con le altre funzioni, dà vita ad un’applicazione più ampia e più complessa, mantenendo al tempo stesso la propria indipendenza.
In contrapposizione all’architettura a microservizi, avrete sicuramente sentito parlare di “architettura monolitica”.
L’architettura monolitica funziona nel modo opposto: l’applicazione viene sviluppata come un unico pacchetto, e non come un insieme di funzioni diverse che agiscono in sinergia tra di loro.
Fatta questa distinzione basilare fra i due tipi di architettura, viene da chiedersi:
Per quale ragione si dovrebbe prediligere un’architettura a microservizi, più complessa e formata da tante parti diverse, a discapito di un’applicazione costituita da un unico pacchetto, apparentemente più semplice?
I microservizi, essendo tanti, piccoli e programmati ognuno con il proprio linguaggio, non saranno molto più difficili da gestire?
È vero che nell’architettura monolitica si usa un solo codice sorgente, un solo linguaggio di programmazione e che l’app è semplice da replicare e da testare. Ma questo vale se l’applicazione in questione ha dimensioni ridotte.
Se l’applicazione è di grandi dimensioni o deve essere modificata ed aggiornata con una certa frequenza, l’architettura monolitica rappresenta un limite.
I microservizi hanno una qualità molto importante: la resilienza.
Esattamente come le persone resilienti hanno la capacità di affrontare e superare un evento traumatico o un periodo di difficoltà, l’architettura a microservizi può continuare a funzionare nonostante gli errori.
Quindi, una funzione può essere eseguita ed elaborata anche se altre funzioni falliscono, il che significa evitare tempi di inattività e perdita di dati.
Abbiamo anche parlato di indipendenza dei microservizi.
Con questo concetto intendiamo che ogni microservizio può essere implementato con il linguaggio di programmazione più adatto al suo scopo e che un team di programmatori lavora a quello specifico microservizio.
Ma a questo punto è lecito domandarsi:
COME COMUNICANO TRA LORO I MICROSERVIZI PER DARE VITA AD UN’APP EFFICIENTE? COME FA L’ARCHITETTURA A MICROSERVIZI A NON RISULTARE DISPERSIVA?
Un grande ruolo in questo lo giocano i container.
Potremmo definire i container come “pacchetti di installazione di un software”. Un container (come dice la parola stessa) contiene tutte le componenti che servono a quel microservizio per poter funzionare.
Con i container la gestione di storage, servizi, sicurezza e rete diventa più agevole. Le app basate su cloud sfruttano i microservizi containerizzati.
COME COMUNICANO TRA DI LORO I DIVERSI CONTAINER DI UN SOFTWARE?
Grazie all’API, acronimo di Application Programming Interface, ovvero un insieme di procedure che permettono lo scambio di informazioni tra componenti del software.
Per comprendere meglio come tutto questo funzioni nella pratica, prendiamo l’esempio più banale: un sito di e-commerce.
Un sito di e-commerce raggruppa varie funzioni:
- La parte dedicata alla ricerca del prodotto, tramite motore di ricerca interno;
- La parte con i suggerimenti sulla base delle preferenze dell’utente;
- La parte del carrellodell’utente;
- La parte dedicata al pagamento;
- La parte dedicata alla spedizione.
Se il sito di e-commerce è costruito con un’architettura a microservizi, ognuna di queste funzioni equivale ad un microservizio ed ognuna di queste funzioni potrà funzionare in modo indipendente dalle altre.
Ne consegue che, se ad esempio la parte dei suggerimenti si blocca per un qualche suo errore interno, l’utente sarà comunque in grado di usare il motore di ricerca, o di procedere ad un pagamento, senza che questo malfunzionamento in una specifica parte comprometta le altre.
C’è anche un ulteriore aspetto da considerare: i microservizi, nei loro container, possono essere distribuiti su più infrastrutture e server, così da non appesantire un server solo.
Si potrà poi ricorrere a specifiche piattaforme, come Kubernetes, che avranno il compito di orchestrare e gestire i container.
Riepiloghiamo quindi i vantaggi di un’architettura a microservizi:
- Ogni funzione dell’app è indipendente dalle altre;
- Ogni funzione dell’app può essere sviluppata con il linguaggio di programmazione più appropriato;
- Gli aggiornamenti dell’app sono più agili, perché non è necessario modificare tutte le singole funzioni, ma solo quella interessata;
- Per lo stesso motivo, si può scalare un microservizio alla volta senza doverli scalare tutti insieme;
- Un microservizio di una applicazione può essere integrato in un’altra applicazione;
- Si possono distribuire i microservizi su più infrastrutture e server, a seconda delle esigenze aziendali.
Tra le applicazioni più famose che utilizzano questo tipo di architettura rientrano Amazon, Netflix, eBay e Spotify.
Questa era solo una prima infarinatura generale sui microservizi.
Naturalmente il discorso è molto più ampio e richiederebbe pagine di trattazione, ma speriamo di avervi dato almeno un’idea di cosa sia questa architettura e perché può rivelarsi davvero molto utile nell’infrastruttura IT di un’azienda.
Continuate a seguire il nostro blog e la nostra pagina LinkedIn: prossimamente parleremo di image recognition nell’automazione industriale.
A presto!
