Nell’ambito IT le macchine virtuali hanno portato ad una vera rivoluzione: la possibilità di installare più sistemi operativi (magari comunicanti tra loro) sulla stessa architettura hardware, ha permesso di risparmiare sui costi e sull’hardware. L’unico vero e proprio problema riguarda il modo di istanziare il sistema operativo: anche se virtuale, necessita comunque di spazio disco e ram (che è quella dell’hardware dove viene fatta girare).
Categoria: Architetture Software
Architettura Microservice – Comunicazione
Per la comunicazione interna tra microservices ci sono diverse scuole di pensiero!
In un mondo ideale, ogni singolo servizio dovrebbe essere indipendente da ogni altro, ma ovviamente solo in un mondo ideale. Se si rende necessaria l’iterazione tra microservices per soddisfare una singola richiesta, non siamo in presenza di un problema di protocollo, bensì di un problema di architettura. In questo caso non è importante quale tipo di comunicazione si sia scelta (HTTP, AMQP, messaggi asincroni ecc…), ma il tempo con il quale verrà soddisfatta la richiesta e soprattutto l’affidabilità dei singoli servizi.
Nel caso in cui sia necessario creare un meccanismo di comunicazione, quest’ultimo dovrebbe essere asincrono.
In un comunicazione asincrona (Async I/O) le chiamate non sono bloccanti per il processo ( o il thread) che le hanno effettuate. In questo modello di comunicazione, la chiamata non risulta bloccante fino alla ricezione di una risposta da parte del servizio destinatario, ma è libera di procedere nel normale flusso di esecuzione. Per poter intercettare la risposta da parte del processo destinazione, è possibile utilizzare callback, promise e streams.
Non è però sempre possibile evitare l’utilizzo di operazioni sincrone: basti ad esempio pensare all’iterazione con un database, che deve avvenire all’interno delle ciclo richiesta-risposta.
La necessità di strutturare le comunicazioni in modalità asicrona, si basa sul principio tale per cui i microservices debbano essere indipendenti l’uno dall’altro e soprattutto dovrebbero funzionare anche se gli altri servizi fossero temporaneamente non disponibili.
Alla base della comunicazione tra servizi, c’è sicuramente la necessità di ottenere risposte nel piu’ breve tempo possibile. In questo scenario, il protocollo HTTP è sicuramente il metodo piu’ semplice, e forse più affidabile, possibile. Inoltre consente di essere impiegato sia in scenari sincroni, sia in scenari asincroni.
L’ HTTP è un protocollo sincrono: a seguito di una richiesta fatta dal client, si attende la risposta.
Volendo implementare una soluzione asincrona, il thread del client potrebbe non attendere, eseguire altro codice, e gestire le operazioni solo alla ricezione della risposta da parte del server.
Una soluzione possibile per disaccopiare i servizi è quella di effettuare una ridondanza dei dati: in questo modo vengono replicati nei vari servizi, con l’evidente vantaggio di delegare la responsabilità ad ogni singolo contesto locale. Ad esempio utilizzando sistemi indipendenti SCS (self-contained system).
Ma come ridondare? Ad esempio, utilizzando processi di polling monitorando richieste RESTFul. L’utilizzo di un’architettura basata su protocollo HTTP consente di utilizzare meccanismi di caching, senza dover implementare nuove astrazioni.
Altri metodi fanno uso di sistemi di messaggistica come Akka o Erlang che consentono di semplificare le funzioni di scambio dati tra servizi.
Architettura Microservices – Analisi
Riprendendo il progetto che è stato convertito da un’architettura monolitica ad una più moderna a microservices, sono state analizzate le tematiche legate ai pro ed i contro del nuovo approccio.
Nell’articolo precedente abbiamo fatto una breve panoramica delle architetture monolitiche e quelle basata sui servizi.
L’analisi dei costi sia in termini economici, sia in termini di risorse, è sicuramente una componente fondamentale nella decisione di approcciare la nuova architettura. Si tratta, infatti, di una vera migrazione, molto volte irreversibile.
Architettura Microservices
Il passaggio dallo sviluppo di un software “tradizionale” ad un software basato su un’architettura basata su microservices risulta, almeno inizialmente, non proprio semplice.
Negli ultimi 4 mesi ho trascorso un pò di tempo nello studio e nell’implementazione di una soluzione basata sui microservices.
L’idea alla base di questo tipo di struttura non è completamente nuova, ma possiamo pensarla come un’evoluzione dell’architettura SOA (Service Oriented Application): si tratta infatti di una serie di piccoli servizi (micro appunto) indipendenti tra loro e ciascuno focalizzato su particolare ruolo all’interno del business.