## 4. Scope and Applicability
### Business Critical Applications: Initial Results
Consequently, the infrastructural requirements and application components' description (Figure 3) are collected in the application description file as presented in Figure 7. The **operation phase** is also enriched with a set of new tool-supported activities specially for **the self-healing**;
3. Automatic deployment of the application occurs through the \"Infrastructure generation\" and the \"Application Deployment\" sub-modules (Deployment and Self-Healing in Figure 3). They create the needed infrastructural resources and deploy the application through Terraform and Ansible templates. Besides the deployment of the application, they also deploy a set of monitoring agents (Telegraf-based [80]) in the infrastructure to gather the corresponding runtime metrics aligned with the selected NFRs;
4. \"Automatic run-time monitoring\" of all the infrastructural elements (Figure 3): It gathers in a single place all the monitored metrics from the different providers' resources. It comprises a full monitoring stack, based on Telegraf agents, the InfluxDB [81] time-series database as the persistence layer and Grafana dashboards [82] for the graphical interface. In this component, the \"Monitoring controller\" is also in charge of detecting SLO violations in the infrastructural elements and informing both the Operator of the application (through an email) and the \"Deployment and Self-Healing\" module (through a REST API) about these violations;
5. Finally, the \"Porting strategies selector\" sub-module (as part of the Self-learning building block in Figure 3) receives the requests from the \"Monitoring controller\" once a violation occurs and re-deploys the application, if needed. If this is the case, the \"Optimized deployment configuration\" is called and the cycle starts again with the optimization of the deployment configuration. It is to be noted that the \"Infrastructural Elements catalogue\" is also updated with the information of the violations that have occurred on the used infrastructural elements. As a result, when the next set of available resources are requested the information of the violations is also considered so that the opinionated selection of infrastructural elements can be provided by the \"Optimized deployment configuration\". As anticipated, the test case only covered some of the main functionalities for the CloudOps framework. Nevertheless, it showed positive impacts and improvements of the Operationalization of the referenced application both qualitative, presented in the description of the Figure 7 components, and quantitative, presented in Table 3. Table 3 shows the quantitative improvements in the form of comparative costs (measured in effort, PM-Person Month and PH-Person Hour) between using the CloudOps framework and not using it. These figures have been reported by the operators of the e-health application. The different phases of the CloudOps workflow were implemented by the operators manually when using the CloudOps framework. Assuming a cost of 40 euros/h (calculated by the e-health application operators, based on the costs of a typical project in their company) a total of 72800 euros was saved. If we assume four health projects of a similar scale per year, then we anticipate a saving of approximately 29,000 Euros, or around 2400 Euros per month (approx. \(\frac{1}{2}\) a Person Month.) The operators of the e-health application also reported qualitative improvements. The most relevant ones were as follows:  
1. The **pre-deployment phase** and the related tools (\"Infrastructural elements catalogue\", \"Optimized deployment configuration\") provide efficiency for evaluating a user's potential NFR options for each of the service classifications and provide an instant response to illustrate matching based on the user's specified values of each of their NFRs to help evaluate the most effective options when selecting a service solution.