<commit_before>%!TEX root = ../dissertation.tex

\chapter{Conclusion}
\label{chapter:conclusion}
At the end, we accomplish our initial goals for this work. However, our solution presents some pain
points that can be enhanced in the future. This chapter outlines the main conclusions of our work,
point out the limitations of the developed work and discuss some improvements for future work.

% Outline
\section{Outline}
\label{sec:outline}
The \acrfull{IoT} is a paradigm where ordinary objects are continuously connected to the virtual
world and interacting with the surrounding environment. In order to make this environment more comfortable and
efficient, \gls{IoT} applications need to understand the context where they are inserted and also to
adapt to this environment. Thus, \gls{IoT} applications usually need to provisioning its infrastructure
in the physical place. This requirement makes that \gls{IoT} applications presents scalability
problems and also make them cost ineffective. The Utility Computing in the cloud helps to solve this
problems by leveraging part of the infrastructure of \gls{IoT} applications to the cloud. However,
\gls{IoT} applications are latency sensitive and the cloud must be able to meet this requirement.\\

Our solution is to determine if a cloud-based approach is suitable to deploy an \gls{IoT} application
for a smart warehouse that is based on the \gls{RFID} technology. To achieve our goals, we will
compare two approaches to determine which one is able to meet the \gls{IoT} applications requirements.
The fog-based approach, which brings the cloud to the edge of the network and a traditional cloud-based
approach, where the application is fully deployed in the cloud. In the implementation phase, we chose
the Fosstrak platform as the \gls{RFID} middleware for our application. The deployment of the
application middleware was performed in a different manner according the approaches. In the cloud-based
approach the application middleware is in the cloud, while in the fog-based approach the middleware
is distributed between the fog and the cloud.\\

To evaluate our solution, we focused in two points where \gls{IoT} applications are sensitive. First,
we evaluated the latency interaction for the proposed approaches. We also evaluated the data storage
performance of the Fosstrak middleware. Regarding the latency interaction performance, the obtained
results confirmed our initial hypothesis, showing that a fog-based approach presents a better
performance for the network latency when compared with the cloud-based approach. Regarding the data
storage performance, the obtained results show that the Fosstrak middleware can handle the amount
of data that is typically generated in a smart warehouse, but it can present some performance issues
if several users concurrently overflow the data repository with events.

% Limitations and Future Work
\section{Limitations and Future Work}
\label{sec:limitations_and_future_work}
Although we achieved the initial goals for our work, our solution still presents some aspects that
need to be improved and other aspects that we are not able to concretize.

% Implementation
\subsubsection{Implementation}
\label{subs:conclusion_impl}
Our solution proposes that the \gls{RFID} application is deployed following a fog-based approach.
This means that we need to have a cloud close to the edge of the network and this cloud must meet
the same requirements of a remote cloud such as high scalability, security and multi-tenancy.
Unfortunately, we are not able to accomplish a fog that meet these requirements and in our implementation
the fog was built on top of a traditional Virtual Machine.\\

In the current implementation we used Docker containers to provisioning the Fosstrak software stack.
In the evaluation of our solution we deploy the containers in a \gls{EC2} \gls{VM}, which overlays two
different mechanisms of virtualization. Although we still are able to take advantage of some benefits
from the containers such as the portability, other benefits such as the low I/O and disk space are
hidden by the \gls{VM} hypervisor. A future improvement that can be made is to perform the deployment
of the containers on top of the bare-metal or a cloud-based container service - e.g. Google Kubernetes
\footnote{\url{http://kubernetes.io/}}, \gls{AWS} \gls{EC2} Container Service\footnote{\url{https://aws.amazon.com/ecs/}} -
in order to improve the overall performance of the solution.

% Evaluation
\subsubsection{Evaluation}
\label{subs:conclusion_eval}
The evaluation was performed only in \gls{AWS} \gls{EC2} instances. For the future is important to
evaluate our solution in other cloud providers to compare which offers the best relation
cost/performance.\\

To evaluate the latency interaction, we defined only two different \textit{ECspecs}. For the future work,
we want to evaluate the latency performance for our solution with \textit{ECspecs} that presents smaller
periods in order to determine which specification is more suitable for our solution.\\

Another limitation of our evaluation process regards with the scenario. Since that a virtual \gls{RFID}
reader was used instead of a physical one, we are not able to reproduce the environment conditions
of a real smart warehouse such as interferences in the \gls{RFID} tags antennas, network bandwidth
variations, etc. Reproducing a real smart warehouse with physical \gls{RFID} readers and antennas
will improve our evaluation process in order to obtain more accurate results.<commit_msg>Improve the conclusion.<commit_after>%!TEX root = ../dissertation.tex

\chapter{Conclusion}
\label{chapter:conclusion}
At the end, we accomplish some of our initial goals for this work. However, our solution presents some
pain points that can be enhanced in the future. This chapter outlines the main conclusions of our work,
point out the limitations of the developed work and discuss some improvements for future work.

% Outline
\section{Outline}
\label{sec:outline}
The \acrfull{IoT} is a paradigm where ordinary objects are continuously connected to the virtual
world and interacting with the surrounding environment. In order to make this environment more comfortable and
efficient, \gls{IoT} applications need to understand the context where they are inserted and also to
adapt to this environment. Thus, \gls{IoT} applications usually need to provisioning its infrastructure
in the physical place. This requirement makes that \gls{IoT} applications presents scalability
problems and also make them cost ineffective. The Utility Computing in the cloud helps to solve this
problems by leveraging part of the infrastructure of \gls{IoT} applications to the cloud. However,
\gls{IoT} applications are latency sensitive and the cloud must be able to meet this requirement.\\

Our solution is to determine if a cloud-based approach is suitable to deploy an \gls{IoT} application
for a smart warehouse that is based on the \gls{RFID} technology. To achieve our goals, we will
compare two approaches to determine which one is able to meet the \gls{IoT} applications requirements.
The fog-based approach, which brings the cloud to the edge of the network and a traditional cloud-based
approach, where the application is fully deployed in the cloud. In the implementation phase, we chose
the Fosstrak platform as the \gls{RFID} middleware for our application. The deployment of the
application middleware was performed in a different manner according the approaches. In the cloud-based
approach the application middleware is in the cloud, while in the fog-based approach the middleware
is distributed between the fog and the cloud.\\

To evaluate our solution, we focused in two points where \gls{IoT} applications are sensitive. First,
we evaluated the latency interaction for the proposed approaches. We also evaluated the data storage
performance of the Fosstrak middleware. Regarding the latency interaction performance, the obtained
results confirmed our initial hypothesis, showing that a fog-based approach presents a better
performance for the network latency when compared with the cloud-based approach. Regarding the data
storage performance, the obtained results show that the Fosstrak middleware can handle the amount
of data that is typically generated in a smart warehouse, but it can present some performance issues
if several users concurrently overflow the data repository with events.

% Limitations and Future Work
\section{Limitations and Future Work}
\label{sec:limitations_and_future_work}
Although we achieved the initial goals for our work, our solution still presents some aspects that
need to be improved and other aspects that we are not able to concretize.

% Fog Implementation
\subparagraph{Fog Implementation}
\label{subp:fog_impl}
Our solution proposes that the \gls{RFID} application is deployed following a fog-based approach.
This means that we need to have a cloud close to the edge of the network and this cloud must meet
the same requirements of a remote cloud such as high scalability, security and multi-tenancy.
Unfortunately, we were not able to accomplish a fog that meet these requirements and in our implementation
the fog was built on top of a traditional Virtual Machine.\\

% Containers Deployment
\subparagraph{Containers Deployment}
\label{subp:containers_impl}
In the current implementation we used Docker containers to provisioning the Fosstrak software stack.
In the evaluation of our solution we deploy the containers in a \gls{EC2} \gls{VM}, which overlays two
different mechanisms of virtualization. Although we still are able to take advantage of some benefits
from the containers such as the portability, other benefits such as the low I/O and disk space are
hidden by the \gls{VM} hypervisor. A future improvement that can be made is to perform the deployment
of the containers on top of the bare-metal or a cloud-based container service - e.g. Google Kubernetes
\footnote{\url{http://kubernetes.io/}}, \gls{AWS} \gls{EC2} Container Service\footnote{\url{https://aws.amazon.com/ecs/}} -
in order to improve the overall performance of the solution.

% Cloud Providers Evaluation
\subparagraph{Cloud Providers Evaluation}
\label{subp:cloud_eval}
The evaluation was performed only in \gls{AWS} \gls{EC2} instances. For the future is important to
evaluate our solution in other cloud providers to compare which offers the best relation
cost/performance.\\

% Latency Interaction Evaluation
\subparagraph{Latency Interaction Evaluation}
\label{subp:latency_eval}
To evaluate the latency interaction, we defined only two different \textit{ECspecs}. For the future work,
we want to evaluate the latency performance for our solution with \textit{ECspecs} that presents smaller
periods in order to determine which specification is more suitable for our solution.\\

% Latency Interaction Evaluation
\subparagraph{Evaluation Scenario}
\label{subp:scenario_eval}
Another limitation of our evaluation process regards with the scenario. Since that a virtual \gls{RFID}
reader was used instead of a physical one, we are not able to reproduce the environment conditions
of a real smart warehouse such as interferences in the \gls{RFID} tags antennas, network bandwidth
variations, etc. Reproducing a real smart warehouse with physical \gls{RFID} readers and antennas
will improve our evaluation process in order to obtain more accurate results.
{'fraction_non_alphanumeric': 0.04328058057182828, 'fraction_numerical': 0.0005246130978403428, 'mean_word_length': 5.06790450928382, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '514631', 'n_tokens_mistral': 2736, 'n_tokens_neox': 2643, 'n_words': 1613}