2018 International Conference on Computational Science and Computational Intelligence (CSCI)
Towards Dynamic On-Demand Fog Computing Formation Based On
Containerization Technology
Hani Sami and Azzam Mourad
Department of Computer Science & Mathematics - Lebanese American University, Beirut, Lebanon
Abstract— The advantage of having fog nodes near IOT
devices can be seen by bringing intelligence near the edge. Fogs
form storage place, real time processing for the tremendous
amount of data generated by sensors, host for users’ services
to provide a better quality of service with a fast response time,
and most importantly saving the IOT devices energy. If a fog
is not present near an IOT device, its advantage will simply be
eliminated. The current fogs in the literature are preconfigured
in specific locations having some specific services running on
them all the time which limits their diverse availabilities and
prevent dynamic update and context adaptation. In this paper,
we address the aforementioned limitations by proposing on-
demand fog formation to create and manage fog devices and ser-
vices on the fly. Our approach benefits from the containerization
technology like Docker to build fog environment on-demand
with the least initialization costs possible using volunteering
devices and Kubernetes utility called Kubeadm, which allows
monitoring fog nodes and orchestrates their services in a highly
dynamic environment. A testing strategy composed of real
devices is used and promising results are presented illustrating
the ability and efficiency of initializing fog devices on the fly
anywhere and whenever needed.
Index Terms— IOT, Cloud Computing, On-Demand Fog, Fog
Formation, Containers, Docker, Kubernetes, Kubeadm.
I. INTRODUCTION
Fog devices are currently extending the cloud solutions
near the edges to aid the constraint IOT devices that are
tremendously increasing[1][2]. Fog computing in the context
of IOT environment can be the software running on a device
that collects, processes, and sends data on behalf of the IOT
devices to the cloud. Moreover, fog nodes perform some
processing on the data to minimize the load on the cloud, and
host some services given from the cloud to respond to users
in a faster way while avoiding the networking costs to/from
the cloud, which can lead to saving energy on the requesting
devices [3]. In this context, there are three layers of IOT
environment with traditional fog devices running specific
types of services all the time covering specific users which
are the cloud, fog, and IOT devices or users. Traditional fogs
are running on initialized and pre-configured fogs having a
fixed location and services running. This is leading to fog
absence to cover other locations with new users demanding
the same or new services to be served by a near fog. There is
a need of having an architecture that can help in creating fogs
on-demand anywhere, and can adapt or configure the services
installed on that fog which should be updated, removed, or
changed dynamically based on the scenarios happening at
the edge.
978-1-7281-1360-9/18/$31.00 ©2018 IEEE
DOI 10.1109/CSCI46756.2018.00187
In parallel, the rise of the containerization technology is
opening the door for interesting solutions serving the fog
computing objectives. Containers are services running on a
device by using its actual operating system to provide them
with services. This makes containers more lightweight and
gives them advantage over virtual machines which use a
full copy of the operating system and are much heavier on
the devices [4]. It is easier now to just have an abstracted
operating system with all the environments needed to run
multiple services in multiple containers that are copy of
images pulled from image repositories like Docker Hub.
Docker is one of the main containerization technologies used
nowadays [5]. The presence of lot of containers opened the
eyes to the need of having managers or orchestrators for
such huge number of containers running on many different
devices. Docker Swarm, Kubernetes, and Apache Mesos-
Marathon are the main popular open source orchestration
tools [6]. The authors in [7] compared between the three of
these orchestrators in terms of their limitations of use towards
IOT devices with fog nodes.
In this paper, we benefit from the containerization technology
and address the aforementioned problems of the existing
statically formed fog computing architectures and solutions
in the literature by proposing a dynamic on-demand fog
computing framework based on Kubeadm and Docker with
the presence of any type of volunteering devices. Our pro-
posed on-demand creation serves as a solution to overcome
the limitation of fog availability, usage of statically defined
locations, hosting pre-configured devices, and embedding
pre-selected services. Kubeadm is a Kubernetes utility that
allows us to create custom clusters on the fly composed of
fogs using Kubelet component on any resource constraint
devices as well as monitoring them through the master node.
However, to initialize a Kubeadm cluster on the spot and
propmt other devices to join causes a significant delay in
time. Kubernetes/ Kubeadm is chosen as the orchestrator tool
because it supports Docker.
To partially overview our approach and illustrate its contri-
bution and advantages, we take two real life scenarios that
require dynamic creation of a nearby fog: (1) An IOT device
consuming significant energy while producing lot of data
and sending it all the way to the cloud. In this Scenario, a
Kubeadm cluster must be created beforehand next to this
user, and the needed services are pushed on-demand to
fogs nearby. (2) A crime happened in an area where our
framework have a Kubeadm environment built, so an image
960
processing service will be pushed to volunteering fog(s) to
process the image and identify faces in the crime seen. In
this case, our framework based on some criteria lets the cloud
decide that we need fog serving near this device. A kubeadm
cluster should be prepared next to this user beforehand using
volunteering devices only, knowing that this user is already
requesting services from the cloud. Moreover, fog as worker
node in the cluster running on any type of volunteering
devices imposes lot of challenges to address in our approach
such as making the right decision on when we actually
need serving fogs, location of the orchestrator of a cluster,
time it takes to initialize the orchestrator, how to decide on
which fog to deploy the service, and dynamicity of volunteers
coming in and out. We were able via our approach to achieve
promising results in terms of better quality of service to
the requesters with faster response time, and deployment of
services on-demand anywhere anytime. In this context, the
contributions of this paper are three folds:
1) A novel on-demand fog creation framework based on
requesters’ need anytime anywhere a volunteering de-
vice exists. Hence, our proposed approach addresses the
problems of the availability of statically located and
pre-configured fog with pre-selected services through
enabling dynamic creation, management, and service
deployment. To the best of our knowledge, none of the
current approaches in the literature have targeted these
problems and provided similar features.
2) Efficient service deployment approach on the fly on
newly formed nearby fogs.
3) Efficient orchestration approach for better response time
in a dynamic fog environment.
This paper is organized as follows. The related work is
described in section II. An elaboration of the methodology
and architecture is shown in section III. Section IV presents
the experiment setup and results. Finally, the conclusion of
the paper with future work is depicted in section V.
II. R ELATED W ORK
In this section, we review some of the literature behind
using containers and orchestration tools as an environment
that can work on the fog and IOT devices. Elaborating the
usage of containers on fog devices in the most useful and
efficient way is one of the recent research topics evolving in
this area.
In the recent work done in [8], authors focused on the ability
of using lightweight Docker containerization technology
to support service provisioning over IOT devices. Authors
compared between two main frameworks. The first one
is Container-Based Pair-Oriented IoT Service Provisioning
where two devices are cooperating and responsible for the
interactions, while the second one is Container-Based Edge-
Managed Clustering where serving IOT nodes are being
monitored by a manager node. Their main contribution
is to show how lightweight containerization technology
can manage IOT resources by hosting services on them.
Their experiments shows the ability and efficiency of using
containerization technology in terms of CPU and energy
961
consumption. In this paper, we are providing a scalable and
flexible framework that can create and manage fog services
on any type of volunteering resources present anywhere. We
are supporting users in need of a service to be hosted nearby.
In addition, our framework is capable of forming the fog
devices with the services requested from users on the fly
taking into account the initialization and deployment time.
The authors in [9] [10] tried to build a framework that
can dynamically push services to fogs present in an area
where these devices are known for the orchestrator. The
main point is to use the containerization technology with
its orchestration to manage the services on the fogs and
to build platform as a service architecture counting on the
orchestration technologies by integrating them into a fully
functional environments supporting IOT. By default, these
orchestration technologies comes in hand with a group of fea-
tures that eliminates a single point of failure by pushing the
containers into many devices at the same time, restarting any
failed services, allowing a link and communication between
containers, and sharing their data volume or storage. Authors
of the papers are concerned in the dynamicity of updating
services on pre-configured fog devices while monitoring their
performance.
A model was proposed by the authors in [11] where dynamic
deployment of services on helper nodes(fogs) of the main
server using Docker is possible. So it is feasible to remove,
add, stop, and run any service on a physically known fog
anytime. The Kubernetes orchestrator was running on a
server. Their approach was to first gather users’ requests on
that server. Second, although fogs are not near users, the
proposed model distributes requests on fogs after pushing
the needed services. This means that fogs are only doing
some processing instead of the server. Furthermore, the
networking delays are not avoided, however they are getting
faster processing time because of distributing the tasks from
one server to many nodes. Last, gather the results back to
the server and send them to users afterwards. The fogs along
with their locations are already known and most importantly
not near users. Furthermore, the user is requesting to push
services to fogs and it is not on-demand decided by the
server. If a user wants a real time update using data generated
by a specific location where a fog does not exist, their
framework will fail in doing the job.
Benefiting from all of these features, we built our framework
to run on volunteering devices to make the fog environment
better suited for all kinds of applications that can now
run anywhere using volunteering resources and dynamic
allocation of services in an on-demand and on the fly manner
without any user interaction. To the best of our knowledge,
none of the literature work has proposed a solution serving
the fog computing paradigm using volunteering devices only.
Our contribution is summarized as an on-demand fog com-
puting formation on the fly using volunteering devices that
can be created anytime anywhere based on users’ needs while
taking into account many constraints such as the profiles of
the volunteers, their time constraints, and their dynamicity
while coming in and out of a cluster.

Fig. 1: Overall Architecture.
III. M ETHODOLOGY AND A RCHITECTURE
In this section of the paper, we discuss the architecture
of our proposed framework illustrated in Figure 1. The on-
demand fog Kubeadm cluster is built using the volunteering
resources and cloud only. Kubeadm utility is used because it
supports Docker and allows us to create Kubernetes clusters
using any constraint devices. The architecture is composed
of four layers: cloud, orchestrators, fogs, and users. Next, we
discuss the role of each layer briefly.
The cloud is responsible of taking a decision on-demand
where we need serving fog(s) for a particular service based
on users behaviors and recurrent requests coming from a
particular location. A fog node should be present in the target
location to host the needed service. For each group of fog
devices, there is an associated orchestrator node. If these
devices are not running and ready before the cloud decides
to push a services, they should be initialized. Therefore, this
process causes huge time delays. For this purpose, the cloud
is also responsible of having the volunteering master node
and potential fog volunteering devices ready before the need
of pushing any service to avoid the delays of initializing new
ones. In addition, the cloud is monitoring all orchestrators’
services and their time availability to make sure that all
clusters are up and running properly.
A master node of a Kubeadm cluster is the orchestrator
which creates that cluster, and is responsible of adding and
removing nodes to it as well as monitoring their status,
pushing, updating, or removing services if they are not
in use for a certain period of time. The orchestrator also
monitors the time remaining for the fogs to serve. Before a
fog volunteer leaves the cluster, the orchestrator migrates the
containers to other suitable volunteer in its cluster.
The worker nodes are the fogs in our case that send joining
requests to the master to become part of that cluster. The
master nodes of the on-demand clusters are monitoring
their workers or fog devices services and time remaining
in the cluster. The advantages of having a second layer of
962
Fig. 2: Node Architecture Per Layer.
orchestration are:
• Reducing the delay in choosing and creating new
fog devices to join the cluster in a highly dynamic
environment of fogs coming in and out. In other words,
the delay of the communication between the cloud and
fogs near edge devices is eliminated.
• Distributing the load coming to the cloud on
orchestrators, especially when fogs joining the
cluster have short period of time availability which
renders the situation very dynamic.
• Avoiding to have a single point of failure where the
cloud is the only orchestrator for huge number of fog
devices.
A fog is the worker node of a Kubeadm cluster that have
at least one service running to serve users. The service is
assigned by a decision from its master node. This fog is
composed as well of volunteering devices who asked to join
by sending requests to the cloud. If there is no suitable fog
available to serve a user, the requests continue their flow
normally to the cloud until the newly created fog’s IP is
published to users.
A user sends requests normally to the cloud if there is no fog
present in the area, and receives a fog IP address once any is
available next to it. This way, the user is experiencing a better
quality of service (QOS) by having a faster response time,
less communication overhead, and a full device dedicated
to serve one or a group of users. This user can be an IOT
device.
The components embedded in each node of the architecture
is presented in Figure 2. All nodes have to run the Kubeadm
containerization required modules. A decision module for
selecting volunteering nodes as orchestrators and fogs has
to run on the cloud and the orchestrator respectively. Fur-
thermore, the profiler component should be running on the
orchestrator and fog volunteers.
In the sequel, we present a description of the modules
running on each layer of the architecture. Each of these
modules is implemented as python scripts using Flask web
services framework and pushed to Docker Hub repository
after building their Docker files. These images are used later
by any device joining a cluster:
A. Kubeadm Containerization Required Modules
Kubeadm helps in building a best practice of the Ku-
bernetes cluster in a very secure, easy, and extensible way
[12]. When using Kubeadm, the type of machine does not
matter and it can range from a Raspberry pi to a server.
Docker should be always running on all devices. Kubelet
component starts running on each end. It is responsible to
keep the communication alive with the master. It also checks
the health of services running and the status of the device
as well. Kubectl is the command line tool which should
be installed to control Kubeadm cluster. A network solution
should be installed in the cluster and on each device to let
the pods communicate with each other. An example of a
CNI network is Flannel [13]. Kubeadm will not run if any
of these dependencies is missing. The master and worker
nodes should have the Kubeadm containerization required
modules installed. When the master is initialized, it will have
a unique hashed token to be sent to devices to join the cluster
as worker nodes. When the worker node is ready, different
images are pulled and run inside its pods once joined.
B. Kubeadm Environment Initializer
The cloud starts initializing the first orchestrator in a
location when it receives certain number of requests above
a certain threshold from this location. For this paper, we
are assuming that there is always a list of available suitable
volunteers to use. The following are the provided functions:
1-Taking decisions for selecting the most suited volun-
teering orchestrators: The Decision module for selecting
volunteering nodes as orchestrator discussed in section III,E
is triggered. It takes as input the profiles of available volun-
teers in a particular location. Its output is the most suitable
volunteer to be assigned as new orchestrator.
2- Joining volunteers to orchestrator created: Whenever
the volunteering orchestrator of a location is ready, the cloud
prompts all remaining volunteering devices in this location
to join the running Kubeadm cluster monitored by the newly
created orchestrator. Therefore, the Kubeadm environment
is ready to directly handle pushing of services without any
initialization delays needed.
3- Guarantees highly available cluster if possible: This
module also checks the time remaining and availability of
all the orchestrator running. It also informs the orchestrator
selection algorithm about the need of having a new orchestra-
tor before the old one terminates. If resources are available,
always another master node should be created next to the
initial one in order to achieve a highly available cluster first
(HA: highly available, this feature is supported by Kubeadm
where both master nodes join the same network [12]). In
addition, if the initial orchestrator goes down, the secondary
one will be replacing it. This way, the framework avoids the
delays of creating new master node. The initial master node
963
always asks for a secondary one from the cloud. A limitation
in Kubeadm is that whenever the master node goes down,
the whole cluster gets down as well. [12].
C. Orchestrator Manager
In the following, we provide a description of the function-
alities offered by the orchestrator manager which is a case
of an orchestrator of orchestrators running on the cloud:
1- Collecting Users Requests: Users requests are the server
logs that can be used for further analysis. These logs should
be uesd to build and train the decision module of deciding if
a serving fog is needed or not. This data represents historical
data of users behavior in a particular location.
2- Taking decision of Fog Creation: The volunteer of a
Kubeadm cluster will not become a fog, until a service is
pushed to it.
Based on users behavior, number of requests coming, and the
level of urgency of services needed near them (a user can
send urgent request when they are losing a lot of energy or
they need a better QOS), the cloud decides if a fog should be
created to host that service. A time sensitive situation where a
fog should be created directly is handled because volunteers
inside Kubeadm cluster are ready if any is available and
suitable. The cloud might also decide that there is no need
to push a service at this moment. It is a complex decision
to be made and it might require a machine learning model
that can classify the user behavior and requests coming into
two categories as follow: no need for a fog, a fog should
be created. however, the implementation of this unit is out
of the scope of this paper. For now, we are assuming in our
experiments that the decision of creating a fog is already
taken by the cloud.
3- Forwarding Requests to Orchestrators: When the cloud
decides to push a service to a particular location, the cloud
will forward a request to a corresponding orchestrator in
a location. This request contains the list of services to be
pushed to fogs or available volunteers under that orchestrator.
D. Fog Manager:
In this section, we discuss the functionalities of the fog
manager, a case where we have an orchestrator of fogs.
The orchestrator is on volunteering devices near fogs. The
following component only runs on the orchestrators:
1- Getting List of Services and Volunteers: The fog man-
ager here accepts requests coming from the cloud containing
a list of services to be pushed. The list of available potential
volunteers is available to the master node since all of them
are connected to it. Therefore, the master can ask for the
volunteers profiles when needed.
2- Calling Decision Module to Select Volunteers: The
orchestrator triggers the decision module to get best distribu-
tion of services needed to be pushed on available volunteers.
4- Load Balancer: This component monitors the number of
requests served by each fog and decides on a Load Balancer
if needed, which means we need more containers to serve this
service. In this case, either the fog hosting the service can
make duplicates of the containre, or the load of is distributed
on others in peak time only. This feature is provided by
Kubernetes [12].
5- Backing-Up Fogs: Similar to how we achieve HA
clusters, this module checks the remaining time of a fog
inside the cluster and tries to initiate a new one, or push the
services to new volunteer in the same cluster before the old
one is down or stopped serving.
6- Monitoring Volunteer Status and Services: This is done
by checking the profile and services running on each fog.
If any service is not being requested by users, it will be
removed. By default, Kubelet restarts any service that fails
automatically and report that failure to the orchestrator [12].
If the failure occurs more than a provided threshold, the
orchestrator in our framework initializes another one with
the required services running before excluding it from the
cluster.
7- Publishing New Fogs IPs: The orchestrator informs the
cloud that new fog IP addresses are available. The cloud will
then inform users that requesting the services you need will
happen through this IP.
E. Decision Module for Selecting Volunteer Nodes as Or-
chestrator or Fog
This module is triggered by the orchestrator or fog man-
ager where an orchestrator or a fog is setup based on its
decision. The optimal selection among nodes is based on
several criteria and profiling measures, which is considered
as multi-objective optimization problem (currently under
development and out of the scope of this paper). For now,
we assume that the chosen orchestrators or fogs are the most
suitable one to run the assigned services which may not be
always the case in real life scenarios. This module chooses
and initializes orchestrators or on-demand fogs based on
their provided profiles such as resources, computation power,
number of requests initiated by users in a specific location,
and the time availability. If an orchestrator should be selected
and initialized to cover a particular area, this algorithm will
have the responsibility to send required modules of our
framework to run on the selected orchestrator. The chosen
orchestrator’s resources should be high enough depending on
the services demands that are known for all the orchestrator
and specified by our framework. If a fog is to be chosen,
it will select it based on the services that should be hosted
in the particular area by comparing its demands to what we
have currently in the available volunteering set.
F. Volunteers Management
The cloud accepts volunteering requests from users and
stores them in a database. The data contains the profile of
the user and most importantly its location. This database is
accessed by the elaborated volunteer management algorithm
whenever the cloud wants to choose an orchestrator. It can
be a file running on the orchestrator having the list of all
available volunteers in its cluster.
G. Profiler
This module allows the master node of a cluster to request
all the necessary information about the device including the
964
computation power, number of CPUs, current CPU usage,
size of the memory, memory usage, size of the disk, disk
usage, battery level if available, name of the device, and more
importantly its location and time availability. The profile
is updated frequently and requested when needed from the
cloud or the orchestrator.
H. Fog Client:
In this section, we discuss the fog client functionalities
running on the volunteering fogs.
1- Sending Requests to Join a Cluster: When a vol-
unteering device wants to advertise its resources to join
as orchestrator or fog, the fog client sends join requests
containing its advertised resources (profile) to the cloud to
keep a record of it.
2- Keeping orchestrator Updated: The volunteer device
replies to the cloud by sending its updated version of the
profile once requested based on time stamps.
IV. I MPLEMENTATION AND E XPERIMENT
We dedicate this section to describe the implemented
scenario and experiments to proof the feasibility and effec-
tiveness of our approach while discussing our findings.
A. Implementation
In order to proof the efficiency of our proposed on-demand
approach, we built a suitable environment composed of many
nodes and a typical network topology where a user can access
services running on machines present in a lab and others
on a cloud server. We set up the environment on a Linux
EC2 T2.small instance running on AWS cloud. We used in
the lab an HP Core i7 laptop running Windows7 with 8GB
of RAM and a Raspberry pi2 to demonstrate the usage of
mobile resource constraint device. The user requesting the
service was two hops away from the lab. The service used
for testing in this environment was composed of a simple
image. The container of the image receives requests from
users and replies back with an HTML file. The purpose
of choosing this service is to check the networking delay
to receive responses from the hosting device rather than
counting on the computation power of them for now. The
service was implemented in Python using Flask framework
along with its Docker file that was pushed to Docker Hub
repository for further usage.
B. Experiment
To illustrate the advantage of our proposed on-demand
scheme, we prompt the AWS instance on the cloud to
send an http message to the Windows7 machine containing
a Kubeadm Init command. Windows7 runs this command
to have the orchestrator initialized. It takes 25 seconds to
initialize the orchestrator on the Windows7 laptop. The user
will not realize the time delay if the Kubeadm cluster is
initialized before-hand, so the cluster is ready whenever
the cloud decides to push any service on the ready cluster.
Once the orchestrator is ready, it sends the cloud a ready
status with a kubeadm token. Furthermore, the cloud tells

Fig. 3: Percentage and Response Time of Requests Sent to
Fog Running On Raspberry Pi2 Against Regular Cloud.
the Raspberry pi2 to join the Kubeadm cluster created by the
Windows machine by sending the token to it. The time for the
Raspberry pi2 to join the cluster is around 24s. This time is
also not counted in our experiments because the Kubeadm
cluster is ready beforehand (We did not include the graph
corresponding to joining time of devices to Kubeadm cluster
because of the space shortage). The pi runs Kubeadm Join
command with the corresponding token to become part of
the cluster. Consequently, the Raspberry pi2 is now the only
worker node active in the windows machine cluster.
We assumed that there is a need of pushing our HTML
service near our user. This request is sent to the orchestrator
that decides to push the service to the ready fog for use.
Figure 3 shows the difference between the response time of
different number of requests sent to the cloud, against the
ones sent to the nearby fog, including the time of pushing
the service from the concerned repository.
The results are promising where major time saving is
achieved with respect to accessing the service from the
cloud. It also explores the feasibility and advantage of our
on-demand approach in real life. The response time of the
requests going to the fog is growing at the beginning until
the docker images get downloaded on the master and the
container is ready to serve. Cluster initialization time is
not counted because it is created before-hand. During this
time, requests continue their flow to the cloud. After having
the service running as container on the fog, the response
time is almost negligible with a value of 16 seconds for
1000 requests compared to the cloud that takes around 220
seconds. An almost constant 93% improvement in response
time is achieved. The results illustrate the significance of our
approach by pushing a fog on the fly to start serving on the
Raspberry pi2 with the least initialization costs possible.
V. C ONCLUSION
Static services running on fog devices along with their
availability near IOT devices are the main challenges targeted
in this paper. User intervention is required to update the pre-
configured services running on fogs. We were able to solve
the problem of fog availability by utilizing idle volunteering
965
resources present anywhere close to users. On the other
hand, we used Kubeadm and Docker to manage the required
services on the fly on volunteering fog devices. A fog can
be any constraint device. Containerization technology and
volunteering resources form our on-demand fog formation
solution to create fog devices on the fly wherever and
whenever needed. This approach is composed of a second
cooperative layer of orchestration to handle the volunteers
and the dynamic environment of resources present. Services
running on them can be updated according to the need.
Kubeadm cluster is created before-hand when possible to
avoid the initialization time when possible. The feasibility
and improvement of using the on-demand fogs as serving
nodes is proven by the experimental results compared to
the cloud as a serving node. The paper shows promising
results in this context. As a future work, we will add the
SDN controller component to the fog manager to manage
all routes between volunteering fogs and update users with
the proper path to reach their services. In addition, we are
working on optimizing the distribution of services on the best
set of suitable volunteers in a particular area next to users.
Our next interest will be to create the model of deciding on
the time a serving fog is needed by studying users behavior
in locations of interest from the log files of the cloud.
R EFERENCES
[1] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of
things (iot): A vision, architectural elements, and future directions,”
Future generation computer systems, vol. 29, 2013.
[2] A. M. Alberti and D. Singh, “Internet of things: perspectives, chal-
lenges and opportunities,” in International Workshop on Telecommu-
nications (IWT 2013), 2013.
[3] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and
its role in the internet of things,” in Proceedings of the first edition of
the MCC workshop on Mobile cloud computing. ACM, 2012.
[4] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, “An updated
performance comparison of virtual machines and linux containers,”
in 2015 IEEE International Symposium Performance On Analysis of
Systems and Software (ISPASS). IEEE, 2015.
[5] D. Merkel, “Docker: lightweight linux containers for consistent de-
velopment and deployment,” Linux Journal, vol. 2014, no. 239, p. 2,
2014.
[6] R. Smith, Docker Orchestration. Packt Publishing Ltd, 2017.
[7] S. Hoque, M. S. de Brito, A. Willner, O. Keil, and T. Magedanz,
“Towards container orchestration in fog computing infrastructures,”
in 2017 IEEE 41st Annual on Computer Software and Applications
Conference (COMPSAC), vol. 2. IEEE, 2017, pp. 294–299.
[8] R. Morabito, I. Farris, A. Iera, and T. Taleb, “Evaluating performance
of containerized iot services for clustered devices at the network edge,”
IEEE Internet of Things Journal, vol. 4, no. 4, pp. 1019–1030, 2017.
[9] C. Pahl, S. Helmer, L. Miori, J. Sanin, and B. Lee, “A container-
based edge cloud paas architecture based on raspberry pi clusters,”
in IEEE International Conference on Future Internet of Things and
Cloud Workshops (FiCloudW). IEEE, 2016, pp. 117–124.
[10] C. Wöbker, A. Seitz, H. Mueller, and B. Bruegge, “Fogernetes:
Deployment and management of fog computing applications,” in
NOMS 2018-2018 IEEE/IFIP Network Operations and Management
Symposium. IEEE, 2018.
[11] H.-J. Hong, P.-H. Tsai, and C.-H. Hsu, “Dynamic module deployment
in a fog computing platform,” in 2016 18th Asia-Pacific on Network
Operations and Management Symposium (APNOMS). IEEE, 2016,
pp. 1–6.
[12] G. Sayfan, Mastering Kubernetes. Packt Publishing Ltd, 2017.
[13] H. Zeng, B. Wang, W. Deng, and W. Zhang, “Measurement and
evaluation for docker container networking,” in 2017 International
Conference on Cyber-Enabled Distributed Computing and Knowledge
Discovery (CyberC). IEEE, 2017, pp. 105–108.