Cos'è l'architettura a microservizi?

L'architettura a microservizi è un metodo per costruire applicazioni come una collezione di componenti piccoli e autonomi che interagiscono su una rete tramite API. Il NIST SP 800-204 riconosce all'approccio una codebase più piccola, team indipendenti e uno scaling per componente.

È come avere un gruppo di lavoratori che operano in modo coordinato con un'agenda comune, ognuno con una specifica competenza. Questo è diverso dalla precedente struttura monolitica, che è come avere un'unica entità che fa tutto, e man mano che l'applicazione diventa più complessa, diventa difficile da controllare.

L'architettura dei microservizi è diversa dall'architettura monolitica tradizionale nei seguenti modi.

• Decentramento: I microservizi prendono le funzionalità e le distribuiscono su servizi individuali, mentre un il monolite combina tutte le funzionalità all'interno di un'unica base di codice.
• Accoppiamento debole: I microservizi comunicano tramite API con coesione di alto livello e accoppiamento di basso livello, mentre nel caso dei monoliti, i componenti sono solitamente accoppiati e coesi.
• Distribuzione indipendente: I microservizi consentono la sostituzione o la distribuzione di un singolo servizio senza tempi di inattività dell'intero sistema, mentre le modifiche all'interno di un'architettura monolitica richiedono il coordinamento della distribuzione.
• Scalabilità: I microservizi possono essere regolati indipendentemente in base ai requisiti degli utenti rispetto ad approcci come quello monolitico, che richiede il ridimensionamento dell'intera applicazione.
• Isolamento dei guasti: Nei microservizi, quando un servizio non funziona, non influenza il resto dei servizi, mentre nei servizi monolitici, il guasto di un componente può causare il guasto dell'intera applicazione.

L'adozione di un'architettura a microservizi scambia la complessità operativa con la scalabilità indipendente e l'isolamento dei guasti.

Benefici:

• Scalabilità: Sviluppa determinati servizi a una determinata scala in base alla domanda in modo che l'utilizzo delle risorse sia efficiente.
• Maggiore agilità: Sviluppare e distribuire in modo indipendente si riferisce a un'iniziazione del ciclo più rapida e a una maggiore reattività al cambiamento.
• Flessibilità tecnologica: La capacità di ciascun servizio di utilizzare linguaggio e strumenti adatti è un fattore che può relazionarsi all'innovazione e all'ottimizzazione del servizio.
• Isolamento dei guasti: Per ridurre l'impatto dei guasti del servizio e migliorare la stabilità del sistema.
• Manutenibilità: Ogni servizio piccolo e specifico è più facile da comprendere, sviluppare e gestire rispetto a un singolo servizio onnicomprensivo.

Sfide:

• Complessità aumentata: La gestione di sistemi distribuiti richiede un approccio più complesso rispetto ai sistemi centralizzati a causa delle complessità intrinseche.
• Gestione dei dati: Nella gestione dei dati, i data store separati per ogni servizio sono spesso associati a una consistenza dei dati finale tra tali servizi, piuttosto che a una consistenza immediata.
• Test: È importante eseguire tutti i test semplici e complessi per garantire la compatibilità di tutti i servizi e la stabilità dell'intero sistema dopo la sua distribuzione.
• Comunicazione: La comunicazione tra servizi è cruciale per un funzionamento efficiente, ma comporta latenza e possibili aree di errore.
• Sicurezza: La protezione dei dati sensibili su più servizi deve essere ben pianificata ed eseguita per evitare vulnerabilità del servizio.

I microservizi interagiscono principalmente tramite API (Application Programming Interfaces), che descrivono come i dati verranno scambiati e in quale formato. Tali modelli di comunicazione includono:

• Richiesta-risposta sincrona: Un servizio inoltra una richiesta a un altro servizio e si aspetta che quest'ultimo risponda. È semplice, ma se non gestito bene, può causare un accoppiamento stretto e difficoltà di prestazioni. Solitamente REST su HTTP, o gRPC per una latenza inferiore; i client esterni accedono tramite un gateway API. Una API REST è il modo in cui si raggiunge un servizio, non un servizio in sé.
• Messaggistica asincrona: I servizi scambiano messaggi tramite un broker di messaggi per contare sul disaccoppiamento e ottenere maggiore scalabilità. Questo modello è più efficace quando è necessario elaborare una grande quantità di dati o eventi. Il broker è solitamente Apache Kafka o RabbitMQ, non un microservizio in sé.
• Architettura basata sugli eventi: I servizi pubblicano eventi che altri servizi possono poi ascoltare al fine di, per favorire accoppiamento debole e reattività. Questo modello si allinea bene con situazioni in cui sono richiesti aggiornamenti o modifiche su più servizi.

Le best practice includono:

• Domain-Driven Design (DDD): Decomporre il sistema in contesti delimitati che coprono le funzionalità di business che miglioreranno la leggibilità e la manutenibilità del sistema.
• API-First Design: Imposta interfacce chiare e ben documentate in cui i servizi devono interagire nel sistema per garantire coerenza e facilità di integrazione.
• Containerizzazione: Dividi i servizi in pacchetti e inseriscili in container di distribuzione per un migliore controllo e facile scalabilità delle soluzioni. Ciò significa distribuendoli in container Docker che Kubernetes orchestra: l'82% degli utenti di container esegue Kubernetes in produzione (CNCF, 2026).
• Integrazione continua e distribuzione continua (CI/CD): Standardizza la compilazione, il test e la distribuzione con rilasci regolari, prevedibili e ripetibili.
• Monitoraggio e Osservabilità: Registra e monitora lo stato e le prestazioni del servizio per assicurarti che siano ben registrati e documentati in modo che, in caso di problemi, la causa principale possa essere facilmente identificata.

Esempi reali di microservizi di successo includono:

• Netflix: Implementata un'architettura basata su microservizi per supportare l'espansione globale e gestire elevati volumi di traffico per il loro servizio di streaming.
• Amazon: Il sito di e-commerce ha optato per un un'architettura a microservizi dopo essere migrato dal suo precedente design monolitico, con l'obiettivo di migliorare l'adattabilità e la versatilità.
• Uber: I microservizi gestiscono separatamente le richieste di viaggio, i pagamenti e i conducenti, facilitando la crescita.

Entrambi Netflix e Amazon sono nati come monoliti e li hanno poi suddivisi: costruire i moduli all'interno di un'unica applicazione, quindi estrarre quello la cui scalabilità crea problemi.