## 4 Model and Design of SPIDEP Platforms
### Variants of Software Architectures
#### 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.