Ar­chi­tet­tu­re mi­cro­ser­vi­ce: molto più della somma delle singole parti

Le pos­si­bi­li­tà per la creazione di un software sono diverse. Invece di rea­liz­za­re un progetto nel suo intero, può avere senso dividere i compiti e al­lac­cia­re tra di loro i vari piccoli pacchetti, anche chiamati mi­cro­ser­vi­ces. Il termine non ha molto a che vedere con la co­stru­zio­ne di un programma per computer, tuttavia gioca un ruolo im­por­tan­te per quel che riguarda la pia­ni­fi­ca­zio­ne di una gestione di progetto che sia agile. Quali vantaggi ha l’ar­chi­tet­tu­ra mi­cro­ser­vi­ce, come funziona e dove si utilizza già questa tec­no­lo­gia?

Non c’è una de­fi­ni­zio­ne ab­ba­stan­za strin­gen­te da per­met­te­re di capire quando si può parlare di ar­chi­tet­tu­ra mi­cro­ser­vi­ce e quando no. Ad aumentare mag­gior­men­te la con­fu­sio­ne vi è anche il fatto che con mi­cro­ser­vi­ce non si intende uni­ca­men­te la tec­no­lo­gia software ma spesso anche uno specifico modo di lavorare degli svi­lup­pa­to­ri. Ma come si rea­liz­za­no al meglio i grandi progetti di pro­gram­ma­zio­ne? Ge­ne­ral­men­te i progetti che si basano sui mi­cro­ser­vi­ce seguono sempre la filosofia unix di Ken Thompson: “Do one thing and do it well”. È dunque im­por­tan­te con­cen­trar­si su un singolo compito alla volta e svolgerlo alla per­fe­zio­ne. Il motto non è inteso solo come consiglio per il lavoro di pro­gram­ma­zio­ne, ma descrive anche il fun­zio­na­men­to dei singoli mi­cro­ser­vi­ce.

Per quanto riguarda lo sviluppo è ne­ces­sa­rio formare piccoli team che si occupano di un singolo servizio ciascuno, rea­liz­za­to sotto forma di mi­cro­ser­vi­ce. Per la gestione del progetto invece verte tutto sul focus dei team e sulla loro in­di­pen­den­za. Invece di un’am­mi­ni­stra­zio­ne centrale ogni team è re­spon­sa­bi­le del proprio prodotto finale e quindi dell’intero ciclo di sviluppo: dall’inizio alla fine, compresa la verifica del processo del lavoro. Questo metodo di lavorare ga­ran­ti­sce molti vantaggi e assicura una struttura modulare del software.

Un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce è pra­ti­ca­men­te uno step suc­ces­si­vo rispetto alla Service-Oriented Ar­chi­tec­tu­re (SOA): anche in questo modello di ar­chi­tet­tu­ra giocano un ruolo i piccoli servizi. Tuttavia questi sono parte di un grande sistema e non in­di­pen­den­ti, pre­ro­ga­ti­va dell’ar­chi­tet­tu­ra mi­cro­ser­vi­ce. Esat­ta­men­te come per quest’ultima, per la quale non c’è una de­fi­ni­zio­ne precisa, anche la SOA è un concetto un po’ vago. Infatti capita spesso che si venga a creare con­fu­sio­ne tra questi due modelli.

Lo sviluppo tra­di­zio­na­le di un software si basa sul principio dell’ar­chi­tet­tu­ra mo­no­li­ti­ca: si rea­liz­za­no tutte le com­po­nen­ti in un’unica grande ap­pli­ca­zio­ne. Tutti i singoli servizi attingono e quindi dipendono da un grande database e vengono offerti at­tra­ver­so l’in­ter­fac­cia utente – si tratta di un’unica grande ap­pli­ca­zio­ne. L’approccio dei mi­cro­ser­vi­ce si basa invece sui moduli: a ogni mi­cro­ser­vi­ce è affidata la rea­liz­za­zio­ne di un singolo compito. Il risultato dei due approcci è tanto diverso quanto lo sono i processi di lavoro.

Mentre nell’ar­chi­tet­tu­ra mi­cro­ser­vi­ce un team si focalizza sullo sviluppo di un mi­cro­ser­vi­ce, il gruppo di lavoro è or­ga­niz­za­to in maniera com­ple­ta­men­te diversa nel caso di un monolito. I vari gruppi di lavoro si or­ga­niz­za­no in base alla tec­no­lo­gia con la quale si devono con­fron­ta­re. Un team si concentra sulle banche dati, un altro programma i singoli servizi e un terzo si occupa dell’im­po­sta­zio­ne dell’in­ter­fac­cia utente. Per la pub­bli­ca­zio­ne di update o per lavori di ma­nu­ten­zio­ne e analisi varie sono re­spon­sa­bi­li altri team ancora. Tuttavia in un’ar­chi­tet­tu­ra mo­no­li­ti­ca tutti i team dipendono l’uno dall’altro. Per quanto riguarda l’ar­chi­tet­tu­ra mi­cro­ser­vi­ce invece, le di­pen­den­ze vanno evitate il più possibile.

Un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce permette la rea­liz­za­zio­ne di una grande ap­pli­ca­zio­ne sotto forma di piccoli moduli mo­no­fun­zio­na­li, ovvero i mi­cro­ser­vi­ce. La fon­da­men­ta vengono svi­lup­pa­te in­di­pen­den­te­men­te le une dalle altre e legano assieme l’intero progetto. Questo stile ar­chi­tet­to­ni­co ha diversi vantaggi.

Nello sviluppo di un mi­cro­ser­vi­ce i team di lavoro agiscono so­li­ta­men­te in maniera to­tal­men­te autonoma. Non c’è né una istanza au­to­ri­ta­ria e superiore che sta­bi­li­sce un modo di procedere, né i singoli gruppi che lavorano al progetto si devono co­stan­te­men­te coor­di­na­re tra loro. Al centro del team c’è un’unica finalità che è l’utente dei mi­cro­ser­vi­ce. Il vantaggio di questo modus lavorandi è che il team di sviluppo può risolvere i problemi che si pre­sen­ta­no nel miglior modo possibile per il mi­cro­ser­vi­ce e non come viene imposto da qualcun altro, al punto tale che è possibile uti­liz­za­re lingue di pro­gram­ma­zio­ne che si dif­fe­ren­zia­no tra loro, lo stesso vale per database e i loro sistemi di gestione.

Un ulteriore vantaggio dell’in­di­pen­den­za è che l’intero sistema diventa in questo modo molto più solido. Se un mi­cro­ser­vi­ce dovesse smettere di fun­zio­na­re, non smette di fun­zio­na­re l’intera ap­pli­ca­zio­ne, sarà il singolo aspetto a non fun­zio­na­re più. Trat­tan­do­si di un processo tra­scu­ra­bi­le risulta molto più semplice ricercare il problema: invece di dover con­trol­la­re il codice sorgente di un intero grande monolito, dev’essere ana­liz­za­to solamente un programma cir­co­scrit­to e dalle di­men­sio­ni re­la­ti­va­men­te piccole.

A tale proposito va nominata anche la con­ti­nuous delivery: ovvero lo sviluppo continuo dei prodotti software. Con i mi­cro­ser­vi­ce i pro­dut­to­ri non sono costretti a fare update di grandi di­men­sio­ni, ma possono pub­bli­ca­re di­ret­ta­men­te le modifiche apportate a un mi­cro­ser­vi­ce in­di­pen­den­te­men­te dagli altri processi, chia­ra­men­te dopo aver eseguito i test necessari. Anche apportare piccoli cam­bia­men­ti in un monolito di tipo de­ploy­ment può risultare molto im­pe­gna­ti­vo. Mo­di­fi­ca­re invece un mi­cro­ser­vi­ce che adempie a una sola mansione è molto meno com­pli­ca­to e richiede un quan­ti­ta­ti­vo minore di risorse.

La con­ti­nuous delivery favorisce anche un processo la­vo­ra­ti­vo agile: il team che si occupa di questo mi­cro­ser­vi­ce è as­so­lu­ta­men­te spe­cia­liz­za­to ed è in grado di ef­fet­tua­re delle modifiche senza grandi problemi. Inoltre si procede lavorando su una modifica alla volta del codice sorgente, ovvero una nuova versione cor­ri­spon­de all’aggiunta di una nuova funzione o alla ri­so­lu­zio­ne di un bug. Questo aiuta anche per le modifiche future e ad as­si­cu­ra­re quindi la stabilità dell’intero sistema in maniera duratura.

Al termine vengono ag­grup­pa­te tutte le varie com­po­nen­ti. Dunque per quanto i vari mi­cro­ser­vi­ce possano differire gli uni dagli altri, alla fine dei giochi devono comunque avere dei punti di col­le­ga­men­to comuni. Questi devono essere impostati nella maniera più facile possibile così che la con­nes­sio­ne non ap­pe­san­ti­sca l’intero processo. Per questo motivo la maggior parte degli svi­lup­pa­to­ri di mi­cro­ser­vi­ce si affidano alle  REST APIs. At­tra­ver­so i metodi HTTP uniformi e snelli, come GET o POST, i singoli mi­cro­ser­vi­ce possono co­mu­ni­ca­re fa­cil­men­te gli uni con gli altri e scambiare così le in­for­ma­zio­ni ne­ces­sa­rie.

Se un monolito (inteso come sistema chiuso che riunisce tutti i processi) deve essere scalato verso l’alto, si è costretti a spec­chia­re l’intero sistema. Un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce dà agli svi­lup­pa­to­ri la pos­si­bi­li­tà di scalare con grande pre­ci­sio­ne, raf­for­zan­do solamente il servizio che ne ha bisogno. Questo permette di mantenere il prodotto finale molto più snello e ri­spar­mia­re dunque risorse. Allo stesso modo non è così com­pli­ca­to integrare un nuovo servizio all’interno di un sistema.

I mi­cro­ser­vi­ce sono to­tal­men­te isolati gli uni dagli altri ed eseguiti all’interno di un ambiente proprio. È solo tramite in­ter­fac­ce che le singole ap­pli­ca­zio­ni co­mu­ni­ca­no le une con le altre. Per rea­liz­za­re un simile iso­la­men­to ci sono diverse pos­si­bi­li­tà:

• Container: la me­to­do­lo­gia più ri­cor­ren­te di creazione di un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce è quella dei container. Questa rap­pre­sen­ta una forma di vir­tua­liz­za­zio­ne molto snella, che invece di creare delle macchine virtuali complete, utilizza il sistema operativo presente e sfrutta il suo kernel. I container vengono eseguiti se­pa­ra­ta­men­te gli uni dagli altri. Tutto quello di cui hanno bisogno per un corretto fun­zio­na­men­to è già presente all’interno del container.
   
• Macchine virtuali: è possibile generare una macchina virtuale per ogni mi­cro­ser­vi­ce. Anche in questo caso i mi­cro­ser­vi­ce agiscono au­to­no­ma­men­te. Lo svan­tag­gio rispetto a una tec­no­lo­gia come Docker è tuttavia che ogni macchina virtuale necessita di un sistema operativo proprio e quindi di molte risorse.

In al­ter­na­ti­va è possibile impostare una istanza server fisica separata per ogni mi­cro­ser­vi­ce. Nella pratica questo equivale a uno spreco di molte risorse, motivo per il quale si fa so­li­ta­men­te af­fi­da­men­to alla vir­tua­liz­za­zio­ne. Ma par­ti­co­lar­men­te im­por­tan­te è che ci sia un iso­la­men­to reale, in­di­pen­den­te­men­te da come lo si vuole rea­liz­za­re. È scon­si­glia­bi­le sia eseguire più mi­cro­ser­vi­ce su uno stesso server, sia all’interno di uno stesso container. Questo potrebbe portare a conflitti tra le varie ap­pli­ca­zio­ni.

Per evitare so­vrac­ca­ri­chi di sistema, si utilizza Load Balancer, che serve a sud­di­vi­de­re au­to­ma­ti­ca­men­te il carico su diverse istanze, evitando così guasti e problemi.

Nel frattempo l’utilizzo delle ar­chi­tet­tu­re mi­cro­ser­vi­ce ha trovato riscontro nei sistemi di grandi imprese, le quali in questo modo sono riuscite a evitare problemi e a ot­ti­miz­za­re l’ese­cu­zio­ne. Gli esempi di Netflix, Spotify e eBay mostrano perché colossi come questi con sistemi mo­no­li­ti­ci affermati hanno deciso di scomporre l’ar­chi­tet­tu­ra e ri­com­por­la con l’utilizzo di mi­cro­ser­vi­ce. Anche altre aziende nel settore dell’IT come Google e Amazon operano in questo modo: uti­liz­za­va­no i sistemi modulari quando questi ancora non avevano neanche un nome.

Come è il caso nella maggior parte delle aziende, in passato anche il servizio di Netflix era basato su un sistema mo­no­li­ti­co (era il tempo in cui Netflix non era ancora un servizio di online streaming ma vendeva DVD spe­den­do­li per posta). Nel 2008 ci fu un errore nel database che mandò in blocco l’intero servizio per ben quattro giorni. Per questo motivo l’azienda decise di ad ab­ban­do­na­re il proprio sistema e a sud­di­vi­der­lo in mi­cro­ser­vi­ce. Così facendo è divenuto possibile im­ple­men­ta­re molto più ra­pi­da­men­te i cam­bia­men­ti anche in corso d’opera e al­tret­tan­to ve­lo­ce­men­te rimediare ai possibili errori. Essendo il sistema di Netflix in­cre­di­bil­men­te ampio è stato svi­lup­pa­to un programma proprio per riuscire a or­ga­niz­za­re i mi­cro­ser­vi­ce tra di loro: Conductor.

Conductor tra le altre cose dà la pos­si­bi­li­tà di gestire i mi­cro­ser­vi­ce in maniera cen­tra­liz­za­ta (metterli in pausa o riav­viar­li) o di scalarli. Al centro del programma vi è un servizio di nome Decider, in grado di pia­ni­fi­ca­re au­to­ma­ti­ca­men­te i processi e reagire quindi ai risultati nel flusso di lavoro. Ulteriori programmi svi­lup­pa­ti sempre da Netflix per lavorare ef­fi­ca­ce­men­te con i mi­cro­ser­vi­ce, sono Mantis (Stream-pro­ces­sing), Dinomite (datastore) e Vizceral (traffic intuition).

Anche un altro servizio di streaming, Spotify, basa la proprio offerta sui mi­cro­ser­vi­ce. La sfida quo­ti­dia­na di Spotify è dettata dalla forte con­cor­ren­za. Nel mercato dell’au­dio­strea­ming i con­cor­ren­ti sono infatti alcune delle più grandi aziende di IT a livello mondiale, tra le quali Amazon, Apple e Google. Nel frattempo lo svi­lup­pa­to­re deve essere in grado di sod­di­sfa­re la crescente domanda e fare at­ten­zio­ne alle re­go­la­men­ta­zio­ni del settore, come i diritti di licenza. Per riuscire a reagire ve­lo­ce­men­te alle mosse della con­cor­ren­za e batterli sul tempo con le proprie in­no­va­zio­ni, così che sia la con­cor­ren­za a dover reagire, i mi­cro­ser­vi­ce sono la soluzione adatta per Spotify.

Ad esempio la funzione di ricerca che vi fornisce dei sug­ge­ri­men­ti ogni qualvolta digitiate un nome, è già un mi­cro­ser­vi­ce di per sé, con alle spalle un team apposito. Inoltre Spotify ap­pro­fit­ta della solidità garantita da un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce: se un mi­cro­ser­vi­ce smette di fun­zio­na­re, il prodotto rimane comunque usu­frui­bi­le, salvo la funzione cor­ri­spon­den­te. Spotify mette assieme un totale di 800 mi­cro­ser­vi­ce. Il servizio di streaming si affida tra l’altro per grande parte ai mi­cro­ser­vi­ce Java. Questo non vuol però dire che i mi­cro­ser­vi­ce non possano essere scritti in altri linguaggi di pro­gram­ma­zio­ne, ma piuttosto riguarda i processi di lavoro: gli svi­lup­pa­to­ri passano spesso da un team a un altro ed è quindi molto più semplice se la lingua di pro­gram­ma­zio­ne rimane sempre la stessa.

La piat­ta­for­ma di vendita all’asta eBay era ini­zial­men­te un monolito, come la maggior parte dei sistemi. Col passare del tempo eBay è arrivato includere 3,4 milioni di righe di codice in un singolo file, fino a decidere di scomporlo a favore dei mi­cro­ser­vi­ce, anche in questo caso svi­lup­pa­ti in Java. Anche con eBay i singoli servizi co­mu­ni­ca­no tra di loro tramite REST.

Il fatto che eBay e molte altre aziende abbiano deciso di in­tra­pren­de­re la via che le ha portate da un’ar­chi­tet­tu­ra mo­no­li­ti­ca a una di mi­cro­ser­vi­zi dimostra la modernità dell’approccio. Mentre nei primi giorni di un progetto online con pochi utenti attivi basta de­ci­sa­men­te un monolito per mettere in piedi un’offerta di facile gestione, con l’aumento dei requisiti diventa ine­vi­ta­bil­men­te un colosso che crea più problemi che altro.

No­no­stan­te ci siano molti motivi per scegliere un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce per il proprio sistema, non vuol dire che sia adatta per ogni azienda e per ogni progetto. Per programmi di minori di­men­sio­ni e con un numero ridotto di compiti, i mi­cro­ser­vi­zi possono cor­ri­spon­de­re a uno sforzo superfluo. Non solo la rea­liz­za­zio­ne dei servizi, ma la ma­nu­ten­zio­ne, lo sviluppo continuo e il mo­ni­to­rag­gio sono tutti passaggi im­pe­gna­ti­vi. Anche la semplice verifica com­pa­ra­ti­va tra mi­cro­ser­vi­ce e monolito per vedere quale funziona meglio va ben pia­ni­fi­ca­ta e, sebbene i mi­cro­ser­vi­ce sono facili da ana­liz­za­re e da misurare, un elevato numero di questi accresce enor­me­men­te l’impegno ne­ces­sa­rio.

Guardando i vantaggi di come si svolge il lavoro, si capisce che non è adatto a ogni progetto, so­prat­tut­to non da un giorno all’altro. Un punto a favore nel lavoro con i mi­cro­ser­vi­ce è l’in­di­pen­den­za dei singoli team, evitando per esempio che un team debba attendere i risultati di un altro. Ma se l’intero team di sviluppo si compone di poche persone, allora questa se­pa­ra­zio­ne perde di si­gni­fi­ca­to. Inoltre se si segue la legge di Conway, un team di piccole di­men­sio­ni all’interno del quale, per motivi pratici, non è possibile tracciare una linea divisoria e dove le coo­pe­ra­zio­ni cambiano in con­ti­nua­zio­ne, otterrà cer­ta­men­te un altro risultato.

Anche nel caso in cui si tratti di un team di grandi di­men­sio­ni è ne­ces­sa­rio un cam­bia­men­to si­gni­fi­ca­ti­vo: le posizioni che con­trol­la­no cen­tral­men­te lo sviluppo stanno di­ven­tan­do sempre più obsolete e i team di sviluppo si or­ga­niz­za­no in maniera sempre più in­di­pen­den­te. Una ri­strut­tu­ra­zio­ne simile richiede un dispendio sia di tempo che di risorse eco­no­mi­che. Anche questa è una questione che va tenuta a mente nel caso si stia pon­de­ran­do di cambiare sistema.

Alcuni so­ste­ni­to­ri delle ar­chi­tet­tu­re di mi­cro­ser­vi­ce con­si­glia­no perciò una strategia monolith first, ovvero iniziare da una struttura mo­no­li­ti­ca. Perciò può risultare sensato iniziare un progetto di pro­gram­ma­zio­ne partendo da un monolito e sfruttare i vantaggi offerti da questo approccio, so­prat­tut­to nelle fasi iniziali. Una volta che il progetto ha raggiunto una di­men­sio­ne adatta, allora sarà il caso di passare a un’ar­chi­tet­tu­ra mi­cro­ser­vi­ce. Tra i due sistemi si trova l’ar­chi­tet­tu­ra service-oriented (SOA), che rap­pre­sen­ta una buona opzione in­ter­me­dia, che a sua volta prevede un approccio basato sui moduli cor­ri­spon­den­ti ai singoli processi.