Applicazioni moderne: Microservices Architecture e best practices 1 Parte

architettura Microservices

Applicazioni moderne: Microservices Architecture è il pattern architetturale emergente che potrebbe esserti utile per migliorare i tuoi servizi.

Perchè passare dall’era “Monolitica” a “Multi-Tier”?

Applicazioni moderne: Microservices Architecture. La comunità degli sviluppatori, fin da subito, ha individuato nelle applicazioni monolitiche degli svantaggi che hanno spinto, in fase di progettazione e sviluppo del software, a scomporre logicamente le applicazioni dando una maggiore scalabilità delle risorse.

Che cosa è la tecnologia Multi-Tier (o Multi-Strato)?

Quando parliamo di multi-tier (n-tier) dobbiamo pensare come ad una torta a multi strati dove ogni strato è rappresentato da un applicativo collegato e comunicante con un altro strato di sfotware. Se diamo uno sguardo ad una applicazione web questi strati sono rappresentati dalla logica di presentazione (frontend), l’elaborazione dei processi (servizi) e la persistenza dei dati (database). Ogni strato software comunica con lo strato software adiacente diventando client o server all’occorrenza. Questa cosa è vera per tutti gli strati interni mentre per quelli estremi possono fungere solo o da client o da server.

L’impiego più conosciuto di una architettura multi-tier è quella a “tre livelli” (three-tier).
Questo tipo di architettura garantisce agli sviluppatori lo sviluppo di una applicazione flessibile e soprattutto riutilizzabile (ovvero scalabile).
Questo tipo di architettura garantisce un maggior controllo del software, una maggiore facilità nell’apportare modifiche o nell’implemnetazione di nuove funzionalità senza dover riscrivere un’intera aplpicazione.

Che cosa è l’architettura three-tier?

Questo tipo di architettura è stata sviluppata da John J. Donovan nell’Open Environment Corporation (OEC). Lo scopo era quello di suddividere il software in tre strati: interfaccia utente, acesso e elaborazione dati e archiviazione dei dati. Generalmente questi tre “moduli” sono su piattaforme separate per garantire una maggiore affidabilità e scalabilità.

L’architettura è suddivisa nei tre seguenti livelli:

  1. Presentazione
    Quando parliamo di applicazione intendiamo il livello più alto dell’applicazione. Se prendiamo ad esempio un sito e-commerce parliamo delle pagine che espongono al cliente la merce, il carrello e la procedura diacquisto di un prodotto o servizio. Questo livello comunica con gli altri livelli adiacenti attraverso i risultati di output al livello browser/client.
  2. Applicazione
    Questo livello elabora e gestisce le informazioni da inviare al primo livello detto di Presentazione. Riceve richiesta dal livello di Presentazione (quindi si espone come servizio server) le elabora chiedendo informazioni al livello “Dati”. Possiamo immaginare questo strato come un webservice che viene invocato da un client per ricevere dati dell’utente, degli acquisti effettuati, dei prodotti in vendita etc…
  3. DatiQuesto terzo strato è costituito generalmente da un server di database. Questo strato mantiene alterate le informazioni non tenendo conto delle applicazioni e delle logiche di business.

Service Oriented Architecture (SOA)

Lo step successivo è stato quello di suddividere le applicazioni in base alle specifiche, funzionalità, del business, perdendo almeno per alcuni aspetti la suddivisione a livello di stack come definito nel multi-tier. In questo modo una più semplice o più comnplessa applicazione diventa una collection di servizi.

Facciamo un esempio pratico?

Prendiamo come esempio un sito e-commerce. Andiamo a suddividere i vari elementi dell’applicazione tenendo conto di voler applicare il SOA.
Quindi analizzando nel dettaglio i requisiti di business avremo i seguenti servizi:

  1. User Service:
    il servizio dovrà occuparsi nello specifico delle funzionalità legate strettamente all’utente.

    1. Login
    2. Profile
    3. Logout
  2. Order Service:
    il servizio dovrà occuparsi nello specifico di tutte le funzionalità legate strettamente agli ordinativi.

    1. Carrello
    2. Acquisto
    3. Lista ordini
  3. Notification Service:
    il servizio dovrà occuparsi nello specifico di tutte le funzionalità di notifica verso il cliente.

    1. Inviare E-Mail;
    2. mandare SMS;
    3. e l’invio di messaggi PUSH.

Analizziamo questa tipologia di architettura

Analizzando questo tipo di architettura vediamo da subito che abbiamo effettivi vantaggi in termini di scalabilità e di una maggiore semplicità manutentiva. Questo perchè abbiamo servizi separati e quindi potenzialmente più piccoli e facili da gestire.

Nonostante il modello descritto abbia fornito notevoli miglioramenti nella costruzione di architetture più efficaci, nella pratica è stata generalmente inefficace a causa di inutili astrazioni e protocolli legacy molto complessi. Gli sviluppatori si sono trovati ad utilizzare SOA per collegare una vasta gamma di applicazioni che parlavano una lingua diversa, e che hanno richiesto l’implementazione di un ulteriore livello, usato per la comunicazione che è l’ Enterprise Service Bus. Tutto questo ha comportato configurazioni costose che non possono tenere il passo con la tecnologia e il business di oggi.

Prima di iniziare a parlare di microservizi è necessario fare un excursus sulle varie modalità di scalare un applicazione e comprendere come si è arrivati ai microservizi (microservices).

Vediamo la scomposizione delle applicazioni in servizi

Per capire meglio come funziona la modalità a scalare di una applicazione ci faremo aiutare dal cubo che vediamo nell’immagine che segue.

La scomposizione delle applicazioni in servizi

Nel modello che vediamo, la consuetudine per far scalare un’applicazione è quello di replicare eseguendo molteplici copie identiche dell’applicazione dietro un bilanciatore di carico (LBL). Questo metodo è noto come scalatura sull’asse X. Questo apporccio migliora la capacità di erogazione e la disponibilità di un’applicazione.

Similmente alla scale X abbiamo quella lungo l’asse Z dove ciascun server esegue una copia identica del codice con la differenza che ogni server è responsabile per solo un sottoinsieme dei dati. Ci sono in questo caso dei componenti del sistema che sono responsabili dell’instradamento di ogni richiesta al server appropriato. Uno dei criteri di routing di uso comune è un attributo della richiesta, come la chiave principale del soggetto a cui si accede (sharding).

Scalare lungo l’asse Z, come lungo l’asse X, migliora la capacità dell’applicazione e la disponibilità. Tuttavia, questi approcci non risolvono i problemi legati alla crescita delle dimensioni e della complessità dell’applicazione. Per risolvere questi problemi abbiamo bisogno di scalare lungo l’asse Y.

Che cosa è la terza dimensione

La terza dimensione di questo modello è l’asse Y o asse della decomposizione funzionale, che è l’approccio usato nei microservices. Se scalare lungo l’asse Z vuol dire dividere le cose che sono simili, scalare lungo l’asse Y vuol dire invece dividere le cose che sono diverse. A livello applicativo, scalare lungo l’asse Y vuol dire dividere un’applicazione monolitica in un insieme di servizi. Ogni servizio implementa una serie di funzionalità correlate, come ad esempio la gestione degli ordini, la gestione dei clienti etc.

Come partizionare?

Decidere come partizionare un sistema in una serie di servizi è un’arte, ma ci sono una serie di strategie che possono aiutare. Un approccio è quello di suddividere i servizi mediante i verbi (azioni da fare) quindi in pratica i vari casi d’uso. Ad esempio, in un ipotetico negozio online partizionato così avremo ad esempio il servizio Checkout, che implementa l’interfaccia utente per il caso d’uso di checkout.

Un altro approccio di partizionamento è di suddividere il sistema in base ai sostantivi o risorse (entità). Questo tipo di servizio è responsabile di tutte le operazioni che operano su entità / risorse di un determinato tipo. Ad esempio, considerando sempre il caso di un negozio online potremmo avere un servizio di Catalogo, che gestisce il catalogo dei prodotti.

Come principio dovremmo pensare che ogni servizio deve occuparsi di un insieme di piccole responsabilità nel principio di design SRP. Possibilmente un servizio deve occuparsi di una singola responsabilità.

Se diamo ad uno sguardo al disegno sotto vediamo come un’applicazione JAVA è stata suddivisa in micro servizi. Ogni singolo servizio è stato inpacchettato in un WAR.

Applicazioni moderne: Microservices Architecture

Applicazioni moderne: Microservices Architecture

SOA vs Microservices

Entrambi gli approcci visti, SOA e Micro Services, basano la loro logica sulla suddivisione funzionale. Anche se il primo, SOA, è orientato a far interagire N applicazioni il socondo, Micro Services, tende alla realizzazione di una singola applicazione composta da N servizi sviluppati e implementati in maniera indipendente secondo il principio della Singola responsabilità (SRP).

Non facciamoci prende in inganno dalla parola “MICRO”. Questo parola non vuol dire che il servizio è di piccole dimensioni anzi, potrebbe trattarsi di un servizio di grandi dimensioni e molto complesso.

La parola “MICRO” dobbiamo vederla in un concetto più ampio: l’architettura a microservizi vuole significare che ogni servizio deve poter essere sviluppato e distribuito in maniera indipendente dagli altri.

Ma come comunicano i servizi tra di loro?

Le comunicazione in una architettura a microservizi è basata su protocollo HTTP(S) attraverso soluzioni basate sull’API RESTful, passando i dati in formato JSON, spesso attraverso una coda di messaggi, soprattutto quando è necessario garantire l’affidabilità del servizio. I singoli Microservices sono generalmente trattati in modo asincrono, innescati da un evento come una chiamata ad una API o un inserimento di un dato in coda (nei prossimi giorni vedremo i servizi di coda come JMS e Kafka). Questo tipo di comunicazione, basata su un protocollo “leggero” quale è l’HTTP, è un ulteriore differenza tra microservices e SOA.

Nel prossimo articolo andremo a vedere nel dettaglio quali sono i benefici che otterremo andando ad utilizzare i microservizi.

Prosegui la lettura dell’articolo in parlo dei vantaggi che si ottengono utilizzando i microservizi

Potrebbero interessarti anche...