## 2 Requirements and Challenges in the Operationalization of the Cloud Continuum
### Self-Healing and Data Portability  
The application of self-healing, refers to the autonomous and responsible behavior of the applications to changes in the execution environment, and has been a challenge since the cloud and distributed computing paradigms appeared on the software operation gameboard. Several solutions have been proposed for specific scenarios such as IoT [64; 65] or traditional cloud environments [66]. Other solutions are focused on specific steps in the self-healing, self-configuration process [67], or in the resolution of specific problems such as scalability [68] or trust enforcement [69]. The cross/multi-layer and the networking aspects are challenges that have not yet been addressed, nor has the face of the problem in a generic way, covering the whole self-healing process from the discovery and configuration of the resources to the network preparation and deployment of all software layers.  
Self-healing mechanisms can include several actions, going from the starting up of the failing resource with a new one, to the re-configuration of the network or the orchestration of portability workflows so that business continuity is ensured. Several approaches have been applied to automatically create computational resources (usually virtual machines) but few initiatives can be found when addressing heterogeneous environments of different natures (edge and cloud) and networking set ups. In such a complex environment, self-healing actions may need dynamic orchestration of the services used for re-deployment following the proper workflow, as well as network resources' re-allocation and setting up.  
This process becomes even more complex when addressing not only the portability of the computational components (stateless components) but also the portability of data, or stateful components. One of the enablers for such portability can be adopted from the application point of view, through the adoption of containers-based technologies, such as Docker. However, containerization per se does not solve the portability problem. When porting components between two cloud providers, data need to be moved and kept synchronized (at three different levels--blocks, files or transactions) and most container-based platformsdon't handle this. Some containers' orchestration systems, such as Kubernetes, provide convenient abstractions for application resource requirements and endpoints, namely persistent volumes, ingress rules and ingress controllers [70]. However, manual configuration is still needed, and stateless components are decoupled from the data that have to be stored in a database or other type of storage. Another important concept to be considered when porting data components from one resource to another is the \"data gravity\", a term coined by [PERSON] [71], who explained that, because of network bandwidth limits, latency, costs and other considerations, data \"want\" to be near the applications analyzing, transforming or otherwise working on it. Consequently, data portability introduces new requirements added to the already time consuming, error prone and mainly manual activity of porting application components over different infrastructural elements [72], such as: (1) Establishing the right networking conditions, so that data can be accessed from the required microservice with the required (network) conditions; (2) Handling persistent data storage, during a redeployment; (3) Data Base automatic configuration so that it can be re-deployed without manual intervention. Security is also to be addressed when selecting a porting strategy. Mechanisms for automatic execution of secure data portability in the Cloud Continuum, preserving data integrity and assuring that the data are not being corrupted need to be considered.