Lasagne o tortellini? Applicazioni monolitiche vs architetture a microservizi
A volte in campo informatico, per spiegare meglio le scelte di sviluppo, vengono proposte succose metafore prese dall’ambito culinario. È il caso delle architetture a monolite e quelle a microservizi. Due “piatti” decisamente diversi: il primo più simile alle lasagne, con più strati, il secondo ai tortellini, composto quindi da più unità simili.
E se le scelte gastronomiche creano accese discussioni a tavola, con fazioni contrapposte, il mondo informatico non è da meno. Cerchiamo dunque di approfondire i pro e i contro di ciascun modello di architettura per capire su cosa verte questo dibattito.
Architettura a monolite
L’architettura monolitica è sicuramente l’approccio più convenzionale e storicamente più utilizzato. La sua struttura prevede che l’applicazione sia complessivamente costruita come una singola unità. Un’interfaccia utente e un’applicazione lato server costituito da vari moduli che operano con i dati forniti dall’utente e applicano modifiche al database che li raccoglie.
La visione monolitica ricorda una soffice e delicata lasagna che, nonostante sia composta da diversi strati e arricchita con sughi di vario tipo, risulta un unico pezzo.
| Vantaggi | Svantaggi |
|---|---|
| Semplice da sviluppare. Scelti in fase di analisi i requisiti, i linguaggi e tecnologie da impiegare | Limitazioni in termini di grandezza e di complessità |
| Semplice da testare | Spesso è d’obbligo fare il deploy completo del server per un update |
| Semplice da effettuare il deploy in produzione | Spesso un singolo bug in una parte dell’applicazione può generare un effetto a catena su tutta l’applicazione |
| Semplice se si vuole effettuare uno scaling orizzontale, in quanto è sufficiente effettuare più copie del server | L’impatto di un singolo cambiamento può avere un effetto domino, ed è quindi d’obbligo testare in modo approfondito |
| Un cambio di tecnologia o di framework è spesso ostacolato in quanto stravolge l’intera applicazione | |
| Tutto lo sviluppo del server spesso è delegato a un’unica azienda responsabile |
Architettura a microservizi
L’architettura a microservizi, al contrario di quella a monolite, ha l’obiettivo di sviluppare un’applicazione come una collezione di servizi.
Mentre la visione esterna da parte dell’interfaccia utente rimane la medesima, la logica di server viene scomposta in servizi indipendenti con un task ben definito. In ambito business, spesso i servizi sono esposti da fornitori diversi e per questo motivo tutti i servizi sono tecnologicamente diversi nella loro interezza (linguaggio, database, etc..).
Questa struttura distribuita ricorda molto un abbondante piatto di tortellini, ognuno leggermente diverso, ma che nel complesso soddisfano la fame di chi li ordina!
Un esempio molto forte di applicazione che si basa su questa architettura è Netflix. L’architettura finale comprende più di 500 microservizi (pagamenti, visione video, ecc… ) e il diagramma finale è simile al seguente:
Ogni nodo verde rappresenta il data store di un servizio e le linee blu rappresentano le connessioni tra due microservizi. L’esempio di Netflix è forse un estremo, però il concetto di architettura a microservizi è stato adottato nella sua totalità, anche se i pregi e difetti di questo modello rimangono.
| Vantaggi | Svantaggi |
|---|---|
| Il problema della complessità viene suddiviso scomponendo l’applicazione in un insieme di servizi | Sviluppare è molto complesso |
| Ogni servizio può essere sviluppato indipendentemente da un team che se ne occupa esclusivamente | I test richiedono più tempo in quanto ogni singolo servizio è da testare |
| Il deploy del microservizio è indipendente dal resto dell’applicazione | Necessità di saper orchestrare bene i servizi tramite DevOps come Docker, Kubernetes, etc.. |
| Il fallimento di un servizio non compromette l’applicazione nella sua interezza | Se un servizio dipende da più microservizi, e uno di questi servizi ha malfunzionamenti, il servizio non è più accessibile |
| La scalabilità dell’applicazione è più facilitata in quanto ogni servizio è scalabile indipendentemente dagli altri |
Micro frontend
In precedenza abbiamo sostenuto che il frontend non venga influenzato dalla scelta contrapposta tra il monolite o microservizi. Questo però non si verifica sempre in maniera precisa.
Molto spesso per un’applicazione i diversi servizi vengono sviluppati da fornitori diversi che autonomamente sviluppano con tecnologie e linguaggi vari. Frequentemente gli stessi fornitori sviluppano anche l’interfaccia grafica che si rapporta direttamente con il servizio. La schermata principale della UI diventa quindi un insieme di questi componenti frontend (spesso tramite <iframe>). In questo caso si parla di Micro frontend.
Il termine Micro frontend fu adottato poco più di due anni fa da Technology Radar ed estende il concetto di microservizi al frontend, lasciando la responsabilità dello sviluppo dei singoli frontend a chi fornisce il servizio. In questo modo ogni team che sviluppa il servizio è tecnologicamente indipendente dal complesso dell’applicazione.
Approfondimenti
Per chi volesse approfondire i concetti esposti di seguito si segnalano alcune fonti su cui l’articolo è basato.
Introduction to Micro Services
Molti concetti provengono dai nostri appunti dell’ultima edizione del Pycon, evento dedicato a Python, uno dei linguaggi più utilizzati al mondo, svoltosi a Firenze a inizio maggio 2019.