L’architettura a microservizi è una modalità di suddivisione di ampi progetti e architetture software in piccoli e poco interdipendenti (loosely coupled) moduli, i quali comunicano tra loro attraverso piccole e semplice API.

La soluzione basata su microservizi è stata inizialmente adottata da molte aziende enterprise come Amazon, Netflix e eBay e sempre di più da aziende medio/grandi. Col tempo l’hanno adottata anche piccole startup, grazie ad una serie di vantaggi a cui si ha accesso utilizzando idee e prodotti opensource messi a disposizioni da alcune famose software house tra le quali, per citarne alcune, Netflix, Twitter, Google, Docker Inc, Pivotal, etc.

Microservizi: vantaggi

L’adozione delle architetture a microservizi porta con se diversi vantaggi tra cui:

• aumenta l’isolamento dei guasti: grosse architetture software possono rimanere largamente non coinvolte dai problemi di un singolo modulo.

• elimina la dipendenze a lungo termine da un singolo stack tecnologico: favorisce l’adozione di nuovi stack tecnologici applicati ad uno specifico servizio senza creare impatti sugli altri.

• rispetto alla soluzione monolitica rende più chiara la dipendenza dei vari concetti gestiti dall’applicazione, permettendo un più semplice cambiamente di singoli componenti e la possibiltà di scartare eventuali cambiamenti che hanno avuto effetti indesiderati; questo perché le problematiche introdotte sono state confinatate in un unico servizio.

• i singoli servizi hanno meno codice coinvolto, rimangono così più flessibili e facilmente manutenibili nel tempo.

• rende più semplice la comprensione delle funzionalità di un servizio per eventuali nuovi sviluppatori coinvolti nell’implementazione e la cura del servizio stesso.

Microservizi: inconvenienti

Solo perché tutti ne parlano e tutte le grandi aziende la utilizzzano non vuole dire che l’architettura a microservizi non abbiamo inconventienti, anzi! Ecco alcune potenziali problematiche derivanti da questo tipo di design:

• sviluppare un sistema distribuito può essere complesso perché proliferano i servizi indipendenti; bisogna quindi aver cura di gestire correttamente le informazioni che attraversano i vari moduli. È per esempio possibile che qualche servizio non sia raggiungibile o non funzionante, ed è quindi necessario gestire quest’eventualità con dei servizi o del codice aggiuntivo.

• è possibile che si introducano eccessive latenze nell’attraversamento dei vari microservizi, con l’eventualità tutt’altro che remota vista la cascata di chiamate remote che si innescano potenzialmente, che in definitiva sia fornita la risposta con un ritardo eccessivo.

• database multipli e transazioni distribuite possono essere molto complicate da gestire, con relativo auemento dei costi di sviluppo e di manutenzione.

• effettuare i test può essere complicato; utilizzando un approccio con unico monolite è sufficiente eseguire il proprio archivio (WAR) ed assicurarsi di avere una connessione al database; adesso con i microservizi interdipenenti tra di loro è necessario avere tutti i microservizi a disposizione e raggiungibili per avviare i test di integazione.

• mettere in produzione i microservizi può essere decisamente complesso. È necessario coordinare molteplici servizi, il loro avvio, la loro interdipendenze. Non è mai semplice come fare il deploy di un WAR in un container.

Certamente, con il giusto tipo di automazione e di strumenti, è possibile fronteggiare gli inconvenienti descritti.

Componenti infrastrutturali comuni

L’adozione della soluzione a microservizi può essere notevolmente facilita dall’adozione di strumenti opensource sviluppati da altre aziende, come per esempio la Netflix Opensource Platform. Gli utilizzatori del linguaggio Java possono inoltre trarre vantaggio dall’ulteriore livello di astrazione ed integrazione costruito sopra la Netflix Opensource Platform: l’insieme delle soluzioni previste nel progetto Spring Cloud.

A questi strumenti è necessario affiancare vari altri prodotti necessari per la creazione, manutenzione, test, monitoraggio e messa in produzione dell’architettura.

Nei paragrafi successivi sono descritti brevemente alcuni servizi applicativi estremamente utili, se non fondanti, nell’architettura a microservizi.

Servizio di configurazione centralizzato

Il configuration service permette a tutti i microservizi del progetto di usufruire di una configurazione centralizzata che tramite l’utilizzo di un repository git permetta il facile e sicuro aggiornamento della configurazione dei servizi. La centralizzazione permette di poter scalare orizzontalmente i servizi senza doversi occupare di replicare la stessa configurazione.

Inoltre l’utilizzo del repository git come sorgente dei dati del configuration service permette un accesso controllato e storicizzato di tutte le informazioni di configurazione.

Il repository GIT può essere facilmente ospitato e gestito tramite Gitlab.

Servizio di registrazione e discovery dei servizi

Al fine di permettere un’affidabile gestione ed una semplice scalabilità dei molti servizi realizzati, è possibile utilizzare un servizio di service discovery, basato sul progetto Netflix Eureka. Il service discovery permetterà ai vari servizi di registrarsi e di avere a disposizione le informazioni dei servizi disponibili per fornire determinate funzionalità. Grazie a questo servizio è possibile aggiungere più istanze dei vari servizi senza dover ulteriormente configurare i servizi che le utilizzano. In altri termini è possibile far scalare orizzontalmente l’architettura, senza introdurre troppa complessità operativa.

Servizio di autenticazione centralizzata

Ogni servizio che richiede un controllo di autenticazione per l’accesso alle proprie risorse, solitamente condivide l’autenticazione derivante da un unico servizio di autenticazione centralizzato. Questo servizio permette, sia agli utenti che ad eventuali altri servizi, di ottenere un token di autenticazione tramite i meccanismi standard definiti dal protocollo OAUTH2, oltre che i servizi necessari per la gestione del refresh token OAUTH2. Esistono vari servizi di autenticazione ed autorizzazoine che supportano il protocollo OAUTH2, questi sistemi possono effettuare il processo di autenticazione necessario per il rilascio del token di autenticazione.

Nel token di autenticazione rilasciato dal servizio saranno presenti le informazioni di base dell’utente/servizio autenticato (nome, cognome, email, etc), oltre alle eventuali informazioni relative alle autorizzazioni degli utenti.

Proxy applicativo dei microservizi

Al fine di garantire un unico punto di accesso controllato e con autenticazione di tipo Single Sign On, è possibile utilizzare un servizio di proxy applicativo, per esempio facendo uso del componente Netflix Zuul. Questo permette la ricezione delle varie richieste HTTP(s) derivanti dai vari servizi e/o front end web ed il loro smistamento verso gli opportuni microservizi. Anche questo elemento è parte integrante della scalabilità orizzontale raggiungibile con questa architettura.

Riferimenti

Prodotti e soluzioni per microservizi

Tra i componenti principali suggeriti:

• Spring Cloud Config: Servizio di gestione centralizzata della configurazione basato su un repository git.

• Spring Cloud Security: Fornisce il supporto per il utilizzare nei client Rest una versione load-balanced del meccanismo di autenticazione OAuth2 appoggiandosi allo Zuul proxy.

• Spring Cloud Netflix: Integrazione con vari componenti opensource di Netflix (Eureka, Hystrix, Zuul, Archaius, etc.).

• Netflix Eureka: Servizio per localizzare i servizi basati su REST (Representational State Transfer) con l’obbiettivo di garantire il load balancing ed il failover dei middle-tier server.

• Netflix Zuul: Proxy applicativo esposto come servizio di frontiera che fornisce dynamic routing, monitoring, resiliency, security e molto altro.

• Gitlab: prodotto integrato per la gestione dell’intero ciclo di sviluppo del software.

• Docker: The Docker platform is the only container platform to build, secure and manage the widest array of applications from development to production both on premises and in the cloud

• Docker registry: The Registry is a stateless, highly scalable server side application that stores and lets you distribute Docker images.