## 5 Validation of Results  
### Experiments Settings  
To evaluate the performance of the resources of each SPIDEP variant incorporating SOA and MSA (i.e., networks and infrastructure), spike testing was used to obtain quantitative values regarding the behavior of the services and their interaction with end users [53; 89; 105; 106]. Before performing these controlled tests, it was necessary to create two Kubernetes environments (K8s). The first environment, named SPIDEP-SOA-K8s, contains all the services of the SPIDEP SOA variant platform, with the following specifications: a custom instance of an Ubuntu Server 18.04 LTS (2 Core, 4 GB RAM and 80 GB SSD), PostgreSQL cluster (database dedicated server only) and a PODs replica. The second environment, named SPIDEP-MSA-K8s, contains all the services of the SPIDEP MSA variant platform, with the following specifications: each microservice has a custom instance of an Ubuntu Server 18.04 LTS (2 Core, 4 GB RAM and 80 GB SSD), PostgreSQL cluster (database dedicated server only) and no PODs replica. Additionally, each environment uses Apache as an endpoint and Nginx as a load balancer. The various user requests are received initially by Nginx, which sends the request to the corresponding services to address the URI-request [21]. After deployment of the K8 environments, the use of scripts with random variables developed in Apache JMeter (5.2) is required to measure and contrast the performance among the 50 virtual users (simulating the terminals of the biometric sensors) and the SPIDEP platforms; however, to avoid altering the results, it is necessary to use dedicated servers to perform these tests. Therefore, we have selected the BlazeMeter servers (US East [Virginia, Google]) to generate a heavy workload towards the platforms, according to small or medium instances of medical telemonitoring environments and their specifications (approximately 200,000 queries every 20 min) [7; 21; 53; 60; 93]; however, these platforms have the capacity of automatic scaling that will determine the distribution of computer resources according to demand (for these tests they were disabled, since we had medium instances), as shown in Figure 3.  
It should be noted that these experiments were evaluated and agreed upon by the experts within the project to be implemented in custom instance of an Ubuntu Server 18.04 LTS [21], as they were previously used to perform load and performance tests, all in order to ensure the quality of the services developed (i.e., performance, scalability and availability), and in conjunction with the use of recent technologies such as: (i) Docker, all platform services have been encapsulated as Docker images to enable their simple management, update and deployment processes within a Cloud environment. In addition, the Docker implementation can be based on individual containers or grouped into a combination of elements that form an overall service [28; 29]; (ii) Kubernetes, this technology is used for the orchestration of Docker containers, as it allows the initialization and scaling of container-based jobs, the exposure of services, as well as the rescheduling of failed jobs and long running services [90; 91]. However, all this set of technologies allows its adaptation and implementation in a simpler way by developers, which results in consistent, measurable, and replicable results. However, this cloud computing-based framework is intended to be implemented in different Linux distributions (e.g., Fedora, CentOS, Amazon Linux, Debian, and others) or Windows Server (e.g., 2016 or 2019). e.g., 2016 or 2019), since this framework is governed by the segmentation of an organization's logic into a series of separate services that run as independent and isolated processes; that is, it is not necessary to use the same languages, OS, database, or development platforms; however, to replicate these results all the specifications implemented in each variant must be taken into account, for more details please refer to Tables 1 and 2 in Section 4.