System Design

Nelle tradizionali applicazioni monolitiche, mantenere la coerenza dei dati tra più entità è semplice. I motori di database relazionali forniscono garanzie ACID (Atomicità, Coerenza, Isolamento, Durabilità) racchiuse nelle transazioni SQL locali. Se l’inserimento di un ordine, una detrazione di pagamento o una riserva di inventario falliscono a metà, la chiamata a ROLLBACK annulla istantaneamente ogni modifica del database.

Nelle moderne architetture guidate dagli eventi (Event-Driven Architecture), i microservizi emettono costantemente eventi (OrderCreated, PaymentProcessed) per comunicare in modo disaccoppiato. Tuttavia, pubblicare eventi in modo affidabile solleva una sfida fondamentale: Come garantire che l’aggiornamento del database locale e la pubblicazione dell’evento abbiano entrambi successo o falliscano insieme? Se un microservizio aggiorna il proprio database (PostgreSQL, MySQL) e subito dopo tenta di inviare un messaggio a un broker (Apache Kafka, RabbitMQ), una disconnessione di rete o un timeout può causare un’incoerenza nei dati.

In un’architettura di microservizi, i servizi formano una rete di chiamate di rete distribuite. Sebbene ciò consenta ai team di creare e scalare i servizi in modo indipendente, significa anche che l’affidabilità complessiva del sistema è forte quanto il suo anello più debole. Se un servizio critico si interrompe o non risponde, può innescare un errore a cascata che interrompe l’intera applicazione.

In un’architettura di microservizi, i servizi comunicano su una rete anziché su chiamate in memoria. Sebbene questo disaccoppiamento consenta un massiccio ridimensionamento orizzontale e implementazioni indipendenti, introduce anche una grave vulnerabilità: la rete è inaffidabile. In qualsiasi momento, un servizio downstream potrebbe riscontrare un breve problema tecnico di rete, un picco temporaneo della CPU, un rapido conflitto di blocco del database o un riavvio dell’aggiornamento in sequenza. Questi guasti temporanei sono noti come guasti transitori.

In un’architettura a microservizi, una singola applicazione viene suddivisa in dozzine o centinaia di servizi indipendenti e collaboranti. Sebbene questa progettazione migliori la modularità e la scalabilità, introduce anche un rischio importante: un guasto in un servizio può provocare il collasso dell’intero sistema. Se un servizio a valle diventa lento o non risponde, le richieste in entrata ai servizi a monte inizieranno ad accumularsi. Se condividono tutti la stessa memoria, CPU o pool di thread, una dipendenza lenta può esaurire rapidamente tutte le risorse disponibili, causando l’arresto anomalo dell’intera applicazione.

Nei moderni sistemi cloud-native, ci si aspetta che i microservizi facciano molto di più che eseguire la logica aziendale. Devono gestire la registrazione, gestire i certificati SSL/TLS, raccogliere parametri, implementare meccanismi di ripetizione dei tentativi e coordinare le comunicazioni sicure con altri servizi. Se incorporiamo tutte queste funzionalità trasversali direttamente all’interno della base di codice di ciascuna applicazione, ci ritroveremo con un ingrossamento del codice, un accoppiamento stretto e un blocco del linguaggio.

Nella moderna ingegneria del software, le applicazioni monolitiche legacy rappresentano una sfida comune. Nel corso del tempo, una codebase di successo diventa così grande e interconnessa che apportare semplici modifiche diventa rischioso, le implementazioni richiedono ore e il ridimensionamento delle singole funzionalità è praticamente impossibile. Quando i team decidono di modernizzare i propri sistemi migrando ai microservizi, si trovano ad affrontare una domanda ad alto rischio: Come possiamo riscrivere il sistema senza compromettere la nostra attività attuale?

In un’architettura a microservizi, i nostri sistemi sono suddivisi in decine di servizi piccoli e mirati, come un servizio utente, un servizio ordini e un servizio prodotto. Ma quando si tratta di mostrare queste informazioni agli utenti, i diversi dispositivi hanno esigenze molto diverse. Un browser Web su un computer desktop ad alta velocità richiede una dashboard ricca piena di tabelle, barre laterali e grafici. Un’app mobile su una rete cellulare lenta richiede un layout semplice e leggero per risparmiare larghezza di banda e batteria. Un’app per smartwatch potrebbe richiedere solo una singola riga di testo.

La transizione da un’unica applicazione monolitica a un’architettura a microservizi risolve molti problemi. Consente ai team di lavorare in modo indipendente, distribuire i servizi separatamente e ridimensionare parti del sistema in base alle esigenze. Tuttavia, introduce anche una nuova sfida: come interagiscono i clienti con tutti questi servizi indipendenti? Se disponi di dieci, cinquanta o centinaia di piccoli microservizi, un’app mobile o una pagina Web dovrebbero connettersi direttamente a ciascuno di essi?

Quando le organizzazioni passano da un’architettura monolitica ai microservizi, si trovano ad affrontare una domanda critica e ad alto rischio: Come tracciamo i confini dei nostri servizi? In teoria, i microservizi dovrebbero essere unità sciolte e disaccoppiate che possono essere sviluppate, distribuite e scalate in modo indipendente. In pratica, tuttavia, molti team finiscono per costruire un monolite distribuito, un sistema in cui i servizi sono così strettamente associati che un singolo cambiamento aziendale richiede la modifica e l’implementazione di più servizi contemporaneamente, aggravando la latenza di rete e gli ostacoli di distribuzione.