Durante la creazione di una nuova applicazione, una delle prime domande utili per la progettazione è se è opportuno lavorare con un’architettura monolitica o un’architettura a microservizi.
Utilizzando entrambe le metodologie si possono creare applicazioni robuste che servono a una varietà di scopi, anche se l’architettura su cui poggia il progetto è molto differente. Inoltre, una volta creata un’applicazione, può essere complesso e dispendioso in termini di tempo modificare l’architettura sottostante. Per evitare costosi errori, quando si creano nuove applicazioni in ambiente web, dovrebbero essere considerati diversi fattori. Di seguito prendiamo in esame le principali differenze tra applicazioni monolitiche e applicazioni basate su microservizi, alcuni casi d’uso per ciascuna e i principali fattori da considerare quando bisogna scegliere il tipo di architettura per il progetto.
Un’applicazione monolitica, spesso definita semplicemente come “monolito”, è un’applicazione composta da un’ampia base di codice che include tutti i componenti dell’applicazione, come il codice front-end, il codice back-end e i file di configurazione.
I monoliti sono spesso considerati un metodo più vecchio e tradizionale per creare applicazioni, ma in realtà moltissime aziende, ancora oggi, traggono numerosi vantaggi dall’utilizzo di un’architettura monolitica.
I monoliti sono generalmente più veloci da sviluppare e distribuire rispetto a un’applicazione che utilizza microservizi e possono essere più semplici da gestire. Tuttavia, le applicazioni monolitiche potrebbero essere difficilmente scalabili e, all’aumentare della complessità, potrebbero risentire di problemi di gestione e manutenzione del codice sorgente.
Le applicazioni monolitiche sono più semplici da sviluppare e mettere in campo (deploy): essendo tutti i componenti di un’applicazione monolitica centralizzati, possono essere relativamente semplici da sviluppare e possono comportare un time-to-market più rapido. Per piccoli team di sviluppo o sviluppatori singoli, un’architettura monolitica generalmente permette di creare, testare e avviare applicazioni più rapidamente.
Le applicazioni monolitiche sono più facili da testare: i monoliti sono spesso più facili da testare rispetto alle applicazioni basate su microservizi, con un solo repository di codice utilizzato durante il test e il debug.
Le applicazioni monolitiche richiedono competenze meno specializzate: anche se il mercato sta cambiando molto repentinamente, la maggior parte dei team di sviluppo oggi è in grado di creare un’applicazione monolitica. La creazione di un’applicazione basata su architettura a microservizi richiede ulteriori competenze e formazione specifica.
Le applicazioni monolitiche hanno una gestione della sicurezza unica: l’utilizzo di un monolito fa in modo che la sicurezza sia gestita in un’unica posizione, anziché dover tenere traccia di eventuali vulnerabilità in tutti i microservizi.
Le applicazioni che utilizzano un’architettura monolitica possono diventare complesse nel tempo: quando un’applicazione cresce e si aggiungono nuove funzionalità, il codice sorgente in un’architettura monolitica può diventare di grandi dimensioni ed estremamente complesso. La gestione del progetto può complicarsi notevolmente, soprattutto quando cresce il team di sviluppatori. Possono verificarsi inattesi effetti collaterali quando le modifiche apportate a un componente dell’applicazione influiscono inavvertitamente su altre funzionalità. Ciò può comportare una dilatazione dei tempi necessari per identificare i problemi.
I monoliti possono essere difficili da scalare: in generale l’unico modo per scalare un’applicazione con architettura monolitica è il ridimensionamento verticale poiché bisogna aggiungere risorse computazionali per scalare tutta l’applicazione. Questo approccio può essere costoso, inefficiente e potrebbero esserci dei limiti alla scalabilità verticale di un’applicazione.
Possono presentare limiti tecnologici: l’aggiunta o la modifica di funzionalità a un monolito può diventare un’attività molto complessa a causa delle dipendenze che si possono trovare. A seconda delle esigenze dell’applicazione, gli sviluppatori potrebbero essere limitati nelle nuove funzionalità e nelle scelte implementative.
Possono essere bloccanti: poiché tutte le parti di un’applicazione sono strettamente collegate, un problema in qualsiasi punto del codice può causare il blocco dell’intera applicazione.
Un’applicazione basata su un’architettura a microservizi suddivide ogni parte dell’applicazione in parti di codice indipendenti che eseguono un’attività specifica.
Solo per fare un esempio, un microservizio può essere utilizzato per la gestione degli utenti, un altro per la gestione dei prodotti,mentre un microservizio separato si occupa dei pagamenti.
Ciascun componente dell’applicazione può essere distribuito e scalato indipendentemente dagli altri moduli. Questi moduli comunicano tra loro tramite API (Application Programming Interface) per creare la funzionalità completa dell’applicazione.
L’uso dei microservizi come metodologia architetturale ha visto una grande crescita negli ultimi anni. Il termine “micro” potrebbe indurre a pensare che si tratti di un servizio piccolo che, quindi, non dovrebbe svolgere funzioni complesse, ma non è così. È vero che un microservizio è un piccolo componente di una grande applicazione, ma può svolgere una vasta gamma di funzionalità, dalle più minuscole alle più grandi e complesse.
Nonostante la loro crescente popolarità rispetto ad applicazioni monolitiche, i microservizi presentano alcuni inconvenienti che dovrebbero essere considerati.
Autonomia: ogni microservizio è autonomo, il che significa che può essere sottoposto a debug, distribuito e gestito indipendentemente dagli altri moduli. Quando un’applicazione cresce, i vantaggi sono innegabili, le modifiche di un componente non influiscono sugli altri e ogni microservizio può essere gestito da un team dedicato alla singola funzionalità.
Scalabilità: utilizzando i microservizi, un’applicazione può essere ridimensionata sempre verticalmente, come nell’architettura monolitica, ma anche orizzontalmente. Ciò significa che ogni microservizio può attingere a maggiori risorse computazionali indipendentemente dagli altri al variare delle proprie specifiche esigenze. Il ridimensionamento orizzontale può essere meno costoso del ridimensionamento verticale e non ci sono limiti alla scalabilità di un’applicazione.
Flessibilità: i team possono aggiungere se necessario nuove funzionalità e nuove tecnologie a un’architettura basata su microservizi più facilmente. Con l’aumento dei requisiti di un’applicazione aumenta semplicemente il numero di microservizi utilizzati per implementare quell’applicazione.
Complessità: anche se i singoli componenti possono essere relativamente semplici, un’intera applicazione basata su microservizi può essere incredibilmente complessa. Il modo in cui i microservizi sono collegati tra loro aggiunge un livello di complessità che non esiste nelle applicazioni monolitiche.
Competenza specializzata: la creazione di un’architettura a microservizi richiede conoscenze specializzate che non tutti gli sviluppatori potrebbero avere. I team che creano microservizi senza la corretta formazione possono incontrare una miriade di problemi che possono comportare ritardi nella consegna o nel time-to-market e costi aggiuntivi per consulenze esterne.
Sicurezza distribuita: ogni componente presenterà le proprie vulnerabilità e bug di sicurezza. Sebbene ciò possa essere utile per prevenire gli attacchi, significa anche aumentare le potenziali vulnerabilità da monitorare e da correggere con maggiori risorse da allocare.
Costi aggiuntivi: l’utilizzo dei microservizi può ridurre alcuni costi (abbiamo visto quelli relativi alla scalabilità ad esempio), ma probabilmente richiederà anche maggiori risorse di sviluppo per gestire ogni singolo microservizio e le relative dipendenze.
Sebbene i microservizi non siano la stessa cosa dei container, i microservizi vengono spesso distribuiti all’interno di un sistema di container, quindi i due vengono regolarmente associati. I container sono sistemi operativi virtuali leggeri che contengono tutti gli elementi necessari per eseguire microservizi o altro software al loro interno. Possono essere eseguiti da qualsiasi luogo, in cloud, su server fisici e su diversi sistemi operativi.
I container possono essere facilmente spostati da una posizione all’altra, ampliati e consentono flussi di lavoro di sviluppo estremamente agili. I container consentono ai team di sviluppo di distribuire microservizi in un ambiente leggero e veloce e, poiché i container possono essere spostati facilmente, un’applicazione che li utilizza ha un’estrema flessibilità.
Coloro che desiderano sviluppare un’applicazione basata su microservizi dovrebbero anche esaminare i vantaggi e le sfide associati all’uso dei container. Attualmente gli strumenti maggiormente utilizzati in questo ambito sono Docker e Kubernetes.
Sia le architetture monolitiche che quelle a microservizi presentano vantaggi e svantaggi e si deve considerare attentamente quale utilizzare per la creazione di un’applicazione. Alcuni elementi chiave da considerare includono:
Complessità delle applicazioni: sebbene le applicazioni più complesse possano trarre vantaggio dai microservizi, i monoliti rimangono popolari per molte applicazioni semplici perché sono facili da creare e distribuire. Se stai sviluppando una semplice applicazione, come un forum web o un negozio di eCommerce di base, o stai creando un prototipo prima di intraprendere un progetto più ambizioso, un’architettura monolitica potrebbe fare al caso tuo.
Dimensioni e competenze del team: il numero di sviluppatori che lavorano sulla tua applicazione e le loro competenze dovrebbero essere uno dei principali fattori decisivi in merito al tipo di architettura da utilizzare. Se il tuo team non ha esperienza con microservizi e sistemi di contenitori, sarà molto complesso creare un’applicazione basata su microservizi. L’architettura monolitica può essere anche indicata per sviluppatori singoli o piccoli team. Se hai a disposizione un team esperto nelle distribuzioni di microservizi e soprattutto prevedi di aumentare i componenti del tuo team nel tempo, iniziare con i microservizi può far risparmiare tempo (e costi) in futuro.
Previsioni di crescita: la complessità e le difficoltà di gestione di un’applicazione monolitica sono direttamente proporzionali con la sua crescita e con l’aggiunta di funzionalità. Possono anche presentare problemi di scalabilità per soddisfare la domanda degli utenti. Se prevedi di aumentare in modo significativo il numero di utenti della tua applicazione, di aumentarne le funzionalità nel tempo e di far crescere il team che la gestisce, i microservizi possono assicurarti una scalabilità più semplice. Al contrario, le applicazioni sviluppate per usi più limitati avranno spesso successo utilizzando un’architettura monolitica.
Costi e tempi di sviluppo: chiaramente si devono considerare anche il costo di sviluppo dell’applicazione e i tempi per andare in produzione. Le applicazioni monolitiche possono avere costi maggiori con la loro crescita ma possono essere economicamente più convenienti nella fase iniziale di un progetto e più veloci da creare. Le risorse iniziali necessarie per sviluppare microservizi sono spesso elevate, ma possono comportare risparmi sui costi quando un’applicazione sarà ridimensionata in futuro.
Le aziende che creano una nuova applicazione devono affrontare numerose sfide e prendere numerose decisioni. Il tipo di metodologia architetturale con la quale progettare ed implementare l’applicazione avrà effetti a lungo termine e potrebbe decretare il successo o il fallimento del progetto.