# Enabling the Orchestration of IoT Slices through Edge and Cloud Microservice Platforms
## 4 Validation of the Solution
### Test Environment  
In order to do the validation of the IoT slice orchestrator various Kubernetes clusters and distinct types of devices have been used and they are described in this section. Regarding Kubernetes clusters, three different clusters have been used:  
* A three Kubernetes node cluster deployed in Google Compute Engine, with two virtual CPUs and 7.5 gigabytes of memory per node. A Network File System (NFS) server with 10 GB of disk in the Kubernetes cluster had to be deployed since Google Compute Engine Persistent Disks do not support writing operations from different containers and it is required by the Edge X Foundry framework. In this cluster two instances of Mainflux (two IoT slices) were deployed and one instance of Edge X Foundry (for one slice). This cluster was used to compare the latency and throughput figures when the IoT gateway is deployed at the edge and when it is deployed in the cloud. * Another cluster composed by three Raspberry Pis 3B+ (cluster could have been created even in one board), all of them with one CPU core and 1 GB of RAM. The storage used in this case is provided through the file system of the Raspberry Pis. In this environment only one instance of the Edge X gateway was deployed for one of the slices. This cluster was also used to compare the latency and throughput obtained when IoT gateway is deployed at the edge and when it is deployed in the cloud. It is important to note that the number of Raspberry Pis in this cluster can be increased or reduced, according to the requirements of the IoT service to be deployed. In addition, the cluster can easily be onboarded on mobile units, such as small unmanned aerial vehicles, following the approach described by [PERSON] et al in [63] where a Raspberry Pi board is assembled in this type of vehicles. This enables a cost-effective solution to offer the functionality of an IoT gateway in IoT scenarios where network infrastructures are insufficient (or simply unavailable), to support data communications with IoT devices over a delimited geographic area (e.g., a remote area in smart farming applications). * Finally, one custom Kubernetes cluster virtualized in four virtual machines (each one with 2 virtual cores and 4 GB of RAM) created in a server with an 8 core AMD processor and 32 GB of RAM. The storage used in this case is represented by the file system of the server. This environment provided a baseline platform to evaluate the time used by the IoT slice orchestrator to create and deploy one IoT slice and to verify that several slices can cohabitate and properly operate within the same cluster (see Appendix D). In this case, both an instance of the IoT Gateway and an instance of the IoT Server were executed on the same server for each slice. Figure 5 shows the test scenario that has been built to perform the functional validation of the solution. This scenario uses the first two clusters in the list above, and it is as a simplified version of the example shown in Section 3.2, considering only two slices, which is sufficient for functional validation purposes. This setup is also used to compare performance figures in terms of end-to-end latency and in terms of throughput. In one of the slices (slice 1), an IoT gateway is deployed in a Raspberry Pi of the second Kubernetes cluster above, while the IoT server is deployed in Google cloud; in another slice (slice 2), both the gateway and the server have been deployed in google cloud (first cluster in the list above). Both clusters are interconnected through the Internet, using a commercial router that is able to route messages from the internal laboratory network, where the Raspberry Pi cluster is connected, to the Google Cloud, and vice versa.