Computing Continuum Simulator: A comprehensive framework for continuum architecture evaluation

Contents lists available at ScienceDirect SoftwareX journal homepage: www.elsevier.com/locate/softx Original software publication Computing Continuum Simulator: A comprehensive framework for continuum architecture evaluation Pablo Rodrígueza, Sergio Lasob,∗ , Javier Berrocala, Pablo Fernándezc, Antonio Ruiz-Cortésc, Juan Manuel Murilloa aUniversidad de Extremadura, Badajoz, Spain bGlobal Process and Product Improvement S.L., Cáceres, Spain cUniversidad de Sevilla, Sevilla, Spain A R T I C L E I N F O Keywords: Computing Continuum Simulator Framework Software as a service A B S T R A C T The Computing Continuum paradigm is essential for meeting the needs of IoT applications that demand realtime processing, reliable connectivity, and low-latency response. Unlike traditional cloud models, Computing Continuum integrates resources across edge, fog, and cloud layers, bringing data processing closer to its source. It is crucial in fields like healthcare, industry, and agriculture, where strict quality requirements have significant economic and social impacts. However, evaluating the performance and reliability of continuum architectures is challenging due to the complexity and high costs of setting up customizable and scalable near-realistic multi-layered environments. To address these challenges, we introduce the Computing Continuum Simulator framework, specifically designed to evaluate the deployment architecture – both physical and logical – of continuum environments. It enables the deployment of large Computing Continuum scenarios, customizing device types, network infrastructure, and custom application setups to accurately simulate and evaluate near real-world conditions. Implemented as a Software as a Service, it minimizes required computational demands on the user-side and integrates seamlessly into DevOps workflows, simplifying deployment, testing, and adoption by software companies, offering a pricing plan to ensure accessibility for various needs. Scalability tests showed the framework maintains stable run times, with different simulation sizes depending on the pricing plan. This consistency underscores the robustness and its suitability for customizable and scalable continuum architecture evaluations. Code metadata Current code version 1.0.0 Permanent link to code/repository used for this code version https://github.com/ElsevierSoftwareX/SOFTX-D-24-00632 Permanent link to Reproducible Capsule N/A Legal Code License CC BY-NC 4.0 Code versioning system used git Software code languages, tools, and services used Javascript, Python, Shell, Mustache, Docker, ADB, and Visual Studio Code. Compilation requirements, operating environments & dependencies Docker, Node 16, Ubuntu 22.04 If available Link to developer documentation/manual Documentation Support email for questions [email protected] Software metadata Current software version 1.0 Permanent link to executables of this version http://ccsim.spilab.es/ Permanent link to Reproducible Capsule N/A Legal Software License CC BY-NC 4.0 Computing platforms/Operating Systems Ubuntu (Linux distribution) Installation requirements & dependencies AWS account, Python 3.10, MySQL 8.0 and NodeJS 22 If available, link to user manual — if formally published include a reference to the publication in the reference list Documentation Support email for questions [email protected] ∗Corresponding author. E-mail addresses: [email protected] (P. Rodríguez), [email protected] (S. Laso), [email protected] (J. Berrocal), [email protected] (P. Fernández), [email protected] (A. Ruiz-Cortés), [email protected] (J.M. Murillo). https://doi.org/10.1016/j.softx.2025.102156 Received 26 November 2024; Received in revised form 18 March 2025; Accepted 31 March 2025 SoftwareX 30 (2025) 102156 Available online 14 April 2025 2352-7110/© 2025 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC license ( http://creativecommons.org/licenses/bync/4.0/ ). P. Rodríguez et al. 1. Motivation and significance The Computing Continuum (CC) paradigm has emerged as a promising solution to the challenges posed by the Internet of Things (IoT) revolution. It has driven the deployment of diverse smart devices designed for efficient interactions to enhance quality of life [1,2]. As IoT systems expand into critical sectors like healthcare, industry, or smart cities, the demand for reliable Quality of Service (QoS) has grown, as failures can lead to serious economic, social, and environmental impacts [3,4]. Traditional cloud solutions can be inadequate to meet such critical IoT services’ stringent low-latency and highavailability requirements, which require real-time processing and rapid response [5]. The CC paradigm extends the traditional cloud model by integrating resources across edge, fog, and cloud layers [6,7], bringing data processing closer to the source, reducing dependence on distant servers and enhancing responsiveness in time-sensitive applications such as smart cities, healthcare, and industry systems that require rapid feedback and reliability [8]. However evaluating CC architectures is complex and costly, as deploying a realistic setup with diverse devices and network conditions requires significant investment. While large organizations may amortize these costs, small and medium-sized enterprises often lack the resources for extensive iterative testing before deployment. To try to overcome these challenges, research simulation tools [9– 11] allow testing in virtual edge-fog environments. Nevertheless, these tools lack the flexibility, scalability, and realism needed to simulate diverse testing scenarios, handle large-scale IoT deployments, or support the deployment of custom applications, limiting their effectiveness for comprehensively evaluating CC architectures. Furthermore, they lack integration with development processes, making them unsuitable for companies relying on continuous development and testing. These limitations highlight the need for approaches that enable the evaluation of highly customizable, scalable CC architectures and that are easy to integrate into professional environments where adaptability and integration are essential. Therefore, this paper presents the Computing Continuum Simulator (CCSIM).1 CCSIM allows the deployment of a large-simulated CC architecture, customizing the number, type, and capabilities of IoT devices, services, and network infrastructure for testing custom applications. This allows the simulation of near real-world environments to evaluate their QoS before being released to production. Implemented as a software-as-a-service (SaaS) solution, it overcomes the limitations of developers’ IT resources, offering accessibility and ease of use without requiring advanced technical expertise. Furthermore, CCSIM supports integration into software development processes like DevOps [12], facilitating its adoption in professional environments. In addition, different pricing plans are offered, allowing different companies to use them. This tool evolves from the integration of two previous frameworks, Perses [13] and EFCC [14]. The main technologies and software used in our proposal are Terraform [15] to create the simulation environment to deploy the simulated architecture in AWS [16], Docker [17] for device management and virtualization, Kathará [18] for network management, and APIPecker [19] and Espresso [20] for evaluation. 2. Software description CCSIM provides a comprehensive platform for simulating and evaluating Computing Continuum (CC) architectures, offering high customization with a wide range of IoT, edge, fog, and cloud devices to enable QoS evaluation in complex and realistic scenarios. CCSIM 1http://ccsim.spilab.es provides a pricing model based on established practices [21] to accommodate different user profiles. Through its project design tool, developers can define a configuration file specifying the architecture’s structure, components, tests, and applications for evaluation. The CCSIM API enables the creation and execution of simulations, progress monitoring, and log retrieval for result validation. Additionally, its automated workflow supports integration with CI/CD pipelines, allowing application evaluation within continuous development environments. The following sections present a detailed architecture of CCSIM, the CCSIM project configuration to define a CC architecture and evaluation, and the CCSIM workflow to automate the execution. 2.1. Software architecture Fig. 1 depicts the principle architecture of CCSIM showing how the components interact to enable deployment projects simulation and testing. This design, composed of multiple interconnected components, ensures a modular and scalable structure that promotes efficient management and maintenance. Key components and main actors (User and CI) are defined below. •User: Users interact with CCSIM primarily through the API, submitting project information, obtaining project status, and downloading results. They can request project details, initiate new projects, and retrieve simulation outcomes. Users provide the data information that defines the project: the CCSIM project configuration, including all architecture elements devices, network configurations, tests, and the application; microservices or the APK and APK-test files for mobile devices if needed. •CI: A continuous integration (CI) provider connects to the CCSIM API to automate and integrate simulation tasks within the development workflow via CCSIM workflow (detailed in Section 2.3). CI can create and launch projects automatically, enabling continuous testing without manual input, saving time, and ensuring simulations run consistently with any updates in code or configurations. •API: The CCSIM API2 serves as the communication bridge, enabling both Users and CI systems to interact seamlessly with CCSIM. Its primary purpose is to allow efficient creation, management, and evaluation of simulation projects without requiring extensive technical expertise or manual configurations. Key features of the CCSIM API include project management, execution and testing of simulated architectures, data retrieval from simulations, continuous integration support, as well as security and authorization controls. •Project Manager: The Project Manager oversees all CRUD (Create, Read, Update, Delete) operations related to project management. It manages the creation and configuration of projects, checks their status, and retrieves log results for download. The Project Manager relies on data stored in the Projects Database and verifies user access with the Users Database to ensure secure project handling. •Core: The core is the heart of CCSIM, managing all stages of the workflow for the deployment of the simulated architecture and evaluation. It consists of several modules: – Initialization: Obtains the data from the projects and provides the necessary information to the other submodules, setting up the project details for subsequent stages. The log results are provided by the Log collector to be saved in the database. 2http://ccsim.spilab.es/documentation SoftwareX 30 (2025) 102156 2 P. Rodríguez et al. Fig. 1. CCSIM’s Architecture. – Deployment: Creates and configures simulation environments on AWS EC2 instances using Terraform. Firstly, it sets up the devices as Docker containers and establishes the network infrastructure through Kathará, based on the specifications in the project configuration. Additionally, a set of custom scripts, developed for the automated creation and deployment of these components, is launched through Terraform, enabling automated deployment. Additionally, the module deploys another set of scripts to install and initiate the execution of the application within the simulated architecture (Listing 1). – Execution: Runs the defined tests, including QoS and User Interface (UI) tests, using different scripts that automate this process (Listing 2). QoS tests evaluate metrics like response times and latency using APIPecker, while UI tests validate mobile interfaces using Espresso. – Log collector: Retrieves and filters logs and metrics generated during testing, storing them in the database for later analysis and download. •Simulation environment: AWS EC2 instances are the virtual domain where the architectures defined in the projects are created, deployed, tested and the results are collected. Each project is deployed in independent instances and can, for example, run several projects in parallel. These instances are automatically managed by CCSIM by the Core component. 2.2. CCSIM project configuration To define and evaluate a continuum deployment architecture within CCSIM, a project configuration file is required. This file specifies the architecture’s devices, network, tests, and application, offering extensive options for simulating diverse scenarios. To facilitate the creation and validation of this configuration, CCSIM Project Designer3 has been developed that enables users to design the architecture, ensuring that all components are correctly defined and structured before deployment. The project configuration file structure is as follows: •architecture: This field defines the entities of the intended continuum architecture, which includes: 3http://ccsim.spilab.es/designer – microservices: Includes the microservices, indicating their Docker image corresponding to the application to be evaluated. For example, if the application is composed of different services and a mobile application, in this section the different services to be deployed are specified. Subsequently, it is specified on which hosts they will be deployed with the established hardware capabilities. – hosts: Describes the computational attributes of hosts, which are virtualized devices like mobile devices, IoT devices, and microservices. It includes information on computational power and memory capacity. Users can define any number of hosts, as long as the pricing plan resources support them. Each host operates as a Docker container running an image and can be assigned one, or multiple microservices. – switches: Includes information on network switches, including their routing configurations. Switches allow communication within the deployed architecture devices, microservices, etc.. Similar to the hosts, each switch is a Docker container running a router image which is preconfigured using the Kathará framework to simulate realistic, communicating network devices. CCSIM also supports external connections for applications requiring external services. However, external network conditions like latency are not simulated, so developers can add logging points to measure their impact. – links: Outlines the network connections between devices, including hosts and switches, with details on latency to shape the network architecture effectively. •mobile_app_installation: Provides specific details of the mobile apps to be installed on hosts defined to be mobile devices, including the app name, application ID, and installation targets. It is optional and used when mobile apps are to be installed and tested. •idle_time: Determines the delay in seconds before running predefined tests after deployment, allowing for any necessary initialization or setup over hosts. The delay should be estimated based on the application’s needs. If no waiting period is required, set the value to 0. •tests: It is an array detailing the tests to be carried out. The tests may include both QoS tests and UI tests (if there is any mobile app), depending on the specific requirements of the user. Tests defined are automatically launched during the Execution stage over architecture to obtain empirical results that closely approximate real-world behavior. SoftwareX 30 (2025) 102156 3 P. Rodríguez et al. [...] echo "$installation_instructions" | while read −r instruction; do app_name=$(echo " $instruction " | jq −r ’ . app_name ’ ) app lication _ id=$(echo " $instruction " | jq −r ’ . a pplicat i on_id ’ ) installation_destination=$(echo " $instruction " | jq −r ’.installation_destination␣|␣j oin ( " , " ) ’ ) for apk_path in " ${ array_apks [@]} " ; do echo "APK␣PATH: ␣$apk_path" echo "APP␣NAME: ␣$app_name" i f [[ " ${apk_path##∗/}" == " $app_name . apk " ] ] ; then i f [ " $ins t al l a ti o n_ d e st i na t ion " == " a l l " ]; then d e v i c e _ l i s t=" $2 " else d e v i c e _ l i s t=" $ i n st a l l at i o n_ d e st i n a ti o n " f i c a l l _ i n s t a l l _ s c r i p t " $apk_path " " $ devi ce _l ist " f i done done [...] Listing 1. Bash script to install the applications on the devices [...] for device in " ${ device_array [@]} " ; do echo "Starting␣UI␣t est ␣on␣$device " kathara exec −d ./ lab " $device " −− adb connect localhost OUTPUT=$( kathara exec −d ./ lab " $device " −− adb −s loca lhost sh e l l pm l i s t instrumentation 2>&1) i f [[ $OUTPUT == ∗" androidx "∗] ] ; then nohup kathara exec −d ./ lab " $device " −− adb −s loca lhost sh e l l am instrument −w−r−e debug false "$2" . test/androidx . test. runner . AndroidJUnitRunner > " ./ devices−logs / espresso / $device−UI−t e s t s _ r e s u l t . txt " & else nohup kathara exec −d ./ lab " $device " −− adb −s loca lhost sh e l l am instrument −w−r−e debug false "$2" . test/android . support . test . AndroidJUnitRunner > " ./ devices−logs / espresso /$device−UI−t e s t s _ r e s u l t . tx t " & f i done [...] Listing 2. Bash script to launch UI tests with Espresso 2.3. CCSIM workflow The CCSIM workflow file4 has been conceived to automate all the processes required to execute a project, seamlessly integrating into the DevOps environment and the typical ecosystem of development companies. This integration streamlines tasks and saves time, eliminating users’ need for multiple manual interventions. Fig. 2 shows an overview of the workflow, which starts with a registered user and a continuous integration provider, such as GitHub Actions (GHA),5 to create and launch a project. When a push in the repository branch triggers the workflow, it automatically executes the various requests to the CCSIM API in an orderly manner to launch the project through the Core modules. 3. Illustrative examples To illustrate the capabilities of CCSIM, we deployed an application in a controlled test environment. 3.1. Example scenario A city council intends to deploy an application, called Air-QualityApp,6 to monitor and analyze air quality across the entire urban area. 4https://github.com/slasom/ComputingContinuumSimulator-SoftwareX/ blob/master/case_study/ccsim-workflow.yml 5https://github.com/features/actions 6https://github.com/slasom/ComputingContinuumSimulator-SoftwareX/ tree/master/case_study Fig. 2. CCSIM workflow. By deploying different IoT sensors, edge, and fog processing nodes distributed in different areas of the city and cloud node following a CC architecture. The system must maintain a high level of QoS (e.g. low average response time for services) to ensure data is accessible, reliable, and usable in real-time. By detecting air quality changes promptly, the system can send timely notifications, allowing residents to take preventive actions against potential health hazards. Additionally, the application SoftwareX 30 (2025) 102156 4 P. Rodríguez et al. Fig. 3. Air quality measurement case study. enables users to contribute localized air quality data, enriching the dataset and enhancing environmental insights through a mobile application. To achieve this, CCSIM deploys a simulated near-real scenario using various devices, including edge (IoT and mobile devices), fog nodes, and cloud, each playing a role in data collection, processing, and dissemination. The following list details these devices and components, as shown in Fig. 3: •IoT devices: Sensors capable of measuring and processing air quality. •Mobile devices: Represents Android smartphones that can obtain air quality data and alerts from a specified location and send additional contextual data to the user. For example, reporting specific pollution incidents (pollen accumulation). •Switches: Common network instruments that connect the various devices in the system, collecting and processing information from IoT sensors and mobile devices. •Cloud: The Cloud obtains data from the switches and aggregates it to obtain air quality information with an overall vision. The proposed tests for this case study aim to evaluate both the application’s functionality and the QoS it delivers. Two primary tests are defined: QoS tests, which assess the response time required for information transmission and reception between devices, and UI tests, which verify the correct operation of the mobile application’s graphical elements. These tests enable a thorough evaluation of whether the application can meet the QoS requirements before its production launch. 3.2. Usage of the tool This subsection guides deploying a simulated continuous architecture to demonstrate the benefits of CCSIM as a SaaS solution, the Project Designer, and the CCSIM workflow. It uses the Air-Quality-App as an example. Fig. 4 presents an overview of the project deployment process. To begin, users must register on CCSIM, obtain an API key, and select a pricing plan. The initial steps include generating the project configuration file within the CCSIM Project Designer. A repository (e.g., GitHub) should also be created for the application under evaluation, with the CCSIM project file located in the repository root. Users must also configure two GitHub secrets in the repository: API_KEY and USERNAME, which correspond to the API key and username provided during registration. Next, the CCSIM workflow should be added to the repository at ‘.github/workflows/workflow.yml’. This file, which requires no modifications, automatically triggers the GitHub workflow. The deployment process is streamlined by detecting changes committed to the main branch, which initiates the CCSIM workflow. Throughout the deployment, it can monitor its execution status and once the execution is complete, test results can be downloaded, all through the CCSIM API. This entire process needs to be completed only once unless modifications are required in the configuration file. Once set up, CCSIM will automatically initiate each time changes are made to the main branch, providing flexibility for multiple iterations. Thanks to its intuitive Project Designer, automated workflow, and robust API, CCSIM eliminates the need for complex installations, streamlines project setup, and enables seamless integration with version control, facilitating continuous deployment and testing for CC architectures. While CCSIM does not currently support automatic scaling policies, users can manually redefine scaling configurations in the Project Designer to evaluate different deployment scenarios. 3.3. Evaluating CCSIM runtime Scalability is key to running large-scale scenarios while ensuring stable run times to optimize the developer’s experience. Consistent run times allow developers to plan their workflows more effectively, ensuring predictable performance when scaling applications. This is particularly important in continuous integration and testing pipelines, where unpredictable simulation times can hinder automation and delay software releases [22]. In this case study, the simulation runtime was 15 min, covering all stages of the CCSIM workflow. However, this duration may vary depending on the scenario setup and the selected pricing plan. Fig. 5 presents the average runtime for each workflow stage across different SoftwareX 30 (2025) 102156 5 P. Rodríguez et al. Fig. 4. High-level operation of CCSIM. pricing plans.7 The results are based on five repeated experiments under a worst-case scenario, where the maximum number of devices is deployed and all available resources are utilized for each plan.8 The average runtime per workflow stage across different pricing plans, with very small error bars, indicating minimal variability between runs. Across the experiments, CCSIM maintained consistent simulation run times between 25 and 35 min. The Deployment stage dominates execution runtime, accounting for approximately 82%, due to the time required for AWS to initialize EC2 instances and deploy all containers. Despite additional resources in higher plans, virtualization 7http://ccsim.spilab.es/#pricing 8https://github.com/slasom/ComputingContinuumSimulator-SoftwareX/ tree/master/evaluation tools are not fully optimized, leading to longer deployment times for large-scale device setups. However, the overall run time remains stable across plan iterations, demonstrating CCSIM’s scalability and adaptability with minimal overhead. The most notable difference, in the Deployment stage stems from the larger number of devices in highertier test scenarios. Specifically, the Enterprise plan takes about 10 min longer than the Basic plan, a reasonable increase given the additional deployed devices. 4. Impact CCSIM streamlines the evaluation of CC architectures, providing a simulation environment to evaluate real distributed applications before their production release. This proposal differs from other works discussed above [9–11] in its variety and customization of scenarios, SoftwareX 30 (2025) 102156 6 P. Rodríguez et al. Fig. 5. CCSIM run time. thus offering a tool that is more adaptable to the specific needs of software development companies. It is currently in its early stages, but shows promising results in terms of usefulness and scalability and it has been used in other research studies [23,24] and academic projects.9 In addition, it has already attracted the interest of several companies. CCSIM primarily targets software development companies, offering seamless integration into their development processes. Its attractive pricing plan, tailored to meet diverse needs, makes advanced evaluation tools accessible to small and medium-sized enterprises without requiring significant investments. The impact of this innovation has also led to the creation of a spin-off aimed at capitalizing on its commercial potential. Currently, steps are being taken to establish it as a startup, representing a significant business opportunity resulting from this proposal. 5. Conclusions CCSIM is presented as an advanced platform to create and deploy simulated continuum architectures for evaluating QoS. This solution allows the creation of highly scalable and customized simulation environments, both in terms of the devices involved and the network infrastructure. This approach represents a significant advance in the challenge of evaluating CC architectures due to their complexity. In addition, as a SaaS solution, it facilitates the configuration and execution of the simulated environment by offering an API and pricing plans, as well as easy integration into software development processes (CI/CD) allowing better adoption by companies. As future work, we are working on the presentation of log results in a more refined way, allowing users to apply highly customized filters or perform processing on the raw results. Additionally, we aim to enhance scalability testing by enabling predefined scaling scenarios within a single project, reducing the need for redeployment. Finally, we are investigating the process of adapting this tool to integrate with Digital Twin technologies [25]. CRediT authorship contribution statement Pablo Rodríguez: Writing – original draft, Software, Resources, Methodology, Investigation, Formal analysis, Conceptualization. Sergio Laso: Writing – original draft, Validation, Supervision, Software, 9https://www.kathara.org/stories.html Methodology, Investigation, Conceptualization. Javier Berrocal: Writing – original draft, Validation, Supervision, Resources, Funding acquisition, Conceptualization. Pablo Fernández: Validation, Investigation, Funding acquisition, Conceptualization. Antonio Ruiz-Cortés: Visualization, Validation, Supervision, Funding acquisition. Juan Manuel Murillo: Visualization, Validation, Supervision, Investigation, Funding acquisition, Conceptualization. Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Acknowledgments This work has been partially funded by grant DIN2020-011586 and projects TED2021-130913B-I00 and PDC2022-133465-I00, funded by MCIN/AEI/10.13039/501100011033 and by the European Union ‘‘Next GenerationEU/PRTR’’, by the RCIS network (RED2022-134148T), by the Department of Economy, Science and Digital Agenda of the Government of Extremadura (GR21133), and by the European Regional Development Fund. References [1] Flores-Martin D, Berrocal J, García-Alonso J, Murillo JM. Towards dynamic and heterogeneous social IoT environments. Computing 2023;105(6):1141–64. [2] Laso S, Berrocal J, Fernandez P, García JM, Garcia-Alonso J, Murillo JM, et al. Elastic data analytics for the cloud-to-things continuum. IEEE Internet Comput 2022;26(6):42–9. [3] Wang J, Lim MK, Wang C, Tseng M-L. The evolution of the internet of things (IoT) over the past 20 years. Comput Ind Eng 2021;155:107174. [4] Bhuiyan MN, Rahman MM, Billah MM, Saha D. Internet of things (IoT): A review of its enabling technologies in healthcare applications, standards protocols, security, and market opportunities. IEEE Internet Things J 2021;8(13):10474–98. [5] Murturi I, Dustdar S. Decent: A decentralized configurator for controlling elasticity in dynamic edge networks. ACM Trans Internet Technol ( TOIT) 2022;22(3):1–21. [6] Dustdar S, Pujol VC, Donta PK. On distributed computing continuum systems. IEEE Trans Knowl Data Eng 2022;35(4):4092–105. [7] Balouek-Thomert D, Renart EG, Zamani AR, Simonet A, Parashar M. Towards a computing continuum: Enabling edge-to-cloud integration for data-driven workflows. Int J High Perform Comput Appl 2019;33(6):1159–74. [8] Pujol VC, Raith P, Dustdar S. Towards a new paradigm for managing computing continuum applications. In: 2021 IEEE third international conference on cognitive machine intelligence (cogMI). IEEE; 2021, p. 180–8. SoftwareX 30 (2025) 102156 7 P. Rodríguez et al. [9] Del-Pozo-Puñal E, García-Carballeira F, Camarmas-Alonso D. A scalable simulator for cloud, fog and edge computing platforms with mobility support. Future Gener Comput Syst 2023;144:117–30. [10] Mahmud R, Pallewatta S, Goudarzi M, Buyya R. Ifogsim2: An extended ifogsim simulator for mobility, clustering, and microservice management in edge and fog computing environments. J Syst Softw 2022;190:111351. [11] Barriga JA, Chaves-González JM, Barriga A, Alonso P, Clemente PJ. Simulate IoT Towards the Cloud-to-Thing Continuum Paradigm for Task Scheduling Assessments. URL https://www.jot.fm/issues/issue_2023_01/article6.pdf. [12] Bass L, Weber I, Zhu L. DevOps: A software architect’s perspective. Addison-Wesley Professional; 2015. [13] Laso S, Berrocal J, Fernández P, Ruiz-Cortés A, Murillo JM. Perses: A framework for the continuous evaluation of the QoS of distributed mobile applications. Pervasive Mob Comput 2022;84:101627. [14] León LJM, Herrera JL, Berrocal J, Galán-Jiménez J. EFCC: a flexible emulation framework to evaluate network, computing and application deployments in the cloud continuum. In: 2023 IEEE symposium on computers and communications. ISCC, IEEE; 2023, p. 1–6. [15] HashiCorp. Terraform, https://www.terraform.io/. [Accessed 10 November 2024]. [16] Service AW. AWS https://aws.amazon.com/. [Accessed 10 November 2024]. [17] Docker. Docker https://www.docker.com/. [Accessed 10 November 2024]. [18] Scazzariello M, Ariemma L, Caiazzi T. Kathará: A lightweight network emulation system. In: NOMS 2020-2020 IEEE/iFIP network operations and management symposium. IEEE; 2020, p. 1–2. [19] Fernandez P. APIPecker, [Accessed 10 November 2024] DOI: 10.5281/zenodo.14177731. [20] Developers A. Espresso https://developer.android.com/training/testing/espresso. [Accessed 10 November 2024]. [21] García-Fernández A, Parejo JA, Ruiz-Cortés A. Pricing4SaaS: Towards a pricing model to drive the operation of saas. In: International conference on advanced information systems engineering. Springer; 2024, p. 47–54. [22] Bisong E, Tran E, Baysal O. Built to last or built too fast? Evaluating prediction models for build times. In: 2017 IEEE/ACM 14th international conference on mining software repositories. MSR, IEEE; 2017, p. 487–90. [23] Laso S, Martín L, Herrera JL, Galán-Jiménez J, Berrocal J, Murillo JM. Dantalion: Digital twinning the computing continuum. In: 2023 IEEE globecom workshops (GC wkshps). IEEE; 2023, p. 1303–6. [24] Laso S, Murturi I, Frangoudis P, Herrera JL, Murillo JM, Dustdar S. A multidimensional elasticity framework for adaptive data analytics management in the computing continuum. 2025, arXiv preprint arXiv:2501.11369. [25] Laso S, Tore-Gálvez L, Berrocal J, Canal C, Murillo JM. Deploying digital twins over the cloud-to-thing continuum. In: 2023 IEEE symposium on computers and communications. ISCC, IEEE; 2023, p. 1–6. SoftwareX 30 (2025) 102156 8