# Facilitating Heterogeneity Management on the Computing Continuum

Martin Molli, Daniel Balouek, Paul Temple, Thomas Ledoux

► To cite this version:

Martin Molli, Daniel Balouek, Paul Temple, Thomas Ledoux. Facilitating Heterogeneity Management on the Computing Continuum. COMPAS 2025 - Conférence francophone d'informatique en Parallélisme, Architecture et Système, Jun 2025, Bordeaux, France. pp.1-8. hal-05138189

HAL Id: hal-05138189

https://hal.science/hal-05138189v1

Submitted on 1 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Facilitating Heterogeneity Management on the Computing Continuum

Martin Molli<fnref n="1" />, Daniel Balouek<fnref n="1" />, Paul Temple<fnref n="2" />, Thomas Ledoux<fnref n="1" />

Corresponding author : martin.molli@inria.fr

## Résumé

The computing continuum combines edge and cloud computing resources to create a seamless infrastructure. This integration brings about a variety of resources, leading to heterogeneity. Therefore, meeting application requirements such as fast response times, high-quality results, detailed data, low costs, and energy efficiency becomes challenging. We suggest using self-adaptive systems and software variability management methods to manage this complexity. Specifically, we propose modeling software variability and infrastructure heterogeneity to help configure and deploy systems effectively. We illustrate this approach with a video analytics use case.

**Mots-clés** : Computing continuum, Variability, Heterogeneity, Feature model, Computing resources

## 1. Introduction

With the rapid advancement of the Internet of Things (IoT), sensors and connected devices have been deployed in various environments, enabling real-time data collection and processing. There will be an estimated 32.1 billion IoT devices for 2030 [1], in applications ranging from smart cities [2], agriculture [1], forest fire detection [3], or disaster recovery [4].

A typical example is video detection, which uses the following application flow: cameras activate when motion is detected, and objects of interest are extracted from captured footage. Video processing can use multiple variants of the same algorithms, approximation techniques [5], or scaling strategies [6].

Traditionally, these applications transmit captured footage to centralized data centers for analysis using cloud computing. Cloud computing offers significant computational power, scalability, and fault tolerance, making it desirable for tasks requiring high processing power but can suffer from high latencies or network congestion [7].

A new paradigm, the computing continuum, seeks a *fluid ecosystem where distributed resources and services are programmatically aggregated on demand to support emerging data-driven application workflows* [8]. This paradigm enhances flexibility and performance by dynamically distributing computation across an infrastructure and processing data closer to where it is produced. However, the Continuum introduces uncertainty due to the changing availability of resources, network conditions, and application demands [9]. Moreover, the different natures of the aggregated resources create heterogeneity, which must be managed.

<footnote n="1">¹IMT Atlantique, Inria, LS2N, UMR CNRS 6004, F-44307 Nantes, France</footnote>

<footnote n="2">²University of Rennes and IRISA</footnote>
Another concept used in this paper is variability. Software variability is defined as *the ability of a software system or an artefact to be efficiently extended, changed, customized, or configured for use in a particular context* [10]. Techniques for modeling and managing software variability were developed for Software Product Lines [11] [12]. These techniques and tools offer a structured way to represent and reason on variability.

This paper investigates how to leverage variability modeling to run applications on the Computing Continuum. The goal is to support developers of real-time streaming applications in deploying their applications across the Continuum. We aim to instantiate the model on a video detection example and design adaptive and resilient applications to meet performance requirements and handle uncertainty in the Computing Continuum.

## 2. Motivating and research questions

A standard video monitoring application consists of multiple components that perform specific tasks such as video streaming, motion detection, and object detection. For example, let us consider an application using cameras in the woods to track wildlife with the architecture shown in Figure 1. The application architecture consists of three components called one after the other: cameras, motion detectors, and an object detector. Video streaming applications typically have performance requirements, such as a fixed resolution, since object detection may not perform well at low resolution.

The application workload depends on the number of animals detected by the cameras. When no animals are present, system usage remains low. However, the system may become saturated if all cameras detect animals simultaneously. Consequently, the workload directly influences how components are allocated, configured, and scaled at runtime.

### 2.1. Background

In video monitoring applications, two computing paradigms are usually used. The first is cloud computing, which according to ISO [13] is *for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand*. Modern clouds' high elasticity and resource availability make them ideal environments for tasks needing high computing power, such as the Object Detector. However, cloud-based solutions are centralized and highly dependent on the network to move data from the camera to the cloud. Hence, any disruption can lead to performance degradation or application failure. The second option is edge computing, where computation is performed directly on the camera or a nearby computer. This means that the motion detection container can be executed directly on the camera and stream video to the cloud only for object detection. Therefore, frames are only sent when needed, reducing the data sent across the network and improving the application throughput. Edge computing also enables new options to ensure the application robustness, such as storing frames in a temporary buffer to anticipate network failure. One of the key challenges in edge-based deployment is ensuring performance guarantees [14] such as a target FPS. However, edge nodes like cameras have limited processing power, memory, and energy availability. Therefore, software must be tailored to the processing power of edge devices such as cameras. Ensuring reliable FPS and data storage becomes significantly more challenging at the edge compared to the cloud, where resources can be dynamically allocated as needed.

### 2.2. Adapting dynamically video processing applications for the continuum

We plan to use a new paradigm called the **computing continuum** to overcome the limitations of both cloud and edge computing. This paradigm aims to merge devices on the edge, fog,
<figure><img src="image_2.png" /><figcaption>FIGURE 1 – Network Graph representing an example micro-service application using cameras for detecting animals</figcaption></figure>

and cloud, making them appear as one infrastructure [8]. Devices of different nature, such as High-Performance Calculators and smart cameras, can coexist within the same infrastructure [15], making the Continuum a **heterogeneous** environment. Moreover, the Continuum is also a highly **dynamic** environment since devices such as cameras with limited battery or connectivity may leave or join anytime. This introduces uncertainty as the available resources change over time. For example, enforcing the performance level becomes challenging, as the application must adapt to maintain performance when a node leaves the continuum [14].

We can make multiple choices to adapt the application :

- Placement : Components can be migrated between nodes to optimize resource utilization. By assigning tasks to nodes based on their specific characteristics, we ensure that processing occurs in the optimal location and time. Thus improving overall application efficiency.

- Quality of Service vs performance : Trade-offs in application processing can be implemented to maintain performance. For example, reducing resolution can help maintain frame rates under resource constraints at the cost of accuracy.

- Scaling : If the application supports parallel processing, as is often the case with video streaming, horizontal scaling across cloud-based layers can be leveraged. In scenarios where parallelism is limited, vertical scaling remains a viable alternative.
These various possibilities arise from applications intrinsic **variability**.

We aim to develop a decision model to adapt applications to heterogeneous infrastructures
while enforcing metrics such as latency and throughput. To achieve this, we need to address
the following questions : How can the variability of applications be modeled to enable them
to adapt to fluctuations in the computing continuum? What are the essential parameters and
metrics to monitor when deciding how to adapt applications? How can we determine whether
the desired performance level can be met?

3. Using variability for resources management

3.1. Design choices

Multiple design choices are possible when writing a generic application processing data streams from various sources. However, we cannot know the exact resources available for computation in advance, since they might change over time. We need to decouple the application from the hardware. The developer (or the software architect) provides the following :

— Applicative code, through, for instance, application containers.

— Performance metrics requirements through a set of textual rules, e.g., a resolution of at least Full HD and latency below 100ms.

On the other hand, we assume that an infrastructure operator manages the hardware and pro-
vides the following :

— The resources needed to run the application.

— System metrics of each machine in the infrastructure, such as CPU, RAM, bandwidth, and disk usage.

3.2. Modeling application variability with feature models

Feature models allow modeling application variability as they capture how application features
can be combined [11]. In our example application, we can use two algorithms to detect ani-
mals : *Features matching* or *Histogram matching*. We can model these choices as shown in Figure
2, where the two algorithms are defined as mutually exclusive. Feature models originate from
the Software Product Line (SPL) domain, which aims to *exploit and manage a common platform to
develop a family of products* [16]. They are hierarchical models that define features representing
different aspects of a product, ranging from high-level abstract functionalities to possible im-
plementations. We can create a new application by selecting and composing features from the
model. The set of values assigned to each feature, while satisfying all constraints, is referred
to as a *configuration*. Temple et al. [6] proposed explicitly separating the execution context from
the software features in the feature models. We apply the same concept to applications execu-
ting in the continuum. On the one hand, we define the context in the model, which consists of
all the elements that depend on the application execution environment. For instance, we might
have a fixed camera on a foggy night with no vibration. However, we can also mount the ca-
mera on a plane with vibration and observe heat haze during a sunny day. These features fall
under the orange "CTXT" class in Figure 2. On the other hand, we define software features as
the algorithms mentioned earlier that we can use under a separate blue "SOFT" class.

3.3. Matching application features with infrastructure capabilities

Enforcing performance metrics requires selecting an appropriate application configuration and
assigning computational tasks to each node in the system. Decision-making requires understand-
ing various factors, such as the execution environment, the impact of each feature in the
feature model, and the characteristics of available nodes, such as their CPU and RAM capa-
<figure><img src="image_3.png" /><figcaption>FIGURE 2 – Example of a feature on a video processing application using the OpenCV computer vision library representing context and software configuration [6]. The boxes represent the application’s features, while the arcs show the constraints between the features.</figcaption></figure>

cities. Therefore, the resource management must consider the application and the available infrastructure. The proposed decision model must integrate two key inputs : a feature model, which captures the application variability and configurable aspects, and an infrastructure model, which captures the system’s hardware and network layout. The output is a system configuration consisting of features to use and, for each feature, which node to execute it.

## 4. Related work

Programming applications to adapt to the heterogeneity of the Continuum is key to maintaining performance [8]. However, a general methodology capable of programming any Continuum application is still needed [9][14]. Current industrial solutions are not able to leverage the computing continuum effectively. Orchestrators such as KubeEdge<fnref n="1" /> or K3S<fnref n="2" /> offer a rich ecosystem but require significant manual configuration to handle dynamic workloads across heterogeneous environments [15]. They offer some degree of adaptability to heterogeneity through containerization and manual orchestrator tuning. Inspired by the cloud trend toward serverless computing [17], serverless approaches are being attempted on the Continuum. The main advantage of serverless computing is that it shifts the complexity of exploiting the infrastructure and setting up servers to service providers. Several Function as a Service models are being explored on the Continuum, and the key challenge is function placement across devices [18][19]. However, these works consider the application a black-box and cannot act on the application logic. Application-level orchestrators where the User can define custom scaling policies are promising [20]. However, they require the User to know the characteristics of the infrastructure. Our approach takes inspiration from the work of Temple et al. [6], which models the context separately from the application itself.

<footnote n="1">1. https://kubeedge.io/</footnote>

<footnote n="2">2. https://k3s.io/</footnote>
There are several possibilities for representing the computing continuum. One approach views the Continuum as distinct physical compute regions or clusters consisting of the cloud, the fog, and the edge. For instance, edge nodes tend to be near a gateway, such as a 5G antenna, while cloud resources are located in datacenters [19]. Moreover, different providers might operate separate compute regions, limiting resource coordination and creating new regions [21]. Another publication retains the notion of separate regions. However, it emphasizes the heterogeneity as regions might be composed of edge nodes and cloud datacenter [22].

## 5. Conclusion and Future Work

Our approach is focused on modeling application variability to adapt the applications in real time to the computing continuum. By modeling application variability and infrastructure heterogeneity, we aim to continuously infer decisions to alter applications in response to changes in the computing continuum.

Future work will focus on validating this approach. We will define a feature model to capture variability in the video processing use case. Grid'5000 [23] will serve as the computing infrastructure, and EnOSlib [24] will emulate network conditions across the continent. We will use virtual machines with dedicated resources to emulate computing power at each tier. Kubernetes manages the deployment of video processing microservices, and Prometheus, together with OpenTelemetry, will be used to monitor key application metrics.

## Références

[1] A. L. DUGUMA et X. BAI, « How the internet of things technology improves agricultural efficiency, » *Artificial Intelligence Review*, t. 58, n° 2, p. 63, 2024.

[2] J. ROBERT, S. KUBLER, N. KOLBE, A. CERIONI, E. GASTAUD et K. FRÄMLING, « Open IoT ecosystem for enhanced interoperability in smart cities—example of Métropole De Lyon, » *Sensors*, t. 17, n° 12, p. 2849, 2017.

[3] I. ALTINTAS, « Building cyberinfrastructure for translational impact : The WIFIRE example, » *Journal of Computational Science*, t. 52, p. 101 210, 2021.

[4] K. FAUVEL, D. DANIEL BALOUEK-THOMERT, D. MELGAR et al., « A Distributed Multi-Sensor Machine Learning Approach to Earthquake Early Warning, » in *Proceedings of the Thirty-Fourth AAAI Conference on Artificial Intelligence*, 2020.

[5] P. PANDEY et D. POMPILI, « MobiDiC : Exploiting the untapped potential of mobile distributed computing via approximation, » in *2016 IEEE International Conference on Pervasive Computing and Communications (PerCom)*, IEEE, 2016, p. 1-9.

[6] P. TEMPLE, M. ACHER, J.-M. JÉZÉQUEL et O. BARAIS, « Learning Contextual-Variability Models, » *IEEE Software*, t. 34, n° 6, p. 64-70, nov. 2017, Conference Name : IEEE Software.

[7] W. SHI, J. CAO, Q. ZHANG, Y. LI et L. XU, « Edge computing : Vision and challenges, » *IEEE internet of things journal*, t. 3, n° 5, p. 637-646, 2016.

[8] D. BALOUEK-THOMERT, E. G. RENART, A. R. ZAMANI, A. SIMONET et M. PARASHAR, « Towards a computing continuum : Enabling edge-to-cloud integration for data-driven workflows, » en, *The International Journal of High Performance Computing Applications*, t. 33, n° 6, p. 1159-1174, nov. 2019.
[9] S. DUSTDAR, V. C. PUJOL et P. K. DONTA, « On Distributed Computing Continuum Systems, » en, *IEEE Transactions on Knowledge and Data Engineering*, t. 35, n° 4, p. 4092-4105, avr. 2023.

[10] M. SVAHNBERG, J. van GURP et J. BOSCH, « A taxonomy of variability realization techniques, » en, *Software: Practice and Experience*, t. 35, n° 8, p. 705-754, 2005, _eprint_ : https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.652.

[11] T. BERGER, R. RUBLACK, D. NAIR et al., « A survey of variability modeling in industrial practice, » en, in *Proceedings of the Seventh International Workshop on Variability Modelling of Software-intensive Systems*, Pisa Italy : ACM, jan. 2013, p. 1-8.

[12] M. GALSTER, D. WEYNS, D. TOFAN, B. MICHALIK et P. AVGERIOU, « Variability in software systems—a systematic literature review, » *IEEE transactions on software engineering*, t. 40, n° 3, p. 282-306, 2013.

[13] ISO CENTRAL SECRETARY, « ISO/IEC 22123-1:2023(E) - Information technology - Cloud computing - Part 1 : Vocabulary, » International Organization for Standardization, Geneva, CH, Standard, 2023.

[14] D. BALOUEK-THOMERT, E. CARON, L. LEFEVRE et M. PARASHAR, « Towards a Methodology for Building Dynamic Urgent Applications on Continuum Computing Platforms, » in *2022 First Combined International Workshop on Interactive Urgent Supercomputing (CIW-IUS)*, nov. 2022, p. 1-6.

[15] A. ULLAH, T. KISS, J. KOVÁCS et al., « Orchestration in the Cloud-to-Things compute continuum : taxonomy, survey and future directions, » en, *Journal of Cloud Computing*, t. 12, n° 1, p. 135, sept. 2023.

[16] ISO CENTRAL SECRETARY, « ISO/IEC 26550:2015 - Software and systems engineering - Reference model for product line engineering and management - Introduction, » International Organization for Standardization, Geneva, CH, Standard, 2015.

[17] J. SCHLEIER-SMITH, V. SREEKANTI, A. KHANDELWAL et al., « What serverless computing is and should become : The next phase of cloud computing, » *Communications of the ACM*, t. 64, n° 5, p. 76-84, 2021.

[18] G. YU, P. CHEN, Z. ZHENG, J. ZHANG, X. LI et Z. HE, « Faasdeliver : Cost-efficient and qos-aware function delivery in computing continuum, » *IEEE Transactions on Services Computing*, t. 16, n° 5, p. 3332-3347, 2023.

[19] G. R. RUSSO, T. MANNUCCI, V. CARDELLINI et F. L. PRESTI, « Serverledge : Decentralized Function-as-a-Service for the Edge-Cloud Continuum, » in *2023 IEEE International Conference on Pervasive Computing and Communications (PerCom)*, ISSN : 2474-249X, mars 2023, p. 131-140.

[20] A. ULLAH, H. DAGDEVIREN, R. C. ARIYATTU, J. DESLAURIERS, T. KISS et J. BOWDEN, « Micado-edge : Towards an application-level orchestrator for the cloud-to-edge computing continuum, » *Journal of Grid Computing*, t. 19, n° 4, p. 47, 2021.

[21] L. BARESI, D. F. MENDONÇA, M. GARRIGA, S. GUINEA et G. QUATTROCCHI, « A Unified Model for the Mobile-Edge-Cloud Continuum, » en, *ACM Transactions on Internet Technology*, t. 19, n° 2, p. 1-21, mai 2019, Number : 2.

[22] Y. S. PATEL, P. TOWNEND, A. SINGH et P.-O. ÖSTBERG, « Modeling the Green Cloud Continuum : integrating energy considerations into Cloud-Edge models, » *Cluster Computing*, t. 27, n° 4, p. 4095-4125, 2024.
[23] D. BALOUEK, A. CARPEN AMARIE, G. CHARRIER et al., « Adding Virtualization Capabilities to the Grid'5000 Testbed, » in *Cloud Computing and Services Science*, sér. Communications in Computer and Information Science, I. I. IVANOV, M. van SINDEREN, F. LEYMANN et T. SHAN, éd., t. 367, Springer International Publishing, 2013, p. 3-20.

[24] R.-A. CHERRUEAU, M. DELAVERGNE, A. van KEMPEN et al., « EnosLib : A Library for Experiment-Driven Research in Distributed Computing, » *IEEE Transactions on Parallel and Distributed Systems*, t. 33, n° 6, p. 1464-1477, juin 2022.