## 6 Discussion  
The purpose of this study is to evaluate and contrast the performance of computing resources (i.e., response time, efficient use of infrastructure and network consumption) used by the different services for each SPIDEP variant, based on the concept of versatile high-performance (acceptance criteria) and the quantitative values obtained from the various tests (performance testing). Another purpose is to offer a software solution focused on the strengths and weaknesses of each variant (SOA and MSA) to provide customized eHealth functionalities and host functionalities based on AI algorithms (e.g., recommender system based on deep learning), according to the storage of adequate data for remote medical care scenarios (telemonitoring) and the demand and the size of the instances of the medical organizations (e.g., clinics, nursing homes or hospitals). There are several significant findings from this study. First, it is important to consider the acceptance criteria such as the average response time of the queries, the 90 th percentile, and their relationship with the percentage of failed requests. Therefore, according to various investigations [107; 108; 109; 110], it was established that the acceptable limit (criterion A) for the average response times of the queries and the 90 th Percentile is 5000 ms (five seconds) and the acceptable limit (criterion B) for the percentage of failed requests is 5%. Any test with results beyond the established limits is considered to have unacceptable performance [21]. Considering the above, from Table 3 we can establish that the tests with 50 concurrent users are acceptable, since both variants meet the two criteria defined; however, we have an interesting case in the SPIDEP-SOA-K8s-T2 and SPIDEP-MSA-K8s-T2 environments, specifically in the parameters of total number of queries, average response time and network consumption. As shown, in the SPIDEP-SOA-K8s-T2 environment, there is an average of 50,572 queries made (42.14 avg. hits/s), while SPIDEP-MSA-K8s-T2 has an average number of 110,435 queries made (92.02 avg. hits/s). This remarkable difference is due to the following two factors:  
* Architectural style: The attributes of MSA focus more on supporting the streamlining and reduction of microservice deliveries in the shortest possible time (all microservice must be lightweight, decoupled, isolated and independent of any programming language, libraries or databases). Conversely, SOA makes use of the ESB or central entry point, which are not considered agile enough [33] because the interactions between the services are interdependent; consequently, the overall performance of the system is affected for each service invoked simultaneously during a high demand under the SOA pattern [75]. This pattern cannot be changed since all the services developed remain loosely coupled and any change requires the rebuilding or reimplementation of the entire application (coarse-grained services) [62; 79; 80; 81]; therefore, the MSA variant is approximately 54.21% more efficient than the SOA variant in terms of total query numbers and average response times. * API gateway: It is important to consider that SOA has a centralized governance of services, which also affects the deliveries and responses of queries to users [33]. We have seen how services develop without considering the weak points of this technology, e.g., not considering the centralization of data (without instances) or not considering a Cloud infrastructure for the operation of the services. The resulting increased traffic of the API of HTTP resources degrades the overall performance of the application until its collapse [111; 112]. However, for MSA, applying decentralized and independent governance requires applying additional security measures unlike SOA (e.g., authenticating the user identity for each message sent and/or received through the signal mechanisms, the use of custom encryption PBKDF2 or the use of the ticket-based protocol CAS 3.0).