Architetture microservice: molto più della somma delle singole parti

Le possibilità per la creazione di un software sono diverse. Invece di realizzare un progetto nel suo intero, può avere senso dividere i compiti e allacciare tra di loro i vari piccoli pacchetti, anche chiamati microservices. Il termine non ha molto a che vedere con la costruzione di un programma per computer, tuttavia gioca un ruolo importante per quel che riguarda la pianificazione di una gestione di progetto che sia agile. Quali vantaggi ha l’architettura microservice, come funziona e dove si utilizza già questa tecnologia?

Non c’è una definizione abbastanza stringente da permettere di capire quando si può parlare di architettura microservice e quando no. Ad aumentare maggiormente la confusione vi è anche il fatto che con microservice non si intende unicamente la tecnologia software ma spesso anche uno specifico modo di lavorare degli sviluppatori. Ma come si realizzano al meglio i grandi progetti di programmazione? Generalmente i progetti che si basano sui microservice seguono sempre la filosofia unix di Ken Thompson: “Do one thing and do it well”. È dunque importante concentrarsi su un singolo compito alla volta e svolgerlo alla perfezione. Il motto non è inteso solo come consiglio per il lavoro di programmazione, ma descrive anche il funzionamento dei singoli microservice.

Per quanto riguarda lo sviluppo è necessario formare piccoli team che si occupano di un singolo servizio ciascuno, realizzato sotto forma di microservice. Per la gestione del progetto invece verte tutto sul focus dei team e sulla loro indipendenza. Invece di un’amministrazione centrale ogni team è responsabile 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 garantisce molti vantaggi e assicura una struttura modulare del software.

Un’architettura microservice è praticamente uno step successivo rispetto alla Service-Oriented Architecture (SOA): anche in questo modello di architettura giocano un ruolo i piccoli servizi. Tuttavia questi sono parte di un grande sistema e non indipendenti, prerogativa dell’architettura microservice. Esattamente come per quest’ultima, per la quale non c’è una definizione precisa, anche la SOA è un concetto un po’ vago. Infatti capita spesso che si venga a creare confusione tra questi due modelli.

Lo sviluppo tradizionale di un software si basa sul principio dell’architettura monolitica: si realizzano tutte le componenti in un’unica grande applicazione. Tutti i singoli servizi attingono e quindi dipendono da un grande database e vengono offerti attraverso l’interfaccia utente – si tratta di un’unica grande applicazione. L’approccio dei microservice si basa invece sui moduli: a ogni microservice è affidata la realizzazione di un singolo compito. Il risultato dei due approcci è tanto diverso quanto lo sono i processi di lavoro.

Mentre nell’architettura microservice un team si focalizza sullo sviluppo di un microservice, il gruppo di lavoro è organizzato in maniera completamente diversa nel caso di un monolito. I vari gruppi di lavoro si organizzano in base alla tecnologia con la quale si devono confrontare. Un team si concentra sulle banche dati, un altro programma i singoli servizi e un terzo si occupa dell’impostazione dell’interfaccia utente. Per la pubblicazione di update o per lavori di manutenzione e analisi varie sono responsabili altri team ancora. Tuttavia in un’architettura monolitica tutti i team dipendono l’uno dall’altro. Per quanto riguarda l’architettura microservice invece, le dipendenze vanno evitate il più possibile.

Un’architettura microservice permette la realizzazione di una grande applicazione sotto forma di piccoli moduli monofunzionali, ovvero i microservice. La fondamenta vengono sviluppate indipendentemente le une dalle altre e legano assieme l’intero progetto. Questo stile architettonico ha diversi vantaggi.

Nello sviluppo di un microservice i team di lavoro agiscono solitamente in maniera totalmente autonoma. Non c’è né una istanza autoritaria e superiore che stabilisce un modo di procedere, né i singoli gruppi che lavorano al progetto si devono costantemente coordinare tra loro. Al centro del team c’è un’unica finalità che è l’utente dei microservice. Il vantaggio di questo modus lavorandi è che il team di sviluppo può risolvere i problemi che si presentano nel miglior modo possibile per il microservice e non come viene imposto da qualcun altro, al punto tale che è possibile utilizzare lingue di programmazione che si differenziano tra loro, lo stesso vale per database e i loro sistemi di gestione.

Un ulteriore vantaggio dell’indipendenza è che l’intero sistema diventa in questo modo molto più solido. Se un microservice dovesse smettere di funzionare, non smette di funzionare l’intera applicazione, sarà il singolo aspetto a non funzionare più. Trattandosi di un processo trascurabile risulta molto più semplice ricercare il problema: invece di dover controllare il codice sorgente di un intero grande monolito, dev’essere analizzato solamente un programma circoscritto e dalle dimensioni relativamente piccole.

A tale proposito va nominata anche la continuous delivery: ovvero lo sviluppo continuo dei prodotti software. Con i microservice i produttori non sono costretti a fare update di grandi dimensioni, ma possono pubblicare direttamente le modifiche apportate a un microservice indipendentemente dagli altri processi, chiaramente dopo aver eseguito i test necessari. Anche apportare piccoli cambiamenti in un monolito di tipo deployment può risultare molto impegnativo. Modificare invece un microservice che adempie a una sola mansione è molto meno complicato e richiede un quantitativo minore di risorse.

La continuous delivery favorisce anche un processo lavorativo agile: il team che si occupa di questo microservice è assolutamente specializzato ed è in grado di effettuare delle modifiche senza grandi problemi. Inoltre si procede lavorando su una modifica alla volta del codice sorgente, ovvero una nuova versione corrisponde all’aggiunta di una nuova funzione o alla risoluzione di un bug. Questo aiuta anche per le modifiche future e ad assicurare quindi la stabilità dell’intero sistema in maniera duratura.

Al termine vengono aggruppate tutte le varie componenti. Dunque per quanto i vari microservice possano differire gli uni dagli altri, alla fine dei giochi devono comunque avere dei punti di collegamento comuni. Questi devono essere impostati nella maniera più facile possibile così che la connessione non appesantisca l’intero processo. Per questo motivo la maggior parte degli sviluppatori di microservice si affidano alle  REST APIs. Attraverso i metodi HTTP uniformi e snelli, come GET o POST, i singoli microservice possono comunicare facilmente gli uni con gli altri e scambiare così le informazioni necessarie.

Se un monolito (inteso come sistema chiuso che riunisce tutti i processi) deve essere scalato verso l’alto, si è costretti a specchiare l’intero sistema. Un’architettura microservice dà agli sviluppatori la possibilità di scalare con grande precisione, rafforzando solamente il servizio che ne ha bisogno. Questo permette di mantenere il prodotto finale molto più snello e risparmiare dunque risorse. Allo stesso modo non è così complicato integrare un nuovo servizio all’interno di un sistema.

I microservice sono totalmente isolati gli uni dagli altri ed eseguiti all’interno di un ambiente proprio. È solo tramite interfacce che le singole applicazioni comunicano le une con le altre. Per realizzare un simile isolamento ci sono diverse possibilità:

• Container: la metodologia più ricorrente di creazione di un’architettura microservice è quella dei container. Questa rappresenta una forma di virtualizzazione molto snella, che invece di creare delle macchine virtuali complete, utilizza il sistema operativo presente e sfrutta il suo kernel. I container vengono eseguiti separatamente gli uni dagli altri. Tutto quello di cui hanno bisogno per un corretto funzionamento è già presente all’interno del container.
   
• Macchine virtuali: è possibile generare una macchina virtuale per ogni microservice. Anche in questo caso i microservice agiscono autonomamente. Lo svantaggio rispetto a una tecnologia come Docker è tuttavia che ogni macchina virtuale necessita di un sistema operativo proprio e quindi di molte risorse.

In alternativa è possibile impostare una istanza server fisica separata per ogni microservice. Nella pratica questo equivale a uno spreco di molte risorse, motivo per il quale si fa solitamente affidamento alla virtualizzazione. Ma particolarmente importante è che ci sia un isolamento reale, indipendentemente da come lo si vuole realizzare. È sconsigliabile sia eseguire più microservice su uno stesso server, sia all’interno di uno stesso container. Questo potrebbe portare a conflitti tra le varie applicazioni.

Per evitare sovraccarichi di sistema, si utilizza Load Balancer, che serve a suddividere automaticamente il carico su diverse istanze, evitando così guasti e problemi.

Nel frattempo l’utilizzo delle architetture microservice ha trovato riscontro nei sistemi di grandi imprese, le quali in questo modo sono riuscite a evitare problemi e a ottimizzare l’esecuzione. Gli esempi di Netflix, Spotify e eBay mostrano perché colossi come questi con sistemi monolitici affermati hanno deciso di scomporre l’architettura e ricomporla con l’utilizzo di microservice. Anche altre aziende nel settore dell’IT come Google e Amazon operano in questo modo: utilizzavano 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 monolitico (era il tempo in cui Netflix non era ancora un servizio di online streaming ma vendeva DVD spedendoli 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 abbandonare il proprio sistema e a suddividerlo in microservice. Così facendo è divenuto possibile implementare molto più rapidamente i cambiamenti anche in corso d’opera e altrettanto velocemente rimediare ai possibili errori. Essendo il sistema di Netflix incredibilmente ampio è stato sviluppato un programma proprio per riuscire a organizzare i microservice tra di loro: Conductor.

Conductor tra le altre cose dà la possibilità di gestire i microservice in maniera centralizzata (metterli in pausa o riavviarli) o di scalarli. Al centro del programma vi è un servizio di nome Decider, in grado di pianificare automaticamente i processi e reagire quindi ai risultati nel flusso di lavoro. Ulteriori programmi sviluppati sempre da Netflix per lavorare efficacemente con i microservice, sono Mantis (Stream-processing), Dinomite (datastore) e Vizceral (traffic intuition).

Anche un altro servizio di streaming, Spotify, basa la proprio offerta sui microservice. La sfida quotidiana di Spotify è dettata dalla forte concorrenza. Nel mercato dell’audiostreaming i concorrenti sono infatti alcune delle più grandi aziende di IT a livello mondiale, tra le quali Amazon, Apple e Google. Nel frattempo lo sviluppatore deve essere in grado di soddisfare la crescente domanda e fare attenzione alle regolamentazioni del settore, come i diritti di licenza. Per riuscire a reagire velocemente alle mosse della concorrenza e batterli sul tempo con le proprie innovazioni, così che sia la concorrenza a dover reagire, i microservice sono la soluzione adatta per Spotify.

Ad esempio la funzione di ricerca che vi fornisce dei suggerimenti ogni qualvolta digitiate un nome, è già un microservice di per sé, con alle spalle un team apposito. Inoltre Spotify approfitta della solidità garantita da un’architettura microservice: se un microservice smette di funzionare, il prodotto rimane comunque usufruibile, salvo la funzione corrispondente. Spotify mette assieme un totale di 800 microservice. Il servizio di streaming si affida tra l’altro per grande parte ai microservice Java. Questo non vuol però dire che i microservice non possano essere scritti in altri linguaggi di programmazione, ma piuttosto riguarda i processi di lavoro: gli sviluppatori passano spesso da un team a un altro ed è quindi molto più semplice se la lingua di programmazione rimane sempre la stessa.

La piattaforma di vendita all’asta eBay era inizialmente 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 microservice, anche in questo caso sviluppati in Java. Anche con eBay i singoli servizi comunicano tra di loro tramite REST.

Il fatto che eBay e molte altre aziende abbiano deciso di intraprendere la via che le ha portate da un’architettura monolitica a una di microservizi dimostra la modernità dell’approccio. Mentre nei primi giorni di un progetto online con pochi utenti attivi basta decisamente un monolito per mettere in piedi un’offerta di facile gestione, con l’aumento dei requisiti diventa inevitabilmente un colosso che crea più problemi che altro.

Nonostante ci siano molti motivi per scegliere un’architettura microservice per il proprio sistema, non vuol dire che sia adatta per ogni azienda e per ogni progetto. Per programmi di minori dimensioni e con un numero ridotto di compiti, i microservizi possono corrispondere a uno sforzo superfluo. Non solo la realizzazione dei servizi, ma la manutenzione, lo sviluppo continuo e il monitoraggio sono tutti passaggi impegnativi. Anche la semplice verifica comparativa tra microservice e monolito per vedere quale funziona meglio va ben pianificata e, sebbene i microservice sono facili da analizzare e da misurare, un elevato numero di questi accresce enormemente l’impegno necessario.

Guardando i vantaggi di come si svolge il lavoro, si capisce che non è adatto a ogni progetto, soprattutto non da un giorno all’altro. Un punto a favore nel lavoro con i microservice è l’indipendenza 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 separazione perde di significato. Inoltre se si segue la legge di Conway, un team di piccole dimensioni all’interno del quale, per motivi pratici, non è possibile tracciare una linea divisoria e dove le cooperazioni cambiano in continuazione, otterrà certamente un altro risultato.

Anche nel caso in cui si tratti di un team di grandi dimensioni è necessario un cambiamento significativo: le posizioni che controllano centralmente lo sviluppo stanno diventando sempre più obsolete e i team di sviluppo si organizzano in maniera sempre più indipendente. Una ristrutturazione simile richiede un dispendio sia di tempo che di risorse economiche. Anche questa è una questione che va tenuta a mente nel caso si stia ponderando di cambiare sistema.

Alcuni sostenitori delle architetture di microservice consigliano perciò una strategia monolith first, ovvero iniziare da una struttura monolitica. Perciò può risultare sensato iniziare un progetto di programmazione partendo da un monolito e sfruttare i vantaggi offerti da questo approccio, soprattutto nelle fasi iniziali. Una volta che il progetto ha raggiunto una dimensione adatta, allora sarà il caso di passare a un’architettura microservice. Tra i due sistemi si trova l’architettura service-oriented (SOA), che rappresenta una buona opzione intermedia, che a sua volta prevede un approccio basato sui moduli corrispondenti ai singoli processi.