A Microservices-based IoT Monitoring System toimprove the Safety in Public Buildings

Marina Mongiello∗, Luigi Patrono†, Francesco Nocera∗, Angelo Parchitelli∗,Luca Riccardi∗, Ilaria Sergi†, Piercosimo Rametta† and Leonardo Avena∗

∗Dipartimento di Ingegneria Elettrica e dell’InformazionePolitecnico di Bari, Bari, Italy

Email: {firstname.lastname}@poliba.it†Dipartimento di Ingegneria dell’Innovazione, Universita del Salento, Lecce, Italy

Email: {firstname.lastname}@unisalento.it

Abstract—Safety of public buildings’ users is an importantissue, especially in buildings frequented by a great number ofpeople. In such places, in case of an emergency, like a fire, rescueworkers must intervene in a timely manner, directing their effortstowards places where there are people to be saved. This workpresents an Internet of Things(IoT)-based framework, aimingat monitoring environmental parameters in order to supportrescuers during emergencies. The microservices paradigm allowsa pattern-based specification of system components that arerefined and adapted on-the-fly depending on the specific executioncontext, based on the changing aspects such as, user’s needand requirements, context variables, user’s behavior, sensordata. First results related to the validation of the proposedsystem mainly concerning non-functional requirements of theimplemented system through a proof-of-concept are reported anddiscussed.

I. INTRODUCTION

The recent regulations on fire prevention adopted by manycountries are aimed at safeguarding buildings and people withthe goal of (i) reducing the causes of fire, (ii) guaranteeingthe stability of the structure, favoring escape of all present,(iii) limiting the spread of fire, and (iv) guaranteeing thepossibility of intervention of firefighters. These regulationsfocus on all the components that are concerned in the eventof a fire: location and structure of the building, materialsand their reaction to fire, measures for the exodus of people,fire-fighting systems, electrical systems, alarm, water systemsand rescue. However, despite all these measures, fires occurand sometimes certain circumstances can nullify or preventthe application of some solutions foreseen at design phase.In such cases, for example, small explosions or collapsescan block the escape routes of some locals and prevent theevacuation by people present at that time. In other cases,instead, smoke can disorient users, causing them to flee inthe wrong direction, arriving in places difficult to reach byrescuers. For these reasons, having a snapshot of the buildingwhen the emergency occurs, with the level of some ambientparameters (temperature, humidity, smoke level, CO2, etc.)and the human presence in each local of the building, wouldbe an important support for rescue workers, especially in caseof large buildings, in order to optimize their work and saveas many lives as possible. Internet of Things(IoT)-enabling

technologies and devices like Bluetooth Low-Energy (BLE),Wi-Fi, smartphones, smart objects, etc. can help in reachingthis goal [1], [2], [3], [4], [5], [6]. Low-cost fast-prototypingplatforms, such as Arduino1 or ST Nucleo2, equipped witha set of ambient sensors, allows the creation of wirelessnetworks of smart devices able to periodically sense thesurrounding environment and to send collected data to a Cloudserver for further analysis.

There, a microservice based software application is pro-posed for the monitoring system. Microservice based architec-tures have started to gain in popularity and are often adoptedin the implementation of modern cloud, IoT, and large- scaledistributed applications. Lewis and Fowler define [7] themicroservice architectural style as an approach to developinga single application as a suite of small services, each run-ning in its own process and communicating with lightweightmechanisms, often an HTTP resource API. Therefore, themicroservices should be independent components conceptuallydeployed in isolation and equipped with dedicated memorypersistence tools (e.g., databases) [8]. Developers can focusalmost exclusively on the few features of the microservice theyare responsible for. However, the final application will consistof many microservices, so each one is able to coordinate withthe others. The independence of a single microservice must notcompromise the functioning of the other microservices and, ingeneral, of the overall system.

Hereby, [9], [10] we model and implement a microservices-based architecture for monitoring data detached from sensorsin a IoT environment for a near real-time situation. Theproposed framework is an innovative system to support rescueworkers (firefighters, first aid workers, civil protection teams,etc.) in case of hazardous events. Particularly, the focus is onevents in which they need to intervene in large environmentswith different access points and with a great number of users,like schools, hospitals, offices, senior citizens’ homes, culturalor entertainment places. In these situations, in fact, it isnecessary to guide the rescuers in a timely manner at the points

1Arduino, https://www.arduino.cc/2ST Nucleo, http://www.st.com/en/evaluation-tools/stm32-mcu-

nucleo.html?querycriteria=productId=LN1847

of the building where there is a certainty that there are usersto help, avoiding waste of resources.

Within each room of the monitored building, a sensingdevice is installed, which detects the environmental parametersof interest and sends collected data to the Cloud back-end,where, if certain thresholds are exceeded, a telephone callto one or more emergency numbers is done. Once alerted,rescuers are able to readily get all the information, through avisual dashboard, about the building and the specific environ-ment in which they need to intervene. The main goals of thisframework is to reduce the intervention time and to minimizethe loss of lives.

The use of microservices ensure the achievement of rel-evant non functional requirements that are implicit in thearchitectural style, such as stability, reliability, scalability, faulttolerance, monitoring and performance [8], [11], [12].

The remaining of the paper is organized as follows. SectionII reports a brief state of the art about microservice-basedarchitectures. Section III describes the main requirements thatled to the design of the proposed solution, while Section IVpresents the system architecture. A functional validation ofthe solution is presented in Section IV and, finally, Section Vdraws some conclusions and outlines future work.

II. STATE OF THE ART

The microservices architecture is an architectural stylewhere complex applications are composed of small indepen-dent processes that communicate with each other throughmessage passing. These services are small blocks build insuch a way that they can perform small operation in aspecific way. This architecture has been proposed to cope theproblem of monolithic architecture, where modules cannot beexecuted independently [13]. Unlike monolithic architecture,the centralization of the application is minimized here. Dif-ferent and heterogeneous development teams could managethe microservices. Microservices of the same application canbe implemented with different programming languages andwill be independent from one to another with regard todevelopment, deployment and production [14]. The currentstate of the art does not allow us to define a perfect mi-croservices architecture, but it is more correct to speak ofoptimal architecture, contextualizing the situation at that time.Therefore, we need to examine the organization, the teamand the people available, their number and the technologiesthey know best and, finally, examine the best communicationprotocols and patterns for each microservice[15].

A. CONTAINERS AND DOCKER

Each microservice runs in a single process and should bedeployed and scaled to multiple hosts, so that the procedureis automated, fast and there are no compatibility issues withdifferent operating systems. For this purpose, a virtual machinewould also be good, but it would consume too many resources.Fortunately, there is an alternative to Linux containers that,unlike virtual machines, do not simulate all the hardwareof a guest operating system, but are executed directly as a

single operating system process [16]. Virtualization providesa number of benefits. It enables a flexible allocation of physicalresources to virtualized applications where the mapping ofvirtual to physical resources as well as the amount of resourcesto each application can be varied dynamically to adjust tochanging application workloads. Virtualization also simpli-fies replication and scaling of applications. There are twotypes of server virtualization technologies that are commonin data center environments: hardware-level virtualization3

and operating system level virtualization [17]. Hardware levelvirtualization involves running a hypervisor which virtualizesthe server’s resources across multiple virtual machines. Eachhardware Virtual Machine(VM) runs its own operating systemand applications. By contrast, operating system virtualiza-tion virtualizes resources at the OS level. This virtualizationencapsulates standard OS processes and their dependenciesto create ”containers”, which are collectively managed bythe underlying OS kernel. Containers promise low-overheadvirtualization and improved performance when compared toVMs. Hardware virtualization involves virtualizing the hard-ware on a server and creating virtual machines that providethe abstraction of a physical machine. Hardware virtualizationinvolves running a hypervisor, also referred to as a VirtualMachine Monitor(VMM). The hypervisor emulates virtualhardware such as the CPU, memory, I/O, and network devicesfor each virtual machine. Each VM then runs an independentoperating system and applications on top of that OS. Thehypervisor is also responsible for multiplexing the underlyingphysical resources across the resident VMs. Operating systemvirtualization involves virtualizing the OS kernel rather thanthe physical hardware. Each container encapsulates a group ofprocesses that are isolated from other containers or processesin the system. The OS kernel is responsible for implementingthe container abstraction. It allocates CPU shares, memoryand network I/O to each container and can also provide filesystem isolation. Containers provide lightweight virtualizationsince they do not run their own OS kernels, but instead relyon the underlying kernel for OS services. An example ofusing container is Docker 4. Before executing them, Dockercontainers must be set up to ”host” the microservice code tobe made available and active. We write a particular file, calledDockerfile, which contains the instructions accepted by Dockerto build an image for the container (often downloaded fromDocker Hub, public registry of Docker images, or other reg-isters) and any commands to be executed within the containerrunning. All of this assures us that, by running Docker as anoperating system process, the various images containing themicroservices can be executed, having the certainty that down-loading the image to other hosts activates the microservice inthe exact same development and execution environment, thusavoiding problems of incompatibility and favouring scalability.For each operation listed and for many other situations, youcan use the API interfaces provided by Docker. All the aspects

3Unix Philosophy, https://en.wikipedia.org/wiki/Unix philosophy4Docker Website, https://www.docker.com/

described so far, necessarily lead to a new way of developingapplications for automation procedures, scalability, frequentrelease of new microservices.

III. MAIN REQUIREMENTS OF THE SAFETYPROJECT

The main goal of this work is to define and setup ahardware/software framework able to provide a snapshot ofthe building environment when an emergency (typically a fire)occurs. In this context, the term snapshot means providinginformation about some ambient parameters in each of themonitored rooms in the building, so that rescue workerscan use this information to speed-up the definition of theintervention plan. Among the possible ambient parameters thatcan be monitored, the most important ones in fire situationsare temperature, humidity, level of smoke, level of CarbonMonoxide (CO) and presence of smoke [18]. These parametersgive an idea of the severity of the fire in the monitored room.But, above all, the most important parameter to detect isthe presence of any living being (human or animal) in thatroom. The sensing infrastructure in charge of monitoring theseparameters must deal with three main aspects, often in conflictwith each other: unobtrusiveness, affordability and availability.Unobtrusiveness means that sensing devices should not impactthe buildings architecture because of invasive wirings forpower source and/or communication. Battery powered deviceswith wireless communication interfaces (like Wi-Fi) should bepreferred. Affordability means that the entire solution shouldnot be too expensive to setup and manage, in order to fosterthe adoption also by public administrations and improve safetyalso at a city level. In this context, the affordability of thesolution is linked to the sensing infrastructure which, in turn, isstrictly tied to the third aspect, the availability. Sensing devicesable to survive fires, ensuring data collection and forwardingeven during the emergency are extremely costly. However,in many cases, there is no need to gather information froma room even during (or after) the fire. The most importantthing is to have information at least when the fire happens,just before the flames (or the heat) may destroy the devices.Information collected in this time frame is sufficient to decideif to intervene or not in that room. Therefore, in order to fosterthe adoption of the system, affordability can be favored at theexpense of availability, by choosing low-cost devices, howeverable to guarantee the required functionalities.

Other non-functional requirements are related to softwarearchitecture, mainly to the pattern-based implementation builton the microservices concept, in back-end Cloud module. Firstof all the microservices style ensures stability and reliability.

A microservice, should ensure that in the case of a malfunc-tion, this does not have serious consequences of instability ofother microservices and, in general, of the whole system. Inaddition to this property the microservice provides a) Scala-bility, b) Fault tolerance, c) Performance: linked to scalability.By increasing the number of simultaneous requests for amicroservice, the efficiency must not change too much; wherepossible, for example, it is a good idea to use asynchronous

and parallel calls instead synchronous calls; d) Monitoring:linked to reliability. It provides for log activity of eventsand errors; e) Reliability: is enhanced by the system featuresthat help to avoid, detect and repair hardware faults[8], [16].situation the system does not deliver the results but detectsand, if possible, corrects the corruption.

Finally, the Cloud back-end should be able to receivedata from heterogeneous devices, technologies or applications.This can be achieved by properly defining an abstractionlayer and a data communication protocol that hide all low-level technological details. Regarding the data visualizationaspect, the main functional requirement is to provide datawith the right format according to users profile. During anemergency, in fact, building security officers may like to havea graphical summary of the situation in each portion of thebuilding, whereas rescue workers need concise informationwithout useless tinsel. Professional users, like system installerand operators, also need tools to easily manage the sensinginfrastructure, in order to associate each device in the rightlocation.

IV. DESCRIPTION OF THE SYSTEMARCHITECTURE

The system architecture of the proposed solution (shown inFigure 1) is composed of the following main building blocks:

(i) Ambient monitoring smartbox: a sensing device basedon prototypal board equipped with a set of sensors able todetect specific environmental parameters (e.g. temperature,smoke, movement, etc.). This device has also one or morecommunication interfaces (Wi-Fi, 3G/4G, BLE) for forward-ing collected data to the CEP Engine;

(ii) Back-end Server: composed of an API Gateway, LoadBalancer and a CEP Engine allows to store, process andvisualize data collected by each smartbox in order to obtainthe magnitudes of interest, together with information relatedto building’s topology and sensing infrastructure. In additionthere is a Business Intelligence module for managing thecollected data for determining whether and which data shouldgenerate an alert to the rescuers, enabling a call to fixed ormobile network numbers;

(iii) Front-end Application: a responsive Web Applicationusable on different platforms (PC, smart-phone, tablet) thatdisplays, through customized interfaces, real-time situationsinside the building, highlighting the ambient parameter statusand the presence of people inside. This application can beconsulted by the rescuers once they receive the alarm so thatthey can quickly decide where and how to intervene;

(iv) Installer mobile app: this multiplatform mobile applica-tion is used by system installers to associate each monitoringsmartbox to the proper location inside the building, and formanagement operations during runtime.

The Ambient monitoring smartbox: Regarding the Ambientmonitoring smartbox, its dual role is to periodically samplethe value of a given set of environmental parameters and totransmit these collected data towards the Back-end Server. It ischaracterized by a modular structure, since the exact hardware

Fig. 1. Overall architecture of the proposed solution

Fig. 2. Implementation example of the Ambient monitoring smartbox

equipment of the sensing node and its communication inter-faces will depend upon many variables, such as the typologyof the building, its dimension and topology, the materialand the furniture of the building, and so on. As explainedin Section III, having decided to privilege the affordabilityrequirement rather than the availability one, the Ambientmonitoring smartbox can be based on a fast-prototyping board,like Arduino, with the possibility to use also microcomputer,such as Raspberry Pi, when further computing and/or commu-nication capacities are required for the sensing node.

Figure 2 shows the schema of a possible implementation ofthe smartbox, based on the Arduino MKR10005, and equippedwith (i) an LM35AH or LM35DZ sensor for measuring airtemperature in the range -55C to 150C, (ii) a MQ2 sensor, di-rectly interfaceable with Arduino boards, for smoke detection,(iii) a MQ7 sensor, to detect other type of toxic gasses, likeCarbon Monoxide, (iv) an IR-based low-cost flame sensor, and(v) a PIR sensor or a more accurate MEMS Thermal sensor todetect the presence of people in a room. With this hardwaresetup, it is worth noting that, considering the cost constraintsand the critical working conditions during the fire, it is notpossible to guarantee that the monitoring device keeps workingalso during the fire event. The important thing is that it cantrack the ambient status (and communicate it to the Back-endServer) at least until a moment before it stops working due tofire.

Microserveces-based architecture: We refer to the mi-croservices paradigm, that allows a pattern-based specificationof system components that are refined and adapted on-thefly depending on the specific execution context, based on

5MKR1000, https://store.arduino.cc/arduino-mkr1000

Fig. 3. Software architecture of the proposed solution

the changing aspects such as, user’s need and requirements,context variables, user’s behavior, sensor data. Architecture’ssketch is modeled in Figure 3. In detail we have a single pointof access to the services made available by the Gateway API.This acts as a single entry to the system’s services: Regis-tration / Authentication, Catalog of offered services, moni-toring services. Each microservice can be developed throughan independent programming language. The communicationsthrough the various microservices and the Gateway API takesplace using the classic HTTP protocols of the web throughthe RESTful paradigm with GET / PUT / POST / DELETEmethods through the data exchange in JSON format. On theleft there are the two content usage platforms (Web / App) thatwill use the APIs to create a flow of appropriate operations.The user, the administrator of the structure – supervisor, makesaccess to the application through the App or the Web. Behindthe system there are the microservices that provide the servicesof authentication, registration and monitoring. The APIs foringesting data from IoT devices located inside the buildingsend up on a separate road. A load balancer and a Flink clusterfor Complex Event Processing services (CEP) are provided inorder to manage quantities of data [19].

The architectural diagram shown in Figure 5 describes theentire orchestration of the services performed. In particular,as it is a microservice architecture, this is modeled in sucha way that each service is provided by a single block. Inthe diagram there is the registration service that allows anindividual to register with the system and obtain the personalaccess credentials. The authentication service allows registeredpersonnel to authenticate themselves to the system and torequest data and statistics from the monitoring service, whichwill interrogate the CEP engine to display the requested data.In this architecture all the services are connected to a GatewayAPI which provides the protection necessary for exposing theservices themselves to the outside. The communication mech-anism used is in fact based on HTTP through the GET, POST,PUT and DELETE methods using JSON as data interchangeformat. In the lower part of the figure, the flow of the IoTsensors located in public spaces is schematized. This flow isdeliberately disconnected from the normal application flow soas not to slow down the real-time monitoring. IoT devicesare directly connected to a load-balancer which, on the basisof the data traffic of all currently active devices, decides on

Fig. 4. Application Scenario

Fig. 5. Docker Server

which node of the CEP engine to get the communication. Thisarchitectural scheme guarantees a higher quality of service(QoS) as it drops the single-point-of-failure relative to thesingle instance of CEP engine, reducing it. In addition, thismechanism offers high scalability thanks to the possibility ofadding nodes to the cluster as IoT devices connected to thesystem grow. The Docker server implementation schema isshown in Figure 5. Docker enables the creation of lightweightcontainers that can accommodate services within them. Dockeris hosted on a server that acts as a host and creates a commonsubstrate that interfaces directly with the operating systemto orchestrate the various containers. The image shows thedistinct containers at the top right. Containers, allows us toisolate and at the same time obtain a network of interconnectedservices. The service instances (Registration, CEP Engine,Monitoring Services, ...) are located above the container man-ager, in this case the Docker Daemon that orchestrates theoperation. At the base of all there is the host operating systemthat interfaces, through the system API, to the server hardware.

V. VALIDATION: PROOF-OF-CONCEPT

The validation of the architectural model and of the pro-posed system highlights some of the strong points related tothe modeling of the scenarios using microservices. For exam-ple, the latter introduce flexibility, modularity and evolutionto the entire system in terms of the quality of the serviceoffered and the maintenance of the software. In particular,modularity and rapidity of evolution are two key aspectson which tests have been carried out aimed at highlightingthe potential of these aspects. Modularity allows the systemto compose isolated components in which each componentcontributes to the general behavior of the system rather thanhaving a single monolith while the evolutionary aspect shows alow coupling in the components able to give the system a high

degree of maintainability while the overlying software evolvesto incorporate new features. Figure 4 describes a criticalsituation environment in the fire in a room is notified to theadministrator and to the firefighters. The validation scenariofollows a public building environment that allows to simulate,in an isolated and controlled situation, the transmission of datafrom IoT devices, the flow of data in the CEP pipeline, andthe visualization of the latter through a Web interface, the useof a CEP pattern. The simulation was structured using threedifferent Arduino boards located in three different rooms. Inthe case in question, the boards were equipped with LM35AHtemperature/humidity sensors, a MQ-7 smoke sensor and alightness sensor. The containerization architecture was createdwithin the Docker environment6 in which the previously de-scribed microservices were modeled, in particular: (i)the Com-plex Event Processing used is Apache Flink7, an open-sourcestream processing framework for distributed, high-performing,always-available, and accurate data streaming applications incluster version; (ii) a basic load balancer made available bythe Docker environment; (iii) for the microservices of accessto the API and to the data display services, NodeJS-basedcontainers were used to display the RESTful APIs and usedthe JSON language as a mechanism for intercommunicationbetween the various services.

The following is an example of a JSON message exchangedwithin the architecture:

{"DeviceName": "ARDUINO-R1", "sensorID":1, "type":"smoke", "value" 1.0, "timestamp": 1512237962769}{"DeviceName": "ARDUINO-R1", "type": "temperature","sensorID":3,"value":30.0,"timestamp":1512296588345}

In particular, a message containing the sensor ID, the sensortype, the measured value and the measurement instant as UnixTimestamp is sent by the ”ARDUINO-R1” board. These twomessages are sent to the load-balancer that routes the trafficto the CEP Flink instance, which analyzes the data receivedwithin the time window and generates an alert message thatis notified in the web dashboard to the administrator.

{ "Message": "warning", "type": "fire","sensors":[{ "sensorID": 1, "deviceName": "ARDUINO-R1","type":"smoke", "value" : 1.0, "timestamp": 1512296543529},{ "sensorID": 3, "deviceName": "ARDUINO-R1", "type":"temperature", "value": 30.0,"timestamp": 1512296588345}] }

For validate the entire architecture we use a particularproperty of system for reach stability and availability of systemand is described below.

Reliability. The distribution of services within the archi-tecture aims to maximize the attention on the reliability ofthe mechanisms of transmission of messages between servicesand the reliability of the service itself. In the case underexamination, during the experimentation we had a reliabilityof the services offered equal to 100% throughout the period

6https://www.docker.com/7Apache Flink https://flink.apache.org/

of use. Furthermore, with the term reliability, that intrinsicproperty is also referred to in the communication and datatransmission systems. In this case, relying on data transmissionto the HTTP protocol, no data or errors were lost in thedata ingestion pipeline that remained reliable even in termsof transmission.

Availability. A crucial aspect in microservice architectures,directly affects the measurement of the time of operation ofa system. The estimation of the availability of the system canbe estimated from the single availability of the services thatmake up the system. In fact, even if a single service is notavailable, the whole system can be compromised. The morea component is subject to errors, the more the system willexpose malfunctions [20]. It was therefore decided to calibratethe number of services with the complexity of the service insuch a way as not to incur problems in terms of integrationand exchange of data. In fact, an excessive number of servicesleads to fragmentation and consequently to an excessive layerof communication and orchestration.

Performance. In terms of performance, it is good to distin-guish two types of services. The computational performancein this architecture is optimized because the entire architecturehas been tested on a PC with an Intel I7-2600 (3.4 GHz)processor with 6 GB of RAM. The main factor that negativelyaffects the performance in micro-service architectures is net-work communication. The latencies in this case are much morepronounced than reading data in RAM because it is preciselythe network stack that imposes delays in connections. In thearchitecture we propose, there is a balancing of communi-cations by optimizing the workloads of the services offeredand intra-service communications to obtain a low latency incommunications.

Security. Given the sensitivity of the system in question,mechanisms have been developed for authentication and accessto the system on both the user and application side. Theexposed microservice architecture exposes the same securityissues known for a Service Oriented Architecture (SOA)whereas both architectures use their own HTTP data exchangemechanisms.

VI. CONCLUSIONS

In this paper we propose a microservice-based architecturefor monitoring system to improve the safety of public build-ings. The framework was modeled according to a pattern-based concept of services implementation aimed at ensuringseveral non functional requirements granted from the modernsoftware architecture styles. The proposed architecture wasimplemented for monitoring near real time critical scenario,such as emergency, fire, etc to ensure rescue workers tointervene in a timely manner. A proof of concept validationrealized in a public building environment proved the validityof the proposed approach and the satisfaction of given nonfunctional requirements.

ACKNOWLEDGMENT

The authors would like to thank the SAFETY project.

REFERENCES

[1] V. Mighali, L. Patrono, M. L. Stefanizzi, J. J. Rodrigues, and P. Solic,“A smart remote elderly monitoring system based on iot technologies,”in Ubiquitous and Future Networks (ICUFN), 2017 Ninth InternationalConference on. IEEE, 2017, pp. 43–48.

[2] L. Mainetti, V. Mighali, L. Patrono, P. Rametta, and S. L. Oliva, “Anovel architecture enabling the visual implementation of web of thingsapplications,” in Software, Telecommunications and Computer Networks(SoftCOM), 2013 21st International Conference on. IEEE, 2013, pp.1–7.

[3] L. Mainetti, L. Patrono, and I. Sergi, “A survey on indoor positioningsystems,” in Software, Telecommunications and Computer Networks(SoftCOM), 2014 22nd International Conference on. IEEE, 2014, pp.111–120.

[4] S. Alletto, R. Cucchiara, G. Del Fiore, L. Mainetti, V. Mighali, L. Pa-trono, and G. Serra, “An indoor location-aware system for an iot-basedsmart museum,” IEEE Internet of Things Journal, vol. 3, no. 2, pp.244–253, 2016.

[5] L. Catarinucci, S. Guglielmi, L. Mainetti, V. Mighali, L. Patrono, M. L.Stefanizzi, and L. Tarricone, “An energy-efficient mac scheduler basedon a switched-beam antenna for wireless sensor networks,” Journal ofCommunications Software and Systems, vol. 9, no. 2, pp. 117–127, 2013.

[6] L. Catarinucci, D. De Donno, L. Mainetti, L. Palano, L. Patrono,M. L. Stefanizzi, and L. Tarricone, “An iot-aware architecture for smarthealthcare systems,” IEEE Internet of Things Journal, vol. 2, no. 6, pp.515–526, 2015.

[7] J. Lewis and M. Fowler, “Microservices: a definition of this newarchitectural term,” MartinFowler. com, vol. 25, 2014.

[8] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi,R. Mustafin, and L. Safina, “Microservices: yesterday, today, and tomor-row,” in Present and Ulterior Software Engineering. Springer, 2017,pp. 195–216.

[9] M. Mongiello, F. Nocera, A. Parchitelli, L. Patrono, P. Rametta, L. Ric-cardi, and I. Sergi, “A smart iot-aware system for crisis scenario man-agement,” Journal of Communications Software and Systems, vol. 14,no. 1, pp. 91–98, 2018.

[10] M. Mongiello, L. Patrono, T. D. Noia, F. Nocera, A. Parchitelli, I. Sergi,and P. Rametta, “A complex event processing based smart aid system forfire and danger management,” in 2017 7th IEEE International Workshopon Advances in Sensors and Interfaces (IWASI), June 2017, pp. 44–49.

[11] T. Di Noia, M. Mongiello, F. Nocera, and U. Straccia, “A fuzzyontology-based approach for tool-supported decision making in archi-tectural design,” Knowledge and Information Systems, pp. 1–30, 2017.

[12] F. Nocera, “Fuzzy ontology-driven web-based framework for supportingarchitectural design: Student research abstract,” in Proceedings of the31st Annual ACM Symposium on Applied Computing, ser. SAC ’16.New York, NY, USA: ACM, 2016, pp. 1361–1362.

[13] C. Guidi, I. Lanese, M. Mazzara, and F. Montesi, “Microservices: alanguage-based approach,” in Present and Ulterior Software Engineer-ing. Springer, 2017, pp. 217–225.

[14] F. Montesi, C. Guidi, and G. Zavattaro, “Service-oriented programmingwith jolie,” in Web Services Foundations. Springer, 2014, pp. 81–107.

[15] D. Taibi, V. Lenarduzzi, and C. Pahl, “Processes, motivations, and issuesfor migrating to microservices architectures: An empirical investigation,”IEEE Cloud Computing, vol. 4, no. 5, pp. 22–32, September 2017.

[16] L. Chaufournier, P. Sharma, P. Shenoy, and Y. Tay, “Containers andvirtual machines at scale: a comparative study,” in International Mid-dleware Conference (Middleware), 2016.

[17] P. Sharma, L. Chaufournier, P. Shenoy, and Y. C. Tay, “Containersand virtual machines at scale: A comparative study,” in Proceedingsof the 17th International Middleware Conference, ser. Middleware ’16.New York, NY, USA: ACM, 2016, pp. 1:1–1:13. [Online]. Available:http://doi.acm.org/10.1145/2988336.2988337

[18] M. Mongiello, T. di Noia, F. Nocera, E. di Sciascio, and A. Parchitelli,“Context-aware design of reflective middleware in the internet of every-thing,” in Software Technologies: Applications and Foundations. Cham:Springer International Publishing, 2016, pp. 423–435.

[19] N. Makitalo, F. Nocera, M. Mongiello et al., “Architecting the web ofthings for the fog computing era,” IET Software, 2018.

[20] L. Hatton, “Reexamining the fault density component size connection,”IEEE software, vol. 14, no. 2, pp. 89–97, 1997.