## 4. Scope and Applicability
### Business Critical Applications: Initial Results  
The proposed CloudOps workflow and framework have been partially validated through an implementation of an MVP (Minimum Viable Product) in an e-health scenario. In this case, an initial version of the proposed CloudOps framework was used to deploy and operate a multi-cloud e-health.NET application. The solution implemented included all the described functional components from Figure 3, with limited features (i.e., only cloud infrastructural elements were considered, a limited set of NFRs were monitored and stateless components were not supported). The different components from Figure 3 have been inserted into the actual framework and the main sub-components for each of the functional blocks are represented in Figure 7. Figure 7 depicts the architecture of the initial MVP of the proposed CloudOps framework validated in the e-health scenario. It also shows how the additional activities proposed in the CloudOps concept in Figure 2 (i.e., pre-deployment and self-healing) are supported by specific tools in this test case. To this end, the **pre-deployment phase** is materialized in two new tool supported activities:  
1. Available cloud resources discovery through the \"Infrastructural elements catalogue\" (Resource discovery functional block in Figure 3): This catalogue provides a unique registry for all the infrastructural elements available along with their relevant characteristics. In this concrete test case, cloud services from Amazon, Azure and Arsys were included. The operators of the tested e-health application were able to discover and filter the different resources to their own convenience. As reported by the operators, this supposed a great advantage and relevant time savings as they did not need to dig into the web pages of each of the cloud providers looking for the best combination of cloud resources. The catalogue has been developed with the JHipster [77] frontend and backend generator;
2. \"Optimized deployment configuration\" provisioning (the Optimized Deployment Configuration building block in Figure 3): This component gathers the information from the application (available in the application description file shown in Figures 8 and 9) and collects the required information from the Infrastructural elements' catalogue (through a REST API). From this, it creates the best combination of  
Figure 7: Architecture of the MVP of the proposed CloudOps framework validated in an e-health scenario. available infrastructural elements fulfilling the application components types' needs (i.e., computing capabilities, storage capabilities, etc.) and the SLOs (i.e., location, performance and availability). It uses the NSGA-II Genetic Algorithm [78] implemented in MOEA Framework [79], an open source Java library. These components provide the application operator team with a tool to perform several tests before the application is deployed. Furthermore, it eases the selection of the services against the selected NFRs, in a multi-objective optimization problem. 765 ~schema\" [ {
757 ~microservices\" : [ ~773 ee044-3 ebb-4864-8 ad0-6c8e89979 fd6\" ],
758 ~csId\" ~22\",
759 ~umId\" : 3
760 ~}, {
761 ~microservices\" : [ ~99 dc9455-bc06-4e97-b87e-dfc29237b3b7c\" ],
762 ~csId\" : \"16\",
763 ~umId\" : 4
764 ~}, {
765 ~microservices\" : [ ~ed702180-bbf6-4 fa6-edc2-bce24 ecafe7e\" ],
766 ~csf\" ~23\",
767 ~umId\" : 5
768 ~}, {  
Figure 8: Snippet of the application description JSON file, where the application’s NFRs are described. Figure 9: Snippet of the application description JSON file, where the best combination of infrastructural elements are suggested in through the “schema” element. As explained, the microservices-based e-health application's main characteristics were maintained in the \"Application Description\" JSON file which was used by the different components to gather and exchange relevant information.