Towards Greener Applications: Enabling Sustainable-aware Cloud Native Applications Design

Computationally demanding applications, including AI, machine learning, and Big Data analytics, consume a significant amount of energy, increased 300’000 times over the past 10 years [19,24].

This paper focus the attention on the active role of applications in the energy footprint of IT and aims at increasing the awareness of application providers on the environmental footprint of their applications.

Current research mainly focuses on dynamic resource allocation and scheduling according to energy efficiency optimization [2,37].

The CodeCarbon initiative [23] provides a tool for estimating CO2 emissions the geographical location and the energy mix of the country in which the application is deployed. Power is also one of the metrics considered in [7], providing black-box monitoring for multi-component applications. This is a first step for enabling energy-awareness in microservice-oriented applications but the workflow enhancement perspective is still missing

A typical application is composed of dozens to hundreds of independent microservices, all implicitly cooperating to reach the overall goal of the organization implementing the application. However, not all the components have the same relevance, being some of them necessary for reaching the goal, while other just enriching the application with additional accessory functionalities that might increase the overall Quality of Experience (QoE) of the customer or the income of the service provider. Moreover, each microservice has different requirements in terms of computational resources and different constraints in terms of Quality of Service (QoS). From this perspective, microservice based architectures are really effective since they allow the scale-out of the single components that are experiencing performance issues. Microservices can be sensitive to the context in which they are executed. Each microservice provides a specific functionality, however, the way in which this functionality is carried out might depend on the context of execution, and slightly different alternative implementations of the same functionality can be provided, i.e., with fail-over mechanisms.

Step 1 is a first step towards sustainable applications. It consists in adding basic sustainability-aware information to the application design. The goal is to enrich the application model with additional information that can drive the deployment decisions of the cloud provider when the single components are deployed. This information is not only related to the energy aspect, but also to functional and QoS requirements.

Step 2. The application designer provides information on which components of the application are mandatory and which are optional: MM ∪ MO ⊆ M where MM is the set of mandatory microservices and MO is the set of optional microservices.

This information is relevant not only for the sustainability of the application (e.g., skip an optional component when renewable power source is not available), but also for QoS (e.g., avoid optional components when the application is experiencing response time or latency issues).

Step 3. It consists in the enrichment of the microservices composing the application through the definition of different modalities of execution for each component. Alternative execution modalities can be defined for a single microservice and the one to enact might depend on the current context.

Proposal: Use three different execution modalities (versions):

• Normal: basic execution modality
• High-Performance: the service does more than needed, e.g. taking previous activities into account to provide better QoE
• Low-Power: Simplified version aiming at reducing the amount of energy consumed, e.g. by skipping sub-activities

SADP provides a methodology for improving and evaluating the sustainability in the design of a cloud-native application, enriching each component with additional details and metadata.

Designing a sustainable workflow requires to select the best configuration for all the components of the application according to the context, aiming at improving energy efficiency, cost, and QoS. The composition of the application will dynamically change selecting a different pool of microservices according to the context of execution.

In order to enable the Low-power execution and the High-performance execution, all the microservices, or part of them, have to be designed according to the Step 3 of the SADP: different interfaces to execute the microservice are provided for each supported modality. These workflow execution modalities are not exclusive, in fact they can be combined together. As an example, if a Lowpower execution is activated together with a Basic execution, all the optional tasks are skipped, while regular tasks are executed using their low-power version if available.

Business rules enable to express conditions on the execution of an activity in a business process. They hide the complexity of the logic preventing the model to become too complex. In this case, business rules are included to define the execution modality of each task according to the values of a set of contextual variables collected by the monitoring system of the application and each of its microservices.

The outcome of the design step will be an annotated and enriched BPMN model containing all the relevant information for the management of sustainability-aware applications. BPMN models can be translated in machine-readable formats like XML or JSON, including annotations and task types that will enrich the description of each task. It is thus possible to translate the model into a set of features that can be exploited by an orchestrator. As an example, a BPMN-driven microservice coordination approach is provided by some existing tools in the state of the art. For instance, Camunda and Zeebee are workflow engines supporting BPMN and DMN for designing workflow orchestrations.

SADP is based on the assumption that monitoring the energy consumption (and even better the CO2 emissions) of each single component of an application is possible. At the moment this information is not provided by any cloud provider natively. However, several initiatives are proposing solutions for estimating both energy and emissions at the application level.

Another critical aspect is the increased complexity in the application design, requiring to define several versions for each microservice. From a design perspective, the proposed approach is incremental, leaving the application owner the right to decide to what extent to refine the existing application model.

From a management perspective, costs will probably increase. Thus, the problem is how to motivate application providers to invest in sustainable applications. Existing studies have demonstrated how sustainability can become a strategic value for both organizations and their customers thanks to a proper awareness of the impact on the environment [32].