Architettura a Microservizi: Isolamento Logico dei Processi in Ambienti Containerizzati

Passo 1 — Origini dell'Architettura Monolitica

Per comprendere l'architettura a microservizi, è necessario partire dal suo opposto concettuale: il sistema monolitico. In un'applicazione monolitica, tutti i componenti funzionali — interfaccia utente, logica di business, accesso al database — risiedono in un unico artefatto di deployment. L'intero sistema viene compilato, testato e distribuito come un blocco unico. Questo approccio, pur presentando vantaggi di semplicità nella fase iniziale dello sviluppo, genera progressivamente criticità di gestione all'aumentare della complessità del sistema.

Le criticità tipiche dei monoliti in produzione includono: tempi di build e test proporzionali alla dimensione dell'intero codebase, impossibilità di scalare selettivamente solo i componenti sotto carico elevato, accoppiamento stretto tra moduli che rende ogni modifica potenzialmente rischiosa per l'intero sistema, e stack tecnologico obbligatoriamente omogeneo per tutti i componenti.

Passo 2 — Principio di Decomposizione Funzionale

L'architettura a microservizi scompone il sistema monolitico in un insieme di servizi autonomi, ciascuno responsabile di un insieme limitato e coeso di funzionalità del dominio applicativo. Ogni microservizio è un processo indipendente, eseguito nel proprio container, con il proprio ciclo di vita di deployment, la propria base di codice e tipicamente il proprio database isolato.

Il principio guida della decomposizione è il Bounded Context, un concetto derivato dal Domain-Driven Design (DDD) che identifica i confini entro i quali un modello di dominio è coerente e valido. La topologia ideale dei microservizi rispecchia la struttura organizzativa dei team di sviluppo — la cosiddetta "Legge di Conway" — dove ogni team possiede, sviluppa e opera in modo autonomo uno o più microservizi del dominio di sua competenza.

Passo 3 — Containerizzazione come Meccanismo di Isolamento

I container Linux rappresentano il meccanismo tecnico primario per l'isolamento dei microservizi a livello di sistema operativo. A differenza delle macchine virtuali, i container non virtualizzano l'hardware sottostante ma condividono il kernel del sistema operativo host, isolando i processi tramite due funzionalità del kernel Linux: i namespaces e i cgroups.

I namespaces Linux creano viste isolate di risorse globali del sistema operativo per ogni container: il namespace PID isola l'albero dei processi (ogni container ha il proprio spazio di PID partendo da 1), il namespace network isola le interfacce di rete e le tabelle di routing, il namespace mount isola il filesystem, il namespace UTS isola hostname e domain name. I cgroups (control groups) limitano e contabilizzano le risorse hardware (CPU, memoria, I/O di rete e disco) consumate da un gruppo di processi, impedendo che un container monopolizzi le risorse dell'host condiviso.

Passo 4 — Comunicazione Inter-Servizio

In un'architettura monolitica, i componenti comunicano tramite chiamate di funzione in-process, con overhead trascurabile e transazioni ACID native. In un sistema a microservizi, ogni interazione tra servizi diventa una chiamata di rete, con tutte le implicazioni che ne derivano in termini di latenza, fallibilità e consistenza dei dati.

I pattern di comunicazione inter-servizio si dividono in due categorie principali. La comunicazione sincrona avviene tipicamente tramite API REST su HTTP/1.1 o HTTP/2, o tramite gRPC (Google Remote Procedure Call) che utilizza Protocol Buffers come formato di serializzazione binario. La comunicazione asincrona utilizza message broker (Apache Kafka, RabbitMQ) per il disaccoppiamento temporale dei servizi: il producer pubblica messaggi su un topic o una coda senza attendere la risposta del consumer, consentendo buffer dei picchi di traffico e resilienza ai guasti temporanei dei servizi downstream.

Passo 5 — Pattern di Resilienza: Circuit Breaker

La natura distribuita dei microservizi espone il sistema a guasti parziali che in un monolite non sarebbero possibili: un servizio dipendente potrebbe rispondere lentamente o non rispondere affatto, causando esaurimento del pool di thread del servizio chiamante per accumulo di richieste in attesa. Il pattern Circuit Breaker, analogo al disgiuntore elettrico, risolve questo problema monitorando il tasso di fallimento delle chiamate verso un servizio dipendente. Quando il tasso supera una soglia configurabile, il circuit breaker passa in stato "aperto" e le successive richieste falliscono immediatamente senza tentare la chiamata di rete, consentendo al servizio dipendente di recuperare.

Passo 6 — Service Mesh e Osservabilità

All'aumentare del numero di microservizi, la gestione dei cross-cutting concerns — sicurezza delle comunicazioni inter-servizio, osservabilità distribuita, retry automatici, circuit breaking — diventa complessa se implementata in modo indipendente in ciascun servizio. Il pattern Service Mesh esternalizza questa logica in un proxy sidecar (tipicamente Envoy) affiancato ad ogni istanza di servizio. I proxy sidecar intercettano tutto il traffico di rete in ingresso e uscita dal container del servizio, implementando in modo centralizzato la cifratura mTLS, il tracciamento distribuito, la raccolta di metriche e le politiche di resilienza.

Il tracciamento distribuito (distributed tracing) è particolarmente critico in architetture a microservizi per ricostruire il percorso completo di una richiesta attraverso i vari servizi. Sistemi come Jaeger e Zipkin implementano il protocollo OpenTelemetry: ogni servizio propaga un identificativo di traccia (trace ID) e di span attraverso le intestazioni HTTP, consentendo la visualizzazione della catena causale completa di ogni operazione end-to-end.

Passo 7 — Orchestrazione con Kubernetes

L'orchestrazione di container a scala è il problema tecnico che ha reso necessario lo sviluppo di sistemi come Kubernetes (K8s), originariamente sviluppato da Google sulla base del sistema interno Borg. Kubernetes astrae l'infrastruttura fisica (o virtuale) in un cluster di nodi, fornendo primitive dichiarative per il deployment, la scalabilità e la gestione del ciclo di vita dei container.

Le risorse fondamentali di Kubernetes includono: il Pod (unità atomica di deployment, uno o più container co-locati), il Deployment (descrive lo stato desiderato di un set di Pod replicati), il Service (astrazione di rete stabile per l'accesso a un set di Pod), e il Horizontal Pod Autoscaler (HPA) che scala automaticamente il numero di repliche in base a metriche di utilizzo come CPU e memoria. Il piano di controllo di Kubernetes è composto da componenti distinti: l'API server gestisce le richieste dichiarative, etcd memorizza lo stato del cluster, lo scheduler assegna i Pod ai nodi in base a criteri di risorse e affinità, e i controller loop monitorano continuamente lo stato effettivo del cluster per riconciliarlo con lo stato desiderato.