In questo articolo affronteremo i seguenti temi:
Sin dagli albori dell’informatizzazione, la delivery e deployment delle applicazioni e dei servizi all’interno di organizzazioni enterprise ha subito non pochi cambiamenti, in ogni livello dell’infrastruttura.
Uno dei cambiamenti e, a detta di molti, “rivoluzione” nei sopracitati aspetti è il passaggio ad applicazioni con architetture a microservizi piuttosto che architetture monolitiche.
Microservizio o monolite: differenze fra i due approcci
Nel caso di applicazioni monolitiche, tutte le parti e le funzionalità dell’intera applicazione sono implementate all’interno dello stesso eseguibile. Oppure, nel caso di linguaggi non compilati, tutte le funzionalità fanno parte di un unico “progetto” o componente (il monolite).
Nel caso di un microservizio invece, esso è un componente software parte di un sistema più grande. L’aspetto interessante, tuttavia, è che il microservizio potrebbe non essere consapevole dell’esistenza del “sistema più grande”. Il microservizio svolge il suo micro-ruolo, ignaro del resto del sistema o dell’architettura. Pertanto, sarebbe possibile, qualora lo si voglia e abbia senso per il dominio in questione, condividere la stessa istanza di un microservizio con molteplici sistemi.
Un’architettura a microservizi è, quindi, un’architettura in cui ciascun componente riflette la definizione sopra riportata. Importante, affinché un’architettura di questo tipo funzioni, è identificare ciascun ruolo all’interno del proprio sistema; e implementare ciascuno di essi utilizzando un microservizio. Il risultato sarà un insieme di componenti che, cooperando, rispecchieranno caratteristiche e requisiti del sistema finale.
Perché dovrei considerare un’architettura a microservizi?
I vantaggi dell’adottare un’architettura a microservizi sono molteplici. Quello più rilevante, nonché quello che ha un impatto maggiore sulla produttività generale del team di sviluppo, è il maggior livello di manutenibilità fra i vari componenti: ciascun microservizio sarà in grado di essere testato, deployato e sostituito in maniera indipendente rispetto al resto. È molto comune, infatti, che ciascun microservizio abbia il proprio numero di versione, indipendente dalle versioni per i restanti microservizi.
La netta separazione fra i differenti microservizi permetterebbe anche a team differenti di lavorare sui differenti componenti in maniera indipendente. Inoltre, essendo ciascun componente molto piccolo in scope, permette di avere team molto più piccoli che sono quindi gestiti in maniera più semplice. Si pensi, per esempio, alle difficoltà di comunicazione che un unico grande team potrebbe avere nel caso in cui alcuni (o addirittura tutti) i membri del team si trovino in fusi orari differenti.
Analizzando, invece, quelli che sono gli aspetti un po’ più tecnici di un’architettura a microservizi, la separazione e il disaccoppiamento derivante da un’architettura a microservizi rende possibile non utilizzare lo stesso “tech stack” per i diversi componenti. Si potrà, se desiderato, utilizzare differenti linguaggi di programmazione, framework, dipendenze, eccetera, in base a ciò che meglio implementa il ruolo svolto da uno specifico microservizio piuttosto che un altro. Non solo, per gli stessi motivi sarà possibile sviluppare microservizi “in-house” o usufruire di soluzioni già pronte (“off the shelf”).
La comunicazione fra i diversi microservizi avviene per protocolli come HTTP/REST oppure il più moderno gRPC. La comunicazione può essere addirittura asincrona utilizzando protocolli come AMQP, che è un sistema di scambio di messaggi basato su code (in inglese “queues”); in contrasto con l’operatività sincrona basata su Request/Response che offrono HTTP/REST.
Architettura a microservizi: pro e contro
Sebbene i microservizi rappresentino un indubbio passo avanti in termini di agilità ed efficienza di sviluppo delle applicazioni enterprise, non sono privi di sfide da superare. Il fatto che ciascun componente sia separato ed indipendente dal resto introduce problematiche del tutto assenti con un’architettura monolitica. In quest’ultima, infatti, richiamare un altro componente risultava piuttosto semplice. Se è tutto in un singolo eseguibile vuol dire che è tutto anche in un singolo processo. Richiamare un altro componente si traduce, nella pratica, nel chiamare una funzione. Con un’architettura a microservizi, invece, se microservizio A necessita di richiamare una funzionalità di microservizio B…dov’è B? Microservizio B potrebbe trovarsi in un altro processo, su un altro host o addirittura in un altro datacenter. Improvvisamente anche solo come raggiungere B è diventato un punto di discussione.
L’aumentata agilità ed efficienza operazionale è controbilanciata dalla maggiore complessità infrastrutturale richiesta per poter implementare un’architettura di questo tipo. Purtroppo, non c’è una risposta assoluta alla domanda se questo è un compromesso che vale la pena adottare. La risposta è da considerarsi variabile sulla base di numerosi fattori; primo fra tutti è la complessità del sistema stesso. Più grande e complesso il sistema, più gioverà degli aspetti forti di un’architettura a microservizi. Non da sottovalutare, inoltre, è la preparazione del team di sviluppo che si occupa della manutenzione del sistema. I problemi appena discussi diventerebbero solo più gravi e numerosi nel caso di una cattiva implementazione!
Non farti cogliere impreparato e approfondisci le le tue conoscenze tramite corsi di Kubernetes, The Linux Foundation, Mirantis e Docker!
Condividi l’articolo!!
Scopri i nostri corsi!
Gianluca Recchia
DCA | CKA | AWS SAP | AAI Instructor
Trainer e consulente con forte background in programmazione e scripting. Ho formato numerosi studenti su argomenti riguardo il mondo Devops, dell’automation, delle cloud infrastructure e della system administration. Advocate per tecnologie open-source e open-standards, spendo la mia vita in una continua quest volta al rendere il mio workflow più efficiente e produttivo possibile.
