I microservizi: architetture versatili ed efficaci.

Quando parliamo di microservizi dobbiamo essere consapevoli che si tratta di un argomento vasto e complesso che si articola in un’ampia gamma di utilizzi e declinazioni. Cercando però di fare un po’ di chiarezza, in questo articolo andremo a vedere quali sono le implicazioni positive e quali possono essere le criticità riscontrabili nell’uso dei microservizi durante la realizzazione di applicazioni.

Microservizi: cosa sono?

Come prima cosa, è necessario definire bene cosa si intende quando si parla di microservizi: si tratta fondamentalmente di un approccio architetturale allo sviluppo delle applicazioni. Tale stile va a contrapporsi al tradizionale metodo monolitico, che prevede un lavoro unico e specifico su di una applicazione e sul suo intero sistema. I microservizi invece agiscono in maniera separata e autonoma, andando a integrare e ampliare le varie funzionalità necessarie. Sinteticamente, potremmo dire che ciascun microservizio rappresenta una applicazione distinta che svolge un’operazione ben precisa all’interno di un sistema più articolato. Prendendo come esempio un sito di vendita online, la ricerca nella barra specifica, l’inserimento di un prodotto nel carrello, i suggerimenti di prodotti simili a quelli cercati sono tutte azioni mirate che possono essere attuate attraverso lo sviluppo di microservizi.

Come funziona però nel dettaglio una architettura basata sui microservizi?

Ogni parte di una applicazione realizzata attraverso i microservizi risulterà autonoma e il suo funzionamento non sarà dipendente da quello delle altre parti. Questo rende ovviamente più semplice la fase di integrazione di ognuno di questi al sistema principale, ma richiede al contempo un ripensamento strutturale del framework che regola la loro comunicazione e lo scambio di dati e informazioni. Il modo più efficace per poter ottenere questo risultato sarà quello di integrare gli elementi fondamentali di una architettura SOA, in particolare se vogliamo facilitare l’esecuzione del deployment dei microservizi.

I microservizi: una storia fatta di evoluzioni

Sfruttando le basi dell’architettura SOA (acronimo che sta a indicare una Service-Oriented Architecture, un’architettura orientata al servizio) possiamo quindi disegnare le applicazioni attraverso i microservizi. Non è una novità, infatti, quella di concepire lo sviluppo come un sistema articolato composto da più parti che dialogano tra loro. L’architettura SOA è appunto uno stile di progettazione dei software ampiamente consolidato, che già a metà degli anni ’90 si andò a contrapporre alla struttura monolitica, aprendo poi di fatto la strada ai microservizi. L’architettura monolitica, benché considerata la più stabile, implica una serie di interventi massivi a seguito di ogni singolo cambiamento a un’app già esistente: il lavoro viene inesorabilmente rallentato, senza considerare i costi che questo può avere in fatto di tempistiche e risorse. Un codice sorgente compilato in una sola unità di deployment, come un monolite unico appunto, richiede che in caso di aggiornamento a una parte dell’applicazione si possa arrivare alla disconnessione dell’intero sistema. Se questo approccio è ancora sostenibile quando si parla di software di dimensioni ridotte, la scala delle lavorazioni attuali obbliga le aziende a orientarsi su sistemi molto più elastici e su cui i tempi di intervento risultano più ridotti. E qui entrano in gioco appunto i microservizi.

I vantaggi della nuova architettura

Quali sono i vantaggi evidenti dell’utilizzo di un’architettura basata sui microservizi?

• Rapida immissione nel mercato: i cicli di sviluppo per queste architetture sono sicuramente più brevi, permettendone un deployment anticipato rispetto alle applicazioni diversamente strutturate e garantendo aggiornamenti più snelli;
• Alto grado di scalabilità: auspicando che la domanda per determinati servizi sia in costante crescita, i microservizi potranno usufruire di una distribuzione più mirata e capillare;
• Massima indipendenza: a fronte di un lavoro di sviluppo realizzato correttamente, ogni microservizio risulta autonomo e non va a intaccare le altre parti della struttura. In questo modo l’intera app non rischia di rimanere bloccata in caso di errore di un componente specifico, come per esempio avviene nelle monolithic;
• Deployment semplificati: le dimensioni ridotte e la loro modularità rendono i microservizi meno soggetti a problematiche derivanti i deployment. Questo richiede però un maggiore coordinamento tra le varie parti, facilmente raggiungibile con un workflow ben strutturato a priori;
• Immediata accessibilità: ogni app è suddivisa in parti più piccole, meno complesse da aggiornare e da implementare, permettendo una sensibile accelerazione dei cicli di sviluppo.
• Struttura Open: grazie alle API non dipendenti dal linguaggio utilizzato, lo sviluppo della app può essere portato avanti utilizzando qualunque tecnologia e sistema vengano considerati migliori per ottenere il servizio richiesto.
• Eterogeneità: linguaggi e tecnologie diverse permettono di sfruttare gli stack maggiormente performanti per aumentare funzioni particolari. Si potrà così, per esempio, introdurre una tipologia specifica di base dati in grado di mappare naturalmente un determinato dato, oppure avviare l’esecuzione di un calcolo in maniera efficiente e puntuale.
• Sostituzione facilitata: l’autonomia di ciascun microservizio permette al team di lavoro di poter intervenire con semplicità in caso ci sia la necessità di andare a sostituire in blocco una funzione.

Una serie di semplificazioni e di vantaggi che rendono la scelta di un’architettura basata sui microservizi particolarmente appetibile per ogni sviluppatore.

Le criticità dello sviluppo tramite microservizi

Non ci sono quindi controindicazioni nell’uso di questo sistema di sviluppo?

Sicuramente c’è la necessità di valutare bene quelle che sono le risorse a disposizione del team di lavoro prima di iniziare a utilizzare la struttura a microservizi: forzare questo approccio in un contesto che presenta difficoltà comunicative e di collaborazione tra i nuclei di sviluppo, potrebbe essere particolarmente rischioso. Non si tratta di una problematica direttamente inerente all’ambito dello sviluppo, ma è basilare per poter procedere in questa direzione.

Questo ovviamente deriva dal fatto che un’architettura costruita sui microservizi risulta particolarmente complessa per essere gestita in maniera produttiva ed efficiente.

Cercando di focalizzare meglio questo aspetto, c’è la necessità di comprendere che lo sviluppo di un microservizio richiede una visione a lungo termine, soprattutto da un punto di vista di ritorno dell’investimento. Trattandosi infatti di un territorio tendenzialmente inesplorato, ogni volta che si inizia un progetto inerente questa tipologia di applicativi, si deve tenere conto del fatto che non è possibile stabilire con certezza le tempistiche per portare a temine il lavoro. Se, infatti, risultano evidenti i vantaggi dei microservizi, dall’altro lato è indispensabile non dimenticare che soprattutto per i piccoli team di sviluppo, la quantità di tempo spesa verrà ripagata soltanto grazie a un’economia di scala ben strutturata. Più una feature verrà utilizzata, più facilmente raggiungerà i potenziali clienti, più velocemente sarà possibile rientrare dell’investimento. Non si tratta di un aspetto secondario, ma di un vero e proprio fattore determinante che non può essere preso sotto gamba nel momento in cui ci si approccia allo sviluppo di un’architettura basata sui microservizi.

Quali sono le criticità derivanti dall’utilizzo dei microservizi?

• L’identificazione delle dipendenze fra i vari servizi coinvolti;
• La maggiore difficoltà nell’attuazione dei test di integrazione e dei test end-to-end;
• La retrocompatibilità con l’intero sistema nel momento in cui viene rilasciata una nuova versione;
• La configurazione iniziale del deployment, in particolare se svolto manualmente in casi di particolare complessità del sistema di microservizi;
• La necessità di registri centralizzati per tenere in collegamento i vari componenti;
• Un monitoraggio costante, in grado di dare una visione centralizzata del sistema ai team coinvolti;
• In caso di architetture particolarmente complesse, è impossibile prevedere un’attività di debugging da remoto.

Le problematiche elencate sottolineano come sia necessario prevedere certe accortezze e apportare determinati accorgimenti in fase di lavorazione e di sviluppo, ma non devono distogliere l’attenzione dai vantaggi e dalle implicazioni in potenza che le architetture basate sui microservizi possono offrire oggi.