Microservices Architecture: da Netflix alle API

Fino a non molto tempo fa, per eseguire una piccola modifica ad una applicazione web era necessario mettere mano ad un blocco monolitico che conteneva tutto il codice sorgente dell’app in questione, spesso coinvolgendo nel processo vari team aziendali, dal controllo qualità al sysadmin fino al marketing. 

Tale approccio - non a caso definito ormai tradizionalmente “monolitico” - è ancora oggi il più diffuso nel campo dello sviluppo di applicazioni web, ma tutto lascerebbe intendere che abbia i giorni contati. 

A partire da realtà come Netflix, tra le prime a percorrere questa strada, infatti, è stato avviato un processo di rivoluzione che coinvolge l’intero settore IT, con la decostruzione degli impianti monolitici dei servizi web in favore dei cosiddetti microservizi.

Ma cosa sono i microservizi? E perché le più grandi aziende IT del mondo hanno abbandonato le strutture native dei propri servizi per passare all’architettura dei microservizi?

Microservices: il caso Netflix

La maggior parte delle aziende progettava i propri servizi web secondo una struttura unica - monolitica - che consente una rapida messa a punto ed un’agevole distribuzione del servizio. Tale sistema è ancora oggi perfettamente adatto alle esigenze delle piccole aziende o di alcune startup, il cui core business è strettamente legato all’attivazione e deployment di servizi e prodotti sempre nuovi. 

Quando un sistema informatico cresce, però, il codice aumenta di complessità, così come si intensificano le attività di manutenzione e gestione del monolite. Inoltre, a fronte di un impianto monolitico, più il sistema cresce e più si vanno ad inficiare velocità, agilità e flessibilità dei servizi - aspetti cruciali per ogni business con un’intensa attività web, come un e-commerce o un servizio di streaming.

È il motivo per cui le più grandi aziende IT del mondo, a partire da Netflix, stanno guidando il passaggio epocale verso la microservice architecture. Il caso di Netflix è indicativo: l’azienda ha iniziato il processo di migrazione di tutti i propri servizi in cloud di microservizi nel 2009, completando l’operazione soltanto nel 2011.

Due anni di lavoro che hanno portato Netflix allo sviluppo di più di 1000 microservizi e API Gateways che gestiscono, quotidianamente, più di due miliardi di richieste da parte degli utenti. Val la pena ricordare qui che Netflix è un’azienda con oltre 200 milioni di utenti in tutto il mondo, che secondo le statistiche più recenti passano oltre 165 milioni di ore - ogni giorno - a “consumare” i contenuti della piattaforma. 

Il caso Netflix, oltre ad essere uno dei primi esempi di successo nel passaggio alla nuova architettura, è emblematico della importante relazione esistente tra la nuova forma dei servizi e la migrazione dei contenuti verso i server cloud.   

L’esigenza cardine, alla base di entrambi i processi, è quella della scalabilità dei servizi: Adrian Cockcroft, il Cloud Architect cui si deve l’epocale passaggio in casa Netflix, ha chiaramente spiegato come tale passaggio si sia reso essenziale con l’aumentare degli utenti del servizio.

Era impossibile, spiega Cockcroft, avere abbastanza spazio fisico per immagazzinare tutti i dati dei nuovi utenti del servizio, che stava effettivamente allora scalando verso le dimensioni oggi note.

Il passaggio all’impostazione cloud-based ha consentito, parallelamente, la suddivisione dell’enorme sistema Netflix nei microservizi di cui sopra. Ma cosa sono i microservizi, e perché il passaggio alla microservice architecture è ormai essenziale per le aziende IT in termini di scalabilità ed implementazione dei servizi?

La scalabilità dei servizi: microservizi, modello n-tier e API

Per comprendere l’orizzonte entro cui nasce la sempre più stringente necessità di confrontarsi con l’architettura del software, è necessario partire da un presupposto ormai chiaro: la diffusione di smartphones ed altri dispositivi con connettività web ha rivoluzionato sia l’uso lato utente sia le necessità di sviluppo delle applicazioni web.

Fino a qualche anno fa, una web app doveva essere in grado di interagire con una singola entità alla volta, generalmente il browser di navigazione web. Oggi si tende ad accedere a diversi servizi da dispositivi assai differenti per uso e caratteristiche, motivo per cui la rapidità e la responsiveness di un’applicazione web sono importanti tanto quanto il prodotto in sé.

Il ricorso ad un'architettura software basata sul modello multi-tier, o n-tier, in cui alle varie funzionalità corrispondono differenti livelli software, è ormai prassi consolidata per gli sviluppatori. Dagli inizi del Duemila si costruiscono servizi three-tier, laddove i tre livelli corrispondono generalmente all’interfaccia utente, ai processi propriamente detti e all’archiviazione dei dati. 

Ma il modello a tre livelli non era pensato per l’uso massiccio che oggi si fa di smartphone ed IoT. Il passaggio alla microservices architecture prevede l’aggiunta di almeno un altro layer, motivo per cui si sente sempre più spesso parlare di architettura four-tier o n-tier. 

La divisione dell’applicazione in livelli è resa possibile dalle API (Application Programming Interface), piccoli mattoncini funzionali ed indipendenti dal linguaggio di programmazione che, esposte tra un livello e l’altro, consentono la comunicazione biunivoca in tempo reale tra due livelli, per esempio il database e l’interfaccia di login di un’app. 

Quali sono i quattro livelli di un sistema del genere?

• Client: il primo livello riguarda ancora l’interfaccia utente, che può essere modificata anche completamente senza interferire con gli altri tre livelli. In tal modo è possibile offrire servizi perfettamente responsive e centrati su una user experience di qualità sempre maggiore;
• Delivery: il livello delivery si occupa di ottimizzare la “consegna” di contenuti e servizi sulla scorta delle informazioni ricevute dall’utente, dalla potenza della connettività web alle specifiche del device coinvolto nello scambio;
• Aggregation: il livello “aggregativo” è quello che mette in comunicazione, in tempo reale, servizi e risorse interni ed esterni attraverso le API. Per esempio Netflix si serve degli AWS (Amazon Web Services) per lo storage in cloud dei propri database, motivo per cui è necessario che il servizio Amazon e quello Netflix possano comunicare in maniera efficiente. 

Molte app dei nostri smartphone, oggi, fanno ricorso a risorse esterne in tempo reale, mentre le utilizziamo: esattamente come Netflix, che fa costante ricorso ai servizi Amazon per distribuire i propri contenuti ai milioni di utenti in tutto il mondo. 

• Servizi: l’ultimo livello, in un’architettura così composta, è quello che fornisce agli altri livelli i dati e le funzionalità richieste dall’applicazione. Il service tier acquisisce il suo senso contestualmente all’applicazione di un’architettura di microservices: si tratta infatti di applicare una sorta di motore principale, indipendente dagli altri, a quei servizi che sono essenziali per la distribuzione del software, come ad esempio il servizio di login o quello di gestione dei pagamenti con carta per qualunque e-commerce. 

In un’architettura per microservizi, infatti, ogni funzionalità ha il suo piccolo motore, ed eventuali malfunzionamenti di un singolo servizio (es: la gestione dell’immagine del profilo utente di un sito) non coinvolgeranno il resto dell’impianto. 

Questo è il senso ultimo della destrutturazione di un monolite come Netflix, e questo è il passaggio inevitabile per ogni azienda che intenda “scalare” i propri servizi oltre una certa soglia, per cui la proporzione tra numero di operazioni ed effort del sistema debba necessariamente saltare a nuova ratio.

Il sistema Netflix per come era nel 2011 - appena prima del passaggio operato da Cockcroft - necessitava di circa 100 sviluppatori impiegati nella manutenzione costante di un monolite sempre più grande e complesso. Allora, contava poco meno di 30 milioni di utenti. 

È lecito chiedersi se la crescita esponenziale di Netflix sarebbe stata fisicamente possibile, senza la migrazione dell’intero sistema su una struttura per microservizi cloud based.