ASCETiC Project D4.1 Intra-Layer Cloud Stack Adaptation

(1)

ASCETiC Project

D4.1 Intra-Layer Cloud Stack

Adaptation

Project Acronym ASCETiC

Project Title Adapting Service lifecycle towards Efficient Clouds

Project Number 610874

Instrument Collaborative Project

Start Date 01/10/2013

Duration 36 months

Thematic Priority ICT-2013.1.2 – Software Engineering, Services and Cloud Computing

Work Package WP4, Static Energy-Efficiency

Due Date: M24

Submission Date: 30/09/2015

Version: 1.0

Status Final

Main Editor(s): Richard Kavanagh (ULE) Django Armstrong (ULE) Karim Djemame (ULE) Reviewer(s) Odej Kao (TUB)

(2)

Project co-funded by the European Commission within the Seventh Framework Programme

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the _Commission) RE Restricted to a group specified by the consortium (including the _Commission) CO Confidential, only for members of the consortium (including the _Commission)

(3)

Version History

Version Date Comments, Changes,

Status Authors, contributors, reviewers

0.01 01/05/2015 ToC agreed Richard Kavanagh (ULE), Karim _{Djemame (ULE)} 0.05 12/06/2015 Integrating initial content

for section 2 Richard Kavanagh (ULE), Django Armstrong (ULE), Raül Sirvent (BSC), Mario Macías (BSC), David Garcia Perez (ATOS)

0.06 08/07/2015 Integrating Application monitor and pricing modellers.

Richard Kavanagh (ULE), Mario Macías (BSC), Alexandros Kostopoulos (AUEB) 0.1 20/07/2015 Integrating SLA Managers

and programming model. Richard Kavanagh (ULE), Luca Porrini (HP), Davide

Sommacampagna (HP), Raül Sirvent (BSC)

0.11 21/07/2015 Adding preface/position of

deliverable in reading path Richard Kavanagh (ULE), Julia Wells (ATOS)

0.12 31/07/2015 Adding SaaS KPI Modelling

and Visualisation Tools Richard Kavanagh (ULE), Jean-Christophe Deprez (CETIC) 0.13 03/08/2015 Adding the outline of the

Software User guide Richard Kavanagh (ULE) 0.14 11/08/2015 Adding further updates

from CETIC. Richard Kavanagh (ULE), Christophe Ponsard (CETIC) 0.15 26/08/2015 Adding content to section

2.4.5 and section 3.3 Richard Kavanagh (ULE), Marc Körner (TUB), David Ortiz (BSC) 0.2 02/09/2015 Adding section 2.6 KPIs and

Metrics Richard Kavanagh (ULE), Davide Sommacampagna (HP)

0.21 02/09/2015 Inclusion of Section 1

Richard Kavanagh (ULE) 0.25 07/09/2015 Structural updates and

review document. Richard Kavanagh (ULE), Karim Djemame (ULE), Django

Armstrong (ULE) 0.4 11/09/2015 Adding updates before

Venice meeting. Richard Kavanagh (ULE), David Garcia Perez (ATOS), Marc Körner (TUB), Mario Macías (BSC), Raül Sirvent (BSC), Luca Porrini |(HP), Davide Sommacampagna (HP)

(4)

0.6 22/09/2015 Adding updates post

Venice meeting. Richard Kavanagh (ULE), Django Armstrong (ULE) Alexandros Kostopoulos (AUEB), Luca Porrini (HP), Marc Körner (TUB), David Garcia Perez (ATOS), Raül Sirvent (BSC)

0.62 22/09/2015 Adding further updates and adding new section on novelty and conclusion

Richard Kavanagh (ULE), Django Armstrong (ULE), David Rojoa (ATOS)

0.64 22/09/2015 Adding updates from AUEB

Richard Kavanagh (ULE), Alexandros Kostopoulos (AUEB) 0.66 23/09/2015 Completing section 3 and

minor changes to various sections.

Richard Kavanagh (ULE), Karim Djemame (ULE)

0.68 24/09/2015 Adding revisions to section

2.2.2 Richard Kavanagh (ULE),

Jean-Christophe Deprez (CETIC) 0.7 25/09/2015 Adding revisions to section

2.2.7 Richard Kavanagh (ULE),

Jean-Christophe Deprez (CETIC) 0.74 28/09/2015 Adding editorial changes

suggested by internal review.

Richard Kavanagh (ULE), Django Armstrong (ULE)

0.8 28/09/2015 Adding changes by various partners relating to

comments made by the internal review.

Richard Kavanagh (ULE), Luca Porrini (HP), Davide

Sommacampagna (HP), Mario Macias (BSC)

0.81 29/09/2015 Fixing section numbering

and improving grammar Richard Kavanagh (ULE) 0.82 29/09/2015 Updates to section 2.2.1

given feedback from the internal review.

Richard Kavanagh (ULE), Raül Sirvent (BSC)

0.84 29/09/2015 Updates regarding the pricing modellers and other minor updates.

Richard Kavanagh (ULE),

Alexandros Kostopoulos (AUEB), Jean-Christophe Deprez (CETIC) 0.90 29/09/2015 Updating the section 2.7.

Inserting additional references and general document check.

Richard Kavanagh (ULE), Karim Djemame (ULE), Davide

Sommacampagna (HP) 1.0 30/09/2015 Final checks

(5)

List of Figures

Figure 1: Y2 deliverables reading path ... 9

Figure 2: GAT vs. NIO, task generation case ... 21

Figure 3: GAT vs. NIO, file transfer case ... 22

Figure 4: GAT vs. NIO, object generation case ... 22

Figure 5: High Level Structure of NFR and some relationships ... 27

Figure 6: Minimisation of indirect energy costs of SaaS application. ... 28

Figure 7: CPU comparison between two nodes in the same test run ... 30

Figure 8: Filtering on aspects. ... 31

Figure 9: Energy vs. Time ... 31

Figure 10: PaaS SAM Overall Workflow... 34

Figure 11: Lab Setup ... 39

Figure 12: Model testing ... 40

Figure 13: Response time of concurrent user requests to generate ISO images 44 Figure 14: Time to prepare a VM image. ... 44

Figure 15: Time measurements of recontextualization. ... 45

Figure 16: Breakdown of time spent during recontextualization. ... 45

Figure 17: Comparison of payments by two applications to IaaS providers as a function of application QoS diversity. IaaS providers employing static pricing are not competitive because they require higher payments for at least one application. ... 50

Figure 18: Aggregate net benefit for the cases of a two-part incorporating energy charges, and a static pricing scheme. In competitive markets, applications are always benefited the most under the two-part tariff. ... 51

(7)

Figure 19: VM optimisation performance for different local search algorithms

and search time (30 hosts – 30 VMs – 20% average load) ... 60

Figure 20: VM optimisation performance for different local search algorithms and search time (30 hosts – 30 VMs – 45% average load) ... 61

Figure 25: Data serving CPU vs. average operations/second ... 63

Figure 26: data analytics Watts vs. execution time ... 63

Figure 27: data caching Watts vs. requests/second ... 64

Figure 28: Data serving Watts vs. average operations/second ... 64

Figure 29: Calibration of the Energy Modeller in ASCETiC ... 67

Figure 30: Example of Calibration Data on Testnode4 Leeds Testbed... 68

Figure 31: Trace of Power Consumption on Testnode4 ... 70

Figure 32: Distribution of Error in the Power Model ... 71

Figure 33: Recursive calculation of energy charges 𝑪(𝑻) up to time 𝑻 by the energy charges 𝑪(𝑻𝒌) and the energy charge during the time period from 𝑻𝒌 up to 𝑻, where 𝑻𝒌 is the last instant the energy price changed prior to 𝑻. ... 74

Figure 34: IaaS provider profits in a monopoly – Using a two-part tariff incorporating energy charges (solid curve) and a static price (dashed). ... 78

Figure 35: Available metrics from IPMI sensors on a Dell PowerEdge R430 server ... 82

Figure 36: Host power consumption monitored via IPMI during instantaneous switching of CPU load from 100% to 0%. ... 83

Figure 37: TUB Cloud Testbed ... 87

Figure 38: Three Tier Web Application Architecture. ... 88

Figure 39: Application life-cycle phases against the number of application server instances. ... 89

Figure 40: Linear relationships of application life-cycle phases against the number of application server instances. ... 90

Figure 41: Power and CPU Utilization during deployment ... 91

Figure 42: Communications workflow in a multi-provider scenario (This figure it is a simplification of the ASCETiC Y2 architecture just to explain the multi-provider scenario at PaaS level). ... 94

Figure 43: Application Monitor main dashboard ... 98

Figure 44: Application Monitor dynamic time-series graphing ... 99

Figure 45 PaaS Layer KPIs and Metrics ... 105

Figure 46: SLA Negotiation ... 115

Figure 47: Training application models ... 116

Figure 48: Monitoring ... 116

Figure 49: Tab with Deployment Properties to specify optimization and boundaries ... 119

Figure 50: System status section ... 122

Figure 51: active applications section ... 123

Figure 52: recently finished deployments section ... 123

(8)

Figure 54: new graph modal form ... 124

Figure 55: Virtual Machine Manager - Dashboard ... 126

Figure 56: Virtual Machine Manager - VMs ... 126

Figure 57: Virtual Machine Manager - Images ... 127

List of Tables

Table 1: Acronyms ... 14

Table 2: Goodness of fit for the Energy Modeller's Calibration ... 69

Table 3: Application life-cycle phases against number of application server instances. ... 90

Table 4: Energy and Power Metrics at the IaaS Layer ... 101

Table 5: IaaS VM Manager Performance Metrics ... 102

Table 6: IaaS General Monitoring Metrics ... 104

Table 7: PaaS Layer Metrics ... 106

Table 8: SaaS - Metrics for defining KPIs and utility function on operational cost. ... 110

Table 9: SaaS - Metrics for defining power and energy usage of applications 113 Table 10: SaaS - Time Performance Metrics ... 114

(9)

Preface – Positioning this deliverable in the ASCETiC project

This deliverable is the second (of three) Scientific report documents corresponding to the second year of the project’s progress. Its position in the “reading path” of deliverables is shown below.

Figure 1: Y2 deliverables reading path

ASCETiC follows an incremental development approach hence each year a separate scientific report will be produced, which will make advances on the previous year, for the duration of ASCETiC project. The first year mainly focused on making the life cycle phases and Cloud components of each service layers energy-aware; the second year enables adaptation at each service layer in isolation; finally, the third year will add adaptation across service layers to reach global energy effectiveness.

(10)

Executive Summary

The purpose of this deliverable is to present the contribution of ASCETiC’s components to science. Furthermore, instructions of how they can be used by actors from each of the architecture layers: SaaS, PaaS and IaaS, are given. The scientific contributions are presented individually per component, comparing them to current solutions and describing how each component goes a step beyond the state of the art. The key action of the second year of the project was to perform self-adaptation on a per layer basis.

In the case of the SaaS layer, the SaaS Modelling Tools advance on the approach of specifying at design time what needs to be measured in an application or a service when it will be deployed and executed, by capturing an applications ability to adapt. Besides, the ASCETiC Programming Model related components now are now not only aware of the energy consumption of an application but can now adapt using advanced scheduling techniques that take account of different versions of an applications core elements, target platform and consumption profile.

The PaaS layer components are orchestrated by the Application Manager. This is now complimented by the new component called the Self-Adaptation manger, which manages applications at runtime and invokes change in cases where SLAs terms are been violated. The component that provides energy awareness is the Energy Modeller, which provides estimates of energy consumption of applications and events inside an application. At the heart of enabling adaptation is the VM Contextualizer that has the ability to inject probes in application images for monitoring as well as enabling the changes to the context of VMs running an application. The Pricing Modeller is used to calculate and predict prices taking into account energy. Pricing and energy information is utilised by the SLA Manager to select the best SLA offer, while the SLA manager in addition defines SLAs and monitors their conformance; and the Application Monitor which stores and analyses application-level metrics obtained with probes.

Regarding the IaaS layer, again the Energy Modeller (this time the one in the IaaS layer) is a key component, since it can predict and measure energy of hosts and VMs as well as assist in the ranking of hosts for VM placement. The energy information is collected by means of the Infrastructure Manager and stored in the Infrastructure Monitor, together with other KPIs. The energy modeller has been added to this year with the inclusion of an Emulated Watt meter, which provides scalability in cases where Watt meters are not attached to each physical host. The SLA Manager works together with its corresponding component in the PaaS layer to select the best offer, as does the Pricing Modeller. The VM Manager performs the deployment of VMs according to a policy specified by the owner of the infrastructure, which has expanded the policies it may use in the second year. The VM Manager has also been extended to include an adaptation manager that can perform rescheduling of VMs to maintain the performance and energy efficiency of the IaaS layer. In general, the key research challenge that the ASCETiC Toolbox has solved in the second year is the ability to take adaptive actions based upon factors such

(11)

as price and energy consumption and performance within each layer of the Toolbox and to examine the effect that it has upon the running applications. In addition to the detailed scientific contributions, we also include user guides for each layer. The most extensive guides are in the SaaS layer, since both the Programming Model and the SaaS Modelling Tools expose graphical interfaces that applications or service developers may use to create their new applications or services powered with the energy-awareness capabilities. Both SaaS manuals include a Getting started section intended to be a fast reference for end users. In the case of the PaaS and IaaS layers, both layers have a central component considered to be the entry point to each layer (the Application Manager for the PaaS and the VM Manager for the IaaS). Therefore, in this case their interfaces are referenced as the User Guide. In the case of the VM Manager, a dashboard is also offered.

Our conclusions emphasize that the second year objectives of the project have been fulfilled. Energy consumption of applications can be measured and utilised within the constraints of each layer to perform adaptation within the ASCETiC architecture.

(12)

1. Introduction

1.1 Purpose

This document is the official deliverable D4.1: Intra-layer Cloud Stack Adaptation, which is described in the DoW as a scientific report, which describes the scientific work and software packages in the second iteration of the ASCETiC Toolbox. The ASCETiC project has considered to deliver not only the software produced in Year 2, but this document to help in explaining mainly what are the individual scientific contributions of the components that form the ASCETiC and how each layer in the architecture will be used. Thus, this deliverable is therefore divided in three sections corresponding to the scientific contributions, novelty and the user guides.

1.2 Structure

The scientific contributions of the ASCETiC Toolbox components have been described in a short paper format: first motivating the problem to be solved, second analysing current related work in the topic or topics addressed, third detailing specifically the scientific contributions of the and fourth providing conclusions and future directions of the research done. The section starts with a sub-section putting in context how ASCETiC achieves energy-awareness in the second year of the project and then explains the scientific contributions of the components organized by layers. This is followed by a summary of the novelty of the components in year 2.

The second major part of this document includes the user guides for each layer, detailing how a Cloud end user, designer, programmer or administrator is able to use the functionalities of each layer: SaaS, PaaS and IaaS. In particular, the SaaS layer has been divided in two: the ASCETiC Programming Model and the SaaS Modelling Tools. These are the two main tools included in the layer. These two sub-sections present first a Getting Started guide and then they detail the functionalities provided and known limitations.

At the end of this deliverable we also provide some conclusions about our scientific achievements, highlighting the relevance and potential scientific impact of the research that is taking place in the ASCETiC project.

1.3 Glossary of Acronyms Acronym Definition

AM Application Manager AMI Amazon Machine Images

API Application Programming Interface APM Application Package Manager APPM APPlication Monitoring

ASCETiC Adapting Service lifeCycle towards EfficienT Clouds CE Core Element

CEI Core Element Interface CellBE Cell Broadband Engine CLI Command Line Interface

(13)

COMPSs Component Superscalar CPU Central Processing Unit

CXE Apache CXF

DB Database

DFS Distributed File System

DHCP Dynamic Host Configuration Protocol DoW Description of Work

DSL Domain Specific Language EC2 Amazon Elastic Compute Cloud

Gb Gigabyte

GHz GigaHertz

GUI Graphical User Interface IaaS Infrastructure as a Service

IDE Integrated Development Environment IM Infrastructure Manager

IP Infrastructure Provider J2EE Java 2 Enterprise Edition JDT Java Development Tools JIT Just In Time

JVM Java Virtual Machine KPI Key Performance Indicator KVM Kernel-based Virtual Machine

LDAP Lightweight Directory Access Protocol MAC

Address Media Access Control Address MAPE Monitor, Analyse, Plan and Execute NFS Network File System

NIC Network Interface Card OE Orchestration Elements OVF Open Virtualization Format PaaS Platform as a Service

PAM Pluggable Authentication Module PKC Public Key Cryptography

PM Programming Model

PM plug-in Programming Model plug-in PMR Programming Model Runtime

POSIX Portable Operating System Interface PUE Power Usage Effectiveness

QCow2 QEMU Copy On Write QEMU Quick EMUlator QoS Quality of Service

RAM Random Access Memory RE Requirements Engineering

ReqIF Requirements Interchange Format REST Representational state transfer ROI Return Of Investment

RRDtool Round Robin Database Tool SaaS Software as a Service

SLA Service Level Agreement SLAM SLA Manager

(14)

SP Service Provider

SPU Synergistic Processing Unit SSH Secure Shell

Tb Terabyte

TOSCA Topology and Orchestration Specification for Cloud Applications

TPS Third Party services UI User Interface

UML Unified Modelling Language VDI Virtual Disk Image

VHD Virtual Hard Disk VM Virtual Machine

VMC Virtual Machine Contextualizer tools VMDK Virtual Machine Disk

VMIC VM Image Constructor VMM Virtual Machine Manager VPN Virtual Private Network

XML eXtensible Mark-up Language Table 1: Acronyms

2. Scientific Report on Components

2.1How ASCETiC Achieves Energy-awareness and Adaptation

The ASCETiC architecture focuses on providing novel methods and tools to support software developers aiming at optimising energy efficiency and minimising the carbon footprint resulting from designing, developing, deploying and running software in Clouds.

ASCETiC and its proposed architecture focuses upon:

a) Providing models for green and efficient software design, supporting sustainability and high quality of service levels at all stages of software development and execution;

b) A framework that identifies energy efficiency parameters and metrics for Cloud services;

c) Measuring, analysing, evaluating and adapting energy usage in software development and execution

d) Integrating energy and quality efficiency into service construction, deployment and operation leading to an Energy Efficiency Embedded Service Lifecycle.

Energy awareness and adaptation is essential to the ASCETiC architecture and is achieved in each of the three layers of the Cloud stack. In the 2nd_{year of the}

project, we will focus on intra-layer adaptation in which each layer will adapt independently, whereas in the 3rd_{year the layers will cooperate with inter-layer}

adaptation.

In the SaaS layer, a collection of components interacts to facilitate the modelling, design and construction of a Cloud application. These components

(15)

help in evaluating energy consumption of a Cloud application during its construction. They take the concrete form of a number of plugins directly usable by developer within an Integrated Development Environment (IDE) and that interacts with the wider ASCETiC framework.

ASCETiC focuses on Cloud services made of several shared software components, which are utilised many times. These components can then be characterised, which allows the SaaS tools to relate software design and energy use. This relationship will further depend on the deployment conditions and the correct operation of the service, which will be achieved by means of an adaptive environment.

The SaaS components in aid of the goal of energy efficiency therefore provide means of packaging Cloud applications in a way that enables provider agnostic deployment, while maintaining energy awareness.

The PaaS layer provides middleware functionality for a Cloud application and facilitates the deployment and operation of the application as a whole. This layer focuses upon selecting the most appropriate provider for a given set of energy and performance requirements and tailoring the application to the selected provider’s hardware environment. It provides facilities such as Application level monitoring and support for Service Level Agreements (SLA) formation and negotiation of to facilitate energy and Quality of Service (QoS) requirements. It goes further at runtime by utilising SLA guarantees to manage power and energy consumption levels in an automated and adaptive fashion by adapting once prior agreed constraints are realised.

The IaaS layer provides admission, allocation and management of virtual resources through the orchestration of the ASCETiC IaaS layer components. Energy consumption is monitored, estimated and optimized using translated PaaS level application requirements.

The focus on self-adaptation can be seen in each layer, with each component adding to the ability of the overall architecture to adapt. In the SaaS generic requirement patterns are captured on quality properties in a quantifiable fashion. The expression of these metrics as well as representative workloads enables the level and types of adaptation to be specified. This is achieved through offering deployment alternatives and selecting the most appropriate configuration for the underlying infrastructure. This is all visualised so that a SaaS development team can easily interpret how the different deployment strategies work.

The captured application requirements are realised in the PaaS layer by the application manager, which enables the deployment of the application. Self-Adaptation then continues in the PaaS layer through the collaboration between the Application manager and other key components such as the Self-Adaptation manager SAM, SLA manager and App Monitor. The SLA manager continually monitors SLA conformance with the aid of the application monitor while the Self-Adaptation manager makes the decisions of when to adapt that application through horizontal scaling.

(16)

The last layer that supports the whole infrastructure is the IaaS layer. The Virtual machine manager (VMM) is at the heart of the adaptation at this layer. Unlike the PaaS Layer that focusses on application level metrics it focuses on optimising the VMs both at deployment and again at runtime. In order to do this it utilises energy and pricing modellers as well as key performance data from the infrastructure monitor and performs rescheduling in order to adapt either on particular events such as submission of new VMs or periodically.

The individual components that have been developed to achieve this energy aware, adaptive architecture are discussed in the rest of this section.

2.2SaaS SDK Tools

2.2.1 ASCETiC Programming Model

The ASCETiC Programming Model section refers to the innovations provided by four components of the SaaS layer in the ASCETiC Architecture. They are the Programming Model, Programming Model Plug-in, Programming Model Runtime and Programming Model Packager.

2.2.1.1Motivation

During the first year of the project, the ASCETiC Programming Model (PM) has been put into context of a set of research topics, namely: frameworks/languages to program services and applications for the Cloud, energy-aware applications, energy-aware programming and energy gains from compilers. These topics were deeply analysed during Y1 SotA revisit (an accompanying document to Deliverable D2.1.1: “ASCETiC Requirement Specification - version 1”), thus we forward the reader to the Y1 SotA revisit to understand the key contributions provided by the ASCETiC PM in these topics. More specifically, during the first year we have successfully delivered the versioning technique, which enables to have applications including a single CE with different implementations, together with the possibility of implementing energy-aware policies in the ASCETiC PM Runtime (a greedy policy was provided as a proof-of-concept).

For the second year and being self-adaptation at intra-layer level the global objective of the project, one of the natural topics to explore was to propose more complex policies to adapt the execution of the application at run time. As it will be shown in the Related Work sub-section, self-adaptation at the software development level has been already considered by other frameworks, but without taking into account the three parameters we consider for the optimization: performance, energy and cost.

2.2.1.2Related Work

The work related to the research topics dealt in the ASCETiC Programming Model has been already presented in the accompanying document to Deliverable D2.1.2: “ASCETiC Requirements Specification (Year 2)”. Thus, we reference the reader to that document for more details. In this section we provide a summary of what was provided previously in D2.1.2.

(17)

Regarding self-adaptation capabilities at software development level, as previously mentioned, other Cloud programming solutions already included them in the past. Although performance is one of the most common parameters found in related work when optimizing the execution of applications in the Cloud (i.e. Pegasus [1], Taverna [2], Galaxy [3] or Swift [4]) other tools such as Aneka [5] and GreenPipe [6] also consider parameters such as cost in the first case (accounting it) and energy in the second (but provided by the user and tailored for a particular case). Nowadays, no other work shows a mixture of optimizing energy, cost and performance as we propose.

Our main scientific contribution is a set of scheduling policies that take into account the application-knowledge level (i.e. the workflow describing the application) with the objectives of:

 Minimizing energy consumption: while considering boundaries for cost and performance.

 Minimize cost: while considering boundaries for energy consumption and performance.

 Maximizing performance: while considering boundaries for energy consumption and cost.

As a side reminder, it is important to highlight that nowadays most common practice towards adaptation in the execution of Cloud applications and services is done using the concept of horizontal elasticity driven from the application. We see horizontal elasticity as a mechanism where several layers of the architecture (and their related information) need to work together to support this mechanism, therefore we envision it to be implemented during the third year of the project, in the inter-layer adaptation. So, optimizing performance, energy or cost will also consider the possibility of requesting new machines or reducing their number at runtime during the next year.

2.2.1.3Scientific Contributions

The scientific contribution provided by the ASCETiC PM for this second year of the project is:

 Scheduling policies at application-level to optimize performance, energy or cost

However, other developments also help to achieve lower energy consumption in the execution of applications, which are:

 Persistent workers  Object cache

In the following paragraphs we describe both the main innovation provided and the rest of developments.

Scheduling policies at application-level to optimize performance, energy or cost

As previously mentioned in the motivation section, in Year 1 we implemented a greedy policy in the runtime to allocate tasks to the machine consuming less energy for a particular CE. This implementation allowed us to demonstrate during first year review that dealing with energy consumption at application-level was feasible and interesting in order to save energy. However, being

(18)

greedy when selecting where to run a CE was not our final goal, since a greedy policy doesn’t need to be the optimal policy when trying to reduce energy consumption. Therefore, in Year 2 we implemented three new policies that are able to exploit the information available in the ASCETiC Toolbox, more specifically the information and prediction in terms of energy and cost for the execution of a CE provided by the PaaS Energy and Pricing Modellers, but combined with the information available in the ASCETiC PM runtime itself regarding execution time of past CEs and prediction of that time for future ones. With this variety of information, the policies we have implemented are:

 Minimizing energy consumption while considering boundaries for cost and performance: we consider the use case where an end user cares about spending the minimum energy when running their application. However, the user is also interested in not to influence very negatively the total execution time (i.e. don’t run the application extremely slowly), or increasing the cost up to a certain maximum (i.e. don’t use very expensive machines even when they are more energy efficient).

 Minimize cost while considering boundaries for energy consumption and performance: in this case, the objective of the user is to execute the application as cheaply as possible, but again limiting the influence that optimizing the cost will have in both the energy (i.e. select cheap machines but with reasonable energy profiles) and the performance (i.e. cheap machines but not the slowest ones).

 Maximizing performance while considering boundaries for energy consumption and cost: in the third case, users want to execute the application as fast as possible, even if this requires to spend more money to use faster machines (but up to a certain level, since money is finite), but they care about spending too much energy in the execution.

It is important to notice that we assume the three parameters are dynamic during the execution of an application, when they are calculated for a specific CE. This is quite obvious with the performance and energy, but not with the cost, since a fixed cost of a physical host could be directly mapped to the Virtual Machine that is using it (so, charging you no matter if you are using the machine or not). In the ASCETiC Toolbox the Pricing Modeller implements a dynamic pricing scheme, where the price of a physical host is divided between its VMs and between its applications, thus allows us the PM runtime to optimize it. If the Price had been fixed, the only possibility to optimize the cost would be to implement elasticity (i.e. demand more or less machines to run the application), which we already stated we foresee that will be implemented in Year 3.

In addition, at the moment of selecting which were going to be the metrics selected to be specified as boundaries, we found that mainly two choices were available. We specify global boundaries as metrics for the whole makespan of the workflow to be executed, such as total execution time of the application, total energy spent and total cost in a set of resources. These metrics are clearly oriented to be applied to the whole workflow of an application. On the other hand, we also considered instant boundaries, such as maximum W, maximum

(19)

€/hour and maximum execution time for a CE, that, as its own name indicates, are metrics to be considered at a particular moment in time for a particular machine.

Several reasons made us select instant boundaries on top of global ones. The first one is due to the nature of the ASCETiC PM applications, that depending on the application we may or may not have the complete workflow to make the scheduling plan in advance. This is because applications can need some information in the main algorithm while progressing, which would cause a synchronization point in the master process, thus stopping the workflow generation. So, applying a global boundary to a partial part of the whole workflow won’t make any sense at all.

Apart of the workflow generation issues, another reason is that global boundaries are more interesting when elasticity can be driven from the application. When elasticity comes into the picture, the runtime would be able to ask for more machines to be added to the pool of resources in more parallel regions of the application and decrease that number in more sequential ones. These actions would be related not only to speed up the application, but also to reduce its energy consumption or its cost, according to the selected policy and the boundaries (e.g. add faster machines to speed up the execution, but be careful not to surpass a total energy consumption number). However, it has been also mentioned previously that elasticity is envisioned for the third year of the project, as an inter-layer mechanism.

A final reason is that global boundaries only make sense for ASCETiC PM-like applications (batch oriented) but not for service-like applications, where a service is waiting for requests to be dispatched.

Therefore, our implementation has considered instant boundaries in order to drive the optimization of either: energy, performance or cost, which will be specified by the end user before the execution of the application. It is also worth to mention that this optimization algorithms mixed with the versioning capabilities presented during Year 1 enable interesting options for deciding how to execute an application in a set of resources, thus, not only having different machines to make that optimization, but also different pieces of software implementing the same functionality.

We have also introduced modifications to the PM Plug-in component in order to allow end users to specify in a graphical way, which is going to be the parameter to be optimized and to specify the corresponding boundaries in each case. This information is then included in the OVF that describes the application and will be read by the ASCETiC PM runtime to schedule tasks according to both the selected policy and the specified boundaries.

Persistent workers

A problem that the past ASCETiC PM version had in terms of energy consumption was that the workers where the CE were executed created a new process at the beginning of each task to run the core and destroyed it at the end. Thus, the Just In Time (JIT) compiler did not optimize the Java byte code of

(20)

the CE causing an important performance loss. An envisaged modification on the runtime system deployment to reduce the application execution time and improve its performance was to convert these worker’s eventual processes to processes persistently deployed on the worker nodes. During this second Year, we have implemented this feature that will allow gains in execution time, which in turn are expected to have a direct impact in the energy saving of an application.

The optimizations performed in the code by the JIT compiler will of course be noticed more in applications that are fully programmed using Java (i.e. all the work is done with the source code provided) in contrast to applications that call an external binary to perform calculations, such as an external simulator software, where the JIT compiler cannot introduce optimizations at all.

Object cache

Another operation commonly done in the ASCETiC PM runtime that has an impact on energy consumption is the serialization of objects. When a task needs an object that has been generated in another machine, the runtime can send the object to the machine where the object is needed, by first serializing it to disk, then sending it to the new machine and then de-serializing it.

In order to avoid these serializations and transfers of objects between machines, we have implemented an intermediate object cache for the master process and each worker in the computation. Every time an object is cached, there won’t be a need of transferring it from one machine to another through serialization, therefore the PM runtime will decrease the energy consumption and the time taken associated to these processes. This cache is effectively implemented as similar cache mechanisms for distributed environments. This means that data consistency is maintained between the distributed copies of a single object, invalidating and updating the copies when needed.

2.2.1.4Evaluation

The PM Runtime new capabilities on self-adaptation are evaluated using the GPF use case (a real application). Therefore and in order to avoid repetitions between deliverables, we encourage the reader to read D6.3.2: “GreenPrefab Use Case Prototype – version 2” to know more about the testing on such capabilities.

However, we would like to include further evaluations on the rest of the improvements made to the Runtime. These improvements are the Persistent Workers capability and the Object Cache and they are the features we evaluate along this section.

In order to carry this evaluation, we have designed a synthetic benchmark that is run both with the previous implementation of the runtime (using the Grid Application Toolkit (GAT)[7] and with the new one, which uses the Java Non-blocking I/O library (NIO) [8]. The benchmark can be configured to run different number of tasks with files and object transfers between the master and the workers during the execution, while the size of the cache is fixed. This flexibility

(21)

allows us to evaluate the difference between GAT and NIO implementations performance. We evaluate three scenarios:

 Task generation: generate n tasks that perform a 1s wait.

 File transfer: generate n tasks that have a 10 MB file as an input parameter (without sharing files between tasks).

 Object transfer: generate n tasks that have a 10 MB object as an input parameter (without sharing files between tasks).

In all the cases there is no computation at all in the tasks, so our tests show purely runtime overhead. That’s the reason why we can see in the plots that adding more workers does not contribute deeply in speeding up the benchmark execution.

One could raise the fair question that it is not always true that decreasing the execution time of an application implicitly means that energy is reduced. We can see proof of this in related work analysing the energy consumption on the different functional units and banks of the machine architecture (i.e. energy spent in the registry or memory banks, in the processor, etc.). However, if we analyse the energy spent in cloud environments, the idle time in machines does a big contribution to the overall energy spent. Thus, in this particular case, we can correctly assume that if we decrease the application execution time, we are contributing the total energy consumption.

Figure 2: GAT vs. NIO, task generation case

In Figure 2 we see that, in all tested cases (from 1 to 100 tasks), NIO implementation outperforms the GAT one for the Task generation case of the benchmark. Only in the case of having one task and 4 workers (1+4 case), the time is similar. In the best case, the reduction of the PM Runtime overhead has been by a factor of 7.

(22)

Figure 3: GAT vs. NIO, file transfer case

In Figure 3, we see that NIO again performs much faster than GAT when the data passed between the master and the different workers are files (from 10 to 500 tasks have been tested, using again different worker configurations). And the same happens when the data are objects, as shown in Figure 4. Here the best improvement factors are reducing between 2 and 3 times the total execution time.

Figure 4: GAT vs. NIO, object generation case

Thus, we can conclude from these experiments that with the NIO version, which implements the Persistent Workers capability and the Object Cache, the PM

(23)

Runtime contributes to decrease the execution time of the application, so decreasing accordingly its energy consumption.

2.2.1.5Future Contributions

For the final year of the ASCETiC project, we will have the objective of inter-layer self-adaptation, thus the different policies applied at different levels will have agree in order to avoid chasing contradictory objectives. A clear mechanism that will come into place derived from inter-layer communication is elasticity driven from the application, which will make our optimization policies richer. This is because the ASCETiC PM runtime will be able to request new machines or reduce their number, depending on the objective to chase specified by the user, leading to a possible consolidation of tasks in the same virtual machine, or the opposite.

We also envision the implementation of a locality-aware policy to avoid data transfers with the objective of saving energy. This policy will try to avoid the energy spent with the network and/or the storage when transferring data from one worker to another and will also consider data already available in shared disk spaces (pre-fetched data transfers) again to avoid transfers during the execution. A clear pre-requisite for us to accomplish such an objective is that we are able to account for the energy spent by the network and/or disks when handling data.

Finally, since the elasticity capabilities will make much more interesting to apply global boundaries to the scheduling of the workflow, we will also study alternatives to implement global boundaries for applications that do not generate the whole workflow in advance, like, for instance considering historical data of past executions to predict a particular metric for the whole workflow execution.

2.2.1.6Conclusions

The ASCETiC PM is a Cloud-unaware programming model that eases the way applications are constructed and deployed by using the Eclipse PM plug-in. Applications are first developed using sequential Java programming and later are deployed to the Cloud using the ASCETiC PaaS framework capabilities. It is a general-purpose programming model that hides the details of directly using the Cloud to end users and that now includes energy-awareness in its runtime, offering a complete solution for end users to program energy-aware applications.

The energy-aware policies implemented in this second year follow the objective of optimizing at application level the energy, performance or cost for the applications, but considering certain boundaries for the optimization. Besides, the persistence of workers and the object cache that have been implemented allow the PM runtime to try to save additional amounts of energy when running an application. These savings come from the Java JIT compiler optimizations and the saving of object serializations respectively.

2.2.2 SaaS KPI Modelling and Visualisation Tools

In contrast to the ASCETiC PM, which proposes a cloud-unaware programming model, in other situations, the SaaS development team prefers to remain aware

(24)

of the underlying Cloud infrastructures composed of various digital resources such as VM, open containers or block storage. Subsequently, they will be able to adapt the architecture of their SaaS application to better exploit these digital resources. The contribution presented by the SaaS KPI Modelling and Visualisation Tools propose a suite of tools to help a SaaS development team and SaaS provider in exploring various Cloud deployment configuration alternatives for a SaaS application. Based on the result of this exploration, the SaaS provider will learn realistic KPI thresholds to use on different metrics during production time. In cases where these thresholds are not deemed “good enough”, the SaaS development team will then have the capacity to use the tool suite to identify components or application features to improve or make optional.

In other words, SaaS KPI Modelling and visualisation tools are a suite of tools provided to SaaS development teams to facilitate their work of understanding the runtime quality properties of Cloud application they develop. This knowledge can then be used to establish realistic trade-off measures and to identify where it may be worth refactoring the given SaaS application to include variability points on which self-adaptation at the level of IaaS, PaaS and SaaS become possible.

Modelling tools are provided as projects of different Eclipse plugins:

 jUCMNav: an Eclipse plugin for Goal oriented Requirement modelling  Papyrus: an Eclipse plugin for UML Modelling

 Acceleo: an Eclipse plugin for performing model to text generation The Visualisation tool is provided as a web application and it requires access to the ASCETiC Application Monitor service provided at the PaaS layer.

2.2.2.1Motivation

Developing software applications or services for the Cloud remains a fairly new concept. Although one might be tempted to believe that it does not affect much how application developers work, it is far from the truth. At first sight, developing SaaS application or services may bear resemblance with traditional web-application. On the other hand, the versatility of Cloud providers going from a private Cloud at a SaaS developing company or federated private Clouds between partner companies to community Clouds generates many alternatives of potential deployment configurations for a SaaS provider.

Each deployment alternatives will come with its advantages and disadvantages. For instance, deploying a complete SaaS application on one’s private Cloud will enable tweaking the underlying hardware and virtualisation layer to achieve the best time performance for the given SaaS. However, this added performance cost at a significant cost since SaaS provider must acquire hardware and also provision the human resource needed to maintain that hardware and tweak the virtualisation layer. In addition, the SaaS provider will also suffer the cost induce by the energy consumed by the SaaS application. At the other end of the spectrum, a SaaS application can be fully operated at a single community Cloud provider such as Amazon, Google, Microsoft or others. In such cases, there is a certain loss of control for the SaaS provider who may not know if for instance, the throughput between two SaaS components deployed on different VMs will achieve or maintain the desired level. Thus forcing a SaaS application to rely on content delivery network services from the

(25)

selected Cloud providers. In the end, the SaaS provider is then often guided to use Cloud provider specific features that ultimately creates a Cloud provider lock-in for the SaaS application. Furthermore, different community Cloud providers propose different performance and cost models for computation, storage or network services. Deploying a SaaS application at a single community Cloud provider may not yield the best option in terms of cost. On the other hand, deploying various components of SaaS application on different private and community Clouds could degrade certain performance.

Therefore, the many potential deployment alternatives for a SaaS application can become overwhelming for a SaaS development team. On the other hand, considering all important runtime quality properties at development time increases the chance of success for the resulting SaaS application. In particular, the SaaS development team must clearly identify how to measure dynamic aspects of a SaaS application such as time performance and cost including how energy consumption could affect the cost when running a part of a SaaS application in one’s private Cloud. In the future, it is realistic to imagine that community Clouds may also develop pricing models that include energy aspects.

To facilitate the work of a SaaS development team for exploring objectively how its SaaS application behaves in terms of time performance, cost and energy consumption for various deployment configuration alternatives, the following challenges should be addressed:

 (Challenge 1) Develop generic requirement patterns on quality properties to consider and how to evaluate them in a quantifiable way (based on metrics and measurements)

 (Challenge 2) Facilitate the work of SaaS development team to express how measurements of various metrics must be performed for the SaaS application and with what workloads (representative of target customer groups)

 (Challenge 3) Facilitate the work of SaaS development team to express the various deployment alternatives considered and for which measurements of time, cost and energy should be obtained (on Cloud testbeds where the ASCETiC toolbox at the IaaS and PaaS layers is installed)

 (Challenge 4) Provide an intuitive visual interface for SaaS development team to interpret easily how various deployment alternatives performed on the selected metrics

2.2.2.2Related Work

Overall, the SaaS KPI and visualisation tools propose an operational approach to perform a particular assessment of the architecture trade-off analysis method (ATAM) [9] focused on runtime quality characteristics of various deployment alternatives of a SaaS application to be operated in Cloud infrastructures. However, unlike traditional assessment with ATAM or other approaches that propose to quantify non-functional requirements [11] that attempt to set values at time of requirement and architecture analysis before the existence of any executable system, the application of ATAM proposed assumes that an executable application exists. For instance, a legacy application needs to be migrated to operate in the Cloud or a SaaS application is developed incrementally and earlier iterations have produced

(26)

portion of the SaaS application that can be studied to better understand its runtime behaviour on time, cost and energy. Both scenarios, migration of a legacy application and incremental development of a SaaS application are common place therefore we believe that this application of ATAM to objectively assess deployment alternatives in the Cloud will cover a significant percentage of Cloud application development projects.

In [12][13], past research efforts in the context of ASCETiC already explored how to augment UML first to specify energy goals and related questions (related to Challenge 1) and second to define what to measure and how to measure it i.e., with what representative workloads (Challenge 2). Furthermore, in [14], a BIRT prototype to visualise measurement results (in relation to Challenge 4) is illustrated.

Although the augmented UML is appropriate to solve Challenge 2 on specifying what to measure and how, the current approach for specifying goals and questions showed shortcomings. In particular, it did not allow to express easily relationships between goals on different metrics. Second, hiding goals and questions inside a UML stereotype makes it hard for SaaS development team to remember what the measurement goals are. Finally, developing more complex goal refinement strategies with potentially different level of refinements to identify metrics of interest and making available a repository of generic goal refinement patterns easily displayable to and understandable by SaaS development team requires a dedicated approach. In particular, UML modelling, even with its current SysML modelling with the notion of Requirement is not appropriate. In the last two decades, a large body of research studied how to express and visualise models of system goals, requirements and their relationships [16] [17] [18]. Effort in [[18], subsequently derived into the ITU-T standard Z.151 [20] and led to the development of the open source tool jUCMNav [19]. Consequently, this tool seemed adequate as a starting point to express goal refinement patterns relevant to the ASCETiC context.

The BIRT prototype also reveals a weak tentative with little room for dynamic interaction from the SaaS development team and the data collected. In particular, an important missing feature in BIRT reporting is the ability to filter results and regenerate results in a reactive manner. Furthermore, it is also important to explore different graphical approaches and widgets to facilitate the filtering of results to identify which deployment alternatives better perform on which metrics. Thus, let the user visually understand the trade-offs between time, energy and operational cost aspects. Consequently, a customer web application based on JavaScript and existing widget libraries seemed the most appropriate.

Related to the Challenge 3 on facilitating the specification on various deployment alternatives, European research effort has produced CAML and CloudML, respectively under the ARTIST and PaaSage FP7 projects. However, it is worth noting that these projects have a different objective than the one targeted in ASCETiC. In particular, using CAML or CloudML, a SaaS development team has the power to model graphically every aspect of how to deploy their SaaS application, using a full-blown model-driven approach. On the other hand, the ASCETiC vision is rather that devops who usually specify

(27)

how SaaS application is to be deployed usually prefer textual representation over graphical representation. Consequently, we rely on devops to provide various deployment scripts using older textual scripting technologies such Chef. The role of the deployment models in ASCETiC are rather to express where various Chef scripts need to be executed to enable the various targeted deployment alternatives. On the other hand, the ASCETiC deployment model, rely on these Chef scripts to execute in the correct order, to open the appropriate communication port, etc. to end with a properly functioning SaaS application deployment. For parameters dependent of a given deployment alternative, for example, in particular case, a given port should be used instead of the standard one then the deployment model, which will explicitly refer to Chef server URL may also add these parameters at invocation time.

2.2.2.3Scientific Contributions

In Year 2 of ASCETiC, a noteworthy contributions is proposed to address Challenge 4 on intuitive interface to identify deployment configuration to achieve feasible quantitative non-functional requirements on time performance, energy and cost. On-going work to continue in Year-3 addresses Challenge 1 on Generic SaaS Goals and Requirements patterns.

Given the on-going nature of the work to address Challenge 1, we will not present here an exhaustive catalogue of goals and requirement patterns on various non-functional aspects but rather highlight our general design approach with a focus on Cloud computing. Given that the approach followed in Year-1 was based, it is quite natural to consider a goal-oriented requirements engineering (GORE) framework to deal with such NFR in a larger perspective, since it provides all the tools to capture NFR as well as their inter-relationship like contributions or conflicts. In the scope of this work we considered GRL and the related Open Source jUCMNav tool [19].

Figure 5: High Level Structure of NFR and some relationships

In order to identify the key NFR, we must also consider the concerned stakeholders because subsequent reasoning on NFR can be done for different sets of stakeholders depending on the kind of deployment considered. From a SaaS application provider's point of view, response time and price are the most common aspect on which metrics are used to evaluate a SaaS applications, for these are the ones that will directly impact end users. From a service host's point of view, the overall cost is the most obvious parameter to minimize. This cost minimization is subject to multiple constraints, which are affected by NFR.

(28)

(29)

that the required quality of service is achieved consistently by defining measurements.

We rely here on the large amount of work already carried out by several European projects [21]. Figure 5 show some of them such as availability, performance (response time, resource and also energy), security/privacy of data, location/access/portability of data, exit strategy, etc.

A distinctive feature of our work is of course the inclusion of energy NFR, which also relate to "Green SLA" that are being considered in the efficient use of resources and particularly energy by services and applications [8]. At this high-level, we can state some generic conflict, e.g. redundancy will increase energy consumption, security will also require more resources (CPU, transfer volume) to cope with encryption for example and thus increase energy demand. However, other contributions might depend on the application, e.g. a good data replication strategy that can provide a positive energy balance for data intensive applications. In the end, the assessment will need to be evaluated in the scope of a specific application which be designed or deployed indifferent way so triggering the need to explore a design space with the energy efficiency becoming a parameter of the total cost function.

Our approach to explore the design space is to keep the SaaS application designer in control (1) by providing him specific visualisation tool detailed in the next section and which allow him to compare the behaviour of different possible design corresponding to different deployment configuration alternatives and (2) by providing decision support taking the form of a measurable goal graph. This means that requirements need to have an associate KPI (identified from our KPI profile [22]) and that refinement/contribution structure is decorated explicitly such as the structure is depicted in Figure 6 where metrics related to a goal of minimising the operating cost for a data centre hosting the SaaS application. This declared structure can then later be used by the visualisation tool to guide the SaaS application designer in exploring measurement results and determine what realistic thresholds to use for different metrics and how to formulate a utility function for evaluating each given quality criteria or cost aspect separately. Intuitive Interface to quantify non-functional requirements

The first and simplest visualisation uses a simple chart to compare a given metric between multiple measurement sets. A measurement set is a set of measures taken in given conditions. For example, a measurement set may contain data about the response time, CPU, RAM and energy usage of one virtual machine (VM) during one particular test (a search in a product catalogue for example), while another measurement set may have taken place for same search but where the underlying VM has different CPU frequency, RAM and disk size, which conceptually corresponds to a different deployment configuration alternative of the SaaS application. These tests are repeated multiple times and measures are aggregated to get reasonable estimates.

(30)

Figure 7: CPU comparison between two nodes in the same test run

Then, these measures can be compared on a graph. For example the response time can easily be displayed using a bar chart, one bar for each measurement set and the CPU usage will be displayed using a line chart, where the CPU usage can be visualised on the duration of the test. Figure 7 illustrates a visualisation comparing CPU history on two nodes of the same experiment.

This kind of graphs allows developers to:

 Identify potential peaks or long CPU intensive operations that could be investigated further and optimised locally

 Compare two SaaS application instances corresponding to two different deployment configuration alternative to see the actual effects of a change on quality criteria of interest or operational cost.

This visualisation is focused on comparing one specific aspect between multiple versions of a service or application. The second visualisation takes another point of view and visualises tests and versions according to several of their characteristics.

The second view approaches the data set from the opposite side. Instead of taking different tests and versions and showing how they compare on one specific aspects, this view takes multiple aspects and for each of them, displays how the various measurement sets are distributed, then it allows to filter out the unwanted parts of the distributions and see which measurements sets match the filter.

Figure 8 illustrates this concept more clearly: three bar graphs display the distributions of the measurements sets over three different aspects: Energy consumption, operational Cost and Time performance. On each chart, the x axis represents an arbitrary measure for the given aspect and the y axis represents the number of measurements sets. In the example below assumes that a utility function is provided to aggregate one or several metrics on a given aspect. The range of the three utility functions a range from 0-70 for energy behaviour and from 0-100 for operational cost and time performance.

(31)

Figure 8: Filtering on aspects.

Figure 8 also shows the filtering mechanism. Using sliders on each graph, the user can easily select the parts of each chart that he wants to include in the filter. In this example, there is no restriction on the energy measures, there is a filter from 0 to 30 on the utility function related to cost and from 0 to 40 on the utility function related to time performance of each workloads exercised on each deployment configuration alternative. The user can immediately see the impact of the filters on how the results are distributed on a scatter plot for two of the aspects, in Figure 9, energy behaviour effectiveness and time performance where their respective utility function remains in the filtered range shown in, 0-70 for energy utility function and 0-40 for time performance utility function. In particular, each dot on the graph represent the scores of a give workload script exercised on a given deployment configuration alternative of a SaaS application (where each alternative is assigned a different colour except for grey, which is reserved to show filtered out points).

Figure 9: Energy vs. Time

Figure 9 shows the result of the filtering on cost and time on the energy versus time plot. We can clearly see that the time dimension (y axis) has been capped at a given level: all the blue points are under the level selected by the filter. We can also see however that not all the points under that line are blue. On the left side for example, a few dots are grey, even though there is no filter on the energy (x axis) aspect. This is an effect of the filter on the cost. The grey dots on the left side of the graph (low energy) had a higher cost, and they were excluded by the filter on the cost aspect. Figure 9 only shows results of exercising different workloads on a single deployment configuration alternative of a SaaS application. If we assume to be still in the development stage, the given graph results would help the SaaS development team observe the following: many points are grey out hence the SaaS development team would observe that the tested deployment configuration alternative for the given filtered ranges on time performance and energy behaviour will likely yield a significant amount of SLA violations. Thus, the SaaS development team would