## 2 Requirements and Challenges in the Operationalization of the Cloud Continuum
### Benchmark of Resources and Application Classification
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Topic** & & **Current Challenges** \\ \hline \multirow{4}{*}{(Dev)Ops} & \(\bullet\) & Partial automation of the DevOps cycle especially in heterogenous environments \\  & \(\bullet\) & Context (cloud, edge, network) specific tools \\  & \(\bullet\) & Specific skills needed, especially for “combined” environments, with cloud services, edge nodes and network elements \\ \hline \multirow{4}{*}{Monitoring} & \(\bullet\) & Inefficiencies mainly due to lack of dynamicity of the distributed proposed models \\  & \(\bullet\) & Lack of holistic approaches covering not only the monitoring of traditional cloud resources but also the integrated monitoring of edge nodes and network communications \\  & \(\bullet\) & Communication channels between application elements (e.g., microservices) are usually considered at device level but not at software components level (even inside the same device) \\  & \(\bullet\) & Lacks the precision or speed needed for high performance architectures as existing solutions for forecasting methods are based on basic offline algorithms such as linear regression or nearest neighbors adapted to online environments \\ \hline \multirow{4}{*}{Benchmarking} & \(\bullet\) & Benchmarking of edge resources is incipient and existing solutions are platform or scenario specific \\  & \(\bullet\) & Existing tools usually involve inefficient or ineffective tests as the complete benchmarking process is not automated \\  & \(\bullet\) & Current approaches for application classification are usually focused on specific applications types (e.g., data streaming applications) and not suitable for other types \\  & \(\bullet\) & The characterization and benchmarking of networking and communication have been barely addressed \\ \hline \multirow{4}{*}{Self-learning, self-healing} & \(\bullet\) & Few available solutions tackle the automatic self-healing of applications based on failure prediction \\  & \(\bullet\) & Existing self-healing works do not consider stateful components’ needs (e.g., data portability issues) \\ \cline{1-1}  & \(\bullet\) & Current approaches focus on certain aspects of the self-healing process, usually the re-deployment of the application, but do not offer integrated frameworks covering previous or subsequent tasks such as failure prediction, new resources contracting or “old” devices and services shut down \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Current unsolved challenges in the Operationalization of applications in the Cloud Continuum. Besides, application and application components need to be classified (e.g., stateful, stateless) and profiled (e.g., computation, data, serverless) in an agnostic manner, without requiring a priori knowledge about the application internals so that the deployment needs can be inferred and deduced. However, most of the available applications profiles are platform- and scenario-dependent and hardly reusable in other contexts. The NAMB project has started to work in the direction of a generic approach that is context and platform agnostic [25; 26]. Moreover, benchmarking of the whole stack, including the network resources, in particular the paths that interconnect the physical or virtual machines hosting application components, has not yet been deeply addressed. In that respect, the profiling of the paths within the cloud and the edge will provide relevant information which can impact on the decision on the selection of the best combination of resources for the deployment. The understanding of these paths is not trivial because public cloud service providers such as Amazon Web Services and Microsoft Azure provide links that interconnect data centers with high performance [27] opposite to typical best-effort Internet links [28]. However, those links present complex traffic engineering techniques, which require careful design and tuning of monitoring tools in order to avoid biased measurements.