Ciao a tutti

ebbene si… nel mentre che aspettiamo che l’Azure IoT Edge SDK venga rilasciata in GA, o almeno in open preview, diciamo 2 paroline sul “di cosa si sta parlando”

Il mondo IoT è un mondo fantastico. Forse è la prima volta che ne parlo. Esiste il retail, droni e sensori associati, il research e l’embedded (industriale), pochi droni, sensori di ogni tipo (e tanti), campionatori analogici, oscilloscopi digitali, analizzatori di quello che vogliamo, gateway da PLC o CNC, prodotti già pronti di campionatura per la ormai ubiqua PredictiveMaintenance e sensori vari tutti che sparano in uno dei formati standard (AMQP, MQTT, etc) o non standard direttamente su Azure in uno dei tanti modi (tipicamente IoT Hub & Friends) cui seguono una marea di cose

L’argomento del giorno, però, sono Fog Computing ed Edge Computing.

Esistono tanti scenari IoT…. se facciamo ad esempio Predictive Maintenance, ci interessa “loggare” i dati…. in genere si usa dire “campionare dati di telemetria” per dire ogni variabile che descrive la meccanica della cosa che vogliamo campionare… In questo caso, non esiste logica da eseguire da qualche parte…. non è che se un sensore vede la temperatura di un motore a 150°C fa qualcosa…. logga e basta

Esiste invece lo scenario in cui l’IoT è usato non per telemetria, ma per un sistema di controllo. In questo caso, magari si campioniamo anche per analisi future e per audit, ma in realtà al sensore è associata una logica (magari con parametri) che tipicamente viene analizzata su di un sistema in background in cloud (WebJob, WorkerRole, etc) che poi produce un eventuale messaggio di “azione” per appunto fare qualcosa: “notificare superamento soglia”, “attivare qualche cosa per risolvere il problema”, etc

In questi due scenari le necessità sono ovviamente diversissime. Mentre nel primo i dati vengono in genere salvati in best-effort (se perdo un pacchetto non capita nulla, anche se non capita quasi mai – se li elaboro dopo 30 secondi non succede nulla, questo invece capita spesso), nel secondo caso la bassa latenza è un requisito importante. Spostando la logica di analisi in un punto più vicino al sensore (il cloud spesso è lontano, nel senso della latenza di elaborazione e risposta) ovviamente andiamo a risparmiare secondi preziosissimi

Il Fog Computing è un’architettura aperta di esecuzione collaborativa di funzioni. In altre parole, è un Grid Computing collaborativo, peer-to-peer, asimmetrico, ed in genere o open source o almeno su standard open per appunto garantire la collaborazione. Pagina WIKI qui

Nel nostro caso, e seguendo il principio della Fog Computing, andremo a decidere di spostare l’elaborazione della logica del nostro sensore, non più nella nuvola (il cloud) ma nella nebbia (il Fog) che rappresenta la locale capacità collaborativa di elaborazione, che può essere un gruppo locale di sistemi di controllo (mini PC, VM con dentro i nostri micro servizi, o quello che ci pare). Quando però ci si è posti il problema del “dove” mettere questa logica quando si parla di sensori IoT, si è pensato bene di usare il sensore stesso, rendendolo un attimino più capace (SO più evoluto, CPU più potente, etc) ed intelligente.

Eccoci arrivati all’Edge Computing, l’architettura dove appunto si sposta la logica di controllo direttamente all’estremo del nostro design architetturale, che è appunto il sensore stesso. Esistono vari design: il sensore ad esempio può attivare una pre-logica ed attendere la risposta definitiva dal cloud, oppure può decidere tutto da solo. Nel nostro esempio, se un sensore dichiara un motore a 150°C, immediatamente attiva dei sistemi di raffreddamento.

Gli aspetti critici dell’architettura sono la capacità di aggiornare detta logica, la capacità di sincronizzare la logica in tutti i sensori, la limitatezza delle possibilità di lavorare in un sistema estremamente ridotto in termini di capacità di calcolo e funzionalità della SDK. D’altro canto, superati queste limitazioni abbiamo tantissimi pro: latenza quasi zero tra acquisizione del dato e esecuzione della logica di controllo necessaria, scalabilità virtualmente perfetta perché ad ogni aggiunta di sensore aumentano anche i nodi di elaborazione, ridotti costi di networking grazie al ridotto numero di transazioni di messaggistica da/per il cloud e ridotto consumo di risorse di calcolo sul cloud. Pagina WIKI qui

Fortunatamente per noi, Microsoft è sulla strada del rilascio di IoT Edge che ci darà modo di lavorare con questo sistema comodamente nel nostro ambiente cloud preferito con il nostro linguaggio preferito.

Presto farò un articolo completo sulla sua programmazione. Come si dice sempre: stay tuned