I microservizi sembrano il sacro Graal dello sviluppo per i cloud e vengono propagandati come una evoluzione inevitabile di qualsiasi ambiente applicativo.
Slogan simili ad altri che abbiamo già sentito per molti altri tipi di sviluppo “destrutturato”, però in questo caso l’esperienza maturata dalle grandi imprese che hanno fatto il salto ai microservizi per sostenere il loro sviluppo dimostra che il valore effettivamente c’è e che non stiamo parlando dell’ennesima moda.
In estrema sintesi, nell’approccio a microservizi le funzioni di una applicazione monolitica sono segmentate in tante piccole applicazioni specifiche (appunto i microservizi) che sono collegate fra loro da API RESTful.
Ogni microservizio è distinto e isolato, nel senso che ha un suo database e non condivide dati con gli altri. Questo tra l’altro permette di sviluppare microservizi dotati della base dati più opportuna a ciò che devono fare, senza il peso di una struttura comune.
Ammettiamo di voler realizzare il portale ecommerce di un negozio. Nell’approccio tradizionale svilupperemmo una mega-applicazione partendo dalla struttura della base dati, collegata quasi certamente a un sisteam relazionale che conterrà tutte le informazioni necessarie (prodotti, utenti e via dicendo) separate nelle varie tabelle.
A partire dalla struttura delle informazioni costruiremmo la logica applicativa che le gestisce e, infine, il codice che serve all’interfaccia e a tutta l’user experience.
L’approccio a microservizi è esattamente opposto: in un certo senso si parte dalla fine. Pensiamo al prodotto completo (il portale di ecommerce) e scomponiamolo nelle sue funzioni logiche. Serve certamente un servizio che mostri la scheda di un prodotto, come uno per completare i pagamenti, uno per gestire la registrazione di un nuovo utente, uno per accettare i commenti a un prodotto… Le funzioni possono essere decine e anche di più.
La logica della scomposizione
I vantaggi di questo “smantellamento” delle applicazioni monolitiche – o delle applicazioni che si sviluppano da zero con questo modello – sono principalmente collegati alla elasticità e scalabilità del sistema e all’organizzazione dello sviluppo.
Tutti i microservizi possono – e dovrebbero, infatti – essere sviluppati in maniera indipendente perché sono concepiti come entità autonome e isolate.
Quindi nello sviluppo di uno di essi non c’è bisogno di preoccuparsi di cosa c’è nel resto dell’applicazione perché non influenza le scelte progettuali del singolo servizio. Se per la registrazione degli utenti basta un semplice database NoSQL, ad esempio, lo si adotta anche se la gestione degli articoli in vendite richiede magari una piattaforma diversa.
Allo stesso modo, il servizio che accetta un commento a un prodotto non si deve preoccupare dell’identificazione di chi lo sottopone, che sarà gestita da un altro. Una conseguenza di questo è che apportare modifiche a una applicazione scomposta in microservizi è semplice e veloce. Si interviene solo sui microservizi coinvolti, senza dover mettere mano a migliaia di righe di codice alla ricerca dei punti in cui fare modifiche.
Un altro elemento importante abilitato dalla logica dei microservizi è che, essendo questi isolati e autonomi, vi si possono associare le risorse più indicate, invece di pensarle per tutta un’applicazione nel suo complesso.
Questo vale in particolare negli ambienti virtualizzati e PaaS, luogo ideale dove far “vivere” i microservizi (ma non necessariamente l’unico, l’approccio è generico).
Il concetto di microservizio si lega bene a quello di container: entrambi sono componenti “atomici” e stateless. Per questo appare solo logico incapsulare un microservizio in un container e gestire un ambiente virtualizzato in modo che il microservizio scali orizzontalmente attivando tante istanze quante ne servono in un certo momento, dotandole delle risorse più opportune.
Proseguendo nel nostro esempio, è prevedibile che il microservizio collegato alla visualizzazione di un prodotto sia usato molto più intensamente di quello che gestisce la registrazione di un utente. Un ambiente PaaS pubblico o privato permette di adeguarsi a queste differenze.
L’altro lato della medaglia
Sarebbe troppo bello se tutti questi vantaggi non implicassero qualche complessità. E infatti lo sviluppo a microservizi ha i suoi punti critici. Anzi, essenzialmente uno: come l’applicazione monolitica viene disgregata in più servizi, anche il flusso dell’applicazione si scompone in vari passi che restano interdipendenti ma sono delegati a moduli autonomi e scollegati. Controllarlo diventa molto più difficile.
Quando si verifica un problema nel flusso delle operazioni distribuite tra più microservizi – magari decine – diventa complesso capire chi ha causato cosa. Non c’è più la possibilità di scorrere il codice monolitico per eseguire magari un debug e, prima o poi, arrivare al punto critico che non ha funzionato a dovere.
Strumenti e servizi dedicati al debug vero e proprio dei microservizi ce ne sono pochi. Si stanno sviluppando, è però probabile che chi passa ora ai microservizi dovrà assemblare da solo una propria cassetta degli attrezzi per affrontare questo aspetto. Che non è il solo, perché anche se i microservizi sono stati sviluppati a regola d’arte devono anche funzionare correttamente insieme. Questo rimanda al tema dell’orchestration, che è più noto e offre piattaforme già ben definite (Kubernetes su tutte).
