Ciao a tutti

Uno degli aspetti più utili del Cloud Computing è la messaggistica. La capacità di gestire un traffico di messaggi da più dispositivi tipicamente con una limitata capacità computazionale e decisionale nei dispositivi distribuiti e con tutta le potenzialità di calcolo, di BI e di analisi in generale disponibili sul Cloud. Va anticipato che tra non molto uscirà l’Edge computing di Azure che è proprio un architettura in grado di offrire la gestione della computazione sui dispositivi (in futuro ne parleremo)

I sistemi di messaggistica tipicamente sono basati o su coda o su Stream. La coda è un sistema di persistenza temporaneo che può lavorare in best-effort, e cioè al meglio delle sue capacità senza garantire transazionalità o sequenzialità, o inversamente può garantire queste cose lavorando in modalità FIFO, LIFO con o senza sessioni e transazioni. Sicuramente invece, tutte le code pubbliche garantiscono l’accesso previa autenticazione e quasi sempre crittografia dei contenuti. Gli Stream offrono un servizio più simile alle code in best-effort, con la differenza che uno Stream è (entro dei limiti) possibile scorrerlo anche tornando un tantino indietro per magari riprocessare qualcosa andata male, o è possibile sfruttarlo in maniera parallela usando partizionamenti o soluzioni analoghe. Gli Stream non supportano transazionalità, ordinamento dei messaggi autogestito, sessioni, identificazione di duplicati, gestione degli scarti (errori) ed altre funzioni tipiche delle code

Tipicamente, le Code sono la scelta migliore dove è necessario garantire la consegna del messaggio, mentre gli Stream sono migliori nella banda disponibile nella trasmissione dei messaggi. Basti pensare che al meglio, in una coda servono tre richieste per mandare un messaggio (invio, ricezione, conferma di ricezione – cancellazione dalla coda), mentre sullo Stream ad ogni messaggio corrisponde una eventuale lettura, proprio come se leggessimo un file condiviso da altri programmi. Proprio per questo motivo, il problema con gli Stream è la persistenza dell’ultimo punto di scorrimento, cosa che si fa più complessa se per necessità di performance o di scalabilità andiamo ad usare più partizioni.

Quando si ha a che fare con un sistema distribuito, o entrerprise che sia, è bene persistere ogni step intermedio di una elaborazione, per renderla più robusta (esente da crash), in grado quindi di ripartire sullo stesso od altro nodo di elaborazione, inoltre questo rende anche la piattaforma scalabile, andando a disaccoppiare i moduli software (od i layer) che intercomunicano con un sistema di messaggistica persistita. Quando invece si ha a che fare con un sistema a basso livello che ha il compito di acquisire (o produrre) informazione, tipo un sensore o un gateway per il cloud, allora la scelta ideale, per quantità di messaggi e latenza e ri-analizzabilità dei messaggi ricade sugli Stream .

Parlando dell’offerta di Microsoft Azure, vediamo oggi alcune possibilità in tal senso, ognuna con pro e contro diversi. Le vecchi Queue (code) dello Storage Account, che supportano 7 giorni di vita per messaggio, 500TB di dimensione massima della coda, 64KB a messaggio, lavorano in HTTP su protocollo REST, hanno uno o più worker per client per poter scodare i messaggi, anche dinamicamente modificabili, supporta batch di invio ed in combinazione con i BLOB sempre dello Storage Account possiamo trasferire messaggi (che in questo caso sono BLOB o file che siano) di dimensioni anche di 200TB. Per contro, non supportano transazionalità, invio multiplo in ottica publish-subscribe, sessioni, partizioni, identificazione di duplicati, etc

Le (ormai vecchie anche loro) Queue/Topic del Service Bus, invece, supportano più protocolli (HTTP, TCP, AMPQ), supportano transazioni, sessioni (che garantisce il FIFO), partizioni, gestione degli scarti, buffer/batch in invio e ricezione, un singolo messaggio di dimensioni maggiori (1MB) anche se nel totale una coda di dimensione totale inferiore. Non ha un TTL (tempo di vita del messaggio) predefinito contro i soli 7 giorni dello Storage. Inoltre supporta la ricezione in maniera asincrona su più handler senza l’uso di worker in polling, il cui numero però non è dinamicamente modificabile. Il prezzo è ovviamente superiore a quello dello Storage Account, e poi se vogliamo trasferire BLOB, dobbiamo usare entrambi i sistemi, non essendo il Bus in grado di fare tutto da solo. Inoltre, nella variante Topic, supporta al posto del singolo FIFO un’architettura publish-subscribe con cui più sottoscrittori possono sottoscriversi alla pubblicazione dei messaggi eventualmente con l’uso di filtri, per poter ricevere tutti insieme i messaggi di loro interesse, senza far scattare la cancellazione del singolo messaggio dalla coda. Concludo dicendo che anche la gestione della sicurezza nel Bus è più articolata e prevede l’emissione di più token di autenticazione con differenti livelli di policy di accesso alle code/topic

In ultimo, abbiamo l’EventHub, lo Stream scalabile di Azure che ci offre il servizio appunto di streaming di dati tipici di telemetria che vengono esposti dai nostri sensori, dispositivi o campionatori. Come già anticipato, qui non vi sono sessioni e transazioni, ma in compenso ci sono: partizioni (max 32), alta banda di trasmissione, bassa latenza, possibilità di usare più sorgenti e consumatori di informazioni, similarmente ad un Topic del Bus, ma con protocolli differenti. Anche qui il limite massimo di oggi è 1MB a messaggio, 7 giorni di durata massima dei messaggi.

Quando andiamo a che fare con gli Strem di EventHub, in genere lavoriamo a basso livello, nel senso che raccogliamo dati dai sensori o da dispositivi estremamente vicini (da un punto di vista software) ai sensori, in pratica un logo gateway. In Azure, la porta per far passare i dati da buttare sullo Stream è l’IoT Hub, che parla già in MQTT, AMPQ, ed antri formati standard, oltre ai formati personalizzabili. Come consumatori, possiamo usare o il preconfigurato (e quindi RAD) PowerBI, parte della suite di Office365, o il Machine Learning, su cui possiamo creare le nostre soluzioni di analisi, sui sistemi di analisi di HDInsight (che supporta Hadoop, R, Spark, etc) con o senza l’uso del Data Lake, oltre ovviamente ai sistemi di analisi di terze parti, alla storicizzazione dei dati ad esempio sul Data Warehouse di SQL Azure, o a tante altre soluzioni di analisi più o meno custom che possiamo andare a scrivere. Qui ovviamente siamo negli scenari BigData, dove andiamo a gestire una grande mole di dati in continua crescita ad alta velocità

Presto un prosieguo con cui vedremo pezzo dopo pezzo tutte queste soluzioni