Page 44 - Kaleidoscope Academic Conference Proceedings 2021

(NATs) and firewalls traversals. Developers then can focus discussed in [11] and [12] (also called deviceless), our
only on the functionalities of their applications. approach is IoT-oriented and aims at adopting the serverless
paradigm to make use of the IoT resources (i.e., sensors and
The paper is laid out as follows; in Section 2, we discuss the actuators). Instead, the approach reported in [11] [12] targets
usage of the serverless paradigm in IoT. We also report related more generally edge computing scenarios: the infrastructure
works. Section 3 presents the subsystems we used to conceive is used as pure execution infrastructure offering compute
the deviceless system. Next, in Section 4, a description of the resources. Authors in [13] investigate the problem of
deviceless system is reported. In Section 5, we describe two the dynamic allocations of serverless functions in edge
use cases that exploit the Deviceless/edge FaaS capabilities. environments including fog and IoT nodes. Still, only the
Section 6 reports some preliminary results of the experiments computing aspect is considered to deploy the functions.
we conducted. Finally, Section 7 closes the paper and gives
a hint about future works. Recent efforts are in progress to expand the applicability
of deploying customized applications on IoT gateways
2. SERVERLESS IN IOT and devices such as Amazon Greengrass [14] and Azure
IoT Edge [15] that provide edge-based runtimes dealing
Recently, the serverless cloud computing model has been with IoT data processing. However, these solutions are
rapidly adopted in the IT field since its first appearance in not real extensions of the serverless paradigm but just
2014 with AWS Lambda1. Most of the cloud providers an extension of the cloud Platform-as-a-Service (PaaS)
such as Microsoft and Google have introduced comparable computing model [11]. Furthermore, these proprietary
Serverless/FaaS services in their commercial offerings systems make the users dependent on the providers’
(i.e., Azure Serverless2 and Google Cloud Functions3, platforms [3]. OpenWhisk-Light (OWL)7 is a solution
respectively). Besides, other opensource solutions have that extends the servelerss approach to the IoT ecosystem
been developed such as Apache OpenWhisk4, Kubeless5 and using OpenWhisk actions. Moreover, the solution has been
Fission6. integrated with a flow-based development environment. Yet,
the solution is limited in the sense that the functions deployed
The serverless computing model provides a set of attractive on the IoT nodes trigger local actions based on only local
benefits from the developer’s point of view [4]. With the detected events. In particular, the platform cannot trigger an
emergence of new services and to meet their requirements action on an IoT node based on an event happening on another
in terms of, for example, latency and bandwidth usage, device or in the cloud, thus, leading to limited applicability
solutions based on edge computing have been adopted [5]. of the solution. Besides, the OWL approach is based on
Furthermore, using the serverless paradigm at the network deploying the whole system on the relatively constrained IoT
edge is intended to provide an efficient solution to be adopted nodes (e.g., Raspberry Pi). In [16], the authors present an
in a set of use cases [6] [7] [8]. In this context of edge extended serverless system for IoT scenarios based on the
computing, the European Telecommunications Standards Calvin framework [17]. The system developed is used to
Institute (ETSI) has defined a reference architecture based conceive flow-based workflows in a serverless-like fashion
on Multiaccess Edge Computing (MEC) to address the using both cloud-based instances and IoT nodes, yet based on
requirements/needs of edge-based computing platforms [9]. long-running processes/functions.
Authors in [10] make use of the ETSI reference architecture to
conceive a system for deploying serverless/FaaS at the edge. In our deviceless view, we aim to abstract the hardware
Nevertheless, extending the serverless computing model to layer of the IoT nodes. Specifically, we would like to make
cover edge deployments is not a straightforward process the developers able to interact with IoT resources (sensors
and brings new challenges such as resource pooling and and actuators) in a serverless-like way through stateless and
infrastructure provisioning/management [11] [12]. Besides, personalized atomic functions. In particular, a code that uses
the network reachability of nodes deployed at the network the deviceless computing paradigm must behave as a cloud
edge is critical to consolidate the cloud and edge resources [7]. serverless native code when it comes to interacting with any
Unlike cloud-based deployments where the execution kind of application.
infrastructure is deployed within the same data center (i.e.,
same physical network), and thus server connectivity is 3. BACKGROUND
taken for granted, IoT networking topologies, instead, are
We provide, in this section, an overview of the subsystems
complex and hard to manage. Indeed, IoT deployments are
used to build the deviceless system.
composed of geographically distributed nodes deployed, most
of the time, behind networking middleboxes (e.g., NATs
3.1 Stack4Things
and firewalls). Compared to the edge serverless approach
Stack4Things (S4T) [18] is an IoT-oriented platform
1 https://aws.amazon.com/lambda/
2 https://azure.microsoft.com/en-us/solutions/serverless/ extending the capabilities of the widely used cloud computing
3 https://cloud.google.com/functions platform, namely OpenStack. In particular, S4T aims to
4 https://openwhisk.apache.org make the IoT infrastructure seem as a typical cloud-based
5 https://kubeless.io
6 https://fission.io 7 https://github.com/kpavel/openwhisk-light

– xl –