# Enabling the Orchestration of IoT Slices through Edge and Cloud Microservice Platforms
## 4 Validation of the Solution
### Throughput Measurements  
Before describing the tests executed to measure the throughput obtained when deploying the Edge X gateway in the Raspberry Pi cluster (edge), and when it is deployed in the GKE (cloud), it is important to mention that these tests do not aim to provide benchmark figures or a possible comparison between edge and cloud computing. Performance metrics would typically depend on the IoT gateway and the IoT server implementations, which are under development in their respective open-source communities at this moment. The objective of these tests is to verify which is the best deployment option (edge or cloud) for the IoT gateway, when throughput requirements are more relevant than latency related requirements in an IoT solution. This will typically depend on the capacity that can be made available by edge-computing platforms (in our tests, edge nodes consist in a Kubernetes cluster made of several constrained devices). Throughput testing was also performed using the environment shown in Figure 5 with emulated devices using JMeter. Now, the comparison is done between the throughput measured when allocating the IoT gateway at the edge (slice 1) or in the cloud (slice 2). In this case, temperature measurements are not considered, just the number of hits per second in all InfluxDB time series databases. When the gateway is executed in the Raspberry Pi cluster (slice 1), several trials were performed, and the maximum throughput obtained was around 10 hits per second and was decreasing when the sending rate was higher than this number. Figure 9 shows the transmission of temperature measurements during one minute from JMeter emulated devices with a sending rate of around 24 messages per second. Figure 10a shows the throughput measured in the IoT gateway and Figure 10b the one measured in the IoT server. The throughput obtained in both sites is around 6.2 temperature hits per second and the time required to process all received messages is almost four times the sending period. Those measures also show that the limiting function is the IoT gateway since IoT server is able to follow the rate generated by the gateway. Figure 9: Throughput measured at JMeter source (~24 hits/second). Some measurements were also performed both at the IoT gateway and at the IoT server with different rates when the IoT gateway is executed in GKE cluster (slice 2). In this case the maximum throughput obtained is around 18 hits per second and the throughput figure is not decreasing so drastically as it was observed when the IoT gateway was deployed in the Raspberry Pi cluster. When sending messages from JMeter emulated devices with a sending rate of around 24 messages per second (similarly as it was shown in Figure 9), the throughput measured in the IoT gateway is around 16.3 temperature hits per second (Figure 11). Hence, Edge X gateway has almost three times better throughput when it is deployed in the cloud. With the hardware resources allocated to the IoT gateway at the Raspberry Pi, the throughput figures are lower than in the case of IoT gateway deployment in the GKE cluster. This is an expected result in realistic IoT deployments, where edge infrastructure resources may be limited in terms of computing and memory capacity. It must be highlighted again that the target of this research is not to develop optimum software implementations of the IoT gateway and server in order to obtain high throughput values, as it is expected from a commercial system. Even if this is not part of this research, it is important to mention that one way to increase the throughput could be achieved by changing the system to allow having more than one microservice replica (in this work a minimum set of microservices with just one replica is used), performing an efficient load balancing among these replicas. On the other hand,  
Figure 10: Throughput measured at the IoT gateway (**a**) and the IoT server (**b**) when the gateway is deployed in the Raspberry Pi cluster.