Quando si affronta un nuovo progetto software, una delle prime scelte architetturali più importanti è: monolite o microservizi? Sebbene l’approccio a microservizi sia sempre più diffuso, non è detto che sia la scelta migliore in ogni contesto. In questo articolo analizziamo vantaggi e svantaggi di entrambi i modelli, con uno sguardo particolare al nostro approccio in CFML.
Il monolite: semplicità, rapidità e coesione. Lo sviluppo monolitico prevede che tutte le funzionalità dell’applicazione siano contenute in un’unica base di codice e distribuite come un unico blocco. Questo approccio ha il vantaggio di essere più semplice da progettare e mantenere, soprattutto nelle fasi iniziali di un progetto. Il deploy è unico, la comunicazione tra moduli è diretta, e la gestione delle dipendenze è centralizzata.
Nel nostro caso, sviluppare in CFML (ColdFusion Markup Language) ci permette di costruire applicazioni monolitiche in modo estremamente rapido ed efficiente. I nostri ambienti sono ottimizzati per questo tipo di architettura, e la velocità di sviluppo è spesso superiore rispetto ad altri approcci più frammentati.
I microservizi: modularità e scalabilità, ma a caro prezzo. L’approccio a microservizi consiste nel dividere l’applicazione in piccoli servizi indipendenti, ciascuno con un proprio ambito di responsabilità, spesso con database separati, e che comunicano tramite API. Questo modello è ideale per realtà complesse, distribuite, ad alta scalabilità e con team di sviluppo numerosi e indipendenti.
Va detto con onestà: adottare i microservizi significa aumentare considerevolmente la complessità. Ogni microservizio richiede deploy separati, monitoraggio dedicato, orchestrazione, logistica di comunicazione, gestione delle versioni delle API, sicurezza distribuita e più test di integrazione.
Inoltre, i tempi di sviluppo si allungano. Non è raro che il tempo per completare una funzionalità si moltiplichi, perché bisogna tenere conto di vari livelli di astrazione e di infrastruttura.
Quando scegliere cosa:
- se il tuo progetto è contenuto, ha un unico team, e non richiede alta scalabilità distribuita: meglio il monolite.
- se invece hai necessità di scalare orizzontalmente, team diversi, e componenti riutilizzabili: i microservizi potrebbero fare al caso tuo.
Nel nostro lavoro quotidiano, consigliamo sempre di partire da un’architettura snella e coerente (spesso monolitica), per poi eventualmente “modularizzare” nel tempo. Il refactoring è possibile, ma partire subito con un’infrastruttura distribuita, senza reale bisogno, può rallentare notevolmente lo sviluppo e aumentare i costi (di sviluppo, di housing/cloud, ecc.).
Per approfondire il tema, indichiamo alcune letture:
- Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith – Sam Newman, 2019 + PDF;
- Building Microservices: Designing Fine-Grained Systems – Sam Newman, 2015;
- Microservices Patterns: With examples in Java – Chris Richardson, 2018;
- Documentazione CFML su Adobe ColdFusion.
Monolite e microservizi non sono in contrapposizione, ma due approcci architetturali con filosofie diverse. La chiave è capire qual è il punto di partenza più sostenibile per il proprio progetto.
In DEV4U ci siamo spesso trovati a partire con applicazioni monolitiche ben strutturate, che nel tempo sono cresciute in moduli o microservizi dove aveva senso farlo. Come sempre, la tecnologia deve seguire la strategia, non il contrario.
Per avere maggiori informazioni su questo argomento vi invitiamo a contattarci.
Fisseremo un incontro per parlarne e approfondire il tema.
Contattaci via mail scrivendo a info@dev4u.it, non perdere altre opportunità!
Autore/i dell’articolo:
Dario Berardi – BIO – Linkedin – Email
System Analyst | Senior Developer | Database Architect
Maurizio Patitucci – BIO – Linkedin – Email
Business Analyst | Project Manager | Account Manager
