Architetture monolitiche e di microservizi

Completato

Fabrikam ha integrato il nuovo servizio drone nell'applicazione esistente. Si rendono conto che questa soluzione non è un buon piano a lungo termine per l'applicazione. Il sistema esistente è un'architettura monolitica, ma cosa significa esattamente?

Che cos'è un'architettura monolitica?

Un'architettura monolitica è un'architettura in cui tutti i componenti per un'applicazione vengono raggruppati all'interno di una singola unità. Questa unità è in genere vincolata all'interno di una singola istanza di runtime dell'applicazione. Le applicazioni tradizionali spesso sono costituite da un'interfaccia Web, da un livello di servizi e da un livello dati. In un'architettura monolitica, questi livelli vengono combinati in un'istanza dell'applicazione.

Le architetture monolitiche sono spesso soluzioni adatte per applicazioni di piccole dimensioni, ma possono diventare poco complesse man mano che l'applicazione cresce. Ciò che originariamente era una piccola applicazione può diventare rapidamente un sistema complesso difficile da ridimensionare, difficile da distribuire in e difficile da innovare.

Tutti i servizi sono contenuti all'interno di una singola unità. Questa disposizione comporta sfide man mano che crescono la loro attività e il carico di sistema relativo. Alcune di queste sfide sono:

• Difficile ridimensionare i servizi in modo indipendente.
• Complesso sviluppare e gestire i deployment mentre la codebase aumenta, ritardando i rilasci e l'implementazione di nuove funzionalità.
• L'architettura è legata a un unico stack di tecnologie, che limita l'innovazione nelle nuove piattaforme e SDK.
• Gli aggiornamenti dello schema dei dati possono essere sempre più difficili.

Questi problemi possono essere risolti esaminando architetture alternative, ad esempio un'architettura di microservizi.

Che cos'è un'architettura di microservizi?

Un'architettura di microservizi è costituita da servizi di piccole dimensioni, indipendenti e ad accoppiamento debole. Ogni servizio può essere distribuito e ridimensionato in modo indipendente.

Un microservizio è sufficientemente piccolo da poter scrivere e gestire un singolo team di sviluppatori di piccole dimensioni. Poiché i servizi possono essere distribuiti in modo indipendente, un team può aggiornarne uno esistente senza ricompilare e ridistribuire l'intera applicazione.

Ogni servizio è in genere responsabile della gestione dei propri dati. La struttura dei dati è isolata, per cui gli aggiornamenti o le modifiche dello schema non dipendono da altri servizi. Le richieste di dati vengono in genere gestite tramite LE API e forniscono un modello di accesso ben definito e coerente. I dettagli di implementazione interna sono nascosti ai consumer.

Poiché ogni servizio è indipendente, può usare stack di tecnologie, framework e SDK diversi. È comune vedere che i servizi si basano sulle chiamate REST per la comunicazione da servizio a servizio usando API ben definite anziché chiamate di procedura remota (RPC) o altri metodi di comunicazione personalizzati.

Le architetture di microservizi sono indipendenti dalla tecnologia, ma spesso per la loro implementazione vengono usati contenitori o tecnologie serverless. Vengono spesso usate tecniche di distribuzione continua e integrazione continua (CI/CD) per aumentare la velocità e migliorare la qualità delle attività di sviluppo.

Vantaggi di un'architettura di microservizi

Perché scegliere un'architettura di microservizi? Esistono diversi vantaggi principali per un'architettura di microservizi:

• Agilità
• Piccolo codice, piccoli team
• Combinazione di tecnologie
• Resilienza
• Scalabilità
• Isolamento dei dati

Agilità

Poiché i microservizi vengono distribuiti in modo indipendente, è più facile gestire le correzioni di bug e i rilasci delle funzionalità. È possibile aggiornare un servizio senza ridistribuire l'intera applicazione ed eseguire il rollback di un aggiornamento in caso di errore. In molte applicazioni tradizionali un bug rilevato in una parte dell'applicazione può bloccare l'intero processo di rilascio. Di conseguenza, le nuove funzionalità potrebbero rimanere in attesa di una correzione di bug da integrare, testare e pubblicare.

Piccolo codice, piccoli team

Un microservizio deve essere sufficientemente piccolo da consentire a un singolo un team responsabile di una funzionalità di crearlo, testarlo e distribuirlo. Le codebase di piccole dimensioni sono più facili da comprendere. In un'applicazione monolitica di grandi dimensioni, le dipendenze del codice tendono a diventare ingarbugliate nel tempo. L'aggiunta di una nuova funzionalità richiede il tocco del codice in molte posizioni. Un'architettura di microservizi riduce al minimo le dipendenze non condividendo codice o archivi dati. In questo modo è più semplice aggiungere nuove funzionalità.

Anche le piccole dimensioni del team promuovono una maggiore agilità. La "regola a due pizze" dice che un team dovrebbe essere abbastanza piccolo che due pizze possano alimentare il team. Ovviamente, non è una metrica esatta e dipende dall'appetito del team! Ma il punto è che i gruppi di grandi dimensioni tendono a essere meno produttivi perché la comunicazione è più lenta, il sovraccarico di gestione aumenta e l'agilità diminuisce.

Combinazione di tecnologie

Teams può scegliere la tecnologia più adatta al proprio servizio. Possono usare una combinazione di stack tecnologici in base alle esigenze. Ogni team può evolvere le tecnologie che supportano il proprio servizio in modo indipendente. I servizi possono usare linguaggi di sviluppo diversi, servizi cloud, SDK e altro ancora, a causa di questa indipendenza. I team possono scegliere le opzioni migliori per il loro servizio, riducendo al minimo qualsiasi effetto esterno sui consumatori del servizio.

Resilienza

Se un singolo microservizio diventa non disponibile, non interrompe l'intera applicazione, purché i microservizi upstream siano progettati per gestire correttamente gli errori, ad esempio implementando l'interruzione del circuito. Il vantaggio per gli utenti o i consumatori di servizi è un'esperienza sempre disponibile per l'applicazione.

Scalabilità

Un'architettura di microservizi consente di ridimensionare ogni microservizio indipendentemente dalle altre. È possibile scalare i sottosistemi che richiedono più risorse senza scalare l'intera applicazione. Questa disposizione migliora le prestazioni complessive dell'applicazione. Consente anche di ridurre al minimo i costi. È possibile aggiungere altre risorse solo ai servizi necessari, invece di aumentare le prestazioni dell'intera applicazione.

Isolamento dei dati

Un'architettura di microservizi migliora la possibilità di eseguire gli aggiornamenti dello schema dei dati perché è interessato solo un singolo microservizio. In un'applicazione monolitica, gli aggiornamenti dello schema possono diventare complessi. Parti diverse dell'applicazione potrebbero toccare tutti gli stessi dati, che apportano eventuali modifiche allo schema rischiose. Con un'architettura di microservizi, è possibile aggiornare uno schema ma mantenere intatta la superficie dell'API. I consumer di servizi hanno quindi la stessa esperienza indipendentemente dall'architettura dei dati sottostante.

Potenziali sfide di un'architettura di microservizi

Esistono molti vantaggi in un'architettura di microservizi, ma non è una soluzione universale. Un'architettura di microservizi presenta un proprio set di sfide:

• Complessità
• Sviluppo e test
• Mancanza di governance
• Congestione e latenza della rete
• Integrità dei dati
• Gestione
• Controllo delle versioni
• Set di competenze

Complessità

Un'applicazione di microservizi ha più parti mobili rispetto all'applicazione monolitica equivalente. Ogni servizio è più semplice, ma l'intero sistema nella sua totalità è più complesso. Con l'individuazione dei servizi, l'orchestrazione e gli strumenti di automazione, è possibile gestire più parti nell'applicazione complessiva.

Sviluppo e test

La scrittura di un servizio di piccole dimensioni che si basa su altri servizi dipendenti richiede un approccio diverso dalla scrittura per un'applicazione monolitica o a più livelli tradizionale. Gli strumenti esistenti non sono sempre progettati per funzionare con le dipendenze del servizio. Effettuare il refactoring tra i limiti dei servizi può essere difficile. È anche difficile testare le dipendenze del servizio, soprattutto quando l'applicazione si evolve rapidamente.

Mancanza di governance

L'approccio decentralizzato alla creazione di microservizi presenta alcuni vantaggi, ma può anche causare problemi. Potrebbero esserci così tanti linguaggi e framework diversi che l'applicazione diventa difficile da gestire. Può essere utile applicare alcuni standard a livello di progetto, senza limitare eccessivamente la flessibilità dei team. La necessità di standard uniformi si applica in particolare alle funzionalità trasversali, come i log e le metriche.

Congestione e latenza della rete

L'uso di molti servizi granulari di dimensioni ridotte può comportare una maggiore comunicazione tra i servizi. Se la catena di dipendenze del servizio diventa troppo lunga, ad esempio, il servizio A chiama B, che chiama C..., la latenza aggiuntiva di queste chiamate di rete può diventare un problema. Progettare attentamente le API. Evitare API eccessivamente chiacchierate, considerare i formati di serializzazione e cercare posizioni in cui usare modelli di comunicazione asincroni.

Integrità dei dati

Ogni microservizio è responsabile della persistenza dei dati. Di conseguenza, la coerenza dei dati può essere una sfida. Implementare la coerenza finale dove possibile. È anche possibile ritrovarsi con dati duplicati e un'architettura dati complessa e dispersiva. Questa situazione può aumentare i costi di archiviazione non elaborati e i costi del servizio della piattaforma dati con la duplicazione dei dati e del servizio.

Gestione

Il successo con i microservizi richiede una cultura DevOps matura. La registrazione correlata tra i servizi può risultare complessa. In genere, la registrazione deve correlare più chiamate ai servizi per una singola operazione utente.

Controllo delle versioni

Gli aggiornamenti di un servizio non devono interrompere i servizi che dipendono da esso. È possibile aggiornare più servizi in qualsiasi momento. Senza un'attenta progettazione, potrebbero verificarsi problemi con la compatibilità con le versioni precedenti o successive. I servizi in ritardo sull'adozione di nuove versioni dell'API possono aumentare le risorse e la manutenzione necessarie per le API meno recenti.

Set di competenze

I microservizi sono sistemi altamente distribuiti. Questi sistemi distribuiti richiedono spesso un set di competenze diverso per sviluppare, gestire e gestire correttamente. Valutare attentamente se il team ha le competenze e l'esperienza necessarie. Concedere il tempo e la pianificazione necessari affinché i team possano evolvere le proprie capacità.

Quando scegliere un'architettura di microservizi?

In base a queste informazioni di base, per quali situazioni è più adatta un'architettura di microservizi?

• Applicazioni di grandi dimensioni che richiedono una velocità di rilascio elevata.
• Applicazioni complesse che devono essere altamente scalabili.
• Applicazioni con domini avanzati o molti sottodomini.
• Un'organizzazione costituita da piccoli team di sviluppo.