Architettura monolitica e architettura a microservizi: quale è la soluzione migliore per te?

L'approccio monolitico è il modello software tradizionale. Quello a microservizi riflette lo sviluppo software più recente, ma non ha reso obsoleta l'architettura monolitica.

Supponiamo che tu abbia iniziato a lavorare per una startup tecnologica e che ti sia stato affidato il compito di implementare un piano IT per la nuova azienda. Ti trovi di fronte a un'infinità di decisioni da prendere, ma nessuna di queste è così fondamentale o di vasta portata come quella fra architettura monolitica o architettura a microservizi. La scelta dell'architettura software non deve essere fatta a caso o senza una chiara comprensione delle esigenze iniziali ed eventuali di trattamento dei dati dell'organizzazione, perché qualsiasi approccio scelto avrà effetti profondi sulla capacità dell'organizzazione di eseguire in modo significativo i propri obiettivi di business.

Quindi la posta in gioco è considerevole. E poiché sei il nuovo Direttore IT, si tratta anche di una decisione importante per te personalmente che, se scelto in maniera oculata, potrebbe condurti a un percorso di carriera brillante.

Quale sceglierai? Per prima cosa, vediamo le tue opzioni.

Come affermato, l'architettura monolitica è il modello di sviluppo software tradizionale. In esso, una base di codice svolge più funzioni (cioè funzioni aziendali). Il kernel del computer le controlla tutte. Nelle applicazioni monolitiche, tutto il codice richiesto per l'intera applicazione viene mantenuto in una posizione centrale.

Le applicazioni monolitiche di solito contengono i seguenti componenti:

• Interfaccia utente (UI) lato client: il termine "lato client" si riferisce a ciò che viene visualizzato sul dispositivo informatico dell'utente. L'interfaccia utente gestisce ciò che viene visto dall'utente, comprese le immagini, il testo e tutto ciò che può essere trasmesso sullo schermo dell'interfaccia utente, come le informazioni relative alle azioni del browser.

• Database: le architetture monolitiche utilizzano un sistema di gestione di database relazionali (RDMS), un tipo di database che organizza i dati in righe e colonne. Queste righe e colonne formano una tabella in cui i punti dati sono correlati tra loro.

• Applicazione lato server: un'applicazione lato server si occupa delle risorse del server, come la memoria, la CPU e lo storage.

L'utilizzo dell'architettura monolitica offre numerosi benefici:

• Sviluppo di applicazioni semplice: le applicazioni costruite con un'unica base di codice sono più semplici da realizzare, con uno sviluppo più rapido.

• Distribuzione di base: l'architettura monolitica funziona con un unico file o directory eseguibile, il che rende l'implementazione meno difficile. Un'architettura monolitica è anche più facile da mantenere in virtù dell'utilizzo di un minor numero di componenti.

• Debug semplice: le operazioni di test e debug sono meno impegnative con le architetture monolitiche. Le operazioni di test end-to-end vengono eseguite da un sistema di registrazione centrale.

• Maggiore sicurezza: poiché un'architettura monolitica è un sistema chiuso, le sue attività di trattamento dei dati sono completamente contenute e protette dalle minacce informatiche.

L'uso dell'architettura monolitica presenta anche possibili problemi:

• Resistenza alle nuove tecnologie: poiché le applicazioni monolitiche sono in genere strettamente accoppiate, può essere difficile integrare nuove tecnologie.

• Riduzione della scalabilità: anche se la quantità di scalabilità necessaria è relativamente piccola (come la regolazione di una singola funzione), potrebbe essere necessario smantellare e ricostruire il sistema per riflettere il nuovo cambiamento, cosa che potrebbe rivelarsi dispendiosa in termini di tempo e manodopera.

L'altro modello di sviluppo software (i microservizi) è uno stile architettonico cloud-native. Con i microservizi, un'applicazione si basa su più componenti o servizi singoli a regime di accoppiamento libero. Le applicazioni di microservizi hanno il proprio stack tecnologico, ovvero una raccolta di tecnologie che lavorano insieme per portare a termine un determinato lavoro.

Il vantaggio principale dei microservizi è che il sistema può essere facilmente aggiornato per affrontare nuove funzionalità aziendali all'interno dell'applicazione, senza impattare l'intero sistema. Questo può tradursi in un notevole risparmio di tempo e manodopera.

I vantaggi dei microservizi sono numerosi, perché si adattano sia alla costante crescita aziendale che ai nuovi cambiamenti tecnologici:

• Scalabilità aumentata: i microservizi eccellono in termini di scalabilità rispetto alle architetture monolitiche. I singoli servizi all'interno di un'architettura di microservizi sono suddivisi in moduli e una singola istruzione per scalare può essere trasmessa a più servizi contemporaneamente. Inoltre, i microservizi sono adatti alla gestione di applicazioni grandi e complesse.

• Pronti per l'automazione: i microservizi in uso consentono alle organizzazioni di automatizzare il processo di integrazione e fornitura continua (CI/CD). Ciò consente lo sviluppo di aggiornamenti del codice che vengono eseguiti in base a una pianificazione continua.

• Operazione indipendente: l'architettura dei microservizi divide ogni servizio in una cella operativa. Con questo tipo di operazione indipendente, non vi è alcun pericolo che il workflow per un'applicazione di microservizi si intrometta nei workflow di altre applicazioni di microservizi.

I microservizi offrono benefici definiti, ma la loro complessità crea alcuni problemi:

• Problemi con i test: con i microservizi, le operazioni di debug non iniziano fino a quando le varie parti di un'applicazione non sono state testate. Ciò include il controllo delle dipendenze, le attività di memorizzazione nella cache e l'accesso ai dati.

• Potenziale esposizione di sicurezza: lo scambio di dati che avviene tra vari processi all'interno di un sistema di microservizi utilizza un API gateway. Un API gateway può creare vulnerabilità di sicurezza nell'autenticazione e in altre attività critiche.

• Aumento della latenza: i microservizi scalano le applicazioni in modo impressionante, ma questo può creare problemi con ritardo e latenza aggiuntivi. Ogni volta che il sistema aumenta la scalabilità, aumenta la complessità e la quantità di dati trasferiti e questo può rallentare l'elaborazione.

Prima di procedere al confronto diretto tra architettura monolitica e architettura a microservizi, è opportuno approfondire la questione con alcuni dettagli storici per fornire un contesto più ampio.

In un certo senso, è difficile far risalire l'origine dell'architettura monolitica a una singola data: più la tecnologia è complicata, più difficile può essere individuare la sua esatta creazione. E vale anche per le architetture monolitiche, che iniziarono a svilupparsi intorno alla metà del XX secolo.

International Business Machines (IBM®) è stato uno dei principali attori in questo primo sviluppo critico. Secondo Pier-Jean Malandrino, collaboratore di DZone, "... aziende come IBM sono state determinanti nella definizione delle prime architetture software attraverso lo sviluppo dei computer mainframe negli anni '60 e '70".¹

Le architetture monolitiche non erano perfette: erano spesso scritte in linguaggi ultra-basici ed erano destinate ad essere lette da una singola macchina. Poiché solo una macchina conteneva l'intero sistema, tutti i componenti del computer erano strettamente collegati. La scalabilità era inesistente o a malapena possibile, e di solito richiedeva la ricostruzione completa di un sistema.

Tuttavia, se l'architettura monolitica appare grezza (col senno di poi), è in parte perché esisteva già prima di qualsiasi altro sistema di architettura software e si è dimostrata costantemente utile e addirittura resistente nel tempo. Il fatto che le architetture monolitiche vengano ancora utilizzate settant'anni dopo la loro introduzione la dice lunga, in un settore in cui l'unica cosa che di solito rimane è il cambiamento incessante.

L'architettura monolitica ha resistito, ma non è più l'unico sceriffo in città, e non lo è più da tempo. Con il progredire degli anni '80, il software engineering ha sperimentato una spinta verso la modularità e l'uso di linguaggi di programmazione orientati agli oggetti. Negli anni '90, il palcoscenico era stato preparato per i sistemi distribuiti che avrebbero potuto utilizzare al meglio i recenti progressi nel network computing.

Ciò ha portato allo sviluppo dei microservizi, che sono diventati ampiamente utilizzati dopo l'inizio del cloud computing e delle tecnologie di containerizzazione negli anni 2000. L'architettura a microservizi è stata creata per migliorare il modello monolitico, adattandola alla scalabilità rapida e ai sistemi decentralizzati.

Ora, negli anni 2020, lo sviluppo del software si basa su un'architettura monolitica o su un'architettura a microservizi. Sulla base di ciò che ci aspettiamo dal cambiamento tecnologico, il nostro pensiero iniziale potrebbe essere quello di presumere che la tecnologia che è arrivata più di recente sia superiore e, in alcune circostanze, è sicuramente così.

Tuttavia, fare questo tipo di generalizzazione è pericoloso, soprattutto perché non è vero. Esistono ancora numerose situazioni informatiche che beneficiano della semplicità del modello di architettura monolitica.

Entrambe le architetture software hanno i loro vantaggi e svantaggi e le aziende devono valutare attentamente entrambi i tipi e considerare le loro esigenze di sviluppo delle applicazioni previste prima di adottare un sistema o l'altro.

Come si confrontano l'architettura monolitica e l'architettura a microservizi se viste attraverso il prisma delle fasi operative chiave?

• Creazione: le differenze principali tra i due formati architettonici iniziano presto, con l'ideazione del sistema desiderato. I sistemi monolitici sono più semplici da costruire perché utilizzano una progettazione più semplice. I microservizi sono notevolmente più complessi e richiedono una maggiore pianificazione per l'esecuzione.

• Struttura: un'architettura monolitica è progettata e costruita come un'unica unità. L'architettura dei microservizi sostiene l'idea di modularità utilizzando una raccolta di applicazioni più piccole e distribuibili che consentono le operazioni di servizi indipendenti.

• Complessità: più un sistema diventa complicato, più è adatto per un'architettura a microservizi. I microservizi modulari accolgono nuove caratteristiche e nuove tecnologie che tendono ad accompagnare l'aumento della complessità.

• Crescita: l'architettura monolitica e l'architettura a microservizi possono essere entrambe efficaci durante il loro utilizzo iniziale. Ma la crescita cambia tutto, in particolare quando le organizzazioni si rendono conto che presto si espanderanno oltre il loro sistema iniziale. A questo punto, le aziende hanno bisogno di una fase di operazioni più ampia, e i microservizi la forniscono, offrendo più modi per scalare rispetto all'architettura monolitica.

• Time to market: questa metrica chiave svolge un ruolo fondamentale nel commercio misurando il tempo necessario per produrre beni e inserirli nei canali di distribuzione. Il time to market è un'area in cui l'architettura monolitica eccelle rispetto ai microservizi. Utilizzando una sola base di codice, gli sviluppatori possono evitare il tempo e la manodopera aggiuntivi necessari per incorporare software da varie fonti.

• Scalabilità: l'architettura dei microservizi è basata su singoli servizi che possono essere compartimentati in forme modulari e trarre beneficio dal coupling libero e dall'intercomunicazione ottenuti utilizzando le API. D'altra parte, l'architettura monolitica è complessivamente meno adattabile a causa di una struttura di base densamente composta e di un software strettamente accoppiato.

• Debugging: il debugging è il processo di utilizzo del software per rilevare e individuare i problemi di codifica e porvi rimedio. L'architettura monolitica gestisce il debug meglio dei microservizi perché è più semplice e diretto. Il debug di un'architettura a microservizi è notevolmente più lento, più complesso e laborioso.

Esiste un'offerta quasi illimitata di casi d'uso che possono essere raggiunti utilizzando un'architettura monolitica o un'architettura a microservizi. Questi sono alcuni dei più diffusi:

• Startup: le aziende che hanno appena iniziato hanno bisogno di due cose: flessibilità e finanziamenti per l'avviamento (e in grande quantità). Un'architettura monolitica è il modo migliore per avviare nuove attività. Inoltre, può essere costruito da team di sviluppo snelli in modo conveniente e senza imporre una curva di apprendimento troppo ripida a questi piccoli team.

• Progetti di base: avere un'unica base di codice ripaga in termini di convenienza, soprattutto con progetti di portata rudimentale. Quando il software può attraversare il processo di sviluppo senza dover incorporare i dati da più fonti, è una vittoria per l'organizzazione.

• Piattaforme di intrattenimento: la gestione di una piattaforma d'intrattenimento internazionale richiede la capacità di cavalcare l'onda mutevole dei workload, sia che la domanda si trasformi in workload leggeri o pesanti. Nel caso di Netflix, il gigante dello streaming video è passato da un'architettura monolitica a un'architettura a microservizi basata sul cloud. Il nuovo backend Netflix contiene un ampio supporto per il bilanciamento del carico che lo aiuta a ottimizzare i workload.

• Ecommerce: l'e-commerce dipende dall'architettura a microservizi per far vivere la magia del marketplace con un'esperienza senza soluzione di continuità. Con rivenditori ambiziosi come Amazon (AWS) che promuovono le vendite con maggiore comodità e consegne più rapide, è facile capire perché il mercato delle vendite di e-commerce del 2023 abbia superato i 5,8 trilioni di dollari.²

• I lavori più difficili: l'uso continuo dei microservizi richiede in genere le competenze di implementazione e amministrazione di team DevOps formati per creare i servizi specifici necessari per quel framework. Queste competenze sono particolarmente utili quando si incontrano applicazioni complesse.

Qualsiasi implementazione su larga scala di un'architettura monolitica o di un'architettura a microservizi sarà inevitabilmente fuorviante se la sua progettazione viene completata alla cieca, senza prima considerare la parte più importante dell'equazione: le esigenze particolari della tua startup tecnologica.

In qualità di direttore IT, questa è l'attività più critica nella pianificazione delle decisioni relative all'infrastruttura software. Sapere quando utilizzare un determinato stile architettonico è fondamentale, così come capire il sistema più adatto in base agli usi necessari.

L'esercizio di autoanalisi è molto prezioso perché è tuo compito non solo selezionare il sistema architettonico ottimale per la tua organizzazione, ma anche stimare con precisione il sistema architettonico di cui la tua azienda avrà bisogno nei mesi e negli anni a venire. In un certo senso, ti viene affidato il compito di prevedere il futuro.

Quindi, anche se un'architettura monolitica potrebbe sembrare perfettamente ideale per la sua startup, spetta a te progettare la crescita futura. E se si prevede un'espansione dilagante, potrebbe rivelarsi più saggio andare avanti e investire in un'architettura a microservizi. Ci sono numerose variabili da considerare:

• Logica di business in uso: proprio come la logica del computer determina ciò che è e non è possibile con un computer, la logica di business si basa su business rule che governano il modo in cui un'azienda può o non può essere gestita. Tecnicamente, si traduce negli algoritmi che definiscono il passaggio di informazioni tra un database e un'interfaccia utente.

• Sviluppo front-end: già quando si pianifica il front-end dell'architettura software, è necessario definire l'approccio architettonico stai seguendo, perché ognuno ha una struttura unica. In un'architettura monolitica, l'applicazione front-end si manifesta come un unico grande codebase che ospita tutto il codice dell'applicazione. In un'applicazione front-end a microservizi, è possibile mettere in operazione più microservizi che operano in modo indipendente.

• Tolleranza ai guasti: un'altra considerazione da fare riguarda quanta tolleranza ai guasti dovrebbe essere necessaria. La tolleranza ai guasti è un problema molto complesso, perché può causare l'arresto di un'intera applicazione se si verifica un errore di un solo componente del sistema. Un'architettura monolitica manca di isolamento tra componenti, e ciò può aggravare la mancanza di tolleranza e portare a lunghi periodi di tempo di inattività.

• Tasso di cambiamento previsto: la scelta tra architettura monolitica e architettura a microservizi non è solo una questione di architettura software. Si tratta in realtà di una scelta tra due mentalità aziendali, una che vuole semplicemente entrare in funzione e un'altra che insiste sul raggiungimento di una crescita aziendale sostanziale. La crescita può essere complicata, ma è ben supportata dagli attributi dell'architettura a microservizi, come cicli di sviluppo più rapidi e una maggiore scalabilità.