NS12 è PMI Innovativa
0689178001

I microservizi nell'epoca dell'Engagement Platform

NS12 > News > Business > I microservizi nell’epoca dell’Engagement Platform

I microservizi nell’epoca dell’Engagement Platform

  • d.barbato
  • Nessun commento

Si dice che 3 sia il numero perfetto...

…in questo articolo però voglio darti un altro numero.

Sei curioso di sapere quale numero è?

Prima di risponderti, voglio elencarti alcune società che hanno in comune una cosa. Le società di cui sto parlando sono Netflix, Uber, Amazon e Ebay.

Queste società si sono rese conto che per il tipo di business effettuato e per il contesto sempre più mobile il numero 3 non andava più bene. Per loro ci voleva un bel 4.

La vecchia architettura web basata sul numero tre e cioè la “three-tier architecture” non offriva loro la flessibilità e la scalabilità necessarie per una buona esperienza mobile. Il tre cominciava ad andare stretto in un mondo sempre più connesso e non stiamo parlando solo di smartphone ma anche di assistenti digitali, domotica, Iot etc.

Ma perché il numero quattro?

Il perché ha relazione con l’inadeguatezza del tre in questo nuovo contesto. Quattro è infatti il numero di livelli in cui sono state separate le funzionalità tecniche della nuova architettura distribuita.

La Engagement Platform

La nuova architettura a quattro livelli è stata definita “Engagement Platform” dalla Forrester Research Inc una società di ricerche di mercato americana.

I quattro livelli sono i seguenti:

  • client tier
  • delivery tier
  • aggregation tier
  • services tier

Descrivo brevemente e semplificando molto i suddetti quattro livelli.

Il livello client si occupa della presentazione dei contenuti.

Il livello di consegna o delivery ottimizza i contenuti in base alla device e si occupa dell’eventuale gestione del caching dei dati. Si inseriscono in questo contesto ad esempio i CDN.

Il livello di aggregazione si occupa dell’integrazione di servizi esterni ed interni e della trasformazione dei dati. Tra le funzioni di competenza possiamo trovare l’individuazione/ricerca dei servizi che troviamo al livello successivo.

Il quarto ed ultimo livello è il livello dei servizi che espone dati e funzionalità di business mediante un set di servizi.

L’architettura a quattro livelli è molto più flessibile, scalabile, responsive e mobile-friendly.

I Microservizi

Nella progettazione di una applicazione a microservizi è preferibile prendere come riferimento questo tipo di architettura.

Le applicazioni vengono scomposte in servizi il più possibili autonomi ognuno dei quali si occupa dei suoi dati e quindi del suo database. Ogni singolo microservizio è una piccola applicazione che si occupa della sua area funzionale.

Il passaggio all’approccio basato su microservizi rende lo sviluppo applicativo più facile da gestire rispetto allo sviluppo di un’applicazione monolite.

L’impatto di una modifica è circoscritta al microservizio e l’area di know how del team di sviluppo è ridotta.

Per il fatto che ogni microservizio è una piccola applicazione può essere sviluppata con il linguaggio di programmazione che per le sue caratteristiche più si presta alla funzione che il servizio deve assolvere.

Al poliglottismo può seguire anche la specializzazione dei database adottati che possono differire da un servizio ad un altro. Si può scegliere tra databases Sql, database NoSql come i DocumentDB (es: Mongo) o un graph databases come Neo4J in funzione della convergenza tra le peculiarità del database e le necessità legate al trattamento dei dati.

Anche il deploy dei microservizi diventa più rapido consentendo di avere anche più messe in produzione giornaliere, il tutto contestualizzato nell’ottica del DevOps della scalabilità e della resilenza.

L’obiettivo è ridurre il time to market, essere dinamici e connessi.

Ovviamente come in tutte le cose c’è un prezzo da pagare.

Le Sfide

Le applicazioni basate su microservizi scalabili verticalmente ed orizzontalmente introducono nuove sfide.

Le sfide partono sin dalla fase di progettazione e design. Si devono individuare bene i Bounded Context applicativi e tutti gli elementi propri del Domain Driven Design in modo tale che ogni microservizio abbia dei confini ben delineati di competenza e sia il più possibile autonomo.

L’autonomia porta quindi ad avere domini dati distinti. Come fare quando abbiamo bisogno di dati provenienti da servizi e quindi domini diversi?

Immagina ad esempio la schermata di una applicazione mobile che deve mostrare dati provenienti dal carrello e dal catalogo dei prodotti.

Hai due possibili opzioni tra cui scegliere se hai bisogno di elaborazioni real-time:

  • l’uso di un API GATEWAY come elemento di aggregazione di dati provenienti da origini diverse
  • l’applicazione del paradigma CQRS (Command Query Responsibility Segregation)

L’API GATEWAY è definito il backend per il frontEnd e rappresenta il punto di accesso dell’applicazione client ai microservizi. Non è bene che il client interagisca direttamente con i microservizi per una serie di ragioni che non approfondisco in questo articolo (compiti per casa). Stando all’esperienza di Netflix e di altre società è bene creare un API Gateway che si adatti alle esigenze della tipologia di client.

Tra i servizi messi a disposizione dall’API gateway se ne potrebbe creare uno che aggreghi i dati e che soddisfi la necessità dell’applicazione mobile dell’esempio di ottenere dati dai diversi microservizi.

Nella progettazione dell’API GATEWAY dobbiamo fare molta attenzione affinché non si trasformi in una applicazione monolite difficile da gestire.

L’applicazione del paradigma CQRS può rispondere alla stessa esigenza di aggregazione. Applicando il pattern delle viste materializzate si possono generare delle tabelle in sola lettura con i dati appartenenti ai diversi microservizi.

Le tabelle create potrebbero essere su un altro database che è usato all’occorrenza da servizi dedicati all’effettuazione delle query necessarie.

Altro aspetto su cui focalizzare la nostra attenzione in fase di sviluppo di applicazioni basate su microservizi è il modo in cui essi comunicano tra di loro.

Poiché ogni servizio ha un suo contesto di esecuzione, si devono prevedere dei meccanismi di comunicazione inter-process. Si consiglia là dove possibile di privilegiare la comunicazione asincrona e prevedere l’uso di sistemi di messagistica tipo message broker o message queue.

Si parla a tal proposito di Event Driven Comunication ovvero comunicazione basata sugli eventi. Quando avviene qualcosa che deve essere notificato ad altri, il microservizio pubblica un evento. Allo stesso tempo ci sono altri servizi interessati all’evento pubblicato che ricevendone notifica avviano azioni ed eventualmente pubblicano altri eventi.

L'Altra Sfida

Un’altra sfida da accettare nell’ambito della realizzazione di applicazioni a microservizi è legata al fatto che il microservizio gira in ambienti dinamici e possono essere soggetti a cambiare di posizione (IP) si devono quindi mettere in atto dei meccanismi di “service discovery” mediante l’ausilio dei “Service Regitry” ovvero di database distribuiti che mantengano informazioni sulle istanze dei microservizi in esecuzione e le loro posizioni.

E come gestire la consistenza dei dati in una applicazione a microservizi?

Metto in evidenza da subito che qui si parla di “consistenza eventuale”.

Come innescare una transazione che aggiorna la tabella degli ordini e contestualmente le giacenze di magazzino se queste entità sono gestite in database differenti e microservizi differenti?

In una applicazione monolite che generalmente ha un unico database relazionale si possono usare le transazioni ACID.

Nell’ambito dei microservizi ognuno di essi possiede il proprio set di dati che potrebbe essere persistito con un approccio poliglotta. Ci potrebbero essere dei database relazionali sql, dei database NoSql etc.

Come dicevo, le transazioni distribuite conosciute come two-phase commit solitamente non sono una strada percorribile.

Per gestire la consistenza si hanno fondamentalmente le seguenti opzioni:

  • la pubblicazione di eventi usando le transazioni locali usando il database come se fosse una message queue
  • usare dei prodotti di mining del log transazionale del database
  • applicare l’event sourcing

Le caratteristiche, i pro e i contro di ognuna di queste tecniche meritano un approfondimento e ti invito a leggere la documentazione che si trova nel web.

Riassumendo possiamo dire che ci sono tanti elementi da tenere in considerazione per creare un’applicazione a microservizi.

Sin dalla fase di disegno e sviluppo fino ad arrivare al deploy tutti questi elementi devono essere chiari e devono esserne chiare le interazioni.

Ma come si può creare un’infrastruttura tale che consenta l’esecuzione di un applicativo a microservizi?

Come incastrare tutti i pezzi del puzzle?

Seguono dei piccoli input pratici.

Le Infrastrutture

Parlando di infrastrutture possiamo dire che a livello di persistenza dati e nell’ottica della scalabilità lo sharding del database deve essere preso in considerazione.

E’ evidente che per il deploy di un’applicazione a microservizi ci vuole un controllo maggiore delle metodologie ed un alto livello di automazione.

Si deve ricorrere a quella che è conosciuta come Platform as a Service (PaaS) che può essere on premise o nel cloud.

Ci sono due possibili approcci che sono legati alle tecnologie impiegate:

  • Affidarsi a piattaforme come ad esempio CloudFoundry o OpenShift
  • Crearsi la propria PaaS. A questo proposito si potrebbe iniziare con scegliere una soluzione clustering come Kubernates abinata ad una tecnologia container tipo Docker

Sia CloudFoundry che Kubernates usano ETCD che è un service registry che assolve alle esigenze di discovery delle applicazioni basate su microservizi.

Altri service registry disponibili che ovviamente dipendono dalla tecnologia scelta sono: Netflix Eureka, Consul, Apache Zookeeper.

Anche per l’API GATEWAY si può decidere di implementarne uno possibilmente adottando un linguaggio che supporti chiamate I/O asincrone non bloccanti. In questo caso potrebbe essere usato ad esempio NodeJS oppure in tecnologia Java si potrebbero adottare dei framework basati su NIO tipo VERTEX, NETTY, SPRING e REACTOR. Per non incorrere nel CALL BACK HELL meglio usare lo stile dichiarativo con l’approccio reactive (RxJs e compagnia bella).

L’altra scelta possibile è usare un API GATEWAY esistente. Mi vengono in mente Kong GateWay oppure in tecnologia NetCore Ocelot API Gateway.

Riassumendo…

Come hai potuto vedere in questo articolo ci sono molti aspetti coinvolti nello sviluppo applicativo a microservizi.

Ti consiglio di munirti di pacchi di caffè o di tè a seconda dei gusti perché ti aspettano tante ore di studio.

Lo scopo di questo articolo è darti una panoramica generale ma ogni singolo argomento merita di essere approfondito e tutti i pezzi del puzzle incastrati tra di loro.

Il percorso per essere dei protagonisti nell’epoca dell’Engagement Platform è lungo ma con il lavoro di squadra e con l’impegno di tutti può essere un viaggio piacevole.

In questo viaggio ognuno può apportare il proprio contributo per ottenere un “bel quattro”.

DANTE CASALI

NS12 è PMI Innovativa
Siamo iscritti al Registro delle Imprese nella sezione speciale comei PMI Innovativa continuando ad investire sull’innovazione progettando soluzioni SW innovative