Container, microservizi e orchestratori

In questo articolo, “Container, microservizi e orchestratori”, impariamo a conoscere cosa sono i Container, perchè sono nati e quali vantaggi offrono. Esploreremo i concetti fondamentali delle applicazioni multilayer, dei moduli che costituiscono l’applicazione stessa fino ad arrivare al concetto di microservizi. Introdurremo Dockers e Kubernetes e, dopo aver imparato i concetti fondamentali possiamo fare riferimento alla guida Dockers all’interno della quale troviamo una sezione per implementare un docker container, realizzare un’applicazione e testarne il funzionamento.

Indice dei contenuti

Introduzione

Nel 2013 alcuni tecnici di GOOGLE si posero la seguente domanda:

Perchè virtualizzare un’intera macchina quando sarebbe possibile virtualizzare solo una piccola parte di essa?

Per capire perchè i tecnici di GOOGLE si posero questa domanda dobbiamo fare riferimento alla tecnologia meno recente:

• Se uno sviluppatore voleva testare la propria applicazione su diversi sistemi operativi aveva la necessità di macchine fisiche sulle quali fossero installati altri sistemi operativi o, comunque, hard disk da dover di volta in volta installare su ciascuna macchina per poi installare un nuovo S.O. e testare la propria applicazione

Per risolvere questo problema si è pensato di implementare su un’unica macchina una tecnologia che consentisse di avere diversi sistemi operativi. C’è stata così una prima rivoluzione tecnologica con la nascita della VIRTUALIZZAZIONE: una tecnica che consente di installare diversi sistemi operativi che poggiano sullo stesso harware (sullo stesso PC o sullo stesso Server) risolvendo, parzialmente, il problema della portabilità di cui abbiamo parlato in precedenza e dell’isolamento degli ambienti

Purtoppo la virtualizzazione ha dei limiti dovuti principalmente alla necessità di avere l’hardware sottostante estremamente performante per poter consentire alle macchine virtuali di lavorare in modo corretto. Essendo condivise le risorse della macchina ospitante, necessariamente le prestazioni della macchina virtuale sono, in alcuni casi, insoddisfacenti.

Ecco l’idea che hanno avuto i tecnici di Google. Per testare la mia applicazione non ho necessità di virtualizzare un intero sistema operativo perchè avrei nella macchina virtuale tutta una serie di servizi che non mi servono

I container

I container sono un’alternativa leggera alle macchine virtuali per fornire ambienti operativi isolati per i carichi di lavoro, utilizzando un metodo diverso per astrarre le risorse. Invece di basarsi su un hypervisor, i container condividono il kernel del sistema operativo (OS) host. Di conseguenza, evitano l’overhead dell’infrastruttura di un sistema operativo completo e forniscono solo le risorse di cui le applicazioni hanno effettivamente bisogno. Ciò significa che possono essere fermati e avviati più rapidamente in risposta alle fluttuazioni dei requisiti di scalabilità e offrono prestazioni complessive migliori rispetto alle macchine virtuali. Inoltre, per costruzione, risultano essere un sistema isolato con tutte le dipendenze necessarie al servizio che ospitano, essendo così portabili e condivisibili su diverse infrastrutture.

I container possono essere distribuiti in diversi ambienti, come sviluppi locali, ambienti di test e produzione, senza problemi di compatibilità

Analizziamo nel dettaglio i vantaggi:

• Indipendenza e autosufficienza: i container sono pacchetti software che contengono tutti gli elementi necessari per essere eseguiti in ogni ambiente
• Leggerezza: i container non virtualizzano tutto il sistema operativo della macchina ospitante. Possono essere avviati interrotti in modo rapido, affidabile e flessibile gestendo le risorse in modo migliore e ottimizzando le prestazioni.
• Portabilità: posso testare facilmente il mio container su altre macchine senza la necessità di avere hard disk o macchine fisiche già preconfigurate per far girare l’applicazione
• Isolamento e sicurezza: essendo unità software autonome (contenenti file, librerie, variabili d’ambiente e dipendenze) risultano dei sistemi isolati (non c’è modo che un container interferisca con un altro) e sicuri
• Facilità di distribuzione: possono essere scaricati da un repository centrale e ciò assicura che qualsiasi container sia identico a prescindere dal pc o dallo smartphone che lo ospita

Una nuova rivoluzione nello sviluppo software

Bene, ora che sappiamo cosa sono i container, e sappiamo che posso racchiudere tutto ciò che mi serve di una applicazione o di UNA PARTE DI UNA APPLICAZIONE COMPLESSA in un container, allora possiamo pensare allo sviluppo di una applicazione complessa in altri termini rispetto al passato: anzichè uno sviluppo di tipo monolitico posso pensare a sviluppare la mia applicazione in modo modulare.

Ciascun modulo dovrà essere indipendente ed autosufficiente e dovrà poter comunicare in qualche modo con gli altri moduli. Posso pensare dunque ad una applicazione complessa come costituita da diversi servizi, una serie distribuita di funzioni autonome ed indipendenti, che interagiscono tra di loro: i MICROSERVIZI.

Ma posso andare oltre e progettare ogni microservizio come un container. Ottengo dunque una applicazione complessa sviluppata con una architettura a microservizi containerizzati.

Facciamo un esempio concreto: un sito di E-commerce. In un approccio monolitico tradizionale, l’intera applicazione – gestione utenti, catalogo prodotti, carrello, ordini, pagamenti – sarebbe sviluppata come un’unica unità. Al contrario, un’architettura a microservizi consente di suddividere l’applicazione in servizi indipendenti, ognuno dei quali esegue una funzione specifica e può essere sviluppato, aggiornato, distribuito e scalato in maniera autonoma.

Servizi identificabili nel sistema E-commerce

Ecco alcuni microservizi tipici in un’applicazione E-commerce, ciascuno containerizzato separatamente:

Posso dunque sviluppare il mio sito di E-commerce con diverse tecnologie, realizzare diversi moduli ciascuno dei quali corrisponde ad un microservizio, permettere la comunicazione tra i vari microservizi e fare il deployment della mia applicazione

Architettura a microservizi

L’architettura a microservizi rappresenta un paradigma di progettazione del software secondo il quale un’applicazione viene scomposta in una collezione di servizi indipendenti e distribuiti, ognuno incaricato di svolgere una funzione specifica. Tali servizi, denominati microservizi, operano in modo autonomo e interagiscono tra loro per costituire il sistema applicativo complessivo.

Questa frammentazione logica si integra perfettamente con la tecnologia dei container, i quali permettono di isolare ogni microservizio, offrendo al contempo un controllo preciso sulle risorse e una maggiore efficienza nell’utilizzo della capacità computazionale.

Secondo la definizione proposta da Gartner, un microservizio può essere descritto come “un componente applicativo orientato ai servizi, debolmente accoppiato, e pertanto implementabile e scalabile in maniera indipendente”. Questa definizione sottolinea l’aspetto dell’indipendenza, fondamentale per garantire la modularità e la flessibilità di sviluppo e gestione.

Per comprendere intuitivamente il concetto di microservizi è utile confrontarlo con l’architettura monolitica, alla quale si contrappone. Un’applicazione monolitica è strutturata come un unico blocco software, spesso distribuito come un eseguibile unico da installare in locale. Sebbene questo approccio garantisca una comunicazione molto efficiente tra i componenti interni dell’applicazione, presenta notevoli limitazioni in termini di aggiornabilità, scalabilità e flessibilità.

Infatti, in un’architettura monolitica, modificare una singola funzionalità implica spesso la necessità di ricompilare e redistribuire l’intera applicazione. Questa rigidità è particolarmente penalizzante negli ambienti cloud moderni, in cui agilità, scalabilità orizzontale e rapidità di distribuzione sono elementi fondamentali.

L’architettura a microservizi nasce proprio per superare questi limiti, proponendo una decomposizione dell’applicazione in unità più piccole, autonome e disaccoppiate. Ciascun microservizio rappresenta una funzionalità ben definita dell’intero sistema ed è in grado di essere sviluppato, aggiornato, scalato e distribuito in maniera indipendente rispetto agli altri.

A differenza del modello monolitico, in cui tutte le componenti condividono lo stesso spazio di memoria e comunicano tramite chiamate dirette, i microservizi interagiscono tramite API (Application Programming Interface). Questa modalità di comunicazione, generalmente basata su protocolli standard come HTTP/REST, gRPC o messaggistica asincrona (es. RabbitMQ, Kafka), consente un’efficace interoperabilità tra servizi eterogenei, eventualmente realizzati con linguaggi di programmazione differenti e distribuiti su nodi diversi della rete.

Nel contesto di un’architettura a microservizi containerizzata, la complessità della gestione cresce proporzionalmente al numero di servizi coinvolti. Ogni microservizio, infatti, è solitamente eseguito all’interno di un container isolato, e un’applicazione composta da decine o centinaia di microservizi richiede strumenti avanzati per la loro distribuzione, scalabilità, monitoraggio e gestione. È proprio in questo scenario che entrano in gioco gli orchestratori.

Gli Orchestratori

Un orchestratore è una piattaforma software che automatizza il ciclo di vita dei container, occupandosi del deployment, della scalabilità automatica, del monitoraggio dello stato e della riparazione automatica dei servizi in caso di malfunzionamento. Inoltre, gestisce il bilanciamento del carico tra le istanze replicate, la comunicazione tra i microservizi (service discovery), la configurazione delle reti virtuali e la gestione dei volumi persistenti.

Il più noto e diffuso orchestratore attualmente in uso è Kubernetes, originariamente sviluppato da Google e oggi mantenuto dalla Cloud Native Computing Foundation. Kubernetes consente di definire l’intera architettura dell’applicazione mediante file di configurazione (manifests YAML), in cui vengono descritti i microservizi, le loro dipendenze, le policy di replica, i limiti di risorse e le modalità di esposizione verso l’esterno (Ingress, Load Balancer, ecc.).

L’orchestratore, in sintesi, rappresenta il livello di controllo intelligente che consente di gestire dinamicamente un ecosistema distribuito e complesso di microservizi, garantendo elevata affidabilità, continuità operativa e scalabilità automatica in ambienti cloud-native.