Architettura Software nel 2024: Quando i Microservizi Vincono e Quando il Monolite Regna

Nel dibattito tecnico che anima la comunità degli sviluppatori italiani, poche questioni generano tanto accaloramento quanto la scelta dell'architettura di base per un progetto CMS. Da una parte i fautori dei microservizi, dall'altra i difensori del monolite ben strutturato: entrambi hanno ragioni solide, e spesso entrambi hanno torto nel momento in cui assolutizzano la propria posizione.

In questo articolo proviamo a fare chiarezza, partendo da un presupposto fondamentale: non esiste una risposta universalmente corretta. Esiste, però, una risposta giusta per il vostro specifico contesto.

Il Monolite: Un Vecchio Amico Spesso Sottovalutato

Il termine "monolite" ha acquisito nel tempo una connotazione quasi dispregiativa nel gergo degli sviluppatori. Eppure, definire monolitica un'applicazione non significa necessariamente che sia mal strutturata o difficile da mantenere.

Un CMS monolitico ben progettato concentra tutta la logica applicativa — gestione dei contenuti, autenticazione, rendering, business logic — in un'unica codebase deployata come unità atomica. WordPress, nella sua forma classica, ne è l'esempio più noto a livello mondiale. XOOPS stesso, nella sua architettura tradizionale, segue questo paradigma, offrendo un sistema coeso in cui i moduli comunicano attraverso API interne ben definite.

I vantaggi concreti del monolite includono:

• Semplicità operativa: un singolo processo da deployare, monitorare e scalare verticalmente.
• Latenza ridotta: le chiamate tra componenti sono in-process, non attraverso la rete.
• Debug facilitato: lo stack trace è lineare e leggibile senza dover incrociare log di servizi multipli.
• Onboarding più rapido: un nuovo sviluppatore può comprendere l'intera applicazione senza mappare decine di repository.

Drupal 10, per esempio, mantiene un'architettura fondamentalmente monolitica pur offrendo capacità headless tramite JSON:API. Il risultato è un sistema robusto, ben documentato e con una comunità matura che ha risolto la maggior parte dei problemi comuni.

I Microservizi: Potenza Reale o Complessità Inutile?

L'architettura a microservizi decompone l'applicazione in servizi autonomi, ciascuno responsabile di un dominio specifico: un servizio per l'autenticazione, uno per la gestione dei media, uno per il workflow editoriale, e così via. Ogni servizio può essere sviluppato, deployato e scalato indipendentemente.

Contentful e Strapi, nei loro approcci più avanzati, incarnano questa filosofia. La promessa è allettante: team indipendenti, tecnologie eterogenee per ogni servizio, scalabilità granulare.

Tuttavia, i costi nascosti sono reali e spesso sottostimati:

• Complessità distribuita: i problemi non scompaiono, si spostano dalla codebase alla rete. Race condition, timeout, eventual consistency diventano preoccupazioni quotidiane.
• Overhead infrastrutturale: service mesh, API gateway, service discovery, distributed tracing — ogni elemento richiede competenze specifiche e introduce potenziali punti di fallimento.
• Latenza di rete: ogni chiamata tra servizi attraversa la rete, introducendo latenze che in un monolite non esistono.
• Testing end-to-end: orchestrare test che coinvolgono più servizi richiede ambienti complessi e spesso fragili.

Un caso emblematico è quello di Amazon, che inizialmente adottò i microservizi su larga scala, salvo poi ammettere — come documentato in un celebre post tecnico del 2023 — che per determinati team il ritorno a un'architettura più coesa aveva portato significativi miglioramenti in termini di produttività e affidabilità.

Criteri Pratici per la Scelta

La domanda che ogni sviluppatore dovrebbe porsi non è "quale architettura è migliore in assoluto?", bensì "quale architettura è adeguata alla dimensione e complessità del mio progetto oggi, e nei prossimi due anni?"

Optate per il Monolite se:

• Il team è composto da meno di dieci sviluppatori.
• Il progetto è in fase early-stage e i requisiti cambiano rapidamente.
• Non disponete di competenze DevOps avanzate per gestire infrastrutture distribuite.
• Il traffico atteso è prevedibile e non richiede scalabilità granulare per singole funzionalità.

Valutate i Microservizi se:

• Avete team distinti che lavorano su domini funzionali separati e necessitano di autonomia nel deployment.
• Specifici componenti del sistema hanno requisiti di scalabilità radicalmente diversi dagli altri.
• La vostra organizzazione ha già maturato competenze solide in Kubernetes, service mesh e osservabilità distribuita.
• I tempi di rilascio del monolite sono diventati un collo di bottiglia organizzativo documentabile.

Il Pattern Modulare: Una Via di Mezzo Pragmatica

Esiste una terza via, spesso trascurata nel dibattito binario: il monolite modulare. Questa architettura mantiene il deploy unitario del monolite classico, ma organizza internamente il codice in moduli con confini netti e interfacce esplicite.

XOOPS adotta esattamente questo approccio: il core rimane un'unità coesa, ma il sistema di moduli consente di estendere le funzionalità mantenendo separazione delle responsabilità. Quando — e se — un modulo specifico dovesse richiedere scalabilità indipendente, la sua estrazione in un microservizio diventa un'operazione chirurgica invece di un refactoring traumatico.

Questo pattern è stato teorizzato da Majestic Monolith da Sam Newman, uno dei massimi esperti di architetture distribuite, proprio come punto di partenza consigliato per la maggior parte dei progetti.

Conclusioni: La Maturità Tecnica Come Variabile Determinante

Nel 2024, la scelta architetturale più sofisticata non è necessariamente quella più complessa. La vera maturità tecnica consiste nel riconoscere i limiti del proprio contesto organizzativo e tecnologico, e nel selezionare l'architettura che massimizza la produttività del team nel breve periodo senza ipotecare eccessivamente la scalabilità futura.

Per la maggior parte dei progetti CMS italiani — dai portali editoriali alle piattaforme di e-learning, dai siti istituzionali ai portali comunitari — un monolite ben strutturato o un'architettura modulare rappresentano ancora la scelta più razionale. I microservizi rimangono uno strumento potente, ma vanno adottati quando il problema da risolvere li giustifica concretamente, non per seguire una moda tecnologica.