Evaluating Service-Oriented and Microservice Architecture Patterns to Deploy eHealth Applications in Cloud Computing Environment

Abstract

This article proposes a new framework for a Cloud-based eHealth platform concept focused on Cloud computing environments, since current and emerging approaches using digital clinical history increasingly demonstrate their potential in maintaining the quality of the benefits in medical care services, especially in computer-assisted clinical diagnosis within the field of infectious diseases and due to the worsening of chronic pathologies. Our objective is to evaluate and contrast the performance of the architectural patterns most commonly used for developing eHealth applications (i.e., service-oriented architecture (SOA) and microservices architecture (MSA)), using as reference the quantitative values obtained from the various performance tests and their ability to adapt to the required software attribute (i.e., versatile high-performance). Therefore, it was necessary to modify our platform to fit two architectural variants. As a follow-up to this activity, corresponding tests were performed that showed that the MSA variant functions better in terms of performance and response time compared to the SOA variant; however, it consumed significantly more bandwidth than SOA, and scalability in SOA is generally not possible or requires significant effort to be achieved. We conclude that the implementation of SOA and MSA depends on the nature and needs of organizations (e.g., performance or interoperability).

1. Introduction

Recent developments in the field of Cloud computing have stimulated the need to create new software solutions for the monitoring, management and optimization of an organization’s services, in which developers build an application and are not concerned about the underlying infrastructure. For this reason, several authors have proposed different software solutions, such as infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS) and function as a service (FaaS), focused on the intensive processing of data from different sources (e.g., Internet of Things (IoT) devices, data repositories or other sources) that will be consumed by the services to offer users different business-specific functionalities [1,2,3,4,5].

Within this context, the eHealth field is an area that is becoming increasingly important in public health policies because health care delivery systems (e.g., public health management or electronic health records (EHR)) are constantly evolving towards more patient-centered customized services and digital transformation (e.g., eGovernment) [6,7], which, based on data collected by the eHealth systems in conjunction with the recommender systems, can accelerate and drive decision making [8].

Considering the above, we have identified a growing concern regarding the increase in the aging population in our society. In Europe, the expected growth of the population over 65 will be 74% by 2060 [9,10,11], while in North America, it will be 20% by 2050 [12,13,14]. This trend places a serious burden on the public health system, since this group of people have high age-related comorbidity (e.g., degeneration in physiology and the abilities of memory, vision and decision), consuming extensive resources of both primary and specialized care [9,15], and consequently, it is more difficult for the elderly to adapt within society.

Telemonitoring systems are very popular today, since these systems are primarily based on the remote analysis of biometric data or daily activities, stemming from either a low availability of medical centers or mobility complications of people. These systems require the use of the Internet of Healthcare Things (IoHT) such as body sensors, bed sensors and smart watches for the collection and monitoring of people through their data, which allows the detection of anomalies in the vital signs of the elderly, and thus alerting medical personnel to these problems [16,17,18,19]. In addition, telemonitoring is an effective low-cost means for periodic health exams or preventive treatments in nursing homes [13,20].

Based on the ideas presented and the use of telemonitoring, we have focused on the design, development and implementation of a platform aimed at detection and clinical diagnosis assisted by a recommender system based on artificial intelligence (AI) algorithms within the field of infectious diseases for the elderly population living in nursing homes. It should be noted that this article is part of an extensive study in the field of infectious diseases focused on the three target groups of acute respiratory infections, urinary tract infections and skin and soft tissue infections. However, the article presented here is based in part on several previous studies by the partners of the Design and implementation of a low-cost intelligent system for the prediagnosis and telecare of infectious diseases in elderly people (SPIDEP) [21,22,23,24,25].

Another priority task in the concept of a platform targeted for Cloud computing environments is to define the architectural pattern to be implemented in the platform (e.g., service-oriented architectures (SOA) or microservices architecture (MSA)), which should be based on the needs (e.g., agility, maintainability or high-performance) and the nature of the organization (e.g., eHealth, transport, energy or supply chain management) [7,26,27,28,29].

For these reasons, this article describes the work done to evaluate and contrast which of the architectural patterns (SOA or MSA) is more consistent with the attributes of software focused on versatile high-performance within the eHealth context [21], while considering the strengths and weaknesses of each architecture based on quality of service (QoS) and its corresponding metrics. Therefore, it has been necessary to modify the SPIDEP platform into two variants following the guidelines of each architectural pattern, which allows us to analyze which of the variants optimally meet the proposed specifications.

However, the contributions of this article are: (i) to provide an overview of the differences between SOA and MSA; (ii) to identify the implications of designing, implementing and deploying SOA and MSA oriented platforms; (iii) to measure the performance of SOA and MSA variants, taking as reference the quantitative values obtained from experiments, and to contrast these obtained results with respect to existing research results. Nevertheless, the SOA and MSA architectural patterns can be considered complementary allies for an interenterprise architecture that confers a suite of different services rather than being competitors; therefore, it is expected that this future architecture will allow the integration and interconnection of different eHealth applications along with microservices adapted to machine learning for various medical scenarios (e.g., a patient monitoring system for hemodialysis or early forecasting of COVID-19).

This article is organized as follows: Section 2 presents a brief description of the related works, including the motivation for the SPIDEP project and its importance in the field of eHealth. Section 3 details the case study applied in SPIDEP, which is a project aimed at telemonitoring in nursing homes. Section 4 describes in detail the architectural models applied in the designs of the SPIDEP platforms and the technologies implemented. Section 5 shows the results of the spike testing based on the three categories of response time, efficient use of infrastructure and network consumption. The benefits and disadvantages of the results are evaluated in Section 6. Finally, Section 7 provides the conclusions of this study, analyzes its potential and suggests future research activities.

2. Background and Related Work

Currently, there is a growing interest in the use of archetypes for the development of various eHealth applications to represent the structure of clinical information and its specifications within a platform [30,31,32]; examples include traditional information systems, clinical decision support systems, platforms oriented to the HL7-FHIR protocol or telemonitoring systems, whose purpose is to significantly improve the accuracy of medical diagnosis by establishing expert systems-based prediction approaches or other means of artificial intelligence.

This interest is why we have performed a brief review of the various existing projects that show different analyses, applications and research conducted in this field; however, classifying these projects according to the architectural pattern implemented (i.e., SOA or MSA) was needed since it is necessary to analyze how SOA and MSA influence the development, integration and deployments of eHealth applications and how these patterns adopt principles or practices to address the software requirements.

2.1. Service-Oriented Architecture (SOA)

According to the norms and standards of service-oriented quality [33,34], SOA was one of the most used software architectural approaches in the early 2000s; it was used for the design and development of applications as services. This architecture aims to provide uniformity in the design, implementation and invoking of services required to meet the desired needs of the application [35]; that is, any process, subprocess or logic of an organization can be encapsulated in services [36].

As can be inferred, SOA is a business-focused information technology (IT) architecture that is supported by the integration of services. Consequently, all the services designed in SOA must comply with the following three fundamental software attributes [37,38]: First, each developed component must have the ability to be reused within the application (reusability). Second, the components must be able to communicate with each other or with other external applications (interoperability). Third, the application must allow the ability to adapt to future needs or objectives of the organization (extensibility).

As a follow-up to this activity, several research projects that propose the combined use of this architectural pattern with several software attributes will be outlined below, focused on various eHealth scenarios.

For example, Gavrilov et al. [38] propose a novel conceptual model of EHR focused on the aspect of cross-border interoperability [39], whose objective is to meet the needs of interconnectivity between the different eHealth systems of Macedonia, under the specifications of the European Patients Smart Open Services project [40,41]. Thus, the authors chose to combine the SOA architectural pattern with the use of the data warehouse (DW) and the following three technologies oriented to an extract, transform and load (ETL) process: the interface description (using Web services description language (WSDL) documents), the communication protocol simple object access protocol (SOAP) (using extensible markup language (XML)) and universal description, discovery and integration (UDDI) repositories (allowing users to find services) [38]. They have shown that the proposed model achieves a successful data exchange between the various platforms tested. Additionally, this model allows the classification and indexing of the data, which allows SOA to be able to communicate with different applications other than the predefined DW because each healthcare system is designed, implemented and validated by the HL7 fast healthcare interoperability resources (FHIR) protocol.

Likewise, Amin et al. [39] propose building a framework for the exchange of information among the eHealth systems of Indonesia, whose purpose is to integrate and synchronize data from different (heterogeneous) platforms through web interoperability. This framework was designed under the concept of service-oriented analysis and design (SOAD) [42,43], which is composed of the three main phases of the conceptual view (CV), which illustrates to those involved all the activities that encompass the workflow of the organization; the logical view (LV), which encapsulates all the logic identified by the CV in various software services; and the physical view (PV), which implements the different web layers, including the presentation, application service, domain model and data access layers. The three previous phases focus on a logic based on SOA, whose objective is to process all user information and exchange data among platforms using the RESTful protocol [44]. They validated their framework by successfully relating eHealth systems and integrated entities and the exchange of data and information in the form of an interoperability matrix (IM), so that organizations can use this matrix as a point of reference for adaptation.

Hameedet et al. [45] present a framework oriented to the real-time monitoring of the vital signs of patients (e.g., electrocardiogram, body temperature, pulse rate and oxygen in blood); their framework consists of the combined use of the SOA architecture, rich Internet application and the IoT (Arduino and eHealth sensor shield) [46]. This combined use is necessary because the framework requires the ability to communicate between services and their sensors and to make associations between different medical administrations (e.g., clinics or medical centers); therefore, the implementation of the REST protocol was required to comply with this aspect [47]. They have shown that the proposed framework increases the efficiency of data collection because each service is designed, implemented and validated in an automated manner for the monitoring of a large number of patients.

Silva et al. [48] develop a pilot system called the mHealth application, based on existing practices of IoT and the SOA architecture, focused on telemonitoring of patients. The main objective of this system is to optimize the follow-up services and treatment of arrhythmias or other heart conditions of the patients remotely, which provides coverage to rural or difficult to access areas. This system consists of the four main modules of the monitoring process and patient electronics (main component of the application), body sensor (cardiac arrhythmia detection), caching mechanisms (temporarily stores data in case of network unavailability) and an alert messaging system (sends a warning to health care professionals if an anomaly is detected). They validated their system using a performance assessment and quality of experience (QoE); their results demonstrated a significant improvement in medical care and assistance to patients. In addition, an unexpected result was that the management of medications was more accurate, efficient and less costly for the medical institution.

2.2. Microservice Architecture (MSA)

Currently, there is a growing interest in MSA in both the industrial and research sectors due to its various advantages, including flexibility, agility, infrastructure automation and loose coupling [49,50,51]. MSA is considered a more refined and simplified version of SOA [33,52], since this architecture responds to the needs of scalability of applications by segmenting the logic of an organization into a series of separate services that are executed as independent processes; that is, it is not necessary to use the same languages, databases or development platforms [21,53,54]. In addition, MSA inherits from SOA the concept of interoperability through the implementation of lightweight mechanisms such as HTTP-based API and others [39,50,55].

Many organizations have recognized the benefits in the migration of their legacy software to microservices-based solutions to enable their applications to evolve, rather than acquiring new third-party software [52,54]. However, performing this process (known as granularity) requires using a pathway or model that can successfully migrate the application; consequently, this factor depends on the use of design patterns (e.g., decompose by business, by verb or use case, by subdomain or by nouns or resources) and how the performance stability of the services is affected [50,51,53,56].

A description of the most significant studies of the new MSA solutions within the eHealth domain is necessary.

Carranza-García et al. [57] present two technological solutions based on MSA (i.e., cognitive training “VIRTRAEL” and frailty prevention “PREFRA”). These solutions aim to integrate the different age-related aspects from the cognitive, physical and social levels; therefore, when addressing these factors, more complete and reliable assessments of the elderly are obtained. However, to achieve this objective, the systems must have the four essential software attributes of reusability, extensibility, interoperability and composition, since these are required for the design, development and implementation of more complex functionalities that make use of different recent technologies (e.g., web or mobile). They have shown that the proposed technologies are a viable solution aimed at meeting the required quality attributes.

García-Moreno et al. [58] develop an MSA-based system that collects sensory data of the elderly in their daily activities (e.g., toilet hygiene or functional mobility); these data include not only a physical dimension but also cognitive and social dimensions. This system is supported by using IoT (i.e., wearable devices), which are used by microservices focused on the collection, analysis and interpretation of data. In addition, this system is supported by several machine learning algorithms (e.g., kNN, RF or NB) to build more accurate models for detecting anomalies in people [59].

Jarwar et al. [17] provide a model focused on semantic interoperable data-driven microservices. This model is responsible for capturing, representing and analyzing various types of data related to depressive disorders (DD). These data are vital to providing the model with a way to monitor the symptoms of DD through the use of indicators (e.g., user facial expressions, voice tone, user emotions from wearable sensors, social network services posts (SNS) and tweets). Generally, microservices do not make intelligent decisions based on data [60]; therefore, it is necessary to implement the following two dedicated servers in the model for this scenario: data mining/machine learning (extracts features and monitors the symptoms from the sensor data and SNS) and web of objects server (applies the semantic web technologies and inference of the user situation to provide the services to the users).

Da Silva et al. [30] propose a tool called Microservice4EHR, which is based on the OpenEHR standard used for the computational representation of EHR (archetype) [61] and the conceptualization of a microservices-oriented software architecture. This tool consists of the five functionality phases of a tool access key, the host server address of the MSA component, a graphical interface with health data based on archetypes, a graphical interface filename and the input/output data (in JSON format), which is processed and presented in a web application [30]. Moreover, all these approaches have the purpose of building reusable components that can be used as building blocks in health applications (e.g., a blood donation center in northeastern Brazil). Additionally, this attribute improves the capacity of the maintainability and interoperability of the applications between the information systems.

2.3. SOA vs. MSA

Considering the above, the previously cited studies reveal different eHealth applications, based on SOA or MSA, that focus on one or several of the software attributes of interoperability, maintainability, reusability and scalability.

Both architectures have their strengths and weaknesses, according to the needs of the software and implementation [62]. SOA focuses mainly on the sharing of services in relation to the processes or capabilities of an organization [50,63]. In this sense, SOA can refer to a broad accumulation of knowledge over the last two decades [62]. Regardless, this approach presents many issues when correcting errors or adding new functionalities, since the design of the application is very complex and time consuming. In addition, scalability in SOA is generally not possible or requires significant effort to be achieved. Consequently, organizations are beginning to migrate to other architectural solutions such as MSA [64,65].

MSA allows efficient development, implementation and maintenance of services compared to SOA. In fact, since the services are autonomous, they can be developed, maintained and tested independently, which facilitates their automation and continuous deployment (e.g., DevOps practices) [21,50,66]; however, such practices entail complexities inherent to a distributed computing environment in relation to the isolation, availability, security and transaction of services [33,50], which in turn causes a fundamental problem known as granularity (i.e., if a microservice needs to decompose or merge) [21,51].

Based on these considerations, the implementation of SOA or MSA depends on the nature of the target system to be developed. Thus, for the development of our eHealth application, it is of utmost importance to contrast the performance between SOA and MSA based on the concept of versatile high-performance [21], since it is necessary to meet the needs of the environment of health organizations, focused on horizontal scalability. Quicker and more accurate real-time responses to demand peaks are thus enabled [22]. Additionally, it is necessary to allow the hierarchy and consolidation of a patient’s clinical information, including what is necessary not only for generating standard reports but also for allowing the integration of recommender systems, to support decision making with consistent and truthful parameterized indicators of the data collected [21].

3. A Case Study from eHealth

The work presented here is based on a previous study performed by the SPIDEP project part of the Joint Call ERANET LAC 2015—FP7 [67], whose objective was to build an intelligent system based on information and communication technologies (ICT) to support the early diagnosis of infectious respiratory and urinary diseases in the elderly [21,24]. For this, an international consortium was formed between the clinical research teams and the Infectious Diseases Unit of the Hospital Universitario Principe de Asturias (Alcalá de Henares, Spain), the Chronic Diseases and Cancer Area of the Ramón y Cajal Institute for Health Research (Madrid, Spain) and the School of Medicine Autonomous University of Santo Domingo (Dominican Republic) and the research teams of the Computer Sciences group of the University of Alcalá (Universidad de Alcalá) and the Technological University of Panama (Universidad Tecnológica de Panamá).

This study incorporates patients living in the Francisco de Vitoria and Cardenal Cisneros nursing home in Spain and residents of the Carls George and Nuestra Señora del Carmen Institution for the Care of the Elderly in the Dominican Republic. The main purpose of the study is to provide health services and care to people at risk or who have difficulties in accessing health services through the use of new technologies to achieve greater efficiency in the organization and care of special population groups, with the added value of cost savings [21].

Actually, health monitoring has become one of the biggest areas in the technology industry, developing many smart devices like watches or another more specific body sensors. This has allowed researchers to contribute to the development of eHealth platforms focused on regularly monitoring the vital signs of at-risk patients, with the aim of carrying out treatments or preventive interventions to minimize health problems and reduce emergency care [10,16,17,18,46,48,58].

4. Model and Design of SPIDEP Platforms

To perform this study, a merging of the computational paradigms of the Edge and the Cloud was used [68,69], based on a hybrid Cloud architecture to support medical telemonitoring applications [21] under the two architectural patterns (i.e., SOA and MSA).

In this sense, we focus on the evaluation of the design, development and implementation of the services created for our use case (SPIDEP) and how they affect performance related to the response time to queries, the efficient use of infrastructure and network consumption.

4.1. Analysis of Software Attributes

This preliminary step is fundamental for the design and development of applications, since it is necessary to define an adequate set of software attributes according to the needs identified [7].

In response to these considerations, it is of utmost importance to mention our needs; they are as follows: (i) neutral technology—those responsible for the development, implementation and monitoring of the assigned services may decide which is the best technology to use according to their objectives; (ii) automation and continuous deployment—each component should be autonomous, independent and focused on a specific task according to the established decomposition (e.g., by verb or use case). In addition, it must have the individual ability to replicate to balance the load, as necessary; (iii) scalable to the demand—the services require a horizontal scalability that allows a faster and more precise reaction to the demand peaks; (iv) interoperable—each service must run a lightweight communication mechanism (e.g., RESTful) to communicate between the different applications or services, either their own or those of third parties. In addition, this mechanism should not have access to visual elements, i.e., it must be separate from the front-end; and (v) high performance—the application must support a large volume of queries of the REST methods (e.g., GET, POST, PATCH and DELETE) from the integration, transfer and storage of the biometric sensors from the different nursing homes (Edge) to the various services offered by the SPIDEP hybrid (Cloud).

As explained in Section 2.3 (SOA vs. MSA), it was decided to adopt the concept of versatile high-performance, since it allows us to meet the needs of the project [21].

4.2. Variants of Software Architectures

Considering the above, it was necessary to build two variants of SPIDEP, according to the specific attributes of each architectural pattern; however, SOA and MSA have different approaches in terms of how their services are designed, implemented and deployed [33,70]. In addition, it must be remembered that MSA remains an architecture in training, while SOA has been studied for more than a decade [35,62].

Therefore, it has been decided to establish two branches of the SPIDEP application since it allows us to contrast and evaluate which of the variants fully meets our criteria [71,72,73].

4.2.1. SPIDEP SOA Variant: Platform Design

The first proposed platform (SPIDEP-SOA) is intended to manage the interactions between users (consumers in the upper layer) and health services (software functionalities in the lower layer), according to the changing needs of the platform (technology, demand and security), as shown in Figure 1.

Next, we will briefly outline our first variant of the platform, which consists of six layers focused on the management of services under the computational paradigms (i.e., Edge and Cloud) [23], as follows:

• Consumers: This layer allows interaction and exchange between the health professionals of the different homes (nurses and assistants), the hospitals in charge of each region (general physicians) and the eHealth applications (SPIDEP or others).
• Edge layer: Establishes HTTP connections with the APP for the asynchronous sending of medical data in the Cloud (i.e., the Cloud layer) [33], whose data come from the different users and their sets of biometric sensors (i.e., blood pressure, pulse rate, body temperature, oxygen saturation and electrodermal activity) [23]. It should be noted that this communication is encrypted by the security layer.
• Cloud layer: This layer performs heavyweight computations; that is, it helps consumers discover, route and deploy health services and infrastructure. In addition, this layer consists of the three sections of infrastructures and resource, support functions and control system. Additionally, different algorithms are used to achieve various objectives (e.g., error tolerance and load balancing) [74].
• Service layer: Contains services for the end users like medical personnel and nursing home administrative staff with their respective profiles.
• Security layer: Ensures access control and consumer authentication through established security policies, whose objective is to determine the user privileges for certain resources and/or specified levels of services.
• Management system: This layer mainly controls the flow of messages between the different layers. In addition, it is responsible for executing the real-time adaptation of the services (versatility) according to demand, e.g., automatically adding a new instance, monitoring the status of the different components that integrate the platform or other monitoring tasks.

It should be noted that this variant of SPIDEP was a refactoring of the legacy application [23] whose purpose was the modernization of existing services oriented to our current software attribute (i.e., versatile high-performance) [64]; however, the strengths and weaknesses of SOA must be considered.

Considering the above, the strengths of SOA are the following:

• Provides a higher level of compression related to the abstraction of the interfaces than MSA (decoupling) [62], since SOA traditionally has the integration of an enterprise service bus (ESB) [75], which facilitates the interaction between the services of the platform.
• Offers extensive knowledge that has been established over more than a decade, which has proven to be effective and reusable in building platforms. It is thus easier for developers to ensure the quality of service required by the organization [76].
• Suitable for large and heterogeneous systems consisting of many applications, nonindependent services and shared components [33,77]. It provides a roadmap for the adoption of its principles, which allows developing or transforming the capabilities of an organization’s software system into reusable services for greater flexibility and agility [78].

However, when applying SOA, the following weaknesses or difficulties must be considered:

• Message exchange is traditionally synchronous (wait-to-connect); i.e., it depends on the state of the ESB [33]. However, when applying a design oriented to service implementation patterns, the support of asynchronous messages is integrated, increasing complexity and maintainability and reducing flexibility [33,76,79,80].
• When developing platforms based on SOA, it is complex to add or modify functionalities to what has already been established; redesigning this type of platform consumes significant time and resources [64,81].

4.2.2. SPIDEP SOA Variant: Implementation of the Platform

For the implementation of the SPIDEP-SOA platform, we opted to modernize the first version developed (Beta “traditional implementation of seven SOA services, without API support”) [23] to the release candidate (RC) (“Modernization of services and current technologies (language, database, libraries and integration of an API)”), whose purpose is to provide the necessary attributes for the implementation of versatile high-performance applications and contrast it with the MSA variant. Therefore, we proceeded to the refactoring and restructuring of the existing components along with their data [53,82], as shown in

Table 1. General structure in the SPIDEP-SOA platform.

Description		Version
Category	Subcategory	Beta	RC
System architecture	Architecture styles	SOA	SOA-based on Quality Requirements
	SOA patterns	Enterprise Service Bus (ESB)	Service Implementation Patterns
	Communication protocol	HTTP	HTTP
	HTTP methods	Disable	GET, POST, PATCH & DELETE
	Messaging type	Synchronous	Synchronous/Asynchronous
Used technologies	Programming language	PHP 5.6	PHP 7.4
	Framework	Laravel 5.1 LTS	Laravel 6 LTS
	Core libraries	acoustep/entrust-gui; zizaco/entrust; Laravel Passport; mockery/mockery; phpunit/phpunit; tinker; composer, and others	Guzzle; fideloper/proxy; kylekatarnls/laravel-carbon-2; zizaco/entrust; Queues; Laravel Sanctum; mockery/mockery; phpunit/phpunit; tinker; composer, Custom libraries, and others
	UI	Bootstrap 3	Bootstrap 4
	Web server	Apache	Apache as an endpoint and NGINX as a load balancer for the implementation
	DBMS	MariaDB 10.1	Postgresql 10
	Data access methods	Stored procedures	Stored procedures
	Object–relational mapping	Eloquent	Eloquent
	API Scheme	Disable	RESTful (JSON Request/Response HTTP)
	API Gateway	Disable	Central Entry Point
	Deployment	Bare Metal	Custom Docker Container
	OS	Ubuntu 16 LTS	Ubuntu 18 LTS
	Authentication Scheme	HTTP Basic Authentication	Custom Authentication (OAuth1, OAuth2 or JWT Web Token)
	Encryption Protocol	OpenSSL (AES-256 and AES-128)	OpenSSL (AES-256 and AES-128) and public/private rsa key pair

for each version.

4.2.3. SPIDEP SOA Variant: Deployment of the Platform

When applying an SOA design pattern (compound, service implementation, service composition, inventory and others) [80], a positive impact is obtained on certain quality requirements (i.e., performance or interoperability), which negatively affects other quality requirements (i.e., redundancy or security). Therefore, it is important to select design patterns according to the software attributes and quality requirements [76].

Considering the above, service implementation patterns were chosen for the development of the SPIDEP-SOA platform, since they allow creating versatile and scalable services that run in the Cloud [83,84]; however, an automated workflow must be defined for the integration and continuous deployment of services [21,80].

Within this concept, we have adjusted our framework for this variant (mainly in the first three sections) [21], because SOA is geared to a modular design to reduce dependencies between platforms [37,85], i.e., that the services collaborate and share their resources (loose coupling), unlike MSA where the services are decoupled and isolated [33].

In addition to the situation, a general overview of the SOA-based proposal follows [21]:

• Teamwork: Responsible for the coordination and monitoring of all platform services (business-centric IT) [86].
• Services: Unlike our MSA framework, each team does not have the autonomy to decide which is the best technology for the development of services. These teams should adhere to the Teamwork decisions that follow the business functionalities. For example, all SPIDEP-SOA services were developed under the Laravel PHP framework and a single DBMS, PostgreSQL 10 (the core systems, except for the mobile app, were developed in Java); however, all services are supported by an asynchronous HTTPS server that is based on transport layer security (TLS) for client authentication and can replicate instances based on demand, unlike the traditional SOA approach.
• Code repository: A Git repository is used to maintain version control of the code from the development branch of the services that make up the platform [87,88].
• Software analysis and testing: The source code and the environment are reviewed to ensure correct functionality and that they meet the desired standard; then, unit tests of the services are performed (e.g., PHPUnit).
• Docker containers (test environment (TE)): To ensure the stability and scalability of our platform, we opted for the customization of a test container (Ubuntu Server 18.04 LTS, 2 Core, 4 GB RAM and 80 GB SSD); however, these containers must pass preliminary test criteria defined by Teamwork before being published in the Docker Hub in a private repository.
• Quality assurance (QA): Functional tests, interoperability tests, and load and performance tests are performed to ensure the quality of services [21,34].
• Docker containers (production environment (PE)): If the integration of all services in the platform is successful, the stable version of the container is deployed to Docker instances (under the same TE attributes); otherwise, the code should be debugged and the QA tests rerun.
• Performed postproduction: Additional tests (e.g., long-term spike testing) are run to ensure that the services work properly in all instances [21,53,89].
• Managed Kubernetes: Kubernetes is used for automating management of computerized services, since it reduces the manual and repetitive processes involved in container management [90]. In addition, Kubernetes scales according to demand, i.e., it increases the use of resources in high demand, and if demand decreases, idle resources are reused [91]. Unlike the traditional SOA approach (which does not have scalability support), it was necessary to make several adjustments to the RC version of the platform.

4.2.4. SPIDEP MSA Variant: Platform Design

The second proposed platform (SPIDEP-MSA) is geared to the use of microservices in the expected medical scenarios of infectious diseases (like its other variant) [21,22,24], as shown in Figure 2.

Both platforms aim to support the interpretation of changes in vital signs of elderly people living in residential facilities, thus alerting the medical team in advance of possible infections; however, the MSA variant has a recommender system to improve decision support in the prediagnosis of infectious diseases [25,92]. Following, we will briefly explain the flow of the SPIDEP platform in relation to microservices [23]:

• Edge architecture: Manages the collection, preprocessing and sending of data from the different biometric sensors (e.g., ECG, blood pressure, SPO2 or others), whose data are backed up locally. If necessary, temporary actions can be performed (e.g., delete, filter or update) before the data are sent to the Cloud architecture, which enables analysis with local data to streamline decision making in case of emergency [16,93]. It should be noted that the connections with each APP are made asynchronously and independently for each stakeholder.
• User communication: Provides the necessary mechanisms for correct communication between the different layers and sublayers (e.g., data, validation of credentials or other). This communication is achieved through the representational state transfer (REST) protocol and its methods (i.e., GET, POST, PATCH and DELETE); however, this protocol requires the use of an API gateway. Therefore, taking advantage of some of the strengths of MSA (e.g., decoupling and isolation of microservices) [30], the Backends for Frontends design was implemented in the API gateway [56,89]. Requests are handled by each stakeholder (i.e., desktop, mobile and third-party source) and not traditionally (i.e., single entry point); consequently, additional security mechanisms must be implemented for their validation [7,94,95].
• Cloud architecture: Provides services for end users (e.g., core or auxiliary microservices) according to their needs and the levels of user roles and permissions [21]. In addition, it manages the stored data of the different DBMS (database per service) [54,96] to provide benefits to target users (e.g., patients, medical personnel or health authorities) [16].

Similarly, we must remember the strengths and weaknesses of MSA. The strengths of microservices are the following:

• Each microservice is incapsulated; therefore, it has more flexibility to use new frameworks, libraries, data sources and other resources [64].
• It allows horizontal scaling of the services instead of vertical scaling as in the case of a traditional or monolithic SOA, which facilitates the ability to use more computing resources (e.g., CPU, GPU and RAM) that will act as a single unit; however, it can be distributed through multiple virtual networks [50,55].
• Each microservice is autonomous, has independence in the execution of its tasks, can be hosted in a specific server on the Internet, is available on the Internet (i.e., any software can interact with it) and does not share the same resources [30,97,98].
• The fault isolation can be obtained without interrupting the normal functioning of the whole system [16,52].
• However, when applying MSA, the following weaknesses or difficulties must also be considered:
• MSA provides many different advantages, but it also increases a solution’s complexity. To address increased complexity, an organization should prepare the specific infrastructure for microservices (i.e., obtain a clear picture of the data structure) [64,99].
• If the level of granularity is determined before knowing the business process or the useful life of the platform, it can lead to problems in the reasoning about the services (e.g., if a microservice should be decomposed or merged with another) [33,51].

4.2.5. SPIDEP MSA Variant: Implementation of the Platform

Similarly, for this variant (SPIDEP-MSA), the respective modernization of the latest built version was performed (β v2 “implementation of the nine microservices, with hybrid instances in MariaDB Galera Cluster and NoSQL, and two EndPoint (Mobile/PC)” [21] to the RC (“Modernization and restructuring of microservices and current technologies (language, database, libraries and integration of a third EndPoint)”).

The following is a general description of the technologies implemented in each version, as shown in

Table 2. General structure in the SPIDEP-MSA platform.

Description		Version
Category	Subcategory	Beta v2	RC
System architecture	Architecture styles	MSA	MSA
	MSA patterns	Service instance per-container; Database per service & API Gateway	Service instance per-container; Database per service & API Gateway-
	Communication protocol	HTTP	HTTP
	HTTP methods	GET, POST, PATCH & DELETE	GET, POST, PATCH & DELETE
	Messaging type	Synchronous/Asynchronous	Synchronous/Asynchronous
Used technologies	Programming language	PHP 7.2 (µs-A) & Python 3.6 (µs-B~I)	Python 3.7 (µs-A~G) & Python 3.8 (µs-H~I)
	Framework	Laravel 5.4 LTS (µs-A) & Django 2.1 (µs-B~I)	Django 2.2 LTS (µs-A~G) & Flask 1.1 (µs-H~I)
	Core libraries	PHP/Laravel dependencies (Guzzle;Laravel Sanctum and others), Python/Django dependencies (setuptools;requests;psycopg2;requests_futures;lxml;six;django-cas-server;django-cas-ng;djangorestframework; celery, TensorFlow and others) & Custom libraries	Python/Django~Flask dependencies (setuptools; requests; psycopg2; requests_futures; lxml;six;werkzeug django-cas-server;django-cas-ng; python-cas; djangorestframework; Flask-RESTful; celery, TensorFlow and others) & Custom libraries
	UI	Bootstrap 3	Bootstrap 4
	Web server	Apache as an endpoint and NGINX as a load balancer for the implementation	Apache as an endpoint and NGINX as a load balancer for the implementation
	DBMS	MariaDB Galera Cluster (Galera 3), Cassandra & Redis	Postgresql 10, Cassandra & Redis
	Data access methods	Stored procedures & Column Family	Stored procedures & Column Family
	Object–relational mapping	Eloquent, QuerySet & Django-Cassandra-Engine	QuerySet, SQLALchemy & CQLAlchemy
	API Scheme	RESTful (JSON Request/Response HTTP)	RESTful (JSON Request/Response HTTP)
	API Gateway	Backends for Frontends (2 EndPoints)	Backends for Frontends (3 EndPoints)
	Deployment	Custom Docker Container	Custom Docker Container
	OS	Ubuntu 18 LTS	Ubuntu 18 LTS
	Authentication Scheme	Custom Authentication [OAuth1, OAuth2 or JWT Web Token] & CAS Protocol 3.0 Specification	Custom Authentication [OAuth1, OAuth2 or JWT Web Token] & CAS Protocol 3.0 Specification
	Encryption Protocol	HTTP Authentication (Tokens and SSL); PBKDF2 with a SHA256 hash; public/private rsa key pair and custom authentication settings	HTTP Authentication (Tokens and SSL); PBKDF2 with a SHA256 hash; public/private rsa key pair and custom authentication settings

.

4.2.6. SPIDEP MSA Variant: Deployment of the Platform

To meet the software attributes and quality requirements, it was necessary to establish an automated workflow for the integration and continuous deployment of the microservices in SPIDEP-MSA. Therefore, we assigned a cross-team (typically a small group of six to eight people [100,101]) for each case (e.g., decomposed by verb or use case [56]); each team is responsible for the development, debugging and deployment of the assigned microservice. This workflow reduces the time between updates or new system functionality (without affecting end users) and implementation of changes to the production environment (without affecting system performance) [21,102,103].

Considering the above, we implemented the same framework proposed for the MSA variant of SPIDEP (beta v2), whose framework is divided into the following nine phases: (i) cross-team project, (ii) service, (iii) code repository, (iv) software analysis and testing, (v) test environment, (vi) quality assurance, (vii) production environment, (viii) performed postproduction and (ix) managed Kubernetes [21].

Unlike the SPIDEP-SOA variant, this platform requires applying the implementation patterns based on MSA (i.e., service instance per container, database per service and Backends for Frontends), since it is necessary to fully support a horizontal scalability of the resources. However, this entails an increase in the effort and complexity to manage all interactions between microservices, according to the size of the organization to be implemented [60]. Additionally, in this variant, we verify the identity of the user for each message sent and/or received through the signal mechanisms; therefore, a secure communication channel is established for different computer attacks (e.g., man-in-the-middle) during active sessions [104].

5. Validation of Results

5.1. 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 Table 1 and Table 2 in Section 4.

Other considerations to take into account would be: (i) type of input and output, for both platforms the RESTful protocol is used to communicate and HTTP methods (GET, POST, DELETE and PATCH). However, the data sent or received are delivered in JSON (Javascript Object Notation) format, since this format is easier to be interpreted by developers or electronic platforms. However, these platforms support other formats like HTML, YAML, XML, XLSX or TXT; (ii) general accessibility, the application was deployed in a cloud environment that can be accessed through a browser (i.e., Google Chrome, Fire-fox, Opera or others); (iii) number of tests performed, four joint tests were created divided into two concepts (Response time and Network consumption, and Efficient use of infrastructure) with an average of 200,000 samples per test for 20 min, grouped in two groups (SPIDEP-SOA-K8s-T1/T2 and SPIDEP-MSA-K8s-T1/T2).

It should be noted that both environments follow the same steps to summon their services. The first step is to authenticate all active sessions using the JWT token that will be verified by the API gateway (all user interface “UI” use is excluded). The second step is to generate approximately 150,000 initial data points in each database, using as seed the existing medical data (8500 records). In this sense, all the data generated is only intended to generate a workload that will drastically increase (ten of ten users every five minutes) to emulate a specific number of concurrent user sessions (50 virtual users); it will not be used to train, validate or test any expert system. The third step is to randomly execute an HTTP command (e.g., GET, POST, PATCH and DELETE) in the specified service. We have chosen the two most demanding services (approximately 75,000 consultations per session) for both platforms (medical data management (service E) and intervention management (service G)). Services H and I are excluded because of their incompatibility in SPIDEP-SOA; they are in the experimental phase of being integrated with SPIDEP-MSA. The fourth step is to monitor and record all the queries made in each test.

5.2. Evaluations and Results

To evaluate these experiments in SPIDEP, a total of 800,000 queries were sent for a period of 80 min (approximately 200,000 queries every 20 min). It should be noted that these values are obtained from the experiments performed between the two variants of SPIDEP, for more details please refer to

Table 3. General results of the simultaneous queries made to the RESTful methods of the SPIDEP application, under the SOA and MSA architectural styles, invoking single and dual services (i.e., medical data management (service E) and intervention management (service G).

Labels	HTTP Methods		Samples	Avg. Response Time *	Avg. Hits/s	90% Line *	95% Line *	99% Line *	Error Count and Percentage	Avg. LATENCY *	Avg. Bytes (Kbytes/s)
SPIDEP-SOA-K8s-T1	GET		25,245	395.2	21.04	607	631	711	0 (0%)	395.19	12.25
	POST		25,237	401.26	21.03	615	639	719	0 (0%)	401.25	4.87
	PATCH		25,226	388.84	21.02	603	627	707	0 (0%)	388.83	4.87
	DELETE		25,217	390.3	21.01	603	627	723	0 (0%)	390.29	4.86
SPIDEP-MSA-K8s-T1	GET		27,838	344.38	23.2	543	579	663	0 (0%)	344.34	22.99
	POST		27,830	363.9	23.21	567	599	691	0 (0%)	363.87	9.74
	PATCH		27,813	362.23	23.20	571	603	683	0 (0%)	362.19	9.98
	DELETE		27,805	358.68	23.19	563	595	683	0 (0%)	358.65	9.98
SPIDEP-SOA-K8s-T2	Intervention Management	GET	50,511	390.89	42.09	603	631	715	0 (0%)	390.88	16.2
		PATCH	50,346	387.13	41.95	599	627	711	0 (0%)	387.12	9.65
	Medical Data Management	POST	50,487	390.39	42.01	615	639	719	0 (0%)	396.39	9.74
		DELETE	50,947	390.12	42.45	603	627	695	0 (0%)	390.11	9.79
SPIDEP-MSA-K8s-T2	Intervention Management	GET	102,009	389.72	85.01	599	639	715	0 (0%)	335.65	57.68
		PATCH	108,978	364.84	90.82	579	623	699	0 (0%)	364.84	36.35
	Medical Data Management	POST	118,534	335.37	98.78	535	571	639	0 (0%)	384.02	42.51
		DELETE	112,221	354.22	93.52	555	595	683	0 (0%)	354.21	36.63

* Time measurements are averages in ms.

. Another factor to consider is that 50 users are simulated requesting a set of random data simultaneously. Now, the response times of the instances are acceptable and are sufficient for this number of users; however, it must be kept in mind that this quality degrades as the number of users increases, if not foreseen with an adequate scalability of the infrastructure vs the demand [21].

The results were collected through a tabular output report generated after each load test, corresponding to its environment, as shown in Table 3. For the tables, the following labels are used: SPIDEP-SOA-K8s-T1 is a K8 environment that hosts all the services of the SPIDEP-SOA platform, this test will run multiple HTTP queries to a single service (service E); SPIDEP-MSA-K8s-T1 is a K8s environment that hosts all the services of the SPIDEP-MSA platform, this test will run multiple HTTP queries to a single service (service E); SPIDEP-SOA-K8s-T2 is a K8 environment that hosts all the services of the SPIDEP-SOA platform, this test will run multiple HTTP queries to two services simultaneously (services E and G); and SPIDEP-MSA-K8s-T2 is a K8 environment that hosts all the services of the SPIDEP-MSA platform, this test will run multiple HTTP queries to two services simultaneously (services E and G).

The report contains several important values divided into four labels reflecting the type of environment executed, including the type of HTTP method executed, the number of samples, average response time, number of requests that are processed (i.e., hits per seconds), 90th percentile, 95th percentile, 99th percentile, number and percentage of failed requests, the average latency time and the data consumption transferred between the user and the service.

Additionally, several stress simulation tests in the infrastructure that host both variants of SPIDEP were performed, whose functions are to detect any problems that may arise in the platform. Reviewing CPU performance, memory, network I/O and connections (e.g., engine health to BlazeMeter) indicates whether the SPIDEP infrastructure itself is capable of supporting the demand-related bottlenecks or errors that appear [21,53], as shown in Figure 4, Figure 5, Figure 6 and Figure 7, with one figure for each environment.

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 90th 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 90th 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). These additional mechanisms are intended to establish a secure communication channel between the different microservices (internal and external) of computer attacks (e.g., man-in-the-middle, DoS or other) [104]. Consequently, it brings with it an increase in the general network traffic between the microservices and their infrastructure, demonstrating a significant increase in the average transfer of data to the users; therefore, the SOA variant is approximately 73.80% more efficient than the MSA variant in terms of network consumption.

The SPIDEP-SOA-K8s-T1 and SPIDEP-MSA-K8s-T1 environments do not have a noticeable difference in the results compared to the K8s-T2 environments, but their trend is similar to the previous environment (approximately 9.31% and approximately 49.05% for each case) because this T1 environment executes multiple HTTP queries to a single service (service E), while the T2 environments execute multiple HTTP queries to two services simultaneously (services E and G).

Regarding the second finding, the four engine health reports of the K8s-T1/T2 environments meet the infrastructure performance (CPU and RAM) under a demand of 50 concurrent users (connections), since the CPU values are lower than 80% (8% to approximately 30%) and the memory levels are lower than 70% (10% to approximately 15%) [113,114]; however, the network I/O value of the SPIDEP-MSA-K8s-T1/T2 environments shows a significant consumption in the bandwidth traffic between the services and the Dockers instances in comparison with the SPIDEP-SOA-K8s-T1/T2 environments. This high consumption is because the MSA variant requires managing more specialized coordination to redirect queries from external platforms to internal microservices (or vice versa) within the Cloud environment [115]. In addition, it must actively route and validate user requests through the API gateway to the respective instances of the microservices [74].

In the third finding, to determine if the SPIDEP variants meet the software attribute (i.e., versatile high-performance), we have analyzed and contrasted the results obtained from the various stress tests of each platform. Considering the above, the MSA variant is the most appropriate for our needs, since it optimally meets the following three important aspects: (i) Scalability—MSA can be scaled individually when running a heavy workload by replicating the microservices on several containers and not replicating those that are underutilized (i.e., maximize the performance with minimal cost); therefore, microservices can handle the increase in demand without latency being significantly degraded, but this requires consuming a significant bandwidth to mitigate the latency [110,114,116]; (ii) Versatility—MSA allows adding and integrating new functionalities to the platform without affecting the availability of the other microservices. Therefore, each team has the autonomy to decide which is the best technology for the development of the service, according to the needs identified [7]; and (iii) Performance—a platform geared towards high demand requires that all its computing resources be distributed in the Cloud, which allows a shorter response time for the services; however, the platform becomes more demanding with the computational load of the instances.

7. Conclusions and Future Work

In this article, we have presented all the steps involved in the design, implementation and deployment of the SPIDEP platform and its RC variants based on the SOA and MSA architectural patterns; the platform is focused on remote telemonitoring of the elderly. Therefore, our purpose is to offer a replicable framework to support the early diagnosis of infectious diseases and their derivatives by using recent ICT developments through artificial intelligence algorithms (e.g., deep learning and machine learning-based inference systems), with the added value of reducing logistical costs for medical institutions.

Therefore, it was necessary to evaluate which of the SPIDEP variants are best suited for our versatile high-performance concept, considering the strengths and weaknesses of each architecture and how they behave in a high demand scenario. As a result, we have analyzed and contrasted the performance of each variant vs. the metrics obtained from the various performance tests (i.e., response time, efficient use of infrastructure and network consumption), which found that MSA is a better performer in terms of the performance quality attribute (approximately 54.21%). In the same manner, when processing multiple requests for various services, the response time was lower compared to SOA (approximately 7.34%), but the bandwidth consumption in MSA was more significant than SOA (approximately 73.80%).

Based on the ideas presented, we feel that the implementation of SOA and MSA depends on the capabilities and needs of organizations (e.g., performance, flexibility, availability, interoperability or other characteristics in return for known and unknown consequences) [33,63]. Therefore, within the eHealth context and based on the results obtained, we observe that MSA is capable of meeting the majority of needs in support of medical decision making and is adaptable to different types of clinical systems (e.g., EHR, IoHT or telemonitoring systems) and various infrastructure solutions (e.g., nursing homes, hospitals and public health management) [16,62,117]; however, this brings with it many challenges [51,74,94,99,105].

The SOA and MSA architectural patterns can be considered complementary allies for an interenterprise or interbusiness architecture that confers a suite of different services, rather than being competitors [33,118,119], i.e., combining the SOA and MSA attributes within an environment. Therefore, we plan to work on a proposal for an intergenerational ecosystem for SOA-MSA, with the aim of developing a basis for the integration and interconnection of the different eHealth applications involved in medical organizations in conjunction with microservices adapted to machine learning-based inference systems to perform specialized tasks in decision support in the prevention, monitoring and treatment of various conditions. Additionally, we are exploring the possibility of extending our framework to other eHealth areas (e.g., a patient monitoring system for hemodialysis) [120,121], early prediction of COVID-19 [122,123,124,125] or prediction of heart and kidney risks in diabetic patients [126,127,128]).

Another possible area for future research would be the adaptation of this proposal to other sectors of industry 4.0 (e.g., smart buildings or tourism) [8,129,130,131,132]; however, additional research is needed to obtain sufficient results to demonstrate the robustness of the architecture in terms of the adaptations of the attributes for these sectors. Our findings will be published in the near future.