Tesi Laurea I Livello - Vaiano

UNIVERSITÀ DEGLI STUDI DI NAPOLI
FEDERICO II
Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato nale in Reti di Calcolatori
Tecnologie FaaS (Function as a Service) in
contesti di Edge Computing
candidato
Marco Vaiano
matr. N46001236
Anno accademico 2019/2020

Indice
Introduzione 1
1 Edge Computing 3
1.1 Da Cloud a Edge 3
1.2 Architettura Edge Computing 5
1.3 Legame con l'IoT 7
1.4 Casi d'uso 8
1.5 Limiti e problemi dell'architettura 10
2 Architettura Serverless 11
2.1 Function as a Service 11
2.2 Legame con l'Edge Computing 13
2.3 Tipologie di FaaS in commercio 13
2.4 Alcuni casi d'uso Edge IoT FaaS 14
3 Sviluppo di un FaaS in Edge Computing 16
3.1 Descrizione della piattaforma 16
3.2 Le risorse 17
3.3 FaaS su IoT Edge-based 21
3.4 Archiviazione su database distribuito 26
Conclusioni 30
Bibliograa 32
I

Corso di Laurea in Ingegneria Informatica Tecnologie FaaS in contesti di Edge Computing
Introduzione
L'evoluzione di internet ha toccato tutto ciò che ci circonda. Gli oggetti
(le cose) acquisiscono intelligenza e riescono a comunicare dati sulla
rete. Questi oggetti si deniscono smart objects e si contraddistinguono
per alcune proprietà e funzionalità. Il paradigma denito IoT, ovve-
ro Internet delle Cose, è fonte signicativa di dati i quali devono essere
gestiti richiedendo un'architettura che consenta di elaborare tutte le in-
formazioni provenienti dagli oggetti connessi.
A supporto di questa innovazione è emerso il cloud computing grazie alle
sue capacità di archiviazione ed elaborazione dei dati disponendo di gros-
si data center dotati di risorse virtualmente illimitate e resi disponibili
dai providers attraverso connessioni protette. L'enorme mole di dati vie-
ne così inviata a questi server per poi eettuare speciche elaborazioni.
Col tempo però sono emersi i limiti di questo modello, specie per alcune
applicazioni. Spesso i data center sono posti in luoghi molto lontani ri-
spetto ai dispositivi IoT con i quali si interfacciano pertanto si potrebbe
avere una considerevole latenza tra end user e cloud server. Questa ar-
chitettura può rappresentare un problema nel caso in cui l'elaborazione
deve necessariamente essere fatta in tempo reale, se pensiamo ad esempio
all'individuazione di soggetti sospetti all'interno di un aeroporto.
Tale dicoltà ha portato allo sviluppo dell' Edge Computing nel quale
vengono accorciate le distanze tra il luogo dove vengono prodotte le in-
formazioni e quello nel quale vengono memorizzate, attraverso particolari
nodi chiamati edge.
Nel paradigma Edge Computing troveremo quindi alcuni dispositivi chia-
mati cloudlet server ed edge nodes i quali posti sul perimetro della rete
sono in grado di orire servizi come quelli nel modello Cloud Computing
ma col vantaggio di avere un minore tempo di risposta, una maggiore
scalabilità e supporto all'eterogeneità del sistema.
1

In questo elaborato di tesi si metteranno in evidenza i limiti dell'infra-
struttura Cloud e la soluzione che ha portato allo sviluppo dell'Edge
Computing ponendo particolare attenzione sull'integrazione con il para-
digma Internet of Thing.
Si deniranno poi particolari tecnologie chiamate FaaS che consentono di
sviluppare, eseguire e gestire le funzionalità delle applicazioni svincolando
il programmatore dalle problematiche relative alla manutenzione dell'in-
frastruttura tipicamente associata allo sviluppo e al lancio di un'app. La
creazione di un'applicazione seguendo questo paradigma rientra nell'ar-
chitettura denita serverless e viene generalmente usata per la crea-
zione di microservizi.
Nell'ambito dell'Edge Computing, questo strumento può essere molto
utile in quanto risulta possibile eseguire operazioni ai margini della rete
che altrimenti sarebbero particolarmente laboriose per essere svolte da
un dispositivo IoT con limitate capacità di calcolo, oppure per implemen-
tare algoritmi di ltraggio dei dati generati dai sensori al ne di ridurne
la quantità da inviare nel Cloud.
In tal senso sarà descritta l'implementazione di un caso d'uso mediante la
piattaforma Microsoft Azure. In particolare si tratterà il controllo di al-
cuni parametri quali la temperatura e umidità di un ambiente attraverso
un sensore simulato collegato ad un dispositivo Edge posto sul perimetro
della rete il quale consentirà di eettuare un pre-processing sui dati pri-
ma di inviarli nel Cloud per la memorizzazione su un database distribuito.
2

Capitolo 1
Edge Computing
In questo capitolo verrà descritta brevemente l'architettura Cloud Computing e
evidenziati i limiti che hanno portato alla denizione di un nuovo paradigma de-
nominato Edge Computing (paragrafo 1.1).
Si approfondirà quindi l'architettura Edge (paragrafo 1.2), il legame con l'IoT
(paragrafo 1.3) descrivendone alcuni casi d'uso (paragrafo 1.4). Saranno inne
delineati i limiti e problemi di questo modello (paragrafo 1.5).
1.1 Da Cloud a Edge
Figura 1.1 Modello di un Cloud Computing
Il concetto di Cloud Computing è relativamente nuovo, maturato negli
ultimi dieci anni. Secondo il National Institute of Standards and Tech-
nology (NIST), il Cloud Computing è un modello che consente l'accesso
attraverso la rete, di risorse informatiche congurabili come ad esempio
reti di server, applicazioni e servizi, i quali possono essere rapidamente
diusi tra gli utenti con il minimo sforzo di gestione o interazione con i
provider. Questo modello usa concetti di virtualizzazione, potenza di cal-
colo, connettività per condividere un pool di risorse tra i vari dispositivi
3

presenti nella rete globale. Grazie a questo modello abbiamo la possibili-
tà di virtualizzare parti di risorse, centralizzare la potenza di calcolo per
orire un accesso eciente alle risorse con un costo di gestione sostan-
zialmente basso. Una delle risorse oerte dai cloud è quella comunemente
denominata storage, ovvero la memorizzazione di dati e applicazioni.
In un ambiente cloud computing, le risorse assegnate non sono condivise
e accessibili tra i vari clienti del provider ma virtualmente isolate tra loro
per garantirne la riservatezza. Le risorse Cloud sono sempre disponibili,
possono essere attivate in pochi minuti e soprattutto sono controllabili
da remoto in qualunque momento e da qualsiasi luogo massimizzando la
produttività dell'utente che ne richiede l'uso. In generale un ambiente
cloud può essere privato, pubblico, ibrido o community a seconda del-
l'accessibilità oerta.
I cloud pubblici orono servizi on-demand gratuitamente, o a paga-
Figura 1.2 Tipologie di Cloud
mento (pay-per-use), attraverso un pool di risorse di elaborazione reso
disponibile a tutti i suoi utenti. L'adozione di un modello pay-per-use
prevede il pagamento del servizio a consumo addebitando all'utente solo
le risorse eettivamente utilizzate. Tali cloud permettono alle aziende di
risparmiare sui costi di gestione e manutenzione di un'infrastruttura di
applicazioni e hardware locale riducendo notevolmente gli investimenti
iniziali. Il provider dei servizi cloud sarà responsabile di tutte le attività
legate alla gestione e manutenzione del sistema. Tra i cloud pubblici
più conosciuti troviamo AWS di Amazon, Google Cloud Platform, IBM
4

Cloud e Microsoft Azure. Questi ambienti cloud sorono però di proble-
mi relativi alla sicurezza dei dati. Quando un utente carica dati sensibili
su una piattaforma cloud pubblica, crescono i rischi relativi al controllo
degli accessi a queste informazioni. I cloud privati sono stati introdotti
per distribuire i servizi oerti solo ad un ristretto gruppo di clienti ga-
rantendo una maggiore sicurezza e riservatezza dei dati. Per cogliere i
pregi di queste due tipologie, ovvero la essibilità dei cloud pubblico e
l'adabilità di quelli privati, si sono sviluppati i cloud privati virtuali,
oerti dai provider cloud pubblici isolando una parte del cloud e ren-
dendo limitatamente accessibili le risorse considivise. Potrebbe capitare
che alcune aziende abbiano la necessità di memorizzare dati e condivi-
derli tra loro in un ambiente cloud privato. In questo caso parleremo di
Community clouds che possono essere parte di un cloud pubblico. Nei
cloud ibridi avremo invece un miglioramento dell'ecienza ottimizzando
le risorse disponibili nei cloud pubblici e privati. Vengono oerti diversi
livelli di sicurezza e privacy per le risorse condivise tra gli utenti. Finché
si tratta di accedere alle informazioni, visualizzarle ed elaborarle, la solu-
zione con server centralizzato andrebbe bene, ma se si pensa ad esempio
al caso in cui dobbiamo prendere delle decisioni in tempi brevi in base ai
valori rilevati da determinati sensori, comprendiamo i limiti del modello
basato su cloud. Il Cloud Computing ha pertanto come caratteristica
di base lo sviluppo di enormi data center centralizzati e talvolta molto
distanti dall'utente. Il paradigma Edge Computing è invece un modello
emergente che si presenta completamente opposto al Cloud Computing:
l'infrastruttura è distribuita e quindi decetralizzata, formata da tante
unità di calcolo denominate edge nodes. Se nel modello Cloud le risor-
se venivano fornite attraverso un' infrastruttura centralizzata distante
dal cliente, con l'Edge Computing tali distanze si accorciano in modo
signicativo e la potenza di elaborazione si troverà nelle vicinanze di chi
richiede il servizio.
1.2 Architettura Edge Computing
I principi dell'Edge Computing possono essere messi in pratica in diver-
si modi, in termini di dispositivi, protocolli di comunicazione e servizi.
5

Ad esempio nel Mobile Cloud Computing e Cloudlet Computing (MCC),
l'idea di base è di delegare l'archiviazione e calcolo provenienti dai dispo-
sitivi mobili a entità remote al ne di ridurre il carico di lavoro e otti-
mizzare il consumo energetico. Questo concetto fu adottato inizialmente
nell'ambito dei cloud ma oggi è stato ampliato pensando al paradigma
Edge. La visione odierna è pertanto quella di delegare l'elaborazione e
archiviazione dei dati ai dispositivi situati ai margini della rete anziché
nel Cloud.
L'architettura Edge Computing viene generalmente divisa in livelli nel
Figura 1.3 Architettura Edge Computing
quale troveranno posto nuovi elementi di rete. Nel livello cloud la po-
tenza computazionale e capacità di memorizzazione sono virtualmentre
illimitate, però la latenza è molto elevata. I nodi Edge conosciuti an-
che come downstream, saranno posizionati entro l'ultimo miglio della
rete. Questi dispositivi possono instradare il traco di rete e sono ca-
ratterizzati da una discreta capacità di elaborazione. Gli Edge Gateway
sono simili ai nodi però meno performanti. Dispositivi in questo livello
eettuano sostanzialmente una traduzione dei messaggi per i dispositivi
ai livelli più bassi. Inne troviamo gli Edge Devices, ovvero tutti i dispo-
sitivi con risorse limitate come ad esempio sensori o sistemi embedded.
Questi sono spesso realizzati per eettuare un solo tipo di elaborazio-
ne e sono dotati di ridotte capacità di comunicazione. Qui troveremo
6

smartwatch, semafori o sensori ambientali. Le implementazioni del mo-
dello Edge Computing hanno tutti l'obiettivo di estendere la capacità del
cloud sul perimetro della rete orendo vantaggi quali bassa latenza, ele-
vata scalabilità e supporto alla mobilità. Spesso Edge Computing viene
confuso con un altro modello chiamato Fog Computing. Sono entrambe
tecnologie basate sull'elaborazione dei dati in prossimità della fonte. La
dierenza tra i due risiede proprio nella collocazione dell'unità di elabo-
razione. Nel Fog Computing è situata all'interno della rete locale, dove i
dati prelevati dai vari sensori vengono elaborati da un nodo fog, mentre
nel caso dell'Edge Computing, l'elaborazione è integrata nei dispositivi
e piattaforme embedded avvicinandola ulteriormente all'origine dei dati
con una soluzione meno centralizzata rispetto alla precedente. Oltre alla
riduzione del tempo di risposta, il costo per l'utilizzo dei data center è
notevolmente ridotto selezionando i nodi come server Edge. Viene ridot-
to il traco sulla rete generando minore congestione. Migliora quindi
sensibilmente il QoS (Quality of Service) minimizzando il trasferimento
dei dati su lunghe distanze. Si riscontrano vantaggi anche dal punto di
vista della sicurezza, i dati sensibili potranno così essere elaborati all'in-
terno della rete attraverso i nodi edge evitando che vengano inviati sul
cloud.
1.3 Legame con l'IoT
Figura 1.4 Elementi a supporto dell'IoT
7

La visione dell'Internet of Things (IoT) si è largamente diusa coin-
volgendo un ingente numero di dispositivi interconnessi. Vengono ge-
nerate enormi quantità di dati e oerti numerosi servizi. I dispositivi
collegati possono essere sensori, attuatori, smartphone, apparecchi per
la casa, automobili i quali acquisiscono intelligenza grazie alla possibilità
di poter comunicare dati ed interagire con l'ambiente esterno. Gli smart
objects rappresentano tutto ciò che può essere collegato, monitorato o at-
tivato da remoto. Si contraddistinguono per alcune proprietà e funziona-
lità: identicazione, connessione, localizzazione. Nel settore industriale
rappresenta una notevole innovazione in quanto si ha la possibilità di con-
trollare gli apparati da remoto senza dover necessariamente prevedere un
intervento locale. Questi dispositivi sono inoltre caratterizzati da ridotte
capacità di calcolo e limiti energetici dovuti all'alimentazione a batterie,
pertanto si è rapidamente diuso il concetto di adare l'elaborazione
a risorse presenti nel Cloud o a dispositivi posti in prossimità, come nel
caso del modello Edge. Sono inoltre richiesti requisiti come QoS (Quality
of Service) e tempi di risposta bassi fondamentali per alcune speciche
applicazioni. Nel caso di un sistema Cloud dove l'infrastruttura è cen-
tralizzata, l'elaborazione dei dati può essere però compromessa a causa
di un sovraccarico della rete generando di conseguenza elevati tempi di
risposta. Con il paradigma Edge, la capacità di elaborazione viene invece
spinta al limite della rete con dispositivi performanti e collegati alla rete
elettrica, migliorando sensibilmente i tempi di latenza e riducendo così il
traco generato. L'architettura Edge Computing è in grado di ridurre la
mole di dati generati dai dispositivi IoT da inviare nel cloud elaborando
i dati critici sensibili alla latenza nel punto di origine attraverso un di-
spositivo situato in prossimità dei sensori. I dati meno sensibili al tempo
potranno invece essere direttamente trasmessi al Cloud per eettuare ad
esempio uno storage a lungo termine per poi eseguire l'analisi di dati
storici.
1.4 Casi d'uso
Ci sono una serie di beneci che la tecnologia edge comptuting porta ad
aziende e utenti nali. Svariate attività economiche richiedono un'elabo-
razione in tempo reale dei dati: dalla produzione di petrolio e gas sino alle
8

banche, passando per le tradizionali vendite. Anche telecamere di sicu-
rezza, smartphone, termostati, auto e televisori creano dati che possono
essere estratti ed analizzati proprio grazie a questo modello, ma diventa
soprattutto utile per la telemetria, quindi per eettuare misurazioni a
distanza, oppure per rilevare guasti sui macchinari prima di ogni altra
analisi. I videogiochi con realtà aumentata rappresentano un mercato
in notevole crescita. Tuttavia i limiti di archiviazione e di elaborazione
hanno rallentato la diusione di questo tipo di applicazioni. L'infrastrut-
tura di Internet attuale non è ancora pronta a causa di restrizioni della
larghezza di banda della rete e latenza eccessiva causata dalla distanza
geograca dell'infrastruttura dove hanno origine i dati. Con l'adozione
del paradigma Edge i dati viaggiano per una distanza breve ottenendo
una migliore esperienza di gioco. Nel settore elettrico può essere invece
usato per ridurre perdite di potenza delle apparecchiature rendendole più
adabili ed ecienti. Nel settore dei trasporti esistono applicazioni che
consentono ad esempio di aiutare gli utenti a trovare parcheggio grazie
all'analisi dei dati in tempo reale. Anche per quanto concerne i dro-
ni, spesso utilizzati per raggiungere luoghi inaccessibili per operazioni di
soccorso, può essere estremamente utile trasmettere le informazioni nel
minore tempo possibile. Altri esempi applicativi possiamo trovarli nell'E-
Health per la realizzazione di servizi che consentono il monitoraggio e lo
scambio in tempo reale dei dati del paziente. Alcuni di questi dispositivi
possono automaticamente, a seguito del rilevamento dei parametri vitali
del paziente, richiedere l'intervento degli operatori sanitari. Tali disposi-
tivi medici intelligenti richiedono una infrastruttura resistente ai guasti
e in grado di ridurre i ritardi nella comunicazione. Problemi di questo
tipo se non arontati nel modo giusto possono causare lesioni o addirit-
tura la morte dei pazienti. È dunque fondamentale che ci sia una bassa
latenza. L'infrastruttura Edge Computing risulta vitale per il rispetto
di questo requisito. Inne nel settore dell'automotive, se pensiamo alle
auto a guida autonoma, è necessario prendere rapide decisioni basandosi
sui dati provenienti dai sensori di rilevamento degli ostacoli quali veicoli
e pedoni. Anche questo caso un'elevata latenza del messaggio non può
essere assolutamente ammessa.
9

1.5 Limiti e problemi dell'architettura
Con il modello Edge Computing il usso di dati si sposterà quindi verso
il margine della rete. Tendenzialmente i providers assegnano una banda
maggiore ai Data Center mentre una inferiore agli endpoint. Una delle
sde di questo modello è riuscire a bilanciare la quantità di dati scambiati
attraverso la rete. Il usso non sarà più unidirezionale verso il cloud ma i
dati attraverseranno la rete in ogni direzione riducendone la controllabi-
lità. Mentre nel caso di Cloud Computing, le aziende provider dei servizi
potevano concentrarsi sulla sicurezza di un determinato Data Center ben
localizzato, nel modello edge bisognerà garantire tale sicurezza per ogni
nodo che appartiene all'architettura di rete. La sda pertanto sarà quella
di garantire la sicurezza ovunque nella rete. Garantire la consistenza dei
dati sui nodi edge rappresenta un'altra sda di questo modello. Risulta
necessario determinare se i dati già presenti siano adabili in quanto
potrebbe capitare che uno di questi sia temporaneamente non disponi-
bile e pertanto potrebbe perdere ad esempio le più recenti misurazioni
provenienti dai sensori. Una delle soluzioni potrebbe essere quella di
distribuire i dati tra i vari nodi creando una ridondanza, migliorando
quindi l'adabilità e disponibilità dei dati archiviati. Uno dei punti cri-
tici risiede proprio nell'impiego dell'IoT che di natura sono dispositivi che
scambiano dati senza eettuare alcun controllo di sicurezza. È pertanto
necessario mappare questi dispositivi autorizzandoli ed escludendoli dal-
la rete in base alle loro caratteristiche di sicurezza attraverso un gateway
edge che funziona come una sorta di rewall tra IoT e rete aziendale.
Con una comunicazione diretta e sicura, agevolata dai pochi passaggi tra
IoT e gateway edge, riduciamo il rischio di alterazione dei dati (ad es.
attacchi Man in the middle) e visto che parte dell'elaborazione avviene
a livello edge si riduce anche lo scambio di dati con il Cloud trasferen-
do solo quelli necessari alle applicazioni che girano su di esso. Risulta
in ogni caso necessario che questi problemi vengano arontati in fase di
progettazione in quanto sono sempre più frequenti applicazioni IoT nel
modello edge che riguardano settori sensibili, come quello dell'E-Health
descritto nel paragrafo precedente, nel quale non sono ammessi errori.
10

Capitolo 2
Architettura Serverless
Si denisce Serverless un modello di progettazione software nel quale
le applicazioni sono sviluppate senza che si tenga conto degli aspetti di
gestione e manutenzione dell'hardware sul quale vengono eseguite. Le
applicazioni sono divise in singole funzioni che possono essere invocate e
scalate individualmente. In questo capitolo si approfondirà tutto ciò che
riguarda questa architettura (paragrafo 2.1) ponendo particolare atten-
zione sull'implementazione nel contesto degli Edge Computing (paragrafo
2.2). Si farà inne riferimento ad alcune soluzioni presenti in commercio
(paragrafo 2.3) e saranno descritti alcuni casi d'uso (paragrafo 2.4).
2.1 Function as a Service
L'elaborazione serverless è principalmente associata a due concetti: ap-
plicazioni che si adano a servizi cloud di terze parti per la gestione di
una determinata elaborazione noti anche come BaaS (Background as a
Service) e applicazioni la cui logica è scritta da sviluppatori software ma
eseguite in un contesto senza stato e attivati a seguito di eventi (event-
triggered), noti anche come FaaS (Function as a Service). Il modello
Function as a Service implementa un'architettura Serverless consenten-
do alle applicazioni, scritte come funzioni prive di stato, di essere eseguite
in ambienti precostituiti senza dover preallocare le risorse. Questa logica
di sviluppo vede le applicazioni come funzioni indipendenti, scritte in va-
ri linguaggi di programmazione e distribuite come funzioni web. Quando
si richiama una funzione di questo tipo, l'utente la esegue attraverso un
contenitore che la lega alle sue dipendenze (moduli, librerie e altre ri-
sorse). I contenitori possono essere riutilizzati (warm container) o essere
11

generati di volta in volta come nuovi (cold container). Il riutilizzo dei
contenitori ha come vantaggio quello di ridurre il sovraccarico per l'inizia-
lizzazione delle risorse. Il modello FaaS assicura che le risorse (memoria,
CPU) siano allocate quando eettivamente necessarie. Mentre nel ca-
so di macchine virtuali, spesso usate nei modelli cloud, si consente alle
applicazioni di condividere risorse siche, le piattaforme FaaS sfruttano
invece i containers per orire diversi vantaggi: ad esempio un singolo
sistema operativo può essere condiviso tra più istanze container per di-
verse funzioni, le risorse utilizzate vengono ridimensionate in base alla
risposta al carico di lavoro. Le piattaforme FaaS attualmente in com-
mercio consentono agli utenti di specicare la capacità di memoria da
utilizzare in un intervallo di tempo predenito. Queste caratteristiche
hanno come risultato un uso più eciente delle risorse computazionali
che è particolarmente vantaggioso per far fronte ad esempio alle limitate
capacità dei nodi edge.
La soluzione Serverless costa meno: di solito un server dedicato (o
Figura 2.1 Confronto richieste e uso eettivo di una macchina virtuale
condiviso) viene pagato per la sua attività 24 ore su 24, ma avendo dei
carichi computazionali dierenti (gura 2.1) in base a diversi fattori, sa-
remo costretti a dimensionarlo basandoci sui picchi maggiori (worst-case)
ed avere così risorse inutilizzate per il resto del tempo. Con la tecnologia
Serverless invece si acquisiranno le risorse in funzione della domanda ed
essendo una soluzione di outsourcing, ci si aderà ad un provider il quale
sarà preposto alla gestione del server, database e logiche applicative che
altrimenti avremmo dovuto gestire da soli.
12

2.2 Legame con l'Edge Computing
Una piattaforma serverless edge deve soddisfare innanzitutto i requisiti
di bassa latenza. L'overhead dovrà essere ridotto il più possibile consen-
tendo ai client di attivare l'esecuzione parallela di funzioni mantenendo
adeguati i tempi di risposta. Gli sviluppatori dovranno pertanto conca-
tenare le chiamate di funzioni individuando specici legami oppure inte-
grare diverse funzioni in un'unica. Quest'ultima soluzione potrebbe però
portare ad un problema di costo da parte del chiamante il quale dovrà at-
tendere un tempo maggiore prima di poter proseguire la sua esecuzione.
Un importante motivo dell'uso dei FaaS nel contesto Edge è la necessità
di anticipare l'elaborazione e analisi dei dati prodotti dalle applicazioni
ai margini della rete. Ad esempio nel contesto IoT e delle smart cities,
un'applicazione di riconoscimento facciale si basa su funzioni ad elevato
usso di dati per identicare soggetti sospetti. Queste funzioni compon-
gono il lavoro svolto da un'applicazione di videosorveglianza dove dai
frame ricevuti vengono estratti i tratti di viso e confrontati con un set di
dati esistente, lavoro che potrebbe essere svolto da funzioni attivate sui
nodi edge a seguito di eventi trigger. Un altro scenario, come già antici-
pato nel capitolo precedente, riguarda le autovetture a guida autonoma.
In questi veicoli c'è la necessità di avere notiche in tempo reale sugli
eventi anomali al ne di prevedere e prevenire collisioni. In questo caso
vengono oerti dei servizi noti come P/S service (Publish-Subscribe)
i quali consentono ai dispositivi IoT (es. sensori) che compongono una
vettura di attivare diverse funzionalità in risposta a determinati eventi.
Alcuni di queste possono allertare i soccorsi a seguito di un incidente
rilevato dai sensori comunicando inoltre la posizione ottenuta dal mo-
dulo GPS. Il protocollo MQTT ore diversi livelli di adabilità a basso
impatto sulla banda, per la comunicazione tra questi dispositivi.
2.3 Tipologie di FaaS in commercio
L'idea di distribuire funzioni cloud sul perimetro della rete è una solu-
zione sempre più adottata dai diversi provider. I messaggi scambiati tra
i dispositivi e il cloud non attraversano più l'intera rete per raggiungere i
Data Center. Le funzioni possono essere eseguite sui nodi Edge per una
13

prima elaborazione in tempo reale. Questi nodi possono trovarsi nella
stessa rete locale dove hanno origine i dati oppure vengono diusi dai
providers in diverse aree geograche al ne di avvicinare il più possibile
le elaborazioni agli utenti. Uno degli esempi è dato dal provider Clou-
dFlare che con il suo servizio Workers consente di implementare dei
FaaS che utilizzano la rete globale CloudFlare orendo numerosi vantaggi
in termini di prestazioni. Stackpath è un'altra società che ore funzioni
Serverless in contesti edge. Gli sviluppatori possono scrivere funzioni che
vengono distribuite nella rete Stackpath garantendo uno startup time di
50ms rispetto agli 800ms di AWS Lambda. Amazon Web Services, noto
anche con l'acronimo AWS ore un servizio cloud serverless denominato
Lambda dalla ne del 2014. I suoi servizi sono operativi in 20 aree
geograche garantendo high availability, redundancy e sicurezza il
cui costo deriva dalla combinazione di tipo e quantità di risorse utilizzate
e scelte dall'utente usando un modello Pay-as-you-go. Per accelerare
l'adozione Serverless, AWS ha presentato un repository sulla nota piat-
taforma di condivisione progetti GitHub attraverso il quale i suoi clienti
possono condividere le applicazioni da loro implementate. AWS inoltre
supporta numerosi linguaggi di programmazioni quali Java, JS, Node.JS.
Inne tra i più noti troviamo anche Microsoft che con Azure Functions
ore un approccio paragonabile a quello di Amazon Lambda. Il servizio
FaaS di Microsoft consente di attivare funzioni a servizi Azure: Cosmos
DB, Event Grid, o di terze parti. Azure Functions supporta C#, F#, Ja-
vascript, Python. Quest'ultima piattaforma verrà discussa nel Capitolo
3 con la realizzazione di un caso d'uso.
2.4 Alcuni casi d'uso Edge IoT FaaS
Uno degli scenari applicativi delle tecnologie descritte nei precedenti pa-
ragra potrebbe essere quello di eettuare un pre-processing e monitorag-
gio sul perimetro della rete di alcuni dati provenienti dai sensori. Queste
elaborazioni possono essere eettuate tramite FaaS richiamate su piccoli
computer industriali che in questo caso costituiranno la parte edge del
modello. Un esempio in tal senso potrebbe riguardare la gestione di una
rete di gasdotti. Molti dei compressori si trovano in zone remote e do-
vrebbero essere costantemente monitorati in maniera del tutto manuale
14

richiedendo l'intervento locale di un tecnico. Inoltre in alcuni dei casi
la logica di controllo è implementata su sistemi embedded con software
proprietario rendendola poco essibile ad eventuali modiche per il quale
è necessario l'intervento di un utente programmatore. Risulta evidente
che lo sviluppo e manutenzione di questo tipo di apparati siano partico-
larmente dispendiosi. Al contrario, un monitoraggio e controllo remoto
mediante l'uso di FaaS in Edge Computing consentirebbe di avere una
notevole riduzione dei costi e complessità di realizzazione delle funzioni
sui quali implementare le speciche logiche di controllo. Un altro caso
d'uso di rilievo potrebbe essere quello di implementare una sorta di ltro
delle richieste web provenienti da diverse aree geograche. Si pensi ad
esempio ai servizi netix oerti negli U.S.A. ma non accessibili in altri
paesi.
1 addEventListener('fetch', event = {
2 event.respondWith(fetchAndApply(event.request))
3 })
4
5 async function fetchAndApply(request) {
6 if (request.headers.get('x−sp−server−countrycode') == 'US') {
7 return new Response('Hello, welcome to our service',
8 { status: 200 })
9
10 }
11 else {
12 return new Response('Sorry, we do not oer service outside
13 the USA at this time',
14 { status: 200 })
15 }
16
17 return fetch(request)
18 }
( Fonte: https://www.stackpath.com/edge-academy/faas/ )
In questo codice d'esempio implementato attraverso il servizio oerto da
Stackpath, si ottiene una semplice funzione che restituisce due messag-
gi diversi a seconda che la richiesta provenga o meno dagli Stati Uniti.
Nello specico, la funzione cattura la richiesta proveniente dal protocollo
HTTP, ne estrae l'header e legge il contenuto dell'attributo countryco-
de. In base a questo valore si distinguerà la provenienza della richiesta
per poi ritornare al chiamante una specica risposta.
15

Capitolo 3
Sviluppo di un FaaS in Edge Computing
In questo capitolo si descriverà l'implementazione di un caso d'uso del-
la tecnologia FaaS in un contesto Edge Computing utilizzando la nota
piattaforma Microsoft Azure. Grazie ad una partnership con l'ateneo e
ad un programma di prova per nuovi clienti Azure, Microsoft ore una
cospicua somma di denaro con la quale risulta possibile testare le po-
tenzialità degli strumenti cloud messi a disposizione. In questo modo è
stato possibile realizzare quanto descritto nel corso di questo capitolo.
Nello specico si svilupperà un sistema di controllo della temperatura
e umidità ambientale generati da un sensore simulato. I dati prelevati
e successivamente ltrati attraverso un dispositivo IoT Edge, verranno
memorizzati in un database distribuito.
3.1 Descrizione della piattaforma
Figura 3.1 Architettura IoT Edge di Microsoft Azure
Microsoft Azure dispone di innumerevoli funzioni e servizi messi a
disposizione dello sviluppatore attraverso un meccanismo pay-as-you-go
16

dove il costo è commisurato alle risorse eettivamente utilizzate. Il porta-
le è facilmente accessibile utilizzando qualsiasi browser ed inoltre dispone
di un'applicazione per il controllo da remoto attraverso dispositivi mobi-
li. In questo caso, visto che si andrà a realizzare un'elaborazione Edge,
si utilizzerà una specica piattaforma denominata Azure IoT Edge la
quale rappresenta un'estensione della suite Azure IoT di Microsoft. Il
primo problema da arontare è senza dubbio quello di far comunicare
il dispositivo IoT con il mondo Cloud. Un servizio fondamentale in tal
senso è rappresentato da Azure IoT Hub il quale permette lo scambio di
messaggi da parte di chi li genera, come ad esempio i sensori per la te-
lemetria, e il cloud che invece invia segnali di controllo. Questo servizio,
già presente di default, consente di trascurare tutti gli aspetti relativi
la congurazione e interfacciamento tra IoT e cloud. Un altro elemento
fondamentale già introdotto nel capitolo precedente è il container che
consente di incapsulare le funzioni (FaaS) all'interno di un ambiente in-
dipendente e trasparente allo sviluppatore. Si andrà quindi a realizzare
un modello partendo da quello di riferimento presente nella documenta-
zione uciale (gura 3.1) il quale rappresenta una generica architettura
contenente edge, cloud e IoT. Si utilizzerà un IoT Edge Device, dispo-
sitivo che collegato al sensore (in questo caso simulato) preleverà i dati
e, attraverso una Azure Function opportunamente scritta in linguaggio
C# realizzerà un ltro che scarterà i campioni al di sotto di un certo
threshold. Nel modello che si andrà a sviluppare si avrà inoltre un'in-
terfacciamento con database distribuito Cosmos DB situato all'interno
del cloud Azure. Il dispositivo Edge IoT rappresenta un elemento chiave
in questa elaborazione e realizza appieno il concetto di Edge Computing.
Grazie ad esso si riuscirà a spostare all'interno della rete parte dell'ela-
borazione che altrimenti andrebbe fatta su Cloud, ottenendo dei notevoli
vantaggi. L'elaborazione di prossimità, in questo specico caso si tratte-
rà di un semplice ltro, sarà quasi immediata vista la vicinanza di tale
dispositivo nella stessa rete nel quale è incluso il sensore.
3.2 Le risorse
Si deniranno diversi elementi chiave all'interno dell'ecosistema Azure:
un registro contenitori per poter implementare le funzioni FaaS, una
17

macchina virtuale per l'esecuzione Edge, un modulo sensore simulato da
caricare all'interno del dispositivo Edge e un Hub IoT che accoglierà i
dati in arrivo sul cloud. Come prima cosa si è partiti istanziando un
Hub IoT e un registro contenitori. Una caratteristica particolare oerta
da Microsoft è quella di poter denire una precisa area geograca (tra
quelle disponibili) per ciascuna delle risorse che si andranno ad allocare
in modo da ottenere elaborazioni quanto più vicine all' utente e pertanto
più ecienti. Questa operazione di inizializzazione dei primi due elemen-
ti sopracitati può essere svolta in maniera del tutto intuitiva attraverso
l'interfaccia graca della dashboard di Azure. Si otterrà quindi un hub
al quale si è assegnato il nome HubIoTest e il registro contenitore col
nome RegContenitori. Al ne di raggruppare tutte le risorse siche si
denirà anche un gruppo di risorse test20 nell'ambiente di Microsoft.
Deniti gli elementi di base, si andrà adesso a modellare il sistema se-
Figura 3.2 Azure Cloud Shell: creazione macchina virtuale
condo l'architettura Edge descritta nel capitolo 1. La piattaforma mette
a disposizione le runtime necessarie a rendere un dispositivo (es. Rasp-
berry) come nodo Edge, oppure vi è la possibilità (a pagamento) di poter
utilizzare risorse virtuali dislocate in diverse aree geograche. La scelta
adoperata in questo caso ricade sull'utilizzo di una macchina virtuale sul
quale verranno installate sia le runtime edge che il modulo di simulazione
per la generazione di dati provenienti dai sensori. Si denirà pertanto
una macchina virtuale Azure IoT Edge on Ubuntu fornita con un siste-
18

ma di pagamento in base al tempo di utilizzo, che preinstalla gli elementi
necessari ad eseguire i servizi IoT Edge in un dispositivo. A dierenza
di quanto descritto prima, in questo caso l'inizializzazione avviene però
tramite Azure Cloud Shell, un meccanismo molto simile al terminal
dei sistemi Unix. Azure Cloud Shell è anch'essa accessibile attraverso
browser web senza dover necessariamente utilizzare specici software per
il controllo remoto. Si può notare (gura 3.2) come venga denita una
macchina virtuale nel nostro gruppo di risorse semplicemente utilizzando
il comando az vm create e denendo alcuni parametri di interesse. Si
sceglierà un nome (in questo caso MacchinaVirtualeEdge), si denirà
l'immagine preparata da Microsoft contenente il sistema operativo ed ele-
menti Azure già pronti all'utilizzo, username di accesso alla macchina e
inne le chiavi per poter eventualmente accedere tramite protocollo SSH.
Il comando completo che si eseguirà nella shell sarà il seguente: [az vm
create resource-group test20 name MacchinaVirtualeEdge image mi-
crosoft_iot_edge:iot_edge_vm_ubuntu:ubuntu_1604_edgeruntimeonly
:latest admin-username azureuser generate-ssh-keys]. In risposta il
cloud fornirà una serie di attributi utili: l'area geograca dove è stata
installata la macchina virtuale, il mac address dell'interfaccia di rete,
lo stato corrente, l'ip privato interno alla rete Microsoft e quello pubblico
per poter accedere da remoto.
Tutti i dispositivi sul quale sono eseguite le runtime di Azure saranno
Figura 3.3 Azure Cloud Shell: stringa di connessione
accessibili nel cloud mediante una stringa di connessione. Essa contie-
ne alcune informazioni come l'identicativo del dispositivo e la chiave
condivisa per l'accesso attraverso la rete Azure. Sarà pertanto fonda-
mentale ricavare la stringa relativa alla macchina virtuale appena creata
lanciando il comando: [az iot hub device-identity show-connection-string
device-id MacchinaVirtualeEdge hub-name HubIoTest], dove si andrà
19

a specicare il nome del dispositivo e il nome dell'Hub IoT denito nella
prima fase di sviluppo (gura 3.3). Occorre adesso eettuare un collega-
mento tra dispositivo IoT Edge appena creato e l'Hub IoT in modo da
far comunicare il dispositivo nel contesto cloud di Microsoft.
A tale scopo si dovrà innanzitutto denire un'identità del dispositivo
Figura 3.4 Azure Cloud Shell: identità dispositivo IoT Edge
IoT Edge presente nel cloud di Azure e, tramite la stringa di connessione
univoca del dispositivo (in questo caso una macchina virtuale) rilevata in
precedenza, si creerà un'associazione tra l'entità sica e quella logica. In
questa fase è importante segnalare che si sta generando un'identità di un
dispositivo con funzionalità Edge pertanto andrà indicato il ag [edge-
enabled]. Si eseguirà pertanto il seguente comando nella shell di Azure:
[az iot hub device-identity create hub-name HubIoTest device-id Mac-
chinaVirtualeEdge edge-enabled]. Analogamente a quanto ottenuto in
precedenza, anche qui il Cloud fornirà una serie di informazioni utili co-
me ad esempio il numero dei messaggi scambiati tra dispositivo e cloud,
stato di connessione, l'ultimo aggiornamento, ecc.
Occorre inne congurare la macchina virtuale associandola alla sua
identità cloud attraverso la relativa stringa di connessione recuperata
poc'anzi. Come per le altre operazioni eseguite da remoto, sarà anche
qui possibile operare da remoto senza agire localmente alla macchina
virtuale. Si eseguirà lo script congedge.sh il quale è stato copia-
to in automatico dall'immagine ubuntu durante la creazione della mac-
china virtuale dove è in esecuzione la runtime IoT Edge. Il comando:
20

Figura 3.5 Azure Cloud Shell: congurazione macchina virtuale Edge
[az vm run-command invoke -g IoTEdgeResources -n MacchinaVirtua-
leEdge command-id RunShellScript script /etc/iotedge/congedge.sh
'HostName=HubIoTest.azure-devices.net;DeviceId=MacchinaVirtualeEdge;Shared
+yRgV6yFIgvgq4TJp4rJI16IoRmq0JU/scZ0c0='] verrà pertanto ese-
guito attraverso la shell di Azure. Si noti che si è specicato il gruppo di
risorse creato nella prima fase di sviluppo col nome test20, il percorso
dello script da eseguire e la stringa di connessione del dispositivo. Come
risultato si è realizzato un ambiente Edge Computing nel quale è presen-
te un dispositivo Edge preposto all'elaborazione dei dati prima dell'invio
sul Cloud Azure.
3.3 FaaS su IoT Edge-based
In questo paragrafo si svilupperà il modulo Azure Function cogliendo i
vantaggi del modello Serverless descritto nel capitolo precedente. Esso
verrà richiamato all'interno del dispositivo Edge ogni volta che arrive-
rà un nuovo campione dal sensore. Nello specico, la funzione dovrà
ltrare tutti i campioni di temperatura prelevati scartando quelli al di
sotto di una soglia minima. In questo caso di sviluppo si stabilisce un
threshold pari a 20 gradi. Esistono diversi strumenti per implementare
funzioni Azure, nel corso di questo elaborato verranno analizzati i due
più signicativi partendo dall'ambiente di sviluppo Visual Studio Co-
de che grazie ad alcuni plugin tra i quali Azure e Docker, consente di
gestire facilmente l'intera architettura Edge. Si partirà innanzitutto dal-
la creazione del progetto Azure Function. E' possibile utilizzare svariati
linguaggi di programmazione, in questo caso si utilizzerà C#. É impor-
21

tante notare che per la creazione del progetto si deniranno le credenziali
di accesso al registro contenitori di Azure creato in precedenza in mo-
do da poter prelevare ed inserire i moduli sviluppati. In ambienti Unix
la gestione dei contenitori avviene attraverso una piattaforma chiamata
Docker. In questo caso si è preferito sviluppare il modulo in ambiente
Windows prevedendo di utilizzarlo invece sul nodo Edge nel quale è stata
caricata una macchina virtuale con sistema Ubuntu. Al ne di evitare
una incompatibilità tra la piattaforma origine e destinazione (target), si
andrà pertanto a specicare nell'ambiente di sviluppo che l'architettura
target è quella utilizzata per la macchina virtuale Linux. É possibile
denire questo parametro dalla console di Visual Studio Code dove vi è
la possibilità di scegliere tre diverse piattaforme target una delle quali
AMD64, la stessa utilizzata per la creazione della macchina virtuale
Ubuntu. I valori di temperatura e umidità simulata sono generati da un
apposito modulo scritto in C# già compilato e disponibile gratuitamente
nel Marketplace di Azure. Con questo modulo vengono sostanzialmen-
te generati dei campioni di temperatura e umidità prelevati ad intervalli
regolari, in maniera simile a quanto farebbe un sensore Bosh BME280.
Nello specico, il modulo simula valori che saranno relativi sia ad un
ipotetico dispositivo da monitorare che al suo ambiente circostante. Di
seguito si andrà invece a descrivere il codice del modulo che agirà da
ltro, direttamente implementato sul nodo edge.
1 ...
2 public static class ModuloFiltro
3 {
4 [FunctionName(ModuloFiltro)]
5 public static async Task FilterMessageAndSendMessage(
6 [EdgeHubTrigger(input1)] Message messageReceived,
7 [EdgeHub(OutputName = output1)] IAsyncCollectorMessage output)
8 {
9 ...
Creato un nuovo progetto Azure Function C#, l'ambiente di sviluppo
fornirà in automatico un modulo d'esempio che agisce semplicemente da
mirror, ovvero verrà stampato in console tutto ciò che arriva nel no-
do sul quale è caricato il modulo. In questa porzione di codice si andrà
quindi a denire il modulo della funzione e i parametri di instradamento
dei messaggi da e verso l'Hub IoT. Il processo di instradamento è fonda-
22

mentale perché consente di stabilire dove prelevare i dati che andranno
in input al modulo e dove inviare quelli in output. Questa operazione
viene eseguita tramite dashboard Azure. In particolare nel codice si nota
input1 che sarà il messaggio ricevuto dal modulo sensore e che funzio-
nerà da trigger facendo scattare l'esecuzione del modulo chiamato Mo-
duloFiltro. Viceversa output1 conterrà invece il messaggio generato
all'interno del modulo, ovvero il campione con temperatura d'ambiente
al di sopra dei 20 gradi, che verrà poi inviato sul Cloud Azure. La fun-
zione sarà di tipo async per evitare di bloccare il thread chiamante
eseguendo il modulo in maniera indipendente dal contesto.
1 ...
2 const int temperaturaLimite = 20;
3 byte[] messageBytes = messageReceived.GetBytes();
4 var messageString = System.Text.Encoding.UTF8.GetString(messageBytes);
5
6 if (!string.IsNullOrEmpty(messageString))
7 {
8 var messageBody = JsonConvert.DeserializeObjectMessageBody(messageString);
9 ...
Nel codice sopraelencato si denisce la temperatura di threshold e la
variabile che ospiterà il messaggio contenente il campione prelevato dal
modulo sensore. Il messaggio ricevuto in formato JSON attraverso la
variabile messageReceived viene così inserito in un array di tipo byte.
Al ne di rendere possibile un'elaborazione sugli attributi è fondamentale
convertire l'informazione ricevuta. In tal caso si eettuerà un casting da
byte a String per ottenere un tipo compatibile alla funzione di con-
versione su notazione JSON. Come appena citato, i messaggi scambiati
sul cloud utilizzano una notazione conosciuta con l'acronimo JSON (Ja-
vaScript Object Notation). Essa, come facilmente intuibile, si basa su un
sottoinsieme del linguaggio JavaScript ma nonostante ciò è un formato
di testo completamente indipendente dal linguaggio di programmazio-
ne pertanto sarà possibile utilizzarlo nella funzione FaaS scritta in C#.
La struttura di questa notazione si basa essenzialmente su un insieme di
coppie nome/valore. In alcuni linguaggi questa struttura viene realizzata
come un oggetto o semplicemente una struct anche se nella maggior
parte dei linguaggi si realizza con un array o vettore. Un oggetto denito
in JSON inizia e termina con una parentesi graa. Ogni nome è seguito
23

da due punti e la coppia nome/valore separata da una virgola. Il messag-
gio ricevuto in input viene quindi convertito in un oggetto compatibile
con il framework di riferimento .NET tramite apposita funzione Json-
Convert.DeserializeObject per consentire di eettuare le operazioni sui
dati, assicurandoci prima che tale valore non sia nullo. Si noti come venga
ridenita questa funzione su uno specico tipo MessageBody utilizzan-
do il meccanismo dei template. MessageBody rappresenta una classe
dove vengono denite le proprietà che ci aspetteremo dal messaggio (in
notazione JSON) proveniente dal modulo sensore.
1 ...
2 class MessageBody
3 {
4 public Machine machine {get; set;}
5 public Ambient ambient {get; set;}
6 public string timeCreated {get; set;}
7 }
8 class Machine
9 {
10 public double temperature {get; set;}
11 public double pressure {get; set;}
12 }
13 class Ambient
14 {
15 public double temperature {get; set;}
16 public int humidity {get; set;}
17 }
18 ...
Per conoscere le proprietà della classe MessageBody è stato fonda-
mentale analizzare prima il codice sorgente del modulo di simulazione
dei campioni di temperatura e umidità. Il codice sviluppato da Microsoft
per il sensore simulato è accessibile liberamente attraverso la piattaforma
GitHub.
1 ...
2
3 if ((messageBody != null) (messageBody.ambient.temperature temperaturaLimite))
4 {
5 using (var messaggioltrato = new Message(messageBytes))
6 {
7 foreach (KeyValuePairstring, string prop in messageReceived.Properties)
8 {messaggioltrato.Properties.Add(prop.Key, prop.Value);}
9 messaggioltrato.Properties.Add(TipoMessaggio, Allarme);
10 await output.AddAsync(messaggioltrato);
11 }
12 ...
24

Si andrà inne a sviluppare il codice relativo all'operazione di ltraggio
sui dati contenuti nei messaggi ricevuti dal nodo Edge. Con la prima
condizione si verica innanzitutto che il messaggio non sia vuoto. I dati
convertiti in precedenza ed inseriti nell'oggetto messageBody vengo-
no confrontati con il valore limite (costante) denito precedentemente.
In particolare il confronto sarà sulla temperatura rilevata nell'ambiente
dove è situato il sensore pertanto si utilizzerà l'attributo temperature
attraversando i membri dell'oggetto mediante l'operatore punto, no ad
arrivare alle proprietà relative l'ambiente. Viene poi istanziato un nuovo
oggetto di classe Message, classe denita di default dal linguaggio di
programmazione, al quale si assegnerà il messaggio prelevato in notazio-
ne JSON attraverso il suo costruttore e, scorrendo tutte le informazioni
attraverso il costrutto foreach, saranno aggiunti gli attributi del mes-
saggio originale e anche uno di allarme tenendo conto che nel nostro
caso stiamo ipotizzando di inoltrare i campioni solo se superiori ad una
precisa soglia critica per il sistema in questione. Si noti come sia possi-
bile aggiungere un attributo al messaggio utitilizzando il metodo Add
appartenente alla classe Message. Per lo scorrimento degli attributi
del messaggio d'origine si utilizza la struttura KeyValuePair perché
nel messaggio di input, ma anche in quello ltrato che andrà in output,
viene seguita la notazione JSON per il quale si ha una coppia nome/va-
lore associato ad ogni attributo. Quando l'intera operazione asincrona
viene completata, l'operatore await restituirà il risultato dell'operazio-
ne, in questo caso il messaggio ltrato. Questo operatore non blocca il
thread che valuta il metodo async. Quando l'operatore await sospende il
metodo asincrono, ad esempio in attesa dei messaggi, il controllo torna al
chiamante del metodo. Con questa funzione sviluppata verranno quindi
scartati tutti i valori al di sotto di una certa soglia ed inoltrati i restanti
sul Cloud ricostruendo prima i messaggi in modo da poter aggiungere la
proprietà di allarme come visto poc'anzi.
Il FaaS appena implementato andrà compilato attraverso l'ambiente
di sviluppo Visual Studio Code specicando nelle impostazioni della so-
luzione software, l'username e password del registro contenitori ottenibili
attraverso l'interfaccia web di Azure. Questa operazione è fondamentale
perchè, come descritto in precedenza, la funzione verrà caricata in un
contenitore nel quale vengono create tutte le dipendenze speciche del
25

Figura 3.6 Messaggi ricevuti dall'Hub IoT
modulo, svincolando il programmatore da tali problematiche. In partico-
lare verranno lanciati due comandi docker, uno di build per la com-
pilazione del codice ed inserimento in un contenitore, l'altro di push nel
registro contenitori Azure. Un deployment distribuirà invece il codice
sul dispositivo Edge. Tale operazione viene eettuata mediante l'inter-
faccia graca dell'ambiente di sviluppo. In Visual Studio Code risulta
possibile analizzare i messaggi in arrivo all'Hub IoT da uno specico di-
spositivo attraverso la console dell'ambiente. In questo caso di sviluppo
è altresì utile creare un Event Endpoint sul dispositivo edge, ovvero un
elemento che monitora tutti gli eventi generati. I messaggi visualizzati
(gura 3.6) saranno quelli ltrati dall'edge IoT mediante il modulo FaaS
implementato. Si noti che il formato dei messaggi segue la notazione
JSON già discussa in precedenza. É possibile inoltre notare come per
ciascun messaggio ricevuto dall'Hub IoT sia inclusa la proprietà di allar-
me sul tipo di messaggio. Questo risultato dimostra che il Cloud riceverà
solo i messaggi ltrati dalla funzione in esecuzione sul dispositivo edge.
3.4 Archiviazione su database distribuito
Si è nora ottenuto un sistema nel quale il nodo Edge invia dati di
telemetria, opportunamente ltrati, nel Cloud. Si desidera adesso me-
morizzare questi dati in una struttura permanente al ne di eseguire,
ad esempio, successive analisi statistiche su una grossa quantità di dati
rilevati. In questo paragrafo si realizzerà una soluzione per trasferire i
messaggi ricevuti dall'Hub IoT di Azure verso il database distribuito nel
26

cloud Azure denominato Cosmos DB. Il servizio è anch'esso oerto da
Microsoft e ore una base di dati distribuita a livello globale. Cosmos
DB consente di memorizzare una grande quantità di informazioni in mo-
do geo-distribuito bilanciando il carico tra i vari nodi. Viene oerta una
vasta gamma di API per eettuare qualsiasi tipo di operazione sul da-
tabase. In questo modello troveranno posto contenitori che in maniera
simile alle classiche tabelle, conterranno i nostri elementi. In questo ca-
so specico si utilizzerà l'API SQL per creare, aggiornare ed eliminare
contenitori ed elementi. Per prima cosa si andrà a creare una istanza di
risorsa Cosmos DB attraverso la piattaforma online accessibile tramite
browser.
Figura 3.7 Congurazione database CosmosDB
In questa fase risulta possibile indicare diversi parametri utili (gura
3.7) come la località geograca tra quelle rese disponibili da Microsoft
nel quale posizionare il database. La ridondanza geograca ci consen-
te di distribuire i dati su un altro database posto in un'area diversa da
quella specicata. Inne la scrittura su più aree consente di scrivere
contemporaneamente su più database distribuiti in diverse aree facendo
però lievitare i costi. Si procederà con lo sviluppo di una funzione Azure
Function, opportunamente scritta ed eseguita ad ogni nuovo messaggio
in arrivo sull'Hub, la quale inserirà l'intero body nel container del
database. In questo caso si utilizzerà un altro servizio Azure denominato
App per Funzioni che costituisce un sistema rapido e alternativo al-
l'ambiente Visual Studio Code per la creazione delle Azure Functions. A
dierenza di quanto fatto per il dispositivo Edge, il modulo FaaS che si
andrà a sviluppare adesso non verrà eseguito su una specica macchina
virtuale (o reale), ma resterà virtuale all'interno del Cloud Azure nel
servizio citato poc'anzi. Attraverso l'interfaccia web della piattaforma si
27

denirà il trigger ovvero l'evento che farà scattare l'esecuzione del mo-
dulo, in questo caso sarà l'arrivo di nuovi messaggi nell'Hub IoT, mentre
in output si avrà un oggetto compatibile con i record accettati dal data-
base creato nell'ambiente Cosmos DB.
1 public static void Run(string inputMessage, out object outputMessage)
2 {
3 dynamic msg = JObject.Parse(inputMessage);
4 outputMessage = new {time = msg.timeCreated, temperatura_ambiente = msg.ambient.
temperature, umidita_ambiente = msg.ambient.humidity};
5 }
Il codice scritto in linguaggio C# prevede una sola procedura denomina-
ta Run che verrà invocata ad ogni evento associato al trigger. Viene
utilizzata anche in questo caso la notazione JSON (JavaScript Object No-
tation) pertanto si eettuerà l'operazione di parsing sul usso di dati in
ingresso attraverso la funzione JObject.Parse al ne di poter analizza-
re il contenuto dei messaggi. Una variabile dynamic dal comportamento
simile ad una Object viene assegnata all'oggetto ricavato a seguito del
parsing del messaggio in input. Dal messaggio verranno estrapolate solo
alcune informazioni di interesse, in questo caso temperatura e umidità
dell'ambiente le quali verranno inserite in un oggetto di output compa-
tibile con il contenitore situato all'interno del database Cosmos DB.
Dall'interfaccia web di Azure si procederà alla compilazione ed esecuzione
Figura 3.8 Log del servizio App per Funzioni
della funzione che resterà attiva n quando non si deciderà esplicitamen-
te di fermarla per eettuare ad esempio una modica al codice. Nella
console del servizio (gura 3.8), accessibile tramite browser, si può inve-
ce analizzare il registro degli eventi (log) associato alla funzione e notare
che eettivamente viene eseguita ad ogni messaggio in arrivo, dal quale
28

si può anche osservare l'identicativo associato.
Ad ogni esecuzione del codice, i messaggi ltrati dal nodo Edge e inviati
Figura 3.9 Elementi presenti nel database CosmosDB
all'Hub IoT verranno catturati dalla funzione appena implementata la
quale provvederà all'invio sul database Cosmos DB, creato in prece-
denza col nome dbtest20. Attraverso l'interfaccia web di Azure (gu-
ra 3.9) risulta altresì possibile visualizzare i dati collezionati all'interno
del contenitore dati_sensore situato nella base di dati. Si noti che a
ciascun messaggio, oltre agli attributi relativi ai dati di temperatura e
umidità dell'ambiente, viene associato un identicativo (id) generato dal
nodo Edge durante la fase di creazione del messaggio di output come
rilevato dal log della funzione visto in precedenza.
29

Conclusioni
Con l'introduzione del modello Edge Computing si sono superati diversi
limiti legati all'architettura Cloud. La soluzione di avvicinare l'elabora-
zione ai dispositivi che generano dati ha consentito di ridurre sensibil-
mente il tempo di risposta favorendo operazioni di controllo su sistemi
particolarmente sensibili alla variabile tempo.
Come si è visto nell'ultimo capitolo, è possibile sfruttare l'elaborazione
Edge per eettuare pre-processing sui dati provenienti dai sensori evi-
tando di sovraccaricare la rete. Si ha inoltre una maggiore tolleranza
quando avviene una disconnessione dal Cloud, le operazioni potranno
così continuare sui nodi Edge per poi inviare i dati nel Cloud una volta
riconnessi alla rete. L'evoluzione del modello Serverless attraverso l'in-
troduzione dei Function-as-a-Service permette di sviluppare servizi nel
quale lo sviluppatore non si preoccuperà più dell'architettura sica sul
quale verranno eseguiti. Nel caso d'uso sviluppato nell'ultimo capitolo
si è riusciti con poche istruzioni scritte in un linguaggio desiderato, ad
ottenere un ltro per rilevare il superamento di una temperatura critica.
Attraverso un dispositivo con funzionalità Edge congurato su macchina
virtuale Ubuntu, i dati di temperatura sono stati prelevati dai sensori e
opportunamente ltrati prima di procedere all'invio nel Cloud per succes-
sive elaborazioni. Nel caso di interesse si è prevista una memorizzazione
su database.
Questa soluzione risulta quindi particolarmente utile per l'analisi e con-
trollo di processi industriali ma anche nell'ambito dell'automotive e ma-
chine learning per eettuare ad esempio manutenzione predittiva su de-
terminati impianti. Risulta così possibile delocalizzare operazioni parti-
colarmente laboriose sui nodi di perimetro senza sovraccaricare i dispo-
sitivi IoT i quali dispongono di una ridotta capacità computazionale ed
energetica. Il modello Cloud dispone comunque di caratteristiche che
un ambiente Edge Computing non potrebbe avere, come la disponibilità
30

virtualmente illimitata di potenza di calcolo e spazio di storage.
Bisognerà pertanto pensare ad una sinergia tra queste due entità.
Il Cloud potrebbe fornire un'unità di calcolo centrale per analisi su larga
scala. I due sistemi se combinati fra loro possono fornire sia informazioni
in tempo reale che storiche basate su elaborazione massiva.
La presenza di numerosi dispositivi di calcolo nel modello Edge presen-
ta però anche problemi relativi all'interazione tra questi soggetti spesso
eterogenei. La soluzione di Microsoft si basa sul rilascio di certicati per
dispositivi compatibili con l'ecosistema Azure.
Importante è anche la questione sicurezza. Se da un lato si ha il vantag-
gio di elaborare dati all'interno della rete anziché sul cloud rispettando
ad esempio la privacy su determinate informazioni, si avrà però il pro-
blema di dover garantire la sicurezza su più dispositivi e relativi canali
di comunicazione.
Nonostante le diverse problematiche da arontare, i vantaggi dell'archi-
tettura Edge hanno permesso una rapida diusione tra i vari provider di
servizi Cloud i quali si sono ben presto adeguati a questo nuovo modello
orendo servizi molto utili. Nel caso di Azure ad esempio, gli strumenti
messi a disposizione consentono di progettare sistemi evoluti attraverso
una piattaforma in continuo sviluppo nel quale ciascuna risorsa può es-
sere posizionata in una precisa area geograca e i costi addebitati per
il tempo eettivamente utilizzato. In un'ottica aziendale la soluzione di
Microsoft risulta particolarmente vantaggiosa grazie agli strumenti per
analizzare dettagliatamente i costi e denire il budget per i servizi utiliz-
zati in determinati periodi al ne di ottimizzare la spesa nel tempo. Edge
e Cloud Computing rappresentano quindi un ottimo connubio per l'ela-
borazione distribuita al quale vanno però ancora risolti alcuni problemi.
La rapida evoluzione di queste tecnologie passando da IaaS, PaaS e oggi
FaaS denota un enorme interesse e non esclude ulteriori miglioramenti
nel breve termine.
31

Bibliograa
[1] F. F. Moghaddam, M. B. Rohani, M. Ahmadi, T. Khodadadi, K.
Madadipouya, Cloud Computing: Vision, Architecture and Characte-
ristics. IEEE 6th Control and System Graduate Research Colloquium,
Aug. 10 - 11, UiTM, Shah Alam, Malaysia, 2015.
[2] H. El-Sayed, S. Sankar, M. Prasad, D. Puthal, A. Gupta, M. Mohanty,
C.T. Lin Edge of Things: The Big Picture on the Integration of Edge,
IoT and the Cloud in a Distributed Computing Environment,Volume 6
Journal Article IEEE, 2018.
[3] J. Eisenzopf ,Towards Serverless (FaaS) as the next step in Infrastructure-
as-a-Service (IaaS) evolution, medium.com, 2019.
[4] L. Baresi, D. F. Mendonca, Towards a Serverless Platform for Edge
Computing, IEEE International Conference on Fog Computing (ICFC)
2019.
[5] M. Nitesh, Research for Practice: Edge Computing, Communica-
tions of the ACM. Vol. 62 Issue 4 p95-99, 2019.
[6] M. Caprolu, R. Di Pietro, F. Lombardi, S. Raponi, Edge Computing
Perspectives: Architectures, Technologies, and Open Security Issues,
IEEE International Conference on Edge Computing (EDGE), 2019.
[7] M. De Donno, K. Tange, N.Dragoni Foundations and Evolution of
Modern Computing Paradigms: Cloud, IoT, Edge, and Fog, Volume 7
Journal Article IEEE, 2019.
[8] C. Byers, Challenges in real-world edge computing architecture,
Cisco Systems, 2018.
32

Tesi Laurea I Livello - Vaiano

More Related Content

What's hot

Similar to Tesi Laurea I Livello - Vaiano

Tesi Laurea I Livello - Vaiano