# A Smart Parking Solution Architecture Based on LoRaWAN and Kubernetes
## 5 Results  
In the following, some important achievements of the proposed solution are presented:  
The inclusion of Kubernetes within this architecture helped to have several instances of services running at the same time with limited OS capabilities. Kubernetes allowed to focus on the implementation of the service itself rather than configuring the whole server and the operating system for developing high available infrastructure. This technology runs over Linux servers and its management is easy to handle. Using containers in this implementation provided flexibility and scalability without much technical effort and hardware resources. In addition, capabilities of Kubernetes allowed the proposed solution to become a \"software as a service\" solution since it delivers all the layers of the smart parking solution. The following Figure 11 shows a comparative chart between the use of containers and virtual machines when deploying and RabbitMQ server. The chart shows one hundred tests and the time taken in collecting data sent from a sensor by a RabbitMQ consumer. The tests were performed by using a single sensor and one consumer, respectively. The orange line corresponds to the behavior of the RabbitMQ consumer over a container whilst the yellow line represents a consumer deployed over a virtual machine (VM). The average time taken to consume the information over a RabbitMQ container deployment borders 282 milliseconds whilst the average time of the same consumer over a VM borders 348 milliseconds which represents an increase of approximately 22%. This shows that the proposed approach in this paper is significantly better in terms of performance compared to a VM deployment. The architecture proposed helps to increase the performance of the solution. RabbitMQ fulfilled the purpose of having a centralized element to process payloads and take different actions depending on structures or content. The fact of publishing and subscribing into topics allowed to enrich raw data for further processing and storage into MongoDB. Figure 10: Web administration interface editing parking lots. Mosquitto acted as a pass-through bridge which was able to deliver all generated payloads from different sensors through the same gateway. At this point, there was no need to perform additional development to support such feature. The following chart (see Figure 12) denotes the time taken in milliseconds by the Mosquito component to process a set of requests. The Kubernetes deployment took an average of 156 ms to process a hundred request whilst the VM version took an average of 155 ms to process the same number of requests. In both scenarios, the maximum amount of time taken was 172 ms. However, the minimum amount of time taken by the Kubernetes deployment was 149 ms whilst the VM scenario tool 146 ms, this scenario took 3 ms less. In terms of general performance, Mosquito behaved very similar in both scenarios showing that performance was not degraded because of the Kubernetes deployment making it a feasible component that could be deployed over the proposed architecture. Figure 11: Time taken to process RabbitMQ Consumer requests. Figure 12: Time taken to process Mosquito requests. MongoDB, a NoSQL database, allowed the generation of complex information structures. The selected structures for the proposed solution were JSON based documents which contains all the required information. These documents can handle several fields of information without performing complex queries between different tables (as in standard SQL databases). NoSQL repository did not degrade the performance of the solution. Several tests were performed to measure the performance impact over MongoDB when performing several requests against the database. The chart in Figure 13 shows the performance of MongoDB in both deployment scenarios.