Monolite o Microservizi ?

Quando si tratta di progettare e realizzare applicazioni software, la scelta tra diversi schemi architetturali possibili va sempre ben ponderata. Due degli schemi più popolari e diffusi sono l’architettura monolitica e architettura a microservizi.

Un’applicazione monolitica è un’unica applicazione che comprende al suo interno tutto (o quasi) il necessario alla sua corretta esecuzione, mentre un’architettura a microservizi è composta da servizi più piccoli e indipendenti. Quale scegliere tra i due dipende da vari fattori. Vediamoli insieme.

Che cos’è un’architettura monolitica?

Un’architettura monolitica rappresenta il tradizionale modello di sviluppo software, concepito come un’entità unificata, autonoma e indipendente da altre applicazioni. La definizione di “monolite” suggerisce un’immagine di qualcosa di massiccio e immobile, il che non è troppo lontano dalla realtà di un’architettura monolitica nel contesto della progettazione del software.

In un’architettura monolitica, l’applicazione viene distribuita come un’unica, grande codebase che contiene tutte le funzionalità, compresi l’accesso ai dati e l’interfaccia di presentazione necessari per l’esecuzione dell’applicazione.

Per apportare modifiche a un’applicazione di questo tipo, è necessario intervenire su tutta l’applicazione operando sui sorgenti, riassemblando il codice e distribuendone una versione aggiornata. Questo processo rende gli aggiornamenti estremamente delicati e richiede notevoli risorse in termini di tempo e impegno necessari.

D’altro canto, l’utilizzo di monoliti può risultare conveniente nelle prime fasi di un progetto, poiché semplifica la gestione della base di codice, riduce la complessità architetturale e complessivamente semplifica il primo rilascio. Questo in conseguenza del fatto che tutte le parti che compongono l’applicazione possono essere sviluppate contemporaneamente e che essendo assemblate in un unico pacchetto l’installazione ne risulta notevolmente semplificata.

Nella scelta dell’architettura monolitica rispetto ad una basata su microservizi il principale vantaggio risiede nella velocità di sviluppo, che deriva dalla semplicità di gestire un’applicazione con una singola base di codice.

Vantaggi di un’architettura monolitica

I vantaggi di un’architettura monolitica includono:

• Facilità di distribuzione – Avere un unico file eseguibile o un unico archivio compresso facilita la distribuzione.
• Sviluppo – Quando un’applicazione è costruita con un’unica base di codice, è più facile da sviluppare.
• Prestazioni – In una base di codice e in un repository centralizzati, una sola API può spesso svolgere la stessa funzione che numerose API svolgono con i microservizi.
• Test semplificati – Poiché un’applicazione monolitica è un’unica unità centralizzata, i test end-to-end possono essere eseguiti più rapidamente rispetto a un’applicazione distribuita.
• Facilità di debugging – Con tutto il codice situato in un unico luogo, è più facile seguire una richiesta e trovare un problema.

Svantaggi di un’architettura monolitica

Le applicazioni monolitiche possono essere molto efficaci finché non diventano troppo grandi e la scalabilità diventa una sfida. Per apportare una piccola modifica a una singola funzione è necessario compilare e testare l’intera piattaforma, il che va contro l’approccio agile preferito dagli sviluppatori di oggi.

Gli svantaggi di un monolite includono

• Velocità di sviluppo ridotta – Un’applicazione monolitica di grandi dimensioni rende lo sviluppo più complesso e più lento.
• Scalabilità – Non è possibile scalare i singoli componenti.
• Affidabilità – Un errore in un modulo può compromettere la disponibilità dell’intera applicazione.
• Ostacolo all’adozione della tecnologia – Qualsiasi modifica del framework o del linguaggio si ripercuote sull’intera applicazione, rendendo le modifiche spesso costose e dispendiose in termini di tempo.
• Mancanza di flessibilità – Un monolite è vincolato dalle tecnologie già utilizzate nel monolite stesso.
• Distribuzione – Una piccola modifica a un’applicazione monolitica richiede la distribuzione dell’intero monolite.

Cosa sono i microservizi?

Un’architettura basata su microservizi rappresenta un approccio architetturale che si fonda sulla distribuzione autonoma di una serie di servizi. Ogni servizio è dotato di una sua logica aziendale e un proprio database, il tutto mirando a uno scopo specifico. Gli aspetti quali aggiornamento, testing, distribuzione e scalabilità sono gestiti internamente a ciascun servizio. I microservizi suddividono le complessità principali e i dettagli specifici del dominio in diverse basi di codice indipendenti. Invece di ridurre la complessità, i microservizi la mettono in evidenza, rendendola più chiara e gestibile mediante la separazione delle attività in processi più piccoli che operano autonomamente, contribuendo ciascuno al risultato complessivo.

Vantaggi dei microservizi

I microservizi non sono assolutamente una pallottola d’argento, ma risolvono una serie di problemi per software e aziende in crescita. Poiché un’architettura a microservizi consiste in unità che funzionano in modo indipendente, ogni servizio può essere sviluppato, aggiornato, distribuito e scalato senza influenzare gli altri servizi. Gli aggiornamenti del software possono essere eseguiti con maggiore frequenza, migliorando l’affidabilità, i tempi di attività e le prestazioni.

Più in generale, i microservizi rendono più facile per i team aggiornare il codice e accelerare i cicli di rilascio con l’integrazione continua e la consegna continua (CI/CD). I team possono sperimentare con il codice e tornare indietro se qualcosa va storto.

In breve, i vantaggi dei microservizi sono:

• Agilità – Promuovono metodi di lavoro agili con piccoli team che si distribuiscono frequentemente.
• Scalabilità flessibile – Se un microservizio raggiunge la sua capacità di carico, nuove istanze di quel servizio possono essere rapidamente distribuite al cluster di accompagnamento per contribuire ad alleviare la pressione. Ora siamo multi-tenanant e stateless, con clienti distribuiti su più istanze. Ora possiamo supportare istanze di dimensioni molto più grandi.
• Distribuzione continua – Ora abbiamo cicli di rilascio frequenti e più rapidi. Prima rilasciavamo gli aggiornamenti una volta alla settimana, ora possiamo farlo due o tre volte al giorno.
• Alta manutenibilità e testabilità – I team possono sperimentare nuove funzionalità e tornare indietro se qualcosa non funziona. Questo facilita l’aggiornamento del codice e accelera il time-to-market delle nuove funzionalità. Inoltre, è facile isolare e risolvere errori e bug nei singoli servizi.
• Distribuibili in modo indipendente – Poiché i microservizi sono unità individuali, consentono una rapida e semplice distribuzione indipendente di singole funzionalità.
• Flessibilità tecnologica – Le architetture a microservizi consentono ai team di scegliere liberamente gli strumenti che desiderano.
• Alta affidabilità – È possibile distribuire le modifiche per un servizio specifico, senza rischiare di mandare in tilt l’intera applicazione.

Svantaggi dei microservizi

Quando si passa da un numero limitato di codebase monolitiche a una crescente quantità di sistemi e servizi distribuiti che supportano i propri prodotti, emerge una complessità imprevista. Inizialmente, è difficile aggiungere nuove funzionalità con la stessa efficienza e sicurezza del passato. L’adozione dei microservizi può portare a una complessità aggiuntiva che può risultare nella dispersione degli sforzi di sviluppo o in una crescita veloce e non controllata. Identificare in modo chiaro come i vari componenti interagiscono tra loro, chi è responsabile di un particolare componente software e come evitare interferenze con i componenti dipendenti può presentare delle sfide complesse.

Gli svantaggi dei microservizi possono includere:

• Sviluppo diffuso – I microservizi aggiungono maggiore complessità rispetto a un’architettura monolite, poiché ci sono più servizi in più punti creati da più team. Se la proliferazione dello sviluppo non viene gestita in modo adeguato, la velocità di sviluppo rallenta e le prestazioni operative sono scarse.
• Costi infrastrutturali esponenziali – Ogni nuovo microservizio può avere un costo proprio per suite di test, playbook di distribuzione, infrastruttura di hosting, strumenti di monitoraggio e altro ancora.
• Costi organizzativi aggiuntivi – I team devono aggiungere un ulteriore livello di comunicazione e collaborazione per coordinare gli aggiornamenti e le interfacce.
• Problemi di debugging – Ogni microservizio ha il proprio set di log, il che rende più complicato il debugging. Inoltre, un singolo processo aziendale può essere eseguito su più macchine, complicando ulteriormente il debugging.
• Mancanza di standardizzazione – Senza una piattaforma comune, può esserci una proliferazione di linguaggi, standard di log e monitoraggio.
• Mancanza di una chiara proprietà – Con l’introduzione di più servizi, aumenta anche il numero di team che li gestiscono. Con il tempo diventa difficile conoscere i servizi disponibili che un team può sfruttare e chi contattare per l’assistenza.