Architettura monolitica e microservizi a confronto

Negli ultimi anni, quando siparladi architettura si sente spesso parlaredi microservizi. Si potrebbe quasi avere l'impressione che i microservizi siano il nuovo standard da utilizzare sempre e comunque. Tuttavia non sono mancate critiche crescenti nei confronti di questa architettura: spesso risulta troppo ingegnerizzata, complessa e, in generale, lo sviluppo e il funzionamento dei microservizi richiede troppo tempo. La principale alternativa è l'architettura monolitica, in realtà da alcuni ritenuta ormai morta. Questo solleva la domanda: ha ancora senso lavorare con un monolite?
I microservizi offrono tutta una serie di vantaggi, ma questo vale anche per i monoliti. Si tratta semplicemente di vantaggi diversi che andiamo ad esplorare in questo articolo.

Architettura monolitica

L'architettura monolitica è la forma storica di sviluppo delle applicazioni, perché si tratta semplicemente di una singola applicazione. Il punto importante è che per monolite intendiamo l'architettura del sistema, composta da un solo blocco per l’intera l'applicazione sviluppata e e non il modo in cui vengono realizzate le funzionalità del software che è invece l'architettura del software.
Ciò significa che un monolite, dal punto di vista del sistema, può anche lavorare internamente con i componenti o livelli, l'unica cosa importante è che si tratti di un unico processo.

E poiché si tratta di un unico processo, dal punto di vista del sistema si tratta sempre di una decisione "all or nothing”. Quindi se decido di pubblicare un monolite, devo distribuire l'intero monolite o niente, non posso rilasciarne solo una parte. Il grande vantaggio è che lo sviluppo è molto più semplice, perché ho tutto ciò che mi serve per l'applicazione. Ciò significa che posso combinare, eseguire, testare e distribuire tutto insieme senza dover effettuare integrazioni. Ho così un'applicazione autonoma e questo è un bene, perché una volta che è in funzione e funziona in modo coerente, non devo più pensare alle integrazioni.
Inoltre avendo tutti i componenti in un’unica applicazione posso effettuare dei test o delle attività di debug in modo più semplice. Infine con questo tipo di architettura è più semplice gestire anche la sicurezza in quanto i punti di attacco possibili sono ridotti.

Microservizi

Con applicazioni più complesse spesso nasce il desiderio o la necessità di controllare tutto a un livello più granulare e di poter facilmente scalare la nostra applicazioni o parti di essa. In questo caso la domanda è: come faccio a sincronizzare i diversi nodi che vengono creati quando eseguo un'applicazione scalabile?
Questa sincronizzazione avviene spesso tramite un database comune e questo database diventa il singolo punto di guasto (SPOF), cioè se il database è fuori uso, tutto è fuori uso perché non ho un vero e proprio sistema distribuito e non ho indipendenza.
Quello che si vuole è una maggiore indipendenza, si vuole essere in grado di separare le applicazioni l'una dall'altra e questo non funziona con un monolite perché non è stato progettato per questo.

È qui che entra in gioco l'idea dei microservizi, che prevedono singoli servizi isolati che sono autarchici e che funzionano in modo autonomo e che sono solitamente già separati fisicamente. Ho quindi più applicazioni separate che dialogano tra loro, ognuna delle quali si fa carico di un set ben definito di funzionalità. La comunicazione tra i singoli nodi avviene interagendo tramite API, realizzate sulla base di REST, GraphQL o altri protocolli come RabbitMQ, e quindi si ottiene una certa separazione.

Quando si comunica tramite HTTP o qualsiasi altro protocollo di rete, si deve prevedere che un endpoint possa non essere accessibile. Ciò significa che si deve pensare a meccanismi di retrial o simili, e da qui nasce il passaggio all’utilizzo di code (message queues) è breve. Questo comporta un modo completamente diverso di pensare, sviluppare, distribuire e gestire il software. Non si tratta di una soluzione migliore o peggiore di per sé, ma semplicemente diversa perché è rivolta ad altri scenari o casi d'uso.

L'autonomia dei microservizi va ancora oltre. Questo vale non solo per le attività operative, ma anche per lo sviluppo. Finché le interfacce sono chiaramente definite, i singoli servizi che voglio interconnettere in seguito possono essere sviluppati indipendentemente l'uno dall'altro. Posso anche farlo in più team e parallelamente, il che porta a una velocità complessiva maggiore rispetto a quella che si avrebbe se tutti lavorassero allo stesso software contemporaneamente.
Infine, i singoli componenti possono essere realizzati utilizzando linguaggi di programmazione diversi. Questo facilita sia lo svilupposia i test, perché i singoli servizi sono più piccoli e più gestibili. Tutto ciò che è più piccolo è più facile da testare, documentare, aggiornare e così via.

Tutti questi aspetti farebbero pensare che i microservizi siano la scelta migliore. Tuttavia, come avevamo detto inizialmente, non tutto è adatto ai microservizi.

Conclusioni

Né i microservizi né l'architettura monolitica sono la soluzione perfetta. Entrambi possono essere una scelta ottimale o meno.
Per un determinato compito è necessario lo strumento giusto che possa risolverlo al meglio. Se si sceglie quello sbagliato, alla fine della giornata si hanno problemi ben più gravi dello strumento stesso, perché si è andati nella direzione sbagliata.
Va considerato inoltre che migrare un monolite ai microservizi o viceversa è relativamente complicato.

Qual è la tua esperienza al riguardo? Preferisci lavorare con un'architettura monolitica o con i microservizi?
Faccelo sapere lasciandoci un commento.