CloudSim Express: A Novel Framework for Rapid Low Code Simulation of Cloud Computing Environments

A Cloud environment is a large and complex system composed of users, computing resources, network facilities, and applications. It focuses on various characteristics, including geographic location awareness, low latency, application scalability, and elasticity. As it evolves, new challenges emerge, such as energy efficiency and load balancing ². However, conducting experiments in actual Cloud environments is expensive, time-consuming, and difficult to replicate. Furthermore, developers lack control over Cloud environments, making it infeasible to repeat benchmark scenarios ².

Simulation allows for the imitation of real-world Cloud environments and enables experimentation with their complex internal interactions ¹⁷. It enables the stress-testing and iterative improvement of new strategies through repeated benchmark scenarios. Moreover, simulation requires fewer resources and less time to conduct experiments. Therefore, the use of Cloud environment simulators for experimenting with new strategies prior to actual deployment is common in research ³.

Cloud simulators provide a system model to represent a cloud environment. For example, the CloudSim toolkit follow a system model consisting of cloud brokers and data centers ⁴. Another example is the GreenCloud simulator, which focuses on network and energy and has a system model consisting of data centers and network devices with their energy models ¹⁸. In most simulators, the system models are extensible, meaning they provide extension points to inject scenario-specific logic. Users can leverage these extension points to experiment with novel approaches, such as scheduling policies and allocation policies ².

Furthermore, the simulation platform itself can be extensible. This is the case for widely used simulators like the CloudSim toolkit, which allows for reusable code ⁴, and enables the creation of extended simulators that are use case specific ². For example, CloudSimSDN provides support for Software Defined Networks in CloudSim by extending the vanilla CloudSim toolkit ¹⁹. Another example is GreenCloud, which extends the Network Simulator NS2 ²⁰ and adds cloud environment components to create an energy and network-focused simulator ¹⁸.

Therefore, the extensibility of cloud simulators, which involves providing extension points and the ability to extend itself, is significant in accommodating various cloud simulation scenarios. Most simulators leverage programming language features, such as object-oriented representation of components, to implement extensibility ^{21, 4}. However, these implementations often come with a steep learning curve. At the same time, simplifying the cloud environment system models (e.g., using script-based system models) to reduce the learning curve can compromise extensibility, as they encapsulate the object-oriented representation of inner components ^{3, 12}.

The CloudSim toolkit is a Java-based event-driven simulation toolkit for Cloud environments ⁴. It is widely used in research ^{11, 10} due to its rich features and its ability to be extended and customized to cater to most simulation scenarios. CloudSim supports the virtualization of physical machines, offering customizable provisioning policies for Virtual Machines (VMs). This capability extends to modeling and simulating application containers. Moreover, CloudSim’s power packages facilitate the modeling of the energy aspects of computations, thereby enabling the simulation of energy-optimization techniques. CloudSim evolves as the field advances enabling researchers to experiment with novel concepts. Such examples features are Microservices architectures, Edge/Fog computing ³⁹, Serveless computing ³¹, and Quantum computing ³². The architecture of CloudSim allows for dynamic insertion of components, enhancing the management of the simulation lifecycle with features like stop-and-resume. The simulation environment’s interconnected networks can be effectively modeled using network topologies. This setup allows for an analysis of the impact of network characteristics, such as latency and bandwidth, on the communication between components. Furthermore, CloudSim includes user-defined policies for resource management, which can be tailored to various customized scenarios, such as allocating VMs to host resources or assigning processing elements to active VMs in a granular manner. This level of customization reduces the effort required for system model development, enabling researchers to concentrate more on aspects of resource management.

The CloudSim toolkit has garnered significant attention within the scientific community, continuously fostering a rich ecosystem of extensions. One notable extension is WorkflowSim, developed by the University of Southern California, which adds a higher layer of workflow management to CloudSim. This layer addresses heterogeneous system overheads and failures ³³, enabling effective evaluations of scientific workflows in distributed settings. A distinctive aspect of modern cloud infrastructures is the investigation of cloud storage and its energy consumption. In this context, CloudSimDisk ³⁴ proposes a scalable module for CloudSim, extending its capabilities to support energy-aware storage solutions. This module has been validated by comparing simulation results with analytical models designed to gauge the energy consumption of hard disk drives in cloud systems. NetworkCloudSim addresses the lack of advanced application models in heterogeneous clouds. It focuses on scalable networking and a generalized application model, encompassing applications such as message passing and workflows. This allows for more accurate evaluations of scheduling and resource provisioning policies ³⁵. The migration of software systems to the cloud necessitates the evaluation of competing cloud deployment options (CDOs). To this end, CDOSim offers a tool for assessing the cost and performance properties of CDOs ³⁶, integrating a migration framework with CloudSim and leveraging provider-specific performance characteristics.

Furthermore, CloudSimEx aims to maintain a collection of extensions that are not only research-oriented but also focused on improving software engineering aspects. These improvements include enhanced logging utilities, the generation of CSV files for analysis purposes, and the capability to run multiple experiments in parallel ³⁷. Cloud2Sim concentrates on executing CloudSim simulations in a distributed manner, utilizing resources such as multi-core CPUs ³⁸. It achieves this through a distributed object storage approach. CloudSimSDN ¹⁹ introduces software-defined networking (SDN) modeling to CloudSim simulations, enabling researchers to explore SDN-oriented resource management approaches. The diverse ecosystem of CloudSim extensions highlights CloudSim’s ability to offer a versatile simulation framework for cloud computing.

At the same time, the CloudSim toolkit, and most of its extensions are based on modules that are written in java, which means that its simulations are developed as Java projects. Therefore, an additional overhead of programming language expertise is added to the development life cycle. Besides, CloudSim does not specify a standard pattern for implementing simulation scenarios, making it complex to reuse common components across simulations. This also leads to simulation code bases that are difficult to manage and have poor code readability. Aforementioned drawbacks are primarily caused by the lack of a standard framework for developing modularized simulations and the absence of a simplified representation of the simulation system model, such as a human-readable script. A modularized framework would enable CloudSim users to share common simulation components, drastically improving code readability and maintainability. A simplified representation of the simulation system model would allow the development of simplified simulations using a top-down approach without requiring expertise in a programming language.

To that end, existing literature aim to minimize the programming language overhead in CloudSim simulations. These works focus on providing a Graphical User Interface (GUI) to facilitate the design and execution of simulations through CloudSim ^{12, 3}. They enable users to set configurable parameters via the GUI and observe statistics of the ongoing simulation. The underlying implementation is responsible for translating between the GUI and CloudSim. A similar approach can be implemented using a human-readable script ¹¹. This method eliminates the need for users to have proficiency in a programming language, as the script and its structure for modeling system components are designed to be human-readable.

However, while approaches aimed at reducing programming overhead can streamline the use of CloudSim, they may also limit the toolkit’s extensibility. Extensibility is an important feature of CloudSim, forming the foundation of its extensive ecosystem of extensions. Compromising on this aspect diminishes the ease with which implemented approaches can be integrated into existing extensions. For instance, DartCSim, which offers a GUI interface, permits the overriding of only a limited set of methods ¹¹, thus constraining the scope for customization. Similarly, CloudSimPlus Automation, which employs a human-readable script to reduce programming complexity, restricts users in customizing implementations due to its specific usage of the Datacenter component ¹¹. Addressing this gap, our work introduces a novel framework that significantly reduces programming overhead while minimally impacting CloudSim’s extensibility.

The Sourcing Layer provides the following external sources.

• •

  System Model Script: The simulation system model is described using a human-readable scripting language. The system model comprises multiple interconnected components and can be simplified using a top-down approach. For instance, a regional Cloud zone itself is a system model that includes one or more Datacenters. Each Datacenter consists of a set of hosts, and these hosts, in turn, have associated processing elements. Thus, the System Model Script describes each of these components and aggregates them into an overall system model component.

• •

  Framework Configurations: Provides various configurations required to initialize the framework, such as location information of the files in the Sourcing Layer.

• •

  Extensions Modules: Provides modularized extensions to the user. These extensions are used to customize the simulation platform, as well as the framework itself.

This layer consists of the following modularized components to translate the human-readable system model into a concrete simulation.

• •

  Environment Resolver: Parses the System Model Script file, into a set of components that describes the system model. It uses the supplied component schema to understand the System Model Script. Upon parsing, components are aggregated into an overall system model component and handed over to the corresponding Element Handler. For example, a host described in the System Model Script can contain $7$ processing elements. This is parsed into a host component having its processing elements attribute set to $7$. Afterwards, multiple hosts components are aggregated to create the Datacenter system model, which is then handled by a corresponding Element Handler.

• •

  Element Handler: Processes a component in the simulation environment, and provides the corresponding simulation logic that needs to be implemented. Therefore, an Element Handler is implemented per Simulation Platform, and injected into the Translation Layer as an extension.

• •

  Extensions Resolver: Provides a central resolver to materialize objects from the provided extension modules. It generates extensions for various Element Handlers, Translation Layer modules, and the extensible components in the Simulation Platform.

• •

  Scenario Manager: Handles simulation scenario by executing Element Handler components.

• •

  Simulation Manager: Manages the overall simulation, such as initializing the simulation platform, initiating the system model translation, starting the simulation and overseeing it’s execution.

This layer consist the simulation platform. The Translation Layer interacts with it during the initialization and simulation execution stages. It decouples the simulation platform logic from the script-based translation logic, thereby allowing framework to be implemented with different simulation platforms.

Fig. 1 denotes the following control flow of the architectural framework.

1. 1.

   initialize the Translation Layer. This includes registering available Element Handlers, initializing Extensions Resolver with the location of extension modules, etc.

2. 2.

   and denotes Environment Resolver parsing the system model. It reads the System Model Script and constructs the system model component using the schematics of the components provided with . Upon construction of the system model component, its associated Element Handler is materialized via the Extensions Resolver in , and then parsed system model component is handed over.

3. 3.

   , , and denotes Scenario Manager handling the simulation scenario using the system model element handler. In doing so, it materializes other associate Element Handlers of the system model element handler in a top-down approach.

4. 4.

   and denotes Simulation Manager managing the simulation by executing the simulation scenario from , with the Simulation Platform provided by .

To simplify the Cloud environment system model with a human-readable script, we choose the human-friendly data serialization language, YAML (YAML Ain’t Markup Language) ¹⁶. YAML provides the capability to describe multiple components and then to aggregate the system model. Besides, YAML is widely used in the industry from managing configurations ²², to describing APIs, thereby provides a familiar experience to users.

To define the schema to write components in the System Model Script , we use OpenAPI 3.0 specification ²³. OpenAPI 3.0 is a machine-readable interface definition language and it is widely used with web services ²⁴. It provides specifications to describe object schematics in a top-down approach.

Firstly, we use OpenAPI code generation library during CloudSim Express compilation time to read components schema definitions and convert them to plain-old-java-object (PoJo) classes. During its run time, CloudSim Express reads the System Model Script YAML file and parse YAML components to objects of aforementioned PoJo classes. Both compilation time and run time translations of the Datacenter component are demonstrated with Listing 1, 2, 3 and Fig. 4.1. In which, Listing 1 shows the object schematics of the Datacenter component, alongside the corresponding attribute names and the type of the value complying with OpenAPI 3.0 specification. Listing 2 shows the PoJo class generated upon compilation of the CloudSim Express. Listing 3 shows the datacenter information sourced from the System Model Script, for a given simulation scenario. This information is written according to the schematics defined in Listing 1. As shown in Fig. 4.1, this information is then translated into a PoJo object during CloudSim Express run time.

The Section 4.1 describes how CloudSim Express translates System Model Script to a system model PoJo object. The run time translation process of that (also demonstrated with Listing 3 and Fig. 4.1 is implemented with the Environment Resolver component. It uses a YAML parsing library to read the System Model Script and map the parsed information into the PoJo object using an object mapping library. Afterwards, it traverses through registered Element Handlers and materializes a new matching Element Handler for the system model PoJo object.

An extension in CloudSim Express is a java module, packed as a jar. Extensions can extend the CloudSim toolkit, as well as the CloudSim Express framework itself. The Extensions Resolver module implementation provides APIs to materialize extension objects. During the launch of CloudSim Express, it reads and loads the class files packed in extension jar modules. It then provides APIs to allow other modules in the Translation Layer to invoke extension creation requests, with necessary information provided as custom java constructor arguments. We use java reflections feature to create objects using the loaded extension classes and the provided constructor arguments.

A standard CloudSim simulation involves building the system model in a java method body. We segregate this implementation to a series of recursive calls of Element Handler components. Each Element Handler provides implementation logic to a specific component in its handle() method, and for any other associated components, it makes a recursive method call of the same method of the corresponding Element Handler. This flow is demonstrated with Fig. 3. In which, a regional zone handler require a datacenter object for its implementation logic. It then calls handle() method of the datacenter handler and obtain the required datacenter object. The datacenter handler requires a host object for its implementation logic, which then is obtained by calling the same method of the host handler. The actual control flow for this scenario is depicted by the number to .
Overall, the handle() method instantiates the required CloudSim classes and creates the elements that are required. A series of element handler calls then generate all the required instances of CloudSim classes to establish the simulation environment. These element handlers can be easily customized to meet user requirements through the schema definition file. In this file, users define the schema for new elements and update the framework with corresponding POJO (Plain Old Java Object) files, which is automated during the build process. Subsequently, the corresponding element handler implementations are dynamically injected into the framework.

Once the Element Handler of the system model is realized (i.e. the process discussed in Section 4.2), it is then passed to the Scenario Manager. The Scenario Manager is controlled by the Simulation Manager. When CloudSim Express starts executing, the Simulation Manager instructs Scenario Manager to build the simulation scenario. The Simulation Manager achieves this by calling the handle() method of the system model Element Handler. As explained in Section 4.4, this eventually implements the CloudSim logic for building the system model. Afterwards, the Simulation Manager starts the simulation with CloudSim platform and oversee towards its completion.

Being able to extend is a powerful feature of CloudSim. Our proposed platform provide the flexibility to keep that intact, by integrating CloudSim extensions with Extensions Resolver. We define an attribute variant, in the System Model Script to indicate that a custom version of a component needs to be used. Listing 3 and Fig. 4.1 demonstrate an example of this. Which, the datacenter component that needs to be used is of the type org.cloudbus.cloudsim.Datacenter. This block of information is passed to the relevant element handler, and the element handler materializes a datacenter component of the mentioned type via the Extensions Resolver, through the java reflection feature. The user needs to place the extension class packed into a jar in the extensions location, and set the corresponding class name in the System Model Script file. Afterwards, the CloudSim Express tool is able to interpret the relevant extended version.

Apart from the simulation platform, the components in the CloudSim Express framework can also be extended in the same manner. However, since this is not a part of the simulation, the user is required to place the corresponding jar same as before, but the corresponding class name needs to be configured in the configuration file of CloudSim Express. This feature is useful if a user wants to change the default behaviour of a component in the Translation Layer, such as changing the behaviour of a default Element Handler.

Apart from the CloudSim Express implementation, the proposed framework is general enough to be applicable to any other simulator that builds the simulation system model using a top-down approach. In such scenarios, the implementation logic specific to the simulator is customized in the Element Handler components, and the Translation Layer components are customized as needed. Each of these components is designed to be pluggable, making the deployment of customized components straightforward.

CloudSim simulations can range from experimenting with allocation policies to experimenting with novel infrastructure changes, such as evaluating low power datacenters. These scenarios are implemented by extending the CloudSim toolkit. Therefore, in order to evaluate true productivity improvements from CloudSim Express, the use case should stress extensibility of the CloudSim toolkit.

The standard extension points of the CloudSim toolkit support a variety of policies, such as virtual machine allocation. In addition to that, it can be further extended using its object-oriented architecture. To capture both extensible aspects, we design following use case requirements.

• •

  R1: A datacenter that is aware of its Virtual Machines (VMs) allocation to physical hosts.

• •

  R2: A datacenter that periodically monitors its Virtual Machines (VMs)

The CloudSim toolkit utilizes the abstract Java class VmAllocationPolicy to define the logic for allocating VMs to physical machines during the simulation. By default, CloudSim includes an implementation of the worst-fit algorithm (i.e., allocating a VM to the host with the most processing elements) through the concrete class VmAllocationPolicySimple, which extends the aforementioned abstract class. In practical scenarios, users can implement their own VM allocation algorithms by extending the same abstract class. Therefore, R1 is also implemented by creating a new class that extends the VmAllocationPolicy abstract class. Once the implementation is completed, the CloudSim simulation code needs to be modified to include the newly created allocation policy class, and the codebase must be recompiled before running the simulation.

The CloudSim extension points do not cover all stages of the simulations. Anything that is not covered by the standard simulation points is implemented through the object-oriented design of the CloudSim toolkit. In such scenarios, users extend specific classes that represent the components in the simulation system model. Therefore, R2 is implemented by extending the standard CloudSim class "Datacenter" and overriding the method "updateCloudletProcessing". Within the overridden method, the logic corresponding to periodic virtual machine monitoring is implemented. Afterward, the extended "Datacenter" class needs to be included in the CloudSim simulation code, and the codebase must be recompiled before running the simulation.

In both implementations, users are required to be familiar with the CloudSim simulation codebase and need to invest effort into recompiling the codebase multiple times. Overall, this process involves significant effort. However, it offers users fine-grained flexibility in designing the simulation. Therefore, an ideal approach for reducing the aforementioned programming language overhead should also involve minimal compromise in simulation design flexibility.

We use the following baseline approaches that reduces the programming language overhead of the CloudSim toolkit.

• •

  CloudSim Plus Automation ^{25, 11}: A YAML (YAML Ain’t a Markup Language) script-based simulation approach for CloudSim simulations.

• •

  GITS: Generic Input Template for Cloud Simulators ¹⁰: A JSON (JavaScript Object Notation) script-based generic input template based approach for CloudSim simulations.

The CloudSim Plus Automation provides YAML script-based system model design. We implemented the use case by designing a single Datacenter, with a single customer. However, the CloudSim Plus Automation does not have native flexibility for custom extensions. It only supports the standard extension points supported with the CloudSim Plus project ²⁶, which is an enhanced version of the CloudSim toolkit. Therefore, to implement R1 and R2 from Section 5.1, we follow the approach below after inspecting the source code of CloudSim Plus Automation.

• •

  R1: Write an extended VM allocation policy class, VmAllocationPolicyCustom, using the java package, org.cloudsimplus.allocationpolicies. This is because CloudSim Plus Automation only supports allocation policy classes with the naming prefix VmAllocationPolicy, and residing in the aforementioned java package. When a custom class is implemented in this manner, it can be selected via the YAML script.

• •

  R2: Write an extended DatacenterSimple class. The DatacenterSimple class represents datacenters in CloudSim Plus Automation. In order to select it, we modified the source code. Because selecting a custom datacenter class is not supported via the YAML script.

To load custom classes during runtime, both were implemented in the CloudSim Plus Automation project. Afterward, CloudSim Plus Automation project was recompiled to obtain a modified tool with custom classes. Finally, the tool was executed with the corresponding YAML script, which is denoted in Listing 4. In this script, we set VM allocation policy value as Custom, so that our custom allocation policy implementation is selected.

The GITS (Generic Input Template for Cloud Simulators) focuses on representing the Cloud environment with either textual (JSON (JavaScript Object Notation) template) or graphical representation, and for this comparison, we use the former. The GITS for CloudSim provides a JSON template describing the Cloud Environment, and a GITS library file to convert Datacenter and hosts information from the JSON template to the GITS java objects.

The Fig. 4 depicts the UML diagram for the objects in the JSON template corresponds to the use case. We implemented GITS library file with the logic to handle objects in the template ¹⁰. Once GITS java objects are created, the CloudSim Datacenters and hosts are populated based on their values. Therefore, we implemented the use case requirements with the standard CloudSim simulation described in Section 5.1 while using GITS as a layer to interpret datacenter and host values from the JSON input template, which is denoted in Listing 5.

The system model of CloudSim Express implementation includes a regional zone with a datacenter. The extensions required by R1 and R2 from Section 5.1 are implemented as follows.

• •

  R1: Write an extended VM allocation policy class

• •

  R2: Write an extended Datacenter class

Both custom classes were developed in a separate java project, and compiled into a jar file. The resulting jar file is then copied to the CloudSim Express tool.

Listing 6 denotes System Model Script for the use case, in which we modified it to select the two custom classes. This System Model Script is also copied to the tool. Since default element handlers follow the commonly used cloud architectures, we do not need to modifiy them. Therefore, we executed CloudSim Express tool, which reads the script and load the custom classes during starup, and then to execute the simulation. CloudSim Express tool require least effort in deploying custom simulation scenarios, as the tool has automated most of the class loading procedures.

Productivity can be measured in two aspects: quantitative and qualitative. We measure the quantitative aspect by considering the amount of programming involved. The primary goal of a scripted simulation is to minimize the time spent on coding. Table 1 depicts the differences in productivity between CloudSim Express and the baseline approaches for the implemented use case.

We measure the lines of code to gauge the project’s magnitude. Additionally, we measure the complexity of the code because customizing the use case sometimes requires analyzing and modifying the simulation platform code. If the code is more complex, it takes more time to analyze. Since all approaches are Java-based solutions, we utilize JaCoCo, an open-source code coverage report generation tool ²⁷, to measure the lines of code and code complexity. JaCoCo calculates cyclomatic complexity value for each non-abstract method in the code, which is an indication of number of unit tests required for possible paths through the methods. A higher complexity number require increased effort in analyzing the control flow of the code. For both measurements, we excluded the GITS library file implementation code from Section 5.4 as it can be imported as a library.

We measure four qualitative aspects: framework re-compilation, CloudSim implementation, runtime extension injecting, and extending via script support. Framework re-compilation indicates whether modifying the provided framework is required to achieve the customized behavior. CloudSim implementation indicates whether at least a partial CloudSim simulation code implementation is needed. Runtime extension injecting indicates whether extended components are dynamically provided without re-compiling the framework. Extending via script support indicates whether framework extendability is achieved via the System Model Script .

The quantitative values of the approaches are denoted in Table 1. The CloudSim Plus Automation involves the largest code base in terms of both code complexity and lines of code. This is because the required customization in the use case mandates analyzing the framework code base and identifying how custom classes can be incorporated in the best possible manner, and then recompiling the framework with customization. In comparison, GITS involves a relatively smaller code base. This is because the script-to-java translation is performed via the provided library file, which can be used out of the box. The library file is then consumed in the standard CloudSim simulation implementation, resulting in a relatively smaller code base overall. Among the three approaches, CloudSim Express provides the smallest code base as it only requires implementing the custom classes. The extension injecting is done dynamically without involving coding implementations.

The qualitative values of approaches are also denoted in Table 1. The CloudSim Plus Automation needs to be modified to incorporate the customized classes; thus, it does not support runtime extension injecting, and a framework re-compilation is also needed. However, it does not require CloudSim simulation implementation, as the system model is generated via the provided script with extension support, and the simulation lifetime is managed via the framework itself. On the other hand, GITS performs worst in all qualitative aspects. This is because it only supports converting the script information to Java objects. The rest of the simulation has to be implemented via CloudSim in a standard manner. The CloudSim Express provides the best development experience since its dynamic extension injecting feature only requires providing the extension classes. The rest of the simulation is managed automatically.

Fig. 5 compares the processing overhead times for each approach when handling the System Model Script. For the GITS approach, this duration was measured from the tool’s launch time to the initiation of the CloudSim simulation, thus encompassing the time taken to process the script and convert it into the model. The method for calculating time is identical for CloudSim Express, covering both script processing and framework loading times. However, the latter tends to be lengthier compared to GITS. In contrast, for CloudSimPlus Automation, the measured duration extends from the tool’s launch to the invocation of the CloudSimPlus framework, which is the lengthiest of the three. Notably, all approaches incur a processing delay of less than a quarter of a second before commencing the actual simulation, indicating that the impact of the System Model Script processing time is generally minimal. Compared to the baseline approaches,CloudSim Express exhibits a reasonable overhead time.

To summarize, we observed that CloudSim Express outperforms the baselines in terms of productivity, both qualitatively and quantitatively. We evaluated all approaches using a practical simulation use case that emphasized the need for extensibility, which is a prominent feature of the CloudSim toolkit. CloudSim Plus Automation offers a reasonably good developer experience by automating the simulation life cycle through a System Model Script that supports the configuration of different policies at runtime. However, implementing extensions requires managing a relatively large code base and necessitates platform re-compilation. On the other hand, GITS involves a smaller code base but provides only partial automation of the simulation life cycle. CloudSim Express stands out by providing dynamic extension capabilities while automating the simulation life cycle, having a reasonable processing time overhead. In addition to its developer-friendly qualitative aspects, it also achieves a reduction of $71.43$% in code complexity and $89.42$% in lines of code compared to the baselines.