Architettura software monolitica contro microservizi

Riassunto

Questa settimana sono volato a Göteborg per incontrare le persone di una grande compagnia di navigazione internazionale e parlare dello sviluppo di software di livello enterprise. Durante la riunione c'erano vari esperti in sala e uno di loro mi ha chiesto come scegliere la giusta architettura software (per app grandi, complesse, di livello enterprise). Un'ottima domanda, che merita un articolo sul blog.

Testo completo

Architettura software

Quando progetti un'app non devi pensare solo all'aspetto e alla sensazione d'uso: un buon progetto riguarda anche come funziona tutto insieme. L'architettura software descrive le strutture fondamentali di un sistema software; ogni struttura comprende elementi, le relazioni tra di essi e le proprietà sia degli elementi sia delle loro relazioni.

È analoga all'architettura di un edificio. Una volta definita e realizzata un'architettura, cambiarla dopo diventa costoso. Per questo conviene scegliere l'architettura software giusta prima di iniziare a costruire.

Per le app semplici l'architettura può essere ovvia, ma man mano che la tua applicazione cresce in dimensioni e funzionalità, il numero di strutture del sistema può aumentare rapidamente. Può succedere col tempo, mentre crescono le esigenze del tuo cliente. Più strutture ci sono, più relazioni ci sono tra loro, e più tutto diventa complesso.

Gestire un progetto software complesso

Se ti aspetti che il tuo software gestisca tante cose diverse, è probabile che dovrai fare i conti con la complessità. Dal punto di vista architetturale ci sono approcci diversi per affrontarla.

Architettura monolitica

L'architettura monolitica si descrive meglio come 'un unico grande blocco'. Qui tutto ciò che fa la tua app fa parte della stessa base di codice.

In una "architettura monolitica" il software è spesso organizzato a strati, e ogni strato è composto da tipi di componenti diversi:

• livello di presentazione: responsabile dell'interfaccia utente e/o dell'interfaccia di programmazione (UI / API).
• logica di business: qui si definiscono le vere regole di business. È il cuore dell'applicazione, molto vicino ai processi aziendali reali.
• livello di accesso agli oggetti dati: offre un'interfaccia comune tra l'applicazione in esecuzione e gli archivi persistenti di backend.
• database e filesystem: qui sono archiviati tutti i dati e le risorse statiche (file, immagini, ecc.).

Più l'applicazione cresce, più ogni strato diventa grande. Questo rende più difficile far scalare un'architettura monolitica: a un certo punto le cose diventano semplicemente troppo grandi e complesse.

Ogni volta che modifichi l'applicazione, viene toccata l'intera base di codice. Per applicazioni (molto) grandi questo rende più difficile la manutenzione, perché serve una comprensione completa dell'intera applicazione.

Siccome l'intera applicazione è interdipendente, i problemi in una parte spesso colpiscono in modo significativo tutto il sistema. La comunicazione tra le diverse parti avviene internamente, a livello di codice. Quindi le diverse parti devono essere programmate nello stesso linguaggio (o in linguaggi compatibili). Questo è un ostacolo per adottare nuove tecnologie (in futuro), perché non puoi cambiare facilmente il linguaggio di programmazione di una sola parte del sistema.

Architettura a microservizi

Invece di costruire un'unica grande applicazione monolitica puoi dividerla in servizi più piccoli e collegati tra loro. Ogni microservizio è una piccola applicazione a sé, completa di una propria architettura (più piccola e più semplice), di una propria logica di business e di propri livelli di dati.

I diversi servizi comunicano tra loro tramite API definite indipendentemente dalla tecnologia usata, spesso in una comune "struttura API" come REST, JSON, Redis e XML. Questo permette all'insieme dei microservizi di funzionare come "un unico sistema".

Scomponendo l'applicazione 'a grande blocco' in servizi più piccoli, diventa più facile capire le varie parti del sistema. E questo rende il sistema più facile da mantenere, perché ogni microservizio si può sviluppare in modo indipendente. Si abbassa anche l'ostacolo all'adozione di nuove tecnologie, perché sei libero di scegliere quella più adatta a ciascun servizio. Una parte del sistema può essere programmata in un linguaggio diverso dalle altre. Così team diversi (con competenze diverse) possono lavorare insieme.

L'arte e la competenza per ottenere l'architettura a microservizi giusta stanno nel saper definire correttamente un microservizio. Troppo ampio o troppo granulare può rovinare l'architettura. Per definire ogni microservizio puoi usare i processi di business, o una separazione gerarchica o per dominio.

La sfida dell'architettura a microservizi è che aggiunge complessità all'intero sistema, perché richiede un meccanismo di comunicazione distribuito. Le diverse API che si collegano tra loro possono essere difficili da testare e da correggere. Diventa più difficile applicare modifiche che attraversano più servizi.

Definire, progettare e realizzare le diverse API tra i servizi richiede un accordo sui dati scambiati, e può essere difficile da raggiungere quando vuoi condividere strutture di dati estese e non universali.

Monitorare e distribuire un'architettura a microservizi può essere complesso quando i servizi aumentano di numero. C'è semplicemente di più da gestire, e serve più pianificazione e coordinamento per ciascuno dei servizi.

Scegliere l'architettura giusta

Mio padre, che non c'è più, una volta mi ha detto che "si guadagna di più con le cose che non si fanno". Costruire applicazioni complesse è difficile per natura: la cosa migliore è cercare di semplificare, semplicemente non facendo tutto. Concentrati sulle cose che contano davvero e falle bene.

Se la tua applicazione è semplice e leggera, l'architettura monolitica è la strada giusta. Sviluppo, distribuzione, manutenzione: tutto è più facile quando le cose sono piccole.

Se non puoi sfuggire alla complessità, allora considera sul serio l'architettura a microservizi. Fatti queste domande:

• Riesci a definire un "linguaggio comune" tra i tuoi microservizi?
• Ci sono processi di business chiaramente distinti?
• Quanto sono interdipendenti questi processi di business?
• Come pensi che si evolverà la tua applicazione nel tempo: crescerà o si ridurrà?
• Quante tecnologie di programmazione diverse pensi di usare? Ti aspetti che cambino in futuro?
• Chi costruirà e manterrà il software? Ha esperienza nella gestione di un'architettura di questo tipo?

Conclusione

Non esiste una risposta "magica" alla domanda su quale architettura software sia giusta. Entrambi gli approcci hanno pro e contro.

La cosa migliore che puoi fare è prendere una decisione consapevole, ben ponderata, e puntarci con decisione!