EVOLUTION OF MICROSERVICES IN INTERNET OF

THINGS

Submitted by:
SOMYA SINGH

Supervisor:
DR. DIRK PESCH

Second Reader:
DR. JAMES DOHERT Y

MSc Computing Science

School of Computer Science & Information Technology
University College, Cork

September 1, 2020
Somya Singh: Evolution of Microservices In Internet Of things, MSc Computing
Science, © September 1, 2020
 ii

Abstract

With the advent of Industry 4.0, the Internet of things has gained im-
mense popularity because of the features offered and seamless user ex-
perience. However, managing wired and wireless connections among
heterogeneous IoT devices has become a challenge due to various fac-
tors such as cost, size of generated data, lack of elasticity, and modularity.
Micro-services are UNIX like style patterns that encapsulate the concept
of modularization, emphasizing on technical boundaries. Every micro-
service operates as a small independent system and offers access to its
internal logic and data via network interfaces. Microservices resolve the
issues posed to IoT systems by building a large complex system with the
help of small, loosely coupled, scalable services working together in con-
cert. The presentation discusses the evolution of microservices in IoT, and
its successful implementation in various fields such as healthcare, trans-
portation, agriculture, housing, etc. Despite its benefits, implementing
microservices in IoT systems pose several challenges such as security of
applications deployed in the cloud, quality of services, and scheduling.
This presentation highlights these issues, their mitigation techniques, and
the future prospects of micro-services. Apart from all the advancements,
microservices still possess a few open issues leaving scope for improve-
ment.
Declaration

I confirm that, except where indicated through the proper use of citations and references,
this is my original work and that I have not submitted it for any other course or degree.

Signed:

Somya Singh
September 1, 2020

iii
Contents

Contents iv

List of Tables vi

List of Figures vii

1 Introduction 1
1.1 Research Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Research objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Key Concepts and Paradigms 5

2.1 Internet Of things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Monolithic Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 MicroServices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Principles of MicroServices . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Benefits of Microservices . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Limitations of Micro-services . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Microservice Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Monolithic vs Microservice Architecture . . . . . . . . . . . . . . . . . . . . 16
2.7 Service oriented Architecture vs Microservice Architecture . . . . . . . . . 16

3 Architectures of micro-service based IoT applications 19

3.1 Open IoT framework based on micro-services . . . . . . . . . . . . . . . . . 19
3.1.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Fog/Edge Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 E-healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Smart City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iv
Contents v

3.5 Smart Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Industrial Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Transportation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Osmotic Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Challenges in IoT systems and how Microservices mitigate them 38

4.1 Fault Tolerance and Fault Isolation . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.2 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2 Interoperable IoT Platform Based on Microservices . . . . . . . . . . 42
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2 Security via Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5 Challenges in Microservice based IoT systems and their mitigation techniques 46

5.1 Quality of Service(QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.2 Mitigation - Microservice QoS management System . . . . . . . . . 47
5.2 Security as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Open Challenges in implementing Microservices 50

6.0.1 Modularization Services . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.0.2 Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.0.3 Front -end integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.0.4 Resource monitoring and Management . . . . . . . . . . . . . . . . . 50
6.0.5 Failure and Self Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Conclusion an Future Scope 52

Bibliography 53
List of Tables

2.1 Comparison of Monolithic Architecture vs MSA . . . . . . . . . . . . . . . . 16

2.2 Comparison of SOA vs MSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Type of interoperability issues IoT systems . . . . . . . . . . . . . . . . . . . 42

4.2 Types of IoT security attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Microservice Quality of Service Parameters . . . . . . . . . . . . . . . . . . . 48

vi
List of Figures

1.1 Systematic Mapping Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Internet of things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Internet of things Architecture [Khan et al. 2012] . . . . . . . . . . . . . . . 6
2.3 Monolithic Layered Architecture [What are Microservices? (+Microservices
vs. Monolithic Architecture) n.d.] . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Service Oriented Architecture [What Is Service-Oriented Architecture? | by
Software Development Community | Medium n.d.] . . . . . . . . . . . . . . 9
2.5 Microservices Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Features of Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Individual Micro-service Architecure [Chapter 3: Architecture of a microser-
vice application - Microservices in Action n.d.] . . . . . . . . . . . . . . . . . 15
2.8 Monolithic Architecture vs MSA [Monolithic vs Microservices Architecture
(MSA) â BMC Blogs n.d.] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 SOA vs MSA [Microservices vs Service-Oriented Architecture (SOA): Funda-
mental Differences n.d.] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Proposed IoT framework [L. Sun, Li, and Memon 2017] . . . . . . . . . . . 20
3.2 IoT model based on micro-services in Fog/Edge Computing level [BANICA,
RADULESCU, and STEFAN 2018] . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Web of Objects reference architecture . . . . . . . . . . . . . . . . . . . . . . 23
3.4 WoO enabled data driven micro-service based E-healthcare model [M. A.
Jarwar, S. Ali, and Chong 2018] . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Beats Per minute architecture for Monitoring health related data [O’Brien,
and O’Reilly 2018] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Architecture of DIMMER platform for smart city [Krylovskiy, Jahn, and Patti
2015] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Architecture of InterScity platform [Del Esposte et al. 2017] . . . . . . . . . 29
3.8 Devices and their connection scheme in a Smart Building [Salikhov et al.
2016] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Microservice based Layered Industrial Internet of things model [Jürgen
Dobaj et al. 2018b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vii
Contents viii

3.10 Industrial Internet of things model using containerised micro-services

[Rufino et al. 2017] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.11 Functional IoT Architecture for micro-service based connected cars [Datta
et al. 2018] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.12 Functional elements of Cloud Based Car Services [Datta et al. 2018] . . . . 35
3.13 A two-layer federated cloud environment in osmotic computing [Massimo
Villari et al. 2016] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Interface between IoT devices and Microservices [Power, and Kotonya 2018] 40
4.2 Architecture of real-time fault tolerant microservice [Power, and Kotonya
2018] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Architecture of predictive fault tolerant microservice [Power, and Kotonya
2018] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Use Case Based On Interoperable Microservices for Ubiquitous IoT Ser-
vices [Muhammad Aslam Jarwar et al. 2017] . . . . . . . . . . . . . . . . . . 43
4.5 Interoperable Microservices within same domain and cross domain [Muham-
mad Aslam Jarwar et al. 2017] . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Distributed Certificate-Based IoT Service Security [M. Pahl, and Donini
2018] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Architecture of Microservice QoS management System [Al-Masri 2018] . . 47

5.2 Security Monitor deployment Strategy parencite sun2015security . . . . . 49
Chapter 1

Introduction

Microservices are an organizational and structural approach to software development,

fostering fault tolerant systems with small release cycles, an ability to scale up by using
an agile method of having multiple independent teams. These services are a combina-
tion of pre - existing software development concepts such as,

• Service Oriented architecture,

• Agile software development,

• API- driven design

• Continuous integration and delivery (CI/CD)

With the advent of IoT and DevOps, the architecture and design principle on which
IoT systems depend on has become one of the driving factors for success and sustainabil-
ity of an organization [Why IoT Development Needs Microservices and Containerization
n.d.] An IoT application is a vast distributed ecosystem of user ended devices, sensors,
actuators, protocols with no single owner which makes integration of these heteroge-
nous components a big, costly challenge. Also, to maximize elasticity and resiliency,
the system requires independent services joined together in concert. Furthermore, to
process large quantities of data generated by IoT systems, a suitable architecture is
required that can do so with minimum overhead.
In a micro-service approach, the business logic is broken down into several small,
independent, loosely coupled micro-services which are cost effective, and easier to
manage. With the help of micro-services, an organization can scale up their application
into large systems easily. Thus, using micro-services approach in IoT systems, reduces
integration cost and dependence between components. To maintain a large IoT system
with seamless user experience, there is a constant need to upgrade servers, devices.
Microservices provide the features of continuous integration and deployment facilities.
Also, small changes are quick to apply in microservices as they are independent of each
other.
1.1 RESEARCH PROBLEMS 2

Using microservices in IoT systems has many advantages. Firstly, since every micro-
service can be written in a different language, IoT systems use containers to deploy these
services. This deployment process is fast, independent of each other and promotes fault
isolation. Containers help in resource management as they can be added and removed,
based on requirement. Secondly, as the system scales up, the number of connected
devices in an IoT system increases. To store this huge amount of data and services, cloud
technologies are used. Microservices provide horizontal and vertical scaling where an
individual service can scale up without affecting others. Thirdly developing IoT systems
is a costly endeavor, microservices reduces that infrastructure cost, maintenance cost
of code repository and containers facilitate proper resource utilization. Fourthly, IoT
systems intend to provide coherent experience to the user. Using microservices with
containers is an optimal solution to achieve fast, resilient, highly available, scale on
demand services.[Why IoT Development Needs Microservices and Containerization n.d.]

1.1 Research Problems

The number of wired and wireless connected devices in the world is growing exponen-
tially. In 2011 Cisco estimated that by year 2020, the world will have 50 billion such
connected devices. Managing connections and communications among these devices
has become a challenge for monolithic systems. They are unable to scale up and handle
complexity after a certain limit. To overcome these challenges Service oriented Architec-
ture or SOA's were introduced. SOA involves splitting a monolithic system into multiple
independent, loosely coupled services that are communicating and coordinating with
each other. SOA in combination with IoT or CPS were able to handle the complexity
between devices, and overcame the problems faced due to decentralization. However,
service-oriented architectures cannot handle communication between heterogenous
devices or multiple service providers. As a result, in 2014 Microservices came into exis-
tence which were an implementation of SOA and emerged from the best practices of
software development. Use of microservices in internet of things has proved beneficial
because of the goal similarities between the two including autonomous deployment,
decentralized administration, independent development, light weight communication.
[Butzin, Golatowski, and Timmermann 2016].
Microservices follow a top down structure where a big system is broken into small
modular services whereas IoT works on a bottom up approach where individual services
align themselves according to the capabilities of their embedded structures. The main
challenge is to design interoperable services in such a way that value added application
can be built from these services.[Butzin, Golatowski, and Timmermann 2016] If IoT
aligns with the design structure of microservices, these value-added applications (Home-
kit by Apple [HomeKit - Wikipedia n.d.]) can be easily built. Many research articles have
been published which propose microservices architecture for IoT in areas ranging from
home automation to trickle drip irrigation. Analyzing these research papers will give an
insight into the future trends and also latest technological innovations, R& D work etc.
1.1 RESEARCH PROBLEMS 3

1.1.1 Research objective

This thesis identifies the role of microservices in Internet of things via past research work,
current state of the art , future trends etc. It also outlines several proposed microservice
architectures in the field of home automation, agriculture, healthcare, transportation
etc. It gives an insight into the benefits of using microservices over traditional mono-
lithic systems. In addition, it provides an overview of implementation challenges of
miroservices in IoT and their mitigation techniques.This thesis also discusses the open
challenges that are yet to be resolved, along with its future scope.
The thesis is structured as follows : Chapter 2 describes key concepts and classifica-
tions, followed by Chapter 3 underlining prior research work in various IoT domains.It
also elucidates critical analysis of each presented architecture.Chapter 4 outlines the
problems in IoT systems and how microservices approach resolves them.Chapter 5
describes various challenges in microservice based IoT systems and their mitigation
techniques.Chapter 6, lays down open challenges of implementing microservices in
IoT.Finally Chapter 7 , summarizes overall findings of this literature review , followed by
an insight into its future scope.

1.1.2 Research methodology

To find relevant studies and research areas of micro-services in Internet of Things, few
questions are formulates- What are the studies published by the scientific community
on the adoption of microservices in IoT, main contributions of the studies, trends of
research int he area of microservices in IoT.[Santana, Alencar, and Prazeres 2018] The
search string used for looking up published articles is "(internet of things" OR * IoT)
AND (microservice* OR micro-service* OR "micro services"*). The boolean AND /OR
unite the keywords and wildcards are used so that any relevant publications is not
missed. Four sources of publications - IEEE Xplore Digital library, ACM digital library,

Figure 1.1: Systematic Mapping Diagram

1.1 RESEARCH PROBLEMS 4

Scopus, Web of Science are selected.Searching the above mentioned string in these
four databases resulted in 700 publications, 242 Web Of Science,197 Acm, 439 Scopus,
182 IEEE.After removing the duplicates, the resultant articles were 646 . Finally, few
exclusion criteria’s are applied such as 1) "publications that are tutorial papers, editorials,
abstracts and extended abstracts, and proceeding papers are removed" 2) "publications
that are not available as full-text" [Campeanu 2018] resulting in 342 publications as
shown in fig 1.1 .
Chapter 2

Key Concepts and Paradigms

2.1 Internet Of things

The term Internet of things is an amalgamation of two words ’internet’ which refers
to interconnected network and ’things’ which refers to physical devices or objects like
laptop, computers, phones, tablets etc. Thus, internet of things is a wide network of
physical devices connected via standard protocols that collect data, process it and
execute autonomous decisions. In 1999 Kevin Ashton likely coined the term Internet of
things during his presentation at Proctor and Gamble, where he stressed on the use of
RFID's to manage, track and book-keep devices.

Figure 2.1: Internet of things

With the evolution of internet, society is moving to a phase of ’always connected

cyberspace’ through wired or wireless devices.Billions of devices are configured glob-
ally that are scalable, interoperable, reliable. As a result, the storage and processing
capacities of these devices is rapidly increasing with a decrease in their size. IoT plays
an important part in machine to machine communication embedding ’objects/devices’
into electronic software, sensors, actuators etc. These sensors collect data, process
2.1 INTERNET OF THINGS 6

information and take intelligent decisions based on the outcome. C OMMUNICATION

TECHNOLOGIES LIKE Z IGBEE , B LUETOOTH , L ORA , CONNECT HETEROGENEOUS I OT DE -
VICES WHERE EVERY OBJECT IS GIVEN A UNIQUE IDENTIFIER , AND CONNECTED TO THE
INTERNET FOR UBIQUITOUS COMPUTATION AND INFORMATION RETRIEVAL . IoT has
proven useful in various fields like, healthcare, transport, smart homes, communication
etc. It increases response and awareness to events, thus its use in industries like manu-
facturing, gas, healthcare improves output due to faster response time. Adding different
types of internet of things creates new business opportunities, like machine as a service,
lighting as a service.

2.1.1 Architecture
Internet of things architecture mainly consists of 5 layers Perception layer, Network
layer,Middleware layer,Application layer,Business layer as shown in Fig 2.2.

Figure 2.2: Internet of things Architecture [Khan et al. 2012]

1. Perception layer: Perception layer or the device layer consists of physical devices
like sensors (RFID, infrared, Lora) and actuators. It deals with device management
and collection of information such as temperature, humidity, location etc. about
objects with the help of sensors. The collected information is then passed onto
the network layer for secure transmission.

2. Network Layer: Network layer transfers information between the sensor devices
and central processing system. Technologies used are 3G, 4G, WiFi, Bluetooth
etc.
2.1 INTERNET OF THINGS 7

3. Middleware Layer : It is responsible for storing information into databases as

received from the network layer. It computes and processes the data and performs
desired operations based on the result. It also provides service management
functionality.

4. Application Layer : This layer provides an interface between the user and IoT.
It offers global application management based on the results from middleware
layer for applications like smart homes, smart watches, retail, tourism etc.

5. Business Layer: Business layer manages the entire system, processes results of
the data received from the lower layers and creates models, graphs, charts etc. for
executives to make an informed decision about business schemes.

2.1.2 Applications
IoT can be deployed into a wide variety of application domains ranging from Health-
care, smart environment domain to transportation and logistics, personal and social
domain [Patra, and Rao 2016]. Smart homes gives the ability to remotely control various
aspects of the house like lighting, security, appliances etc. Theft prevention applica-
tions are installed in homes, that inform the owner via sms, or alert in case of possible
encroachment on the property. Smart pool sensor system, smart garages, sprinkler
system , smart grid etc. are few other applications of smart homes. Transportation
systems gives the user alternate routes in case of traffic to prevent congestion and acci-
dents. Smart parking systems tells the user all the available spaces without having to
move around the entire area. Geo fencing tracks the location of a vehicle which helps
transport companies to track their vehicles. Environment monitoring systems help
monitor unmanned locations like volcanic activities, earthquakes and flood prone areas
and generate precautionary warnings in case of a calamity. Smart machines equipped
with sensors to detect pressure, humidity, temperature are helpful in various industrial
activities like mining.
Smart technologies like asthma monitors, depression monitors, ingestible sensors,
cancer monitoring system CYCORE, insulin pens, have proven extremely beneficial
in healthcare domain [10 examples of the Internet of Things in healthcare â Econsul-
tancy n.d.] Wearable devices like Smart watches with inbuilt proximity, accelerometer,
gyroscope sensors monitor a person's bodily movement including pedometer, heart
rate, blood, temperature pressure, sleep pattern. Smart shelves in supermarkets have
replaced paper labels with electronic labels, where the prices can be changed through a
centrally located system. The user can also scan the label using RFID readers embedded
with sensors to tag a product. Temperature sensors in stores maintain the temperature
of the freezers and the store.
2.2 MONOLITHIC ARCHITECTURE 8

2.2 Monolithic Architecture

In a monolithic architecture all parts are interwoven together as one deployment unit.
The architecture is divided into three tightly coupled layers as shown in Fig 2.3 : Applica-
tion layer, Middleware layer, and Database layer. The application layer is a client site
user interface that is responsible for delivery the queried data to the user. The middle
layer is responsible for execution of business logic with the help of the information
received from database layer. Using as single database has its own advantages as it is
easier to manage, data divided into partitions to scale up, define and track transactions.
Since the system is one deployment unit due to single shared code base, it easier and
faster to develop, deploy and maintain components, as long as the application remains
moderately small. These components are interdependent on each other for their in-
dividual operations. However, this often leads to reliability issues, because failure of
one can easily cascade to other, resulting in an application shut down. Also, in a single
repository removing and adding new servers after a certain threshold deteriorates the
code base and makes it unmanageable, leading to scalability issues. Refactoring a large
monolith application can cause issues, as change in one part of the application harms
another due to lack of test coverage.

Figure 2.3: Monolithic Layered Architecture [What are Microservices? (+Mi-

croservices vs. Monolithic Architecture) n.d.]

2.3 Service Oriented Architecture

Service oriented architectural design splits a monolithic system into multiple services,
such that each service performs an operation and all services communicate with each
2.4 MICROSERVICES 9

other as shown in fig 2.4. The main component in this structural design is formed
by services and rely heavily on it to perform business operations and functionalities.
SOA's are generally distributed in nature i.e., the services are accessed remotely through
remote access protocols like REST (Representational State Transfer), SOAP (Simple
Access Object Protocol), JMS (Java Messaging Service), RMI (remote method invocation).
SOA's are based on the principle of component sharing where each component has a
fixed set of roles and responsibilities and have 2 consideration types Service Request
and Service Response. Service Request defines the ability of a service to accept requests
or establish connections with remote services in a timely manner, whereas Services
Response describes the consumer's ability to receive a response from the service in an
acceptable duration of time. SOA's provide features like better scalability, decoupling,
greater control over development, testing, changes, deployment and modularity.

Figure 2.4: Service Oriented Architecture [What Is Service-Oriented Architecture?

| by Software Development Community | Medium n.d.]

2.4 MicroServices
Micro-Services is a type of service oriented architectural style pattern where a product is
decomposed into small building blocks such that each block performs a single operation
as shown in Fig 2.5. These blocks are often referred to as services. These services are
small, independent and focused in nature, and work together in cohesion with each
other .The term Micro Web Services was first introduced by Dr Peter Rogers in 2005 at a
conference as a ’Unix like pipeline’ architecture, where he illustrated how microservices
2.4 MICROSERVICES 10

platform can be created by combining the architectural principles of web and REST
Api together with UNIX like scheduling. Later on in 2011, Jamie Lewis and Fred George
described microservices in detail during two separate technical workshops. Today,
this architectural approach has been adopted by several huge companies like Netflix,
Amazon, LinkedIn, SoundCloud etc.

Figure 2.5: Microservices Layout

Microservice architecture comprises of a subset of business driven services, com-

municating with each other over API's. These services are fine grained, lightweight
and have a high degree of autonomy which means that each service can be changed
and deployed in isolation in the production environment without having to change
any other service associated with it. Thus, they are based on ’share as little as possible’
principles in order to prevent efferent coupling which is a situation that occurs when
components are tightly coupled together such that performance or execution of one
depends on the other.
Microservices have a limited taxonomy, which defines the type of services and their
roles in an service oriented architecture. There are mainly 2 types of services ’Functional
Services and Infrastructure services’. Functional Services are the ones that perform and
support functional capabilities like shipping, registry, temperature control etc. while,
infrastructure services perform nonfunctional operations like security, audit, logging
etc. Functional Services are shared externally and internally with other services while
the latter are not exposed to the outside world and are shared internally among other
services.
2.4 MICROSERVICES 11

2.4.1 Principles of MicroServices

Principles define constraints or a set of rules administrating proper implementation
and functioning of microservices. It ensures the system is efficiently put into operation,
it is resilient, observable, intelligent, fault tolerant by adopting fault isolation techniques
and following guidelines in case of cascading failures. Some of the principles are as
follows:

1. Modelling around Business Domain: In a three tier architecture every layer has
a clear set of boundaries and Api's, but it often leads to issues where a change
in one layer causes tumbling effects in rest of the layers. As a result, every layer
had to be altered even for a small change by different teams. To avoid this issue,
microservice architecture layers the system vertically so that business changes
are well within the service boundaries and only specific business domain services
needed to be changed. Every service contains its own three tier architecture. Mod-
elling a service around the business domain helps technical and non-technical
individuals to understand the system better. In addition to this, grouping services
that provide similar functionalities prove beneficial since the code is easier to
locate and fix. The teams working on these services have greater control on every
tier, instead of just one, broadening their technical skills.

2. Automation: Concepts of continuous delivery and continuous integration play a

vital role in maintaining and enhancing the quality of software with quick releases
and preventing change build up. API- driver host provisioning (AWS, Vmware)
make is easier to launch and configure systems, providing a production like
environment for the developer to test and deploy there changes. Automated unit,
integration testing mechanisms amplify code quality through several hundred
test cases.

3. Hide Implementation Details: Bounded context is a term that defines a logical

boundary around services such that data inside these services is independent
of other service data, and any change in one does not affect the other. Bounded
context is imperative in hiding operational details of a service. It is essential for
a service to decide the amount of data shared with other services and hidden
from, so that changes are accomplished independently, and one does not affect
the other. Also making alterations in a service becomes challenging when other
services have full access to it, therefore hiding implementation details of parts
where changes can be done becomes crucial. The most common approach for
this, is having different databases for every service.

4. Decentralization: Decentralization is one of the key aspects that should be con-

sidered when creating micro-services. It gives the developer an ability to make
changes in a component without having to co-ordinate with other components.
It grants ownership, independent decision making , along with the responsibility
of the whole lifecyle to development teams without having to depend on other
teams for testing , maintenance etc.
2.4 MICROSERVICES 12

Internal open source capabilities is also another way of achieving decentraliza-

tion, where service are open source and available within the entire internal system.
Members of any team can make use of other service's code base, suggest changes
or make changes to it. However it will depend on the team that originally build it
to accept or reject these changes. Message Brokers like RabbitMQ are examples of
routing between services through service buses. Choregraphed approach where
every service is only aware of the operations it performs and is unaware of other
service operations, is another way of achieving decentralization.

Figure 2.6: Features of Microservices

5. Independent Deployment: Independent deployment refers to the ability of a ser-

vice to make changes and deploy those changes in the production environment
without having to impact the operations of other services.This can be achieved
through one service per operating system, or virtual machine. Having more ser-
vice in a single container creates an interdependent web where change in one,
will affect the other.

6. Prioritizing Customers: Every successful microservice is a result of a consumer

driven approach. The services should be designed and built keeping in mind the
needs of a customer. Having frequent customer interactions through phone calls,
video conferences, forums, in house meetings are necessary for consumer driven
contracts. Appropriate business and functional requirement documents , user
manual/guidelines should be maintained. Having standard API's like Swagger
across the system maintains consistency all over.

7. Isolate failures: It is important to make distributed systems and microservices

resilient to prevent cascading failures. This ripple effect occurs when a service
calling another service, which is dependent on a third service, fails leading to
system shut down. Thus, isolating failures at every part of the system becomes
2.4 MICROSERVICES 13

necessary. Approaches like circuit breakers, timeout between components, bulk-

heads etc should be applied to achieve insulate failures. Bulkheading is a process
of having on thread pool per downstream application, where if a thread pool fails
or exhausts, there are others to rely upon.

8. Observable System: Microservice system should have standard monitoring facil-

ities like log formatting, auditing, log aggregation, registry etc. There must be
standardized format throughout the system irrespective of different technology
stack that are being used by individual services. Incorporating dashboard for
semantic monitoring should be in place to track the health of a system, network
and service outages.

2.4.2 Benefits of Microservices

Microservices offers a wide array of features that have proven to be advantageous over a
traditional monolithic architecture. Due to its benefits more and more companies are
adopting this style during software development cycle. Some of its advantages are listed
below :

1. Better Alignment with the Organisation: Adoption of microservice style pattern

provides a better alignment of the system architecture with that of the organiza-
tion's. Large development teams are broken down into smaller efficient teams
irrespective of their geographical locations which work independently, taking
ownership of their own services. According to Melvin Conway ’Any organiza-
tion that designs a system will produce a design whose structure is a copy of
the organization's communication structure.’ [The Principles of Microservices
n.d.] Microservices often help to scale the architecture of the system and the
organization for better growth as opposed to that of monolithic style.

2. Fast and Fault Tolerant: Changes to the services can be made easily and quickly as
compared to monolithic architecture and changes in one service does not impact
the working or require changes in other services. It is based on the concept of fault
isolation where a fault or bug in one service doesn't not disrupt other services.

3. Scalability: As the system is broken into small components, it is easier to scale up

or scale down an application depending upon the requirements as compared to
a monolithic where adding or removing resources from a large system becomes
difficult. The process of scalability also becomes cost effective comparatively.

4. Security:
In a traditional system, security is provided as an outer layer to the entire sys-
tem, however in a microservice architecture every individual service or group of
services can have a security feature. This adds an extra layer of protection.

5. Different Technology Stack: Every individual service in this architecture can be

written in a different programming language like Java, Ruby, C++, python unlike
2.4 MICROSERVICES 14

monolithic where there is one code base throughout the system and refactoring
it is difficult. The choice of technology depends upon the developer's comfort.

6. Independent Development and Deployment: Developing microservices in small

teams that are geographically separated grant developers more independence
and the ability to make technical decision quickly. Individual services can be
deployed independently, without affecting others, unlike in a monolithic pattern
where the entire code base is deployed together. Independent deployment results
in faster release cycle and quick consumer feedback.

7. Easier Data Management: Most of the services have their own databases, thus
making it decentralized with effective data management capabilities.

2.4.3 Limitations of Micro-services

1. Variety of Options to choose from: Micro-services provide a range of options in
term so technology stack, deployment techniques, testing mechanisms, archi-
tectural design, data storage etc which can tun into a disadvantage where the
developer is unable to make a choice and maintain such a diverse system.

2. No Short-term benefits: Services after deployment can take a long time to reap
benefits as it takes a significant amount of time to design, create and deploy a
service as it is a slow process. Initial investment in terms of effort is also large.

3. Complex testing scenarios: Testing services can seldom become a cumbersome

and complicated task when the tester has to decide what type of test cases and
how many test cases per services to execute. Also, queries like does changing a
component requires testing of that component only or all other services that are
communicating with it.

4. Monitoring issues:
In a monolithic system it is often easier to locate the problem site because of a
single code base, however, often in a micro-services architecture comprising of
100 or more services, exploring the area of issue can be difficult. Moreover, the
bigger the ecosystem of services harder it is to manage.

5. Resilience comes at a cost: Breaking a single system into multiple services to

make it more resilient can sometimes lead to cascading failures, where failure
of a service collapses other services, steering to a situation where the system
shuts down. Multiple databases can also result in transaction management,
information retrieval challenges.

6. Increased Number of Virtual Machines: In a micro-service style design, manually

managing, provisioning and controlling large number of machines/servers cre-
ates huge infrastructure requirement problems as every service can be deployed
on a separate server
2.5 MICROSERVICE ARCHITECTURE 15

7. Distributed systems are Complex: Understanding distributed systems and its

associated features can become grueling to understand as the system behavior
changes in different circumstances.

8. Experienced Developers required: Developing micro-services requires skilled and

experienced developers with deep insight in this field to make complex architec-
tural design decisions. Due to the technology stack(API's, communication buses)
that micro-services work upon, a developer needs to also undergo thorough
training.

2.5 Microservice Architecture

This architecture is relatively new and has gained popularity as a standard for develop-
ing large scale applications in the recent years after being published as a white paper
by Martin Fowler. They act as highly decoupled building blocks of a large complex
application. Microservice works on a divide and conquer formula, where a large mono-
lith is broken down into multiple individual services. An individual microservice is
similar to a monolithic application where it performs some logic, store data, returns the
result via API’s as shown in fig 2.7 [Chapter 3: Architecture of a microservice application
- Microservices in Action n.d.] .A micro-service communicate with other services via
standard API’s like Rest over light weight protocols such as HTTP. Each service runs as
multiple instance for scale and redundancy. Since every service performs one single task
only, it can be easily replaceable by another service if the first services fails, where the
latter starts from the previous one’s point of failure. It has its own separate datasource
to perform CRUD operations seamlessly. Since the size of a service is small and has
separate, it makes it easy to achieve modularity in the codebase and restricts access to
internal methods of other services.

Figure 2.7: Individual Micro-service Architecure [Chapter 3: Architecture of a

microservice application - Microservices in Action n.d.]
2.6 MONOLITHIC VS MICROSERVICE ARCHITECTURE 16

2.6 Monolithic vs Microservice Architecture

As described previously, monolithic architecture is a traditional style of software de-
velopment where all components are tightly coupled into a single unit, whereas in
micro-services architecture all components are deployed as micro-services that work
independently as shown in fig 2.8.They work with minimum communication with each
other over standard API’s . Micro-services are preferred in building applications that
need to be fast and scalable with huge amount of data. This style of application devel-
opment addresses all the shortcomings of a monolith application. And despite having
its certain drawback it serves as a better choice of design. Table 2.1 lays out difference
between both these architectural patterns.

Category Monolithic Architecture Micro-Service Architecture

Repository single code base for entire ap-
every microservice has its
plication own code base
Database single database for entire ap-
every micro-service can have
plication its own database, depending
upon need, such as NoSQL
,Relational
Scalabe Difficult to scale after a cer- Independent services can be
tain threshold scaled up based on require-
ments
Deployment Entire application deployed Independent deployment of
as one unit, change in one services, individual changed
,app needs to be redeployed don't impact each other
Ease to develop- Time consuming for devel- simple, easier to understand,
ers opers to understand large maintain
monoliths
Technology Stack single technology stack per Every service can be written
layer in any language
Fault isolation no fault isolation, can lead to Error in one service, doed not
system shutdown affect other services.

Table 2.1: Comparison of Monolithic Architecture vs MSA

2.7 Service oriented Architecture vs Microservice Ar-

chitecture
SOA’s follow a modularization approach to software development, with a collection of
disparate services communicating over a network. MSA’s are an implementation to
2.7 SERVICE ORIENTED ARCHITECTURE VS MICROSERVICE
ARCHITECTURE 17

Figure 2.8: Monolithic Architecture vs MSA [Monolithic vs Microservices Archi-

tecture (MSA) â BMC Blogs n.d.]

SOA’S but with limited and focused functionality as shown in fig 2.9. [Microservices vs
Service-Oriented Architecture (SOA): Fundamental Differences n.d.] per service. Services
in SAO can be large or small depending upon the requirements and are based on share as-
much-as-possible approach, whereas MSA follows share as-little-as-possible-approach.
Table 2.2lays out difference between both these architectural patterns.[Microservices vs
SOA: What’s the Difference? - DZone Microservices n.d.]

Category SOA MSA

Data Storage services share database each service can have it's
own database
Size small to large services, vary small in size, limited to one
according to requirements function per service
Fault Tolerant Issue in ESB’s can cause mul- Fault tolerant due to inde-
tiple service failure pendent services and deploy-
ment
Communication use ESB’S for communica- use messaging systems
tion among services
Threading Multithreaded systems with single threaded, focus on de-
focus in reusability coupling
Protocol Stack support multiple messaging use light weight protocols
protocols such as HTTP

Table 2.2: Comparison of SOA vs MSA

2.7 SERVICE ORIENTED ARCHITECTURE VS MICROSERVICE
ARCHITECTURE 18

Figure 2.9: SOA vs MSA [Microservices vs Service-Oriented Architecture (SOA):

Fundamental Differences n.d.]
Chapter 3

Architectures of micro-service based

IoT applications

Carefully designing an architecture is important as it can have implications on reliability,

sustainability, scalability of a software .The software should to robust, interchangeable
and rapidly growing. The services in this framework should exchange data over some
standard API's (REST, Swagger) with well-defined data formats like JSON or Xml. These
control passing features should be at the service boundaries. For internet of things,
SNON(sensor network object notation) data formats are used as they contain some pre-
defined fields that deals with sensors. Specifications like DDS(data distribution service)
or DDs- DLRL(DDS- data local reconstruction layer) are used to handle data interchange
responsibilities in IoT systems. Custom Api's are also created by some organizations
for specific data exchange. Messaging protocols are used for transfer of information,
like HTTP, UDP, COAP, MQTT, XMPP.HTTP and HTTPS are the most commonly used
protocols that use TCP for communication.UDP can be used where continuous sharing
of data is not required. MQTT can handle publish/subscribe mechanism between
machine to machine communication. XMPP is a xml based messaging protocol that is
designed for message based middleware communication.
Below mentioned are few proposed IoT frameworks based on micro-services :

3.1 Open IoT framework based on micro-services

[L. Sun, Li, and Memon 2017] depicts a generic microservices architecture for IoT
applications which breaks down the system into 9 manageable components as shown
in fig 3.1. Every service performs one business function and communicates with each
other over Rest API's with minimum overload. The system also uses publish subscribe
model to help the client subscribe to multiple topics and be notified every time with the
help of core service broker. The entire design is flexible and can be changed according
to requirement fluctuations. The system is made up of 8 microservices and one core
service, which are as follows:
3.1 OPEN IOT FRAMEWORK BASED ON MICRO-SERVICES 20

Figure 3.1: Proposed IoT framework [L. Sun, Li, and Memon 2017]

• Core Service : Core service is the central service which regulates and administers
all other services. It loads several tenant engines which performs most of the
processing logic in the system. The core service provides asynchronous commu-
nication (via ActivemQ) of the object nodes between microservices and external
components.

• Geo Microservice: It is developed over the Geoserver.This service provides loca-

tion data by implementing map API over GIS layer.The service creates a layer
dynamically by invoking REST Api on map UI library.

• Security Service: The security service manages authentication and authorization

of user and management roles. It stores access control policies of a user and
checks it during create or change operations on entities, to identify which rights
the user possesses. It also helps several other operations including monitoring,
auditing, administration ,single sign on.[Sill 2016].

• Tenant Service : It uses a multi-tenant design where a microservice can be used

by multiple application architecture with a single instance. It is mainly used
for logging and auditing purpose. Every tenant has a separate data store and a
processing pipeline to isolate data and support logic isolation.[Sill 2016].

• Device Service : It manages and assigns device plugins based on the device's
hardware specification and meta data. It communicates with low level hardware
to collect data from sensors and passes it to actuators for execution.

• BigData Service : It provides different persistence types like MongoDB for docu-
ment storage , REDIS for photo data storage to store data .It adds new storage im-
3.2 FOG/EDGE COMPUTING 21

plementation in the system by communicating through encapsulated Api's.Direct

database operations are not allowed, instead CRUD API's are used for information
storage and retrieval.

• Automation Service : It monitors ,analyses and processes events generated by

different event sources and notifies the participants through queries.

• Artificial Intelligence Service : This service is based on IoT big data and provide AI
tools like machine learning, data mining etc.

• Application Service : This application provides user interface through mobile

apps, client computer etc.

3.1.1 Discussion

3.2 Fog/Edge Computing

Due to advancements in IoT applications, today people rely heavily on their smart
phones applications or wearable devices to connect to their surroundings to gather
information and assistance around them Fog acts as a middle layer between the cloud
and IoT devices. Fog nodes are devices that have storage and computational capacity ,
network connectivity and the ability to be placed anywhere within the network. These
fog nodes help in analyzing the IoT data better, because closer the point of collection,
lesser is the latency. Also, it reduces the load on the network traffic, and keeps the data
secure within the internal network. For instance, fog nodes are most helpful when there
is time sensitive data as the response is generated within milliseconds or sub second as
compared to uploading it on the cloud for historical analysis which can takes days or
hours [computing-overview.pdf n.d.] This model is best suited for distribution and retail
sector where accurate real time data is necessary for supply chain management . The
model proposed by Banica et al [BANICA, RADULESCU, and STEFAN 2018] is divided
into four layers as shown in fig 3.2 .They are as follows :

• Physical layer : This layer contains sensors, actuators, data captors, collection de-
vices that accumulate data from the environment, detection devices that identify
the presence of other IoT devices.

• Network layer. This layer facilitates communication and data transfer between
the nodes.

• Fog/Edge Layer: This layer stores, computes and analyses, the data received from
network layer. Computing the data involves filtering it according to a specific
criterion, data formatting, and decryption. Micro-services are embedded in
the fog/Edge nodes and are accessible by all other IoT devices in the system
via standard Api's over HTTP. Th end users indirectly communicate with these
micro-services through Api gateways, that route user request to these services,
3.2 FOG/EDGE COMPUTING 22

Figure 3.2: IoT model based on micro-services in Fog/Edge Computing level

[BANICA, RADULESCU, and STEFAN 2018]

and receives a desired response from it. This Api gateway performs several other
operations like User authentication, load balancing, SSL connections.

• Cloud Layer: This layers provides various services including data mining, data
analytics, storage service to backup received data into databases, and analyze
them to predict the future state of devices.

Similar to the previous architecture authors of [Taherizadeh, Stankovski, and Gro-

belnik 2018] present a fog and edge based innovative capillary distributed computing
framework for IOT devices such as cars, smartphones , robots, rasberry pi’s. It supports
data intensive applications that run at edge of the network and is based on a monitor
analyze plan execute reference model. The monitor provides input data to the analyzer,
which in turn performs decision making over self adaptation.As per the adaptation
mechanisms the planner generates suitable actions for the target system to perfom.
Microservices are embedded in the edge computing resources.These microservices can
be offloaded at run time from the edge node to fog node in case of limited available
resources.

3.2.1 Discussion
Fog computing bring the cloud services closer to IoT devices by reducing the distance
between them for analysis of data .It also acts as a secondary data storage apart from
3.3 E-HEALTHCARE 23

cloud.Both the architecture used fog and edge nodes to its advantage.Offloading micro-
services from edge to fog node allows elasticity in the application in case edge node
becomes overloaded.in comparison to cloud environment, fog computing reduces
network traffic and latency, thus increasing response time.However, this also leads to
issues such as task scheduling and resource management.For instance, if the fog node
is overloaded, the mobility of microservices from fog to cloud during execution is also
impacted.

3.3 E-healthcare
Depression is a form of mental illness that affects a person's state of mind, well-being
,persistent sadness, and can lead to serious consequences like suicide. According to
WHO, depression affects more than 264 million people all over the world and 800000
people die due to suicide.[Depression n.d.] 70-80% people in low income countries
receive no treatment due to lack of resources, lack of healthcare providers, inaccurate
assessment. Today IoT based E-healthcare applications make use of wearable and non-
wearable IoT devices to gauge an individual's mental well-being by collecting everyday
data and analyse it to provide assistance to the patient, by connecting the patient to
the psychiatric. However, the data received from various IoT devices including wear-
ables, sensors, electronically saved medication history ,emotional quotient collected
via social network services etc, is not semantically interoperable. This makes it difficult
to accurately accumulate , analyse , and assess it. To achieve this semantic interoper-
ability, Jarwar et al [M. A. Jarwar, S. Ali, and Chong 2018] suggest a IoT system that uses
WoO(Web of Objects) enabled data driven microservices as shown in fig 3.3 and fig 3.4.
WoO is a three layered architecture.

Figure 3.3: Web of Objects reference architecture

• VO(virtual object) layer collects data from real world objects like sensors, actua-
tors and pass it in to the CVO layer.
3.3 E-HEALTHCARE 24

• CVO(Composite virtual object) layer processes the data received from the VO
layer.This data is then used by microservices.

• Service layer provides amenities to end user applications based on the knowledge
provided by the micro-services.

Figure 3.4: WoO enabled data driven micro-service based E-healthcare model
[M. A. Jarwar, S. Ali, and Chong 2018]

With the help of machine learning models, these microservices, exchange, share and
translate and format data into a uniformly understandable form for accurate processing.
Firstly micro-services are placed at the virtual object level to make the physical devices
interoperable by communicating over vendor specific API'S and data formats. Every
object has a separate service which can be used to read data from sensors or send
commands to actuators. Additionally, they are also placed at the CVO layer to supply
processed data to the service layer. Every microservice has one or more CVO data to
enable reusability and modularity.[M. A. Jarwar, S. Ali, and Chong 2018] These services
contain the logic in the form of microcode, and provide user customized e healthcare
services.The application system is divided into two parts and hosted on two servers.
First server is responsible for collecting and processing information from the user using
machine learning and data mining techniques while the second server is responsible
for providing services to the user using WoO architecture.
Contrary to the Web of Objects based architecture 'Brien et al [O’Brien, and O’Reilly
2018] discusses a microservice based monitoring framework Beats Per Minute(BPM)
that process data from activity trackers to analyse a user’s heart rate and symptoms of
heart related diseases.Activity trackers are very useful in gathering everyday user data
3.3 E-HEALTHCARE 25

such as heart rate, steps per day, calories burnt,blood pressure, respiration etc.Real time
data from sensors is collected for diagnostic purposes. BPM application is used by two
types of users 1) Clients whose heart rate data is collected and 2) administrator : users
who are doctors or admins that utilise this information for analysis. This application
stores historical data of users and helps in accurate analysis with the large amount if
data available.Any type of heart related ailment can be detected ,prevented and cured
at an earlier stage.The messages are encoded via SOAP and sent over HTTP. The fig 3.5
shows a BPM model comprising of 4 services:

Figure 3.5: Beats Per minute architecture for Monitoring health related data
[O’Brien, and O’Reilly 2018]

• Data Service :This service is responsible for polling data from the activity trackers,
as well as converting the data into a compatible format.This service has access to
the database.

• Viewer Service : This service displays heart rate visuals in the form of charts in the
browser using the data from the dataservice.

• Analysis Service :It is responsible for analysing and performing calculations on

the user data .

• Alert Service : This service generates alerts in the form of emails or SMS when a
user’s heart rate exceeds a certain threshold.

Similar to the above mentioned framework, Richard Hill et al. also describes a
health care application based on microservices.Wearable biosensors monitor patients
heart rate, blood pressure, glucose level as well as environment sensing features such as
occupancy and pressure in a room.Secondly, computational hardware can be embed-
ded in the patients home using FPGA(field programmable gate arrays) for monitoring,
3.4 SMART CITY 26

collecting and processing of personal health data.This stream of continuos data stored
in elastic cloud services and used by authorised personnel only.[Hill, Shadija, and Rezai
2017]

3.3.1 Discussion
The first application monitors user’s real time feelings, emotions at home, office, through
social media tweets, wearable devices, facial expressions. This data proves helpful in
precise depression diagnosis. This information is stored as user’s history which can
be utilised later for diagnostic purposes. Web of Objects (WoO) architecture is useful
for providing web based IoT services to the user.[Yu et al. 2018] This model makes the
system interoperable, adaptable, and intelligent. It resolves the issue of collecting data
from several heterogeneous sources.Whereas, the second model also monitors user’s
heart rate and stores the data for diagnostic purposes in cloud based services.This
application also leverages cloud infrastructure for scaling the framework as the user
base grows.
However the first architecture does not address the security and privacy concerns
related to user data. It lacks security enabling micro-services to handle information
collected from the user’s via cars, home, wearable devices. Also, data hosted in the
cloud can be susceptible to attacks. Thirdly, since every object has a separate service,
the number of services required are more. Using two separate servers for storage and
services requires additional overhead of maintaining the servers.In contrast , the second
model faces issues due to the number of calls permitted for every activity tracker.For
instance Fit Bit allows 150 calls per hour , as a result of which data can be collected every
24 secs only.In addition to that, the time taken by the activity tracker to sync the data in
its data store and then be polled by the BPM is large, thus defeating the purpose of real
time data collection.

3.4 Smart City

Due to diverse IoT systems available in the market today, there is a high demand for
building robust infrastructures and service platforms to utilize IoT data and perform
operations such as energy management, user surveillance,traffic management etc.
Alexandr Krylovskiy et al [Krylovskiy, Jahn, and Patti 2015] describes a smarty city plat-
form (DIMMER platform) that encompasses several services to make an energy efficient
city with the help of energy data simulators, context awareness frameworks etc. Fig 3.6
below shows the DIMMER platform which is divided into three conceptual layers.At
the bottom lies sensor technologies and District information models that are used by
smart city applications.The second layer is a service platform which is a combination
of middle-ware services such as service catalog, resource catalog, message broker and
smart City services such as geographic information service(GIS), business information
model (BIM) , system information models(SIM) etc.Middleware services gather the
3.4 SMART CITY 27

information from the sensor systems and process the data for further analysis. The top-
most layer represents smart city applications like desktop, laptop, mobile applications
that are used by system administrators, common citizens, energy professionals,and
even third party organisations for their internal purpose.

Figure 3.6: Architecture of DIMMER platform for smart city [Krylovskiy, Jahn,
and Patti 2015]

Service Platform: The service platform acts as an integration between IoT devices
and ICT system(hardware, software, communication technology, data).It is divided into
two types of micro-services :

• MiddleWare Service :This service accesses real time sensor data via standard API’s
and protocols, models an abstraction between real world IoT devices and sensors,
help applications search and discover these devices for resource utilization.Every
service has its own data store to manage IoT devices meta-data efficiently.An
IoT data gateway that acts as an interface between the services and applications,
which distributes consumer requests to appropriate platform services and returns
the response to consumers conveniently.in Few micro-services in middleware
are as follows:

– Resource Catalog: It is responsible for providing information regarding IoT

devices such as configuration details ,deployment techniques, communica-
tion protocols.
– Semantic Data Store: It uses semantic web technologies to provide ad-
ditional information about devices,their relation with other entities and
platform services etc.
– Historical DataStore : This micro-service uses time-series database for
storing large amount of sensor data.
3.4 SMART CITY 28

– MessageBroker: It is used for publish/subscribe communication of sensor

data.

• Smart City Services :They enforce the core functionality of the DIMMER platform
and are built on top of IoT middleware.Some of the micro-services are as follows :

– Energy efficiency engine: This service is used by applications to optimize

district energy consumption, with the help of optimization algorithm .
– Context awareness framework : It provides context awareness feature to
applications which can then simulate real world situations and monitor for
changes.

Contrary to DIMMER platform , Esposte et al. [Del Esposte et al. 2017] describe an
open source micro-service based smarty city platform InterSCity, that aims at being
modular, high quality, scalable middleware infrastructure that can be re- used across
cities by government and companies.It uses open source technologies and methods to
support future smart city platforms.New devices are added to the system via IoT gateway
and the sensors communicate with each other over Rest API.The framework contains 6
microservices as shown in fig 3.7 namely,
• Resource Adapter :service is for integrating IoT devices.It allows IoT gateways to
register and update resources on the platform.

• Resource Catalog, Data Collector, Actuator Controller : These services are used
for data and resource management.Resource Catalog registers and assigns all the
city resources with a unique identifier and notifies other services about it.Data
Collector stores sensor data such as linked event , context information etc. gath-
ered by the city resources. Actuator collector service is used for auditing purpose
and store all actuation request made by the city resources.

• Resource Discovery: This service is used by client applications such as Smart

Parking App to search for city resources via context -aware search API.

• Resource Viewer : This is a visualization service that graphically presents city

resources from the data collected by data collector and resource catalog.
The services communicate with each other over asynchronous messages through
AMQP(Advanced Message Queuing protocol).The client applications interact with the
platform via City resources such as buses cars, their location, direction etc such that if
two buses registered on the smart city platform are accessed, it is done over the same
standardized API irrespective of the device or communication technology being used
.[Del Esposte et al. 2017]

3.4.1 Discussion
Smart cities have becomes extremely necessary and pervasive over the last few years due
to the flexible architecture it provides which can be altered as per the evolving customer
3.5 SMART BUILDING 29

Figure 3.7: Architecture of InterScity platform [Del Esposte et al. 2017]

needs [Badii et al. 2019].They are designed to fulfil functional and non functional re-
quirements of its citizens.Both the models encapsulate all the necessary functionalities
that a smart city has to offer in a very robust and transparent manner.Use of microser-
vices resolve interoperability issues and a need for standardised deployment strategy
across all cities.Real time services can be quickly availed by consumers through their
mobile phones, which is a bonus.
Apart from the advantages the first model lacks a centralized monitoring system to
monitor proper functioning of each application.Also, the architecture leave open issues
of scalability and performance.The second InterScity model however, talks about open
source technologies that are used in the platform to prevent vendor lock in and promote
interoperability.This helps to scale the model in future.The first architecture uses only
rest API’s for communication whereas the second also uses asynchronous messaging
system which prevents blocking of synchronous request and reply interactions.Thirdly,
with the large amount of data that is generated per city there is no provision for cloud
data storage facilities in first model whereas the second model uses cloud based services
to store IoT resources and hosts the platform in a cloud infrastructure.

3.5 Smart Building

IoT sensing and perception technologies are widely available to detect temperature,
humidity, pressure along with emotional state of people inside the building. Micropro-
cessor platforms that connect with sensors to generate and process data with small
3.5 SMART BUILDING 30

battery powers are also readily available.It is easy to provide a wide area network on
these platforms due to increase of network technologies.All these factors lead to the
development of smart buildings that use underlying IoT technologies which can evolve
over time according to changing consumer needs. [Salikhov et al. 2016] describes a
Intranet of things based Smart building that uses micro-services as its underlying ar-
chitecture.This system uses Jolie programming language for developing micro-services
as they can be reused, orchestrated and combined with other services.Since a single
platform communicates with all the sensor devices, it generates huge amounts of data.
To handle the data in large quantities, Could computing resources are used to reduce
computational pressure on the system. As shown in fig 3.8 sensors and raspberry pie
are configured and connected via Bluetooth technology to detect temperature, pressure
, luminosity, humidity.A door sensor is also incorporated to detect human presence at
the entry and exit points of the premises.Services developed in Jolie are reused by sev-
eral sensors for connectivity, data retrieval and other processing The data(temperature,
humidity, pressure) collected from these sensor Tags is parsed and stored along with
outdoor temperature data gathered from Internet in a file. The data generated from
the door sensors is cross referenced with the web camera at the door for corrobora-
tion.Presence of a person is also verified using mac address of their smart watches which
tells the total number of people in the building at any given point of time.

Figure 3.8: Devices and their connection scheme in a Smart Building [Salikhov
et al. 2016]
3.6 INDUSTRIAL INTERNET OF THINGS 31

3.5.1 Discussion
Using Jolie as the programming language for developing microservices has its own
benefits.It creates blocks of software as services instead of functions or objects, which
can be relocated and reused as required. One of the main selling points of micro-
services is its reusability and orthogonality and Jolie provides both these features in its
design.Smart Housing society’s are a product of innovation in IoT. It provides security,
energy efficiency, flexibility to the consumers. Using Bluetooth low energy (BLE)for
measuring lighting, temperature and pressure overcomes the drawbacks of Zigbee and
Wifi. Bluetooth is a low power radio technology that is present in almost every smart
phone available in the market today, unlike Zigbee which requires an additional dongle
or gateway to connect.BLE controlled devices are easy to setup and are cost effective.
Aside from the advantages , this smart building architecture does not address secu-
rity concerns related to cloud data management, and data transfer between sensors and
the cloud. Moreover, this architecture depends upon mac address of smart watches to
verify the presence of a person inside the building which is an added requirement of
wearing a smart watch while entering and leaving the building.

3.6 Industrial Internet of Things

After the advent of Industry 4.0, Internet of things has played a major role in manu-
facturing, automation, and industrial sector.It has led to development of innovative
technologies, heterogeneous devices that can communicate with each other on a larger
scale. Dobaj et al [Jürgen Dobaj et al. 2018b] describes a four layered micro-service
based architecture for industrial internet of things, as shown in fig 3.9.Every layer has
several micro-services which interact with each other within the layer and vertically
with services in other layers.The four levels are as follows :

• Domain Specific Service(DSS)) Layer :It is the topmost layer that provides services
and device limited functionalities to the system based on different domains.Data
Specific Service(DSS) encapsulates the services offered by this layer from low
level functionalities implemented by lower layers, thereby reducing complexity
and facilitating reusability of micro-services.The number of services(DSS’S) on
this layer depends on domain specific requirements of a system and multiple
DSS’s can execute simultaneously on a device.[Jürgen Dobaj et al. 2018b]

• Domain Specific Data Abstraction Layer: It acts as a middleware between DSS

and DDS layer .It is responsible for management of device’s state and it’s local
data through CRUD operation.It hosts a process variable service that consists of a
process variable pool and mediator.The process variable pool maintains all the
operations of a device along with variables that describe it’s state.The mediator
acts as a synchronization mechanism between DSS and DDS layer and helps the
process pool to update its variables and data models.
3.6 INDUSTRIAL INTERNET OF THINGS 32

• Domain Distribution Service(DDS) Layer :This layer integrates heterogeneous

devices ,protocols and facilitates communication between them .It also manages
service discovery and data distribution. It follows a publish subscribe model
and passes information received from physical devices to process variable ser-
vice.[Jürgen Dobaj et al. 2018a] Sometimes, it also filters and processes the re-
ceived data to optimize resource consumption before passing it to the process
variable service.

• Distributed Global Data Space(DGDS):This layer routes entire system data across
sensors, fog, cloud devices, subsystems etc.It also acts as an abstraction for
network and hardware details to facilitate interoperability among heterogeneous
devices in the top layers,

Figure 3.9: Microservice based Layered Industrial Internet of things model

[Jürgen Dobaj et al. 2018b]

On the other Hand, Rufino et al [Rufino et al. 2017] describes an IIoT architecture
using containerised micro-services.Unlike the previous framework, this model uses
Docker, an open source platform, used by developers to build ,share and execute their
distributed applications.Docker helps in scaling the architecture while containerisation
promotes service isolation .Micro-services are divided into smaller services and spread
throughout the system to achieve modularization and decentralization.Every service
is embedded in a docker container as shown in fig 3.10 and run independently.The
architecture is divided into three layers.

• Sensing layer : This layer communicates and senses outside physical systems and
end users.The data collected from this monitoring process is stored in a gateway
which forms the second layer.Services stored in containers can be deployed and
scaled up on demand.
3.6 INDUSTRIAL INTERNET OF THINGS 33

Figure 3.10: Industrial Internet of things model using containerised micro-

services [Rufino et al. 2017]

• Mediation Layer :The gateway acts as a mediator for communication between the
other two layers and is used for data processing and data analytics. The gateway
acts as fog computing paradigm and reduces the gap between the nodes and
cloud resources .It hiss three microservices namely, SDN controller, database,
machine learning unit.The controller is responsible for controlling the networked
devices, facilitating communication between them.[Rufino et al. 2017] The ma-
chine learning unit provides intelligence to the gateway to resolve real time
requirements.It communicates with the controller adn distributed database for
analytical purpose.

• Enterprise layer :This layer performs CPU intensive services like data mining, data
treatment, data modelling, behaviour analysis etc.Enterprise systems act as main
management and control entities.

3.6.1 Discussion
The demand for industrial internet of things applications is growing with the increase
in IoT technologies. However, this has also led to technology fragmentation as sev-
eral providers have come up with their own IoT technologies, sensors etc each work-
ing on a different communication model.This heterogeneity leads to interoperability
issues within the IIoT systems as explained in section 4.2.1.The first model success-
fully resolves interoperability issue via services hosted in the distributed global data
space(DGDS).Secondly, since data and information flows seamlessly through each lay-
ers for processing and storage, QoS and data consistency is maintained throughout the
system instead of being constrained at each level separately.However, this model does
not specify the types of micro services used and their data storage capabilities.Similarly,
the second architecture uses Docker as a virtualization technique simplifies manage-
ment and promotes distributed deployment. Interoperability is achieved via REST
protocols and distributed database as the gateway. However data consistency remains a
challenge since all the micro -services share a database.
3.7 TRANSPORTATION 34

3.7 Transportation
Explosion of IoT systems have resulted in inventions in the connected car domain.Micro
services when used in conjunction with IoT systems integrate heterogeneous sensors
and vehicular communication technologies for data annotation and local data pro-
cessing using edge servers. [Datta et al. 2018] depicts an architecture of a connected
car using micro-services as shown in fig 3.11 . A connected car is an IoT resource that
provides functionalities such as cellular connection , efficient emission management,
real time data collection using IoT platforms.The framework consists of micro-services ,
an edge server, WOT based things repository, Restful API’s etc.

Figure 3.11: Functional IoT Architecture for micro-service based connected cars
[Datta et al. 2018]

• Connected Car : The system includes one connected car, containing a vehicular
onboarding unit(OBU) that embeds vehicular intelligence in the car .A Thing
Descriptor(TD) connects the car to an IoT system which shows events, processes
available to sensors and actuators.Interoperability between car services is main-
tained using W3C Web of Things initiative.
Edge Server : An edge server is used for vehicular data validation, processing, actu-
ation and exchange with cloud services.It includes two interfaces for V2X(Vehicle
to everything) and cloud communication.V2X is a car communication system
used for autonomous driving where information from sensors and actuators is
sent using high bandwidth and low latency[What is V2X communication? Creat-
ing connectivity for the autonomous car era | ZDNet n.d.]The edge server gathers
heterogeneous data from the sensors and performs annotations based on infor-
mation like timestamp, type of sensor,operation domain etc.For instance, it uses
3.7 TRANSPORTATION 35

temperature and humidity sensor information and makes the server turn on fog
lamp of the car in case of foggy weather.
Cloud based micro-services The services use HTTPS to exchange encrypted data(AES)
with the edge server and connected car .The secure provisioning service uses
JSON Web Token for authentication and authorization of data.Sensors,actuators
and Things Descriptor are first registered with the Thing Repository and then
securely stored in the cloud.Separate services are used for semantic reasoning
on vehicular data for trajectory mining and tourism recommendation system
[Datta et al. 2018] These micro-services hosted in the cloud use containers for
deployment and support scalability, modularity, virtualization in the cloud.
Cloud And Control Things Application : This android application is available
to the user for monitoring and visualizing TD services and data of a connected
car.The services include experiment submission and report generation as shown
in fig 3.12 .

Figure 3.12: Functional elements of Cloud Based Car Services [Datta et al. 2018]

3.7.1 Discussion
The architecture highlights efficient use of micro services to integrate heterogeneous
components together,solving the issue of interoperability.Use of micro services make the
application scalable with the ability to seamlessly add new services such as positioning
service for geo location.Connected cars are means for ’vehicle to Internet’ and ’vehicle
to vehicle’ communication.These interactions help to combat several transportation
issues such has heavy traffic, vehicle safety, and congestion.Vehicle to Vehicle (V2V)
3.8 OSMOTIC COMPUTING 36

communication helps the driver in prevention against collision, improved personal

safety and traffic management.Vehicle to internet communication provides the driver
with facilities such as audio playback, live location services, historical data etc.[El Yassini
n.d.]
Apart from the benefits offered by this framework, security of data being trans-
ferred to the cloud remains a challenge as explained in section 5.2.1.Firstly , Encryption
technology used is AES which can be decrypted resulting in information exploitation.
Secondly , implementing resource discovery services, edge server are a costly affair.
Thirdly, due to the presence of different car manufacturers,telecom providers , support
for several communication technologies with V2X technology is a challenge, as it may
lead to incompatibility issues.

3.8 Osmotic Computing

Osmotic Computing divides services based on their resource usage and parameters like
energy, processing time and load [Sharma et al. 2017]."Osmotic computing implies the
dynamic management of services and microservices across cloud and edge datacenters,
addressing issues related to deployment, networking, and security, thus providing reliable
IoT support with specified levels of QoS". [M. Villari et al. 2016]It decomposes the appli-
cation into small micro-services deployed in containers that exploit resources at cloud
infrastructure.

Figure 3.13: A two-layer federated cloud environment in osmotic computing

[Massimo Villari et al. 2016]

MarioFazio et al [Massimo Villari et al. 2016] illustrates a two layered architecture

for osmotic computing as shown in fig 3.13 . The top L1 layer consist of cloud data
centers, hosting several microservices formulated according to user’s requirements.
The lower L2 layer is made up of edge data centers consisting of data capture points
3.8 OSMOTIC COMPUTING 37

and gateway nodes.These devices collect raw data , encrypt the incoming data stream ,
encode the transactions and send it to the L1 layer for further analysis.The devices at
L2 are resource constrained and work on low power, limited network etc. that perform
operations without exploiting available resources.General purpose microservices ,net-
work management services , security management services are utilised by both layers
for efficient resource and service sharing.The network management service helps in
setting up virtual networks in a federated cloud/edge environment, whereas microser-
vices offering security management help in their cross platform development.These
microservices are deployed in virtual containers to reduce deployment overhead.

3.8.1 Discussion
The symbiosis of IoT,edge and microservices is a revolutionary concept that balances
load distribution between cloud and edge resources.It divides tasks into macro and
micro services and assign them an infrastructure for faster computation.However, this
architecture does not describe resource scheduling which is crucial for managing a wide
array of microservices [Maksimović 2018].Secondly, QoS metrics are not available in the
system to gauge the performance of the application.Thirdly,the model lacks a standard
security policy required for execution and deployment of micro-services within cloud
data centers and edge servers.
Chapter 4

Challenges in IoT systems and how

Microservices mitigate them

4.1 Fault Tolerance and Fault Isolation

4.1.1 Challenges
IoT systems are driven by data and to maintain billions of connections between IoT
devices, a durable infrastructure is required. The system should provide services which
are reliable, trustworthy, highly available, while maintaining the quality of service. This
dependable system is often threatened by faults and errors that can cause system failure.
These faults can be mitigated by three approaches:

• Fault Avoidance : Avoid the introduction of errors in the design and program-
ming phase.

• Fault detection and correction : Remove faults before deployment by verification

and validation.

• Fault tolerance: design the system such that it can detect and recover from faults
itself.

Achieving fault tolerance is challenging in IoT systems because of their distributed

nature. Distributed systems are prone to several failures such as 1) Crash failure: that
occurs when the system server stops and a restart is required.2)Omission failure: it
occurs when the server stops sending and receiving messages.3)Timing failure:it occurs
when the server responds too fast or very slowly.4)Response failure:occurs when the
response generated from the server is incorrect. 5)Arbitrary failure: occurs when the
root cause of the failure is unknown. These failures occur because IoT devices depend
upon wireless communication and are typically constrained in terms of energy, com-
putation, resources).As a result, these systems are unable to handle recovery strategies
and when a fault occur they rely on a third party like cloud or fog to handle and mitigate
4.1 FAULT TOLERANCE AND FAULT ISOLATION 39

it. IoT systems are continuously evolving to handle new services, features that were
not present int he original design. A monolithic IoT system, is unable to handle these
changes and scale up after a certain threshold. However, microservices serve as an ideal
design approach for IoT systems as they are fault tolerant and promote fault isolation.
New services can be independently deployed without affecting the original design.

4.1.2 Mitigation
Alexander Power et al. [Power, and Kotonya 2018]proposed a micro-service based fault
tolerant framework that provides real time predictive fault tolerance (FT) support for IoT
systems. The system continuously performs health check with the help of micro-services
that examine the state of the system, data , detect and resolve errors. Based on this
assessment, fault patterns are established so that next time in a similar circumstance,
the system is aware of the type of error that has occurred. In some cases, the system
can evaluate the state even before the error occurs. The proposed framework contains
four microservices integrated together out of which two service render fault tolerance
support. The first service uses complex event processing for reactive FT to supply
real time data stream and the second services uses machine learning for proactive
FT. Reactive fault tolerance is a situation where error recovery takes place after it is
detected whereas in proactive fault tolerance error recovery is initiated before an error is
discovered. These services communicate with each other using REST interface because
of its advantages in cloud support. The data is exchanged using JSON. The Web Interface
APi describes three categories which the microservices utilize.

• properties: it defines the attributes of an IoT application, internal information

about devices and services

• events: they describe the events that occur in the IoT system. For instance,
/events/error/detect is an interface where errors are posted and /events/error/
assessment is an interface where they are calculated.

• actions: actions define the operations that a microservice preforms in an IoT

system

After registering itself with a service broker, micro-services subscribe their topics of
interest (properties, events, actions). Other microservices send data to these subscribers.
Fig 4.1 depicts four microservices and their interaction with IoT devices :

• Edge: This service helps IoT devices to transfer their properties such as name
,type, unit, source address, timestamp, value to other parts of the system .It acts
as an entry point between microservice and IoT devices and sends all its data to
microservices that have subscribed to it. It also performs operations internally
that are sent by IoT devices.

• DB: It is a back-end database that receives and stores information for the micro-
services to subscribe to it.
4.1 FAULT TOLERANCE AND FAULT ISOLATION 40

Figure 4.1: Interface between IoT devices and Microservices [Power,

and Kotonya 2018]

• Real Time FT :This micro-service shown in fig 4.2 is situated between the edge
and DB service and only allows properties into the DB service after they pass
through Real time FT engine. The engine verifies these properties for errors sends
it further to a CEP system, where they are analyzed and checked for new errors.
CEP system intelligently preforms error recovery by verifying a cluster of errors
together. For instance, in case of 6 IoT devices failure, the system checks for the
faulty gateway, rather than the devices. [Power, and Kotonya 2018]

Figure 4.2: Architecture of real-time fault tolerant microservice [Power,

and Kotonya 2018]

• Predictive FT: The service shown in fig 4.3 captures the continuous data that flows
within the systems and analyses it for faults by constantly checking the state of the
system and other surrounding factors. Fault predictions are made with this data
using an Online Learning approach which approach monitors the continuous
4.2 INTEROPERABILITY 41

stream of data and discards it after it is done. The result of this analysis is again
fed in to a Learner which trains the algorithm to identify new errors, learn how
the system handles it ,evaluate how effective is this error recovery .Using this
knowledge fault patterns are generated which acts as a guide in case of errors in
the future.

Figure 4.3: Architecture of predictive fault tolerant microservice [Power,

and Kotonya 2018]

4.2 Interoperability
4.2.1 Challenges
IoT technologies have revolutionized machine to machine interactions in the field of
manufacturing, agriculture, industrial, personal ,transportation, commerce. Due to
its advantages and increased demand significant development of new technologies
and devices, API’s have taken place in the last few years. However, every new technol-
ogy has a closed ecosystem with vendor specific infrastructure, platform dependent
API’s, incompatible data formats etc forcing the consumer to avail services offered by a
single provider only[Noura, Atiquzzaman, and Gaedke 2019].The services offered by a
single provider may not fully cater to the consumer’s need, or are incompatible to the
user’s environment resulting in high operational costs, poor features and a unsatisfied
customer. Interoperability is "The ability of two or more systems or components to
exchange information and to use the information that has been exchanged " [“IEEE
Standard Glossary of Software Engineering Terminology” 1990].Various factors lead-
ing to interoperability issues in IoT applications are : Security: Security is one of the
key features of IoT applications. Using multiple heterogeneous devices increases the
4.2 INTEROPERABILITY 42

possibility of a security leak in a system. Competitive Edge: Several service provides

offer closed ecosystem of devices to have an edge over other providers in the market.
Device Complexity : Enforcing interoperability among large complex IoT devices is
also very challenging without a common management system. Lack of Resources : To
make open API and devices, huge resources are required to monitor and test them for
common implementations, security in case of heterogenous communication between
devices over.[Konduru, and Bharamagoudra 2017] Table 4.1 illustrates various types of
interoperability issues IoT systems.

Interoperability
Device interoperability
Network interoperability
Syntactical interoperability
Semantic interoperability
Platform interoperability
Description
ability to integrate new de-
vices in IoT systems. commu-
nication between heteroge-
nous devices and protocols
handle routing, QoS, re-
source utilization, address-
ing, mobility support [Bello,
Zeadally, and Badra 2017]
interoperability between
data format, data structure
of exchanged information
exchange of meaningful and
understandable information
integration and exchange of
data between different IoT
platforms

Table 4.1: Type of interoperability issues IoT systems

4.2.2 Interoperable IoT Platform Based on Microservices

Web of objects is a platform that combines virtual objects and resources together for
efficient development, and operation of IoT services. It uses semantic web technologies
to make heterogeneous devices interoperable.[Sajjad Ali et al. 2018] Wo0 architecture
has three layers namely Service layer, Virtual object(VO) layer , Composite virtual ob-
ject(CVO) layer. ”Microservices use WoO architecture to encourage rapid semantic inter-
operability, scalability, and replaceability by encapsulating & virtualizing diverse objects
and communication protocols with proxy microservice component" [Muhammad Aslam
Jarwar et al. 2017] In this architecture all the heterogeneous objects operate within their
own container and communicate with other over WoO platform to exchange, process
and understand data. Fig 4.4 depicts a scenario of interoperable IoT system where three
domains (smart home, car, workplace) use the same underlying platform (WoO)and one
4.2 INTEROPERABILITY 43

domain has a third party platform. Every domain has its own server and a "translating
and formatting" server is used for cross domain platform. When a user moves from
one location to another in the first three domain, if any service feature is unavailable in
a server, it sends a request to use CVO/VO of another domain via microservices .The
microservice transfers data to the requesting data where another set of microservices
are used to process and understand the received information. In case a WoO domain
communicates with third party domain, a translating and formatting server analyses
the request, converts the semantic ontology from one domain to other domain’s under-
standable form with the help of microservices as shown in fig.4.5.[Muhammad Aslam
Jarwar et al. 2017]

Figure 4.4: Use Case Based On Interoperable Microservices for Ubiquitous IoT
Services [Muhammad Aslam Jarwar et al. 2017]

Figure 4.5: Interoperable Microservices within same domain and cross domain
[Muhammad Aslam Jarwar et al. 2017]
4.3 SECURITY 44

4.3 Security
4.3.1 Challenges
With the increase in demand for IoT devices, security concerns around it has also
magnified. IoT systems are vulnerable to four types of attacks including communication
attack, lifecycle attack, software attack and physical attack as mentioned in table 4.2
[What is IoT Security â Arm n.d.]Also, IoT systems are enforce access policies, which
heavily rely on the developer for its creation .[M.-O. Pahl, Aubet, and Liebald 2018]
IoT applications provide personalized services that access private sensor data, and
actuator data.Thus security of these services needs to be maintained by addressing
three challenges - authenticity, integrity, and accountability.Authentication verifies that
the service belongs to a particular developer, or store or an IoT site.Integrity defines the
consistency and accuracy of data, while accountability relates to responsibility.

Type of Attack Description Combat Technique

Communication attack on the data transmit-
attack ted between IoT device and
server
Lifecycle attack compromise integrity of IoT
device during maintainence
Software attack attack on device software
Physical attack attack on the device chip
Cryptography technologies
such as RSA, AES,DES fro au-
thorization and authentica-
tion
Security services
software system isolation
tamper mitigation and side
channel attack mitigation
techniques

Table 4.2: Types of IoT security attacks

4.3.2 Security via Certificates

Marc-Oliver Pahl et al [M. Pahl, and Donini 2018] discusses a secure microservice
based architecture using certificates as shown in fi g 4.6.Certificates are used to protect
the executable data as well as any additional meta data.To protect executable data, a
cryptographic hash known as executableHash is stored on top of the executable.Property
attributes can be directly added in the certificate or in the metadata, which is protected
by an executable hash, thus maintaining the integrity of the data .
For verification, a keypair is generated during the lifecycle of a service. The developer
creates a public key and registers it at the store.During delivery of the service, a developer
hashes the executable data, adds it to the certificate and signs the certificate with a
private key, which is then uploaded to the store.
4.3 SECURITY 45

Figure 4.6: Distributed Certificate-Based IoT Service Security [M. Pahl,

and Donini 2018]
Chapter 5

Challenges in Microservice based

IoT systems and their mitigation
techniques

5.1 Quality of Service(QoS)

5.1.1 Challenges
The main task of IoT devices is sending data and receiving it. Data is the one of the key
driving factors for the success of an IoT system as it results in fast decision making and
processing. Data between devices is properly transferred through REST interface and
microservices. Therefore, guaranteeing its continuous availability becomes a primary
concern. In IIoT application microservices are used to provide continuous stream of
data. However, as the number of services proliferate in an IoT system, the possibility of
its availability without any downtime decreases. In IoT systems, several microservices
are used to connect wired and non -wired network devices. If any one of these microser-
vices fail, they may transfer incorrect signals or reading to other components. This can
result in a compromised system. Hence, there is a need detect operational continuity of
these microservices through various attributes such as Quality of service. To resolve this
issue, mechanisms to monitor the quality of service offered by microservices should be
created, and checks should occur when a micro-service is integrated into the IoT system.
Apart from constantly checking the quality of work offered by these micro-services,
there is a need to check quality of microservice itself especially in case of applications
that use third party microservices. Complete reliance on the service provider can often
lead to deteriorating results, as they influence the quality check of a micro-service or
fabricate it. Therefore, certain standards need to be created that check the microservice
Qos (MQoS).
5.1 QUALITY OF SERVICE(QOS) 47

5.1.2 Mitigation - Microservice QoS management System

Eyhab Al-Masri [Al-Masri 2018] proposed a framework for microservice QoS manage-
ment system as shown in fig . that determines the overall quality of a microservice in
an IoT application. This system tracks both local and external microservices attached
to an application. The microservices that need to be monitored for their quality are
selectively chosen by clients.

Figure 5.1: Architecture of Microservice QoS management System [Al-Masri

2018]

• Controller: The controller coordinates tasks for measuring MQoS. The table below
shows various mQoS attributes .

• MQoS management capabilities(mQoSMC) : It is responsible for discovering mi-

croservices and coordinating with the schedular and controller to measure the
quality of mQoS.It aslo looks after routing and configuration of micro-services.

• MQoS Operational capabilities(mQoSOC):It automatically executes QoS polices

to measure mQoS.

• mQoSS: It is a database that stores information including bandwidth, response

time, availability of various modules as shown in table 5.1. Since microservices
rely on network connection to and cloud for consumption of its resources, their
QoS fluctuates during their lifecycle. Thus the historical data stored in this
database from time to time is used for accurate measurements.
5.2 SECURITY AS A SERVICE 48

mQoS parame- Description Unit of Measurement

ters
Reliability The degree to which a mi- No of failures per 10 day/ No.
croservice performs function of requests
without failure.
Response Time Time consumed to send and milliseconds
request or receive one
Availability Ratio of time during which % per 10 day period
microservice is available
Throughput Total no. of requests handled requests/min
in a given time
Cost Cost per microservice invoca- cents per service request
tion

Table 5.1: Microservice Quality of Service Parameters

5.2 Security as a Service

5.2.1 Challenges
A huge monolithic system is broken down into logical blocks resulting in hundreds of
microservices that communicate with each other via API’s creating a large complex
network. Security issues due to this large network complexity makes processes such as
monitoring, debugging, auditing, forensic analysis of entire system extremely difficult.
IoT systems deal with huge amount of user data that is exchanged over wired and non-
wired network. Security is crucial as it consumes large privacy related data, such as
detecting a user’s presence, habits, alarm system passwords etc. Access based policies
configured in IoT systems pose a security threat, as they rely on developers completely
for correctness.
Moreover, it is challenging for the owners to view their application as a whole in case
microservices are hosted on the cloud where the owner has no control or limited access.
As a result, these microservices becomes susceptible to attack by hackers. Achieving
security and privacy of user information in IoT systems is a key challenge especially in
a distributed microservices environment. Microservices are designed in such a way,
that each service trusts the other. Due to this, compromise in one and bring down
an entire system. Attackers can gain access to public microservices and privilege to
private virtual machines and propagate this control over other connected microservices
resulting in system shutdown. Insider attacks like abuse of privilege on microservices is
also a concerning factor.[Y. Sun, Nanda, and Jaeger 2015]
5.2 SECURITY AS A SERVICE 49

5.2.2 Mitigation
To mitigate the above-mentioned security threats, traffic monitors are used. Marc-Oliver
Pahl et al [M.-O. Pahl, Aubet, and Liebald 2018] proposes a graph based communication
model as shown in fig 5.2 . that shows communication between microservices. Every
IoT node, routers, switches have a monitor, which is independent from the developers
of micro-services. The monitors intercept every communication between the services
and perform a deep packet inspection (DPI). During this inspection, all communicating
services are identified and stored as vertices ,and the communication relationship
between them is stored as edges in the model. Ever node maintains its own graph and
anomaly detection occurs for every monitor. As IoT systems are constantly evolving, its
topology changes leading to dynamic management complexity. Thus, every time new
IoT device are added or removed, graph is updated. Site managers can visually see these
graphs and detect suspicious behaviour among microservices.
Another approach to mitigate security issues in microservice based Cloud IoT sys-
tem is using Software defined network (SDN) capabilities offered by clouds. SDNs
monitor complex network interactions and enforce policies on these networks. It pas-
sively monitors network packets flowing through and decides if it has to be distributed
further based on application requirements. This helps in attack situations where the
data packets are routed through a different path in case SDNs sense a compromise.
Security monitors placed inside their own VM's and are known as security VM's. They
are isolated from application VM's, to monitor the network events and change easily
according to application needs. Security monitors perform several functions such as
1)logging all internal and external network events like messages, HTTP request/response
.2) It protects its public facing microservices, or other specific services like privilege
escalation detection for Database. 3)It passively monitors the network, or sometimes
redirects the data for honey pot analysis.

Figure 5.2: Security Monitor deployment Strategy parencite sun2015security

Chapter 6

Open Challenges in implementing

Microservices

Despite the several benefits offered by micro-services in IoT, there are still open chal-
lenges that have not been addressed.Few of them are listed below :

6.0.1 Modularization Services

When modularization approach is used, the appropriate number of modules/components,
their right size, and responsibility of each is a challenge.
If boundaries are not well defined and designed , it can result is increased net-
work communication.Due to this increase, the system becomes unstable and performs
abysmally.

6.0.2 Granularity
Another challenge is designing the right size of microservices.Although micro-services
should be as small as possible, every development team interprets it differently Some
teams use micro-services with few LOC(lines of code), others encapsulate classes and
databases in them.

6.0.3 Front -end integration

UI is not the focal point of many advocates of microservices.As a result of which , a
condition where monolithic front end connects to multiple back end microservices can
occur.This inhibits the goals of micro-services since monolithic features still exists.

6.0.4 Resource monitoring and Management

As the IoT application’s size increases, the number of infrastructure resources such
as virtual machines, logs, thread pool, messages also increases which have to be con-
 51

tinuously monitored and managed.Also, the services can be deployed across multiple
geographic regions and zones which generate huge amount of data such as ’states’ and
’behaviour’.Collecting and monitoring this information is overwhelming for develop-
ers,resulting in untimely management decisions.
Additionally, it becomes challenging to generate an alert threshold notifying the de-
veloper in case of issues without overloading them with redundant information.[Jamshidi
et al. 2018]

6.0.5 Failure and Self Repair

Microservices are fragile in nature as they tend to become inaccessible, unavailable or
might totally fail in certain situations.They are susceptible to failure due to increased
number of messages that are exchanged between them .As a result ,due to these depen-
dencies, services fail time to time, or become inaccessible to consumers.
Chapter 7

Conclusion an Future Scope

This literature review aimed at discussing the role of micro-services in Internet of Things.
Specific approaches have been embraced to address the research problems via reviewed
service architectures, use cases, and its bottlenecks. It lays down SOA, monolithic
and microservice architectures in detail. Despite being a new style of development, it
has eliminated the challenges of SOA and the monolithic style of design. The review
also highlights interoperability, security, and fault tolerance issues in developing large,
complex IoT systems, along with their mitigation techniques. In addition to this, the
thesis discusses open challenges in implementing these micro-services.
However, this review has some limitations. It doe snot cover some frameworks of
micro-services that are more metaphysical, without any scope for future implemen-
tations. This study focussed on prominent issues of performance and, security with
limited interest in suggesting mitigation techniques for other open challenges as it was
cost-ineffective and required deep analysis.
Microservices encapsulates the best practices for designing innovative, resilient,
scalable applications. It is responsive to changing requirements and follows incremental
learning by doing approach. This technique limits the impact of failure during design
and run time. Using micro-services in IoT will build momentum towards service-based
IoT systems [Bringing the power of microservices to IoT - Wipro n.d.] . Future of this
approach lies in the potential of reuse of assets for consumption. It can be viewed as
a server-less and " function as a service" architecture, focussing on decentralization.
In the future, it can be used for data analytics and data science via intelligence-driven
services. Future studies will focus on improving service discovery, load routing, shared
library, service to service communication features.
Bibliography

10 examples of the Internet of Things in healthcare â Econsultancy [n.d.] https:

//econsultancy.com/internet-of-things-healthcare/. (Accessed
on 08/31/2020).
Ali, Sajjad et al. [2018]. “A model of socially connected web objects for IoT
applications”. In: Wireless Communications and Mobile Computing 2018.
Badii, Claudio et al. [2019]. “Microservices suite for smart city applications”. In:
Sensors 19.21, p. 4798.
BANICA, Logica, Magdalena RADULESCU, and Cristian STEFAN [2018]. “Iot
And The Cloud: The Future Of A Digital Society”. In: Scientific Bulletin -
Economic Sciences 17.2, pp. 33–41. URL: https://ideas.repec.org/a/
pts/journl/y2018i2p33-41.html.
Bello, Oladayo, Sherali Zeadally, and Mohamad Badra [2017]. “Network layer
inter-operation of Device-to-Device communication technologies in Inter-
net of Things (IoT)”. In: Ad Hoc Networks 57, pp. 52–62.
Bringing the power of microservices to IoT - Wipro [n.d.] https://www.wipro.
com / applications / bringing - the - power - of - microservices - to -
iot/. (Accessed on 08/31/2020).
Butzin, B., F. Golatowski, and D. Timmermann [2016]. “Microservices approach
for the internet of things”. In: 2016 IEEE 21st International Conference on
Emerging Technologies and Factory Automation (ETFA), pp. 1–6.
Campeanu, G. [2018]. “A mapping study on microservice architectures of Inter-
net of Things and cloud computing solutions”. In: 2018 7th Mediterranean
Conference on Embedded Computing (MECO), pp. 1–4.
Chapter 3: Architecture of a microservice application - Microservices in Action
[n.d.] https://learning.oreilly.com/library/view/microservices-
in-action/9781617294457/c03.xhtml. (Accessed on 08/31/2020).
computing-overview.pdf [n.d.] https://www.cisco.com/c/dam/en _ us/
solutions/trends/iot/docs/computing-overview.pdf. (Accessed on
08/31/2020).
Datta, Soumya Kanti et al. [2018]. “Iot and microservices based testbed for
connected car services”. In: 2018 IEEE 19th International Symposium on"
BIBLIOGRAPHY 54

A World of Wireless, Mobile and Multimedia Networks"(WoWMoM). IEEE,

pp. 14–19.
Del Esposte, Arthur M et al. [2017]. “InterSCity: A Scalable Microservice-based
Open Source Platform for Smart Cities.” In: SMARTGREENS. Vol. 1, pp. 35–
46.
Depression [n.d.] https://www.who.int/health- topics/depression#
tab=tab_1. (Accessed on 08/31/2020).
Dobaj, Jürgen et al. [2018a]. “A Microservice Architecture for the Industrial
Internet-Of-Things”. In: Proceedings of the 23rd European Conference on
Pattern Languages of Programs. EuroPLoP ’18. Irsee, Germany: Association
for Computing Machinery. ISBN: 9781450363877. DOI: 10.1145/3282308.
3282320. URL: https://doi.org/10.1145/3282308.3282320.
[2018b]. “A microservice architecture for the industrial Internet-of-
Things”. In: Proceedings of the 23rd European Conference on Pattern Lan-
guages of Programs, pp. 1–15.
El Yassini, Khalid [n.d.] “Connected Car Overview: Solutions, Challenges and
Opportunities”. In: []
Hill, R., D. Shadija, and M. Rezai [2017]. “Enabling Community Health Care
with Microservices”. In: 2017 IEEE International Symposium on Parallel
and Distributed Processing with Applications and 2017 IEEE International
Conference on Ubiquitous Computing and Communications (ISPA/IUCC),
pp. 1444–1450.
HomeKit - Wikipedia [n.d.] https://en.wikipedia.org/wiki/HomeKit.
(Accessed on 08/31/2020).
“IEEE Standard Glossary of Software Engineering Terminology” [1990]. In: IEEE
Std 610.12-1990, pp. 1–84.
Jamshidi, Pooyan et al. [2018]. “Microservices: The journey so far and challenges
ahead”. In: IEEE Software 35.3, pp. 24–35.
Jarwar, M. A., S. Ali, and I. Chong [2018]. “Exploring Web Objects enabled Data-
Driven Microservices for E-Health Service Provision in IoT Environment”. In:
2018 International Conference on Information and Communication Technol-
ogy Convergence (ICTC), pp. 112–117.
Jarwar, Muhammad Aslam et al. [2017]. “Exploiting interoperable microservices
in web objects enabled Internet of Things”. In: 2017 Ninth International
Conference on Ubiquitous and Future Networks (ICUFN). IEEE, pp. 49–54.
Khan, Rafiullah et al. [2012]. “Future internet: the internet of things architec-
ture, possible applications and key challenges”. In: 2012 10th international
conference on frontiers of information technology. IEEE, pp. 257–260.
Konduru, Venkateswara Raju, and Manjula R Bharamagoudra [2017]. “Chal-
lenges and solutions of interoperability on IoT: How far have we come in
BIBLIOGRAPHY 55

resolving the IoT interoperability issues”. In: 2017 International Conference

On Smart Technologies For Smart Nation (SmartTechCon). IEEE, pp. 572–576.
Krylovskiy, A., M. Jahn, and E. Patti [2015]. “Designing a Smart City Internet of
Things Platform with Microservice Architecture”. In: 2015 3rd International
Conference on Future Internet of Things and Cloud, pp. 25–30.
Maksimović, Mirjana [2018]. “The role of Osmotic computing in Internet of
Things”. In: 2018 17th International Symposium INFOTEH-JAHORINA (IN-
FOTEH). IEEE, pp. 1–4.
Al-Masri, Eyhab [2018]. “QoS-Aware IIoT Microservices Architecture”. In: 2018
IEEE International Conference on Industrial Internet (ICII). IEEE, pp. 171–
172.
Microservices vs Service-Oriented Architecture (SOA): Fundamental Differences
[n.d.] https://insights.daffodilsw.com/blog/microservices-vs-
service - oriented - architecture - soa - fundamental - differences.
(Accessed on 08/31/2020).
Microservices vs SOA: What’s the Difference? - DZone Microservices [n.d.] https:
//dzone.com/articles/microservices-vs-soa-whats-the-difference.
(Accessed on 08/31/2020).
Monolithic vs Microservices Architecture (MSA) â BMC Blogs [n.d.] https://
www . bmc . com / blogs / microservices - architecture/. (Accessed on
08/31/2020).
Noura, Mahda, Mohammed Atiquzzaman, and Martin Gaedke [2019]. “Interop-
erability in internet of things: Taxonomies and open challenges”. In: Mobile
Networks and Applications 24.3, pp. 796–809.
O’Brien, O., and R. D. O’Reilly [2018]. “Beats-Per-Minute (BPM): A Microservice-
based Platform for the Monitoring of Health Related Data via Activity Track-
ers”. In: 2018 IEEE 20th International Conference on e-Health Networking,
Applications and Services (Healthcom), pp. 1–7.
Pahl, M., and L. Donini [2018]. “Securing IoT microservices with certificates”.
In: NOMS 2018 - 2018 IEEE/IFIP Network Operations and Management Sym-
posium, pp. 1–5.
Pahl, Marc-Oliver, François-Xavier Aubet, and Stefan Liebald [2018]. “Graph-
based IoT microservice security”. In: NOMS 2018-2018 IEEE/IFIP Network
Operations and Management Symposium. IEEE, pp. 1–3.
Patra, L., and U. P. Rao [2016]. “Internet of Things â Architecture, applications,
security and other major challenges”. In: 2016 3rd International Conference
on Computing for Sustainable Global Development (INDIACom), pp. 1201–
1206.
Power, Alexander, and Gerald Kotonya [2018]. “A microservices architecture
for reactive and proactive fault tolerance in iot systems”. In: 2018 IEEE 19th
BIBLIOGRAPHY 56

International Symposium on" A World of Wireless, Mobile and Multimedia

Networks"(WoWMoM). IEEE, pp. 588–599.
Rufino, Joao et al. [2017]. “Orchestration of containerized microservices for
IIoT using Docker”. In: 2017 IEEE International Conference on Industrial
Technology (ICIT). IEEE, pp. 1532–1536.
Salikhov, Dilshat et al. [2016]. “Microservice-based iot for smart buildings”. In:
arXiv preprint arXiv:1610.09480.
Santana, C., B. Alencar, and C. Prazeres [2018]. “Microservices: A Mapping
Study for Internet of Things Solutions”. In: 2018 IEEE 17th International
Symposium on Network Computing and Applications (NCA), pp. 1–4.
Sharma, Vishal et al. [2017]. “Managing service-heterogeneity using osmotic
computing”. In: arXiv preprint arXiv:1704.04213.
Sill, A. [2016]. “The Design and Architecture of Microservices”. In: IEEE Cloud
Computing 3.5, pp. 76–80.
Sun, L., Y. Li, and R. A. Memon [2017]. “An open IoT framework based on
microservices architecture”. In: China Communications 14.2, pp. 154–162.
Sun, Yuqiong, Susanta Nanda, and Trent Jaeger [2015]. “Security-as-a-service
for microservices-based cloud applications”. In: 2015 IEEE 7th International
Conference on Cloud Computing Technology and Science (CloudCom). IEEE,
pp. 50–57.
Taherizadeh, Salman, Vlado Stankovski, and Marko Grobelnik [2018]. “A capillary
computing architecture for dynamic internet of things: Orchestration of
microservices from edge devices to fog and cloud providers”. In: Sensors
18.9, p. 2938.
The Principles of Microservices [n.d.] https : / / learning . oreilly . com /
videos/the-principles-of/9781491935811. (Accessed on 09/01/2020).
Villari, M. et al. [2016]. “Osmotic Computing: A New Paradigm for Edge/Cloud
Integration”. In: IEEE Cloud Computing 3.6, pp. 76–83.
Villari, Massimo et al. [2016]. “Osmotic computing: A new paradigm for edge/cloud
integration”. In: IEEE Cloud Computing 3.6, pp. 76–83.
What are Microservices? (+Microservices vs. Monolithic Architecture) [n.d.] https:
//learn.g2.com/microservices. (Accessed on 08/31/2020).
What is IoT Security â Arm [n.d.] https://www.arm.com/glossary/iot-
security. (Accessed on 08/31/2020).
What Is Service-Oriented Architecture? | by Software Development Community |
Medium [n.d.] https://medium.com/@SoftwareDevelopmentCommunity/
what-is-service-oriented-architecture-fa894d11a7ec. (Accessed
on 08/31/2020).
What is V2X communication? Creating connectivity for the autonomous car
era | ZDNet [n.d.] https://www.zdnet.com/article/what- is- v2x-
BIBLIOGRAPHY 57

communication-creating-connectivity-for-the-autonomous-car-
era/. (Accessed on 08/31/2020).
Why IoT Development Needs Microservices and Containerization [n.d.] https://
www.einfochips.com/blog/why-iot-development-needs-microservices-
and-containerization/. (Accessed on 08/31/2020).
Yu, Jaehak et al. [Sept. 2018]. “WISE: Web of Object Architecture on IoT Environ-
ment for Smart Home and Building Energy Management”. In: J. Supercomput.
74.9, 4403â4418. ISSN: 0920-8542. DOI: 10.1007/s11227- 016- 1921- 6.
URL : https://doi.org/10.1007/s11227-016-1921-6.