Overview

Depending on the application’s software stack and cloud deployment, various elasticity relationships can exist at different software layers between components or composite components. Thus, we must be able to analyze multiple application types, from simple applications, to complex application running multiple components in virtual containers distributed among virtual machines hosted in different clouds.

Usually, elasticity of applications is driven by quality, cost, resource usage, or a combination of the three. Moreover, application owners usually view their applications from a perspective driven by cost, quality, or both. As different elasticity relationships can exist between different perspectives, we classify relationships after the two fundamental business dimensions, Cost and Quality, and the three elasticity dimensions, Quality, Cost, and Resources . The relationship category is given by the type of monitoring information used to determine it, different categories being potentially of interest to different stakeholders. Application developers and elasticity controllers might be interested in Quality dependency or Resource quality relationships, which they can use to eliminate bottlenecks or reduce resource underutilization. An application owner might be interested in cost-related relationships, such as Cost effectiveness, Benefit-Cost dependency, or Cost composition. Various parameters of elasticity relationships are interpreted by rSYBL elasticity controller (DMM core), ensuring better control decisions.

Table 1: Relationship types

Category	Relationship	Interested stakeholder	Usefulness
Quality dependency	Quality→Quality	Developer, Controller	Indicates potential quality/performance bottlenecks
Benefit-Cost	Quality→Cost	Owner, Developer, Controller	Indicates potential resource bottlenecks
Resource quality	Quality→Resource	Owner, Developer	Describes expected quality/performance when using certain resources
Cost effectiveness	Cost→Quality	Owner, Developer	Describes expected quality/performance under certain cost scheme
Cost composition	Cost→Cost	Owner, Developer	Describes the cost elements contributing to overall application's cost, indicating potential cost hot spots
Cost utility	Cost→Resource	Owner, Developer	Indicates potential resource bottlenecks under certain cost schemes

 

Elasticity of cloud applications is driven by elasticity requirements, which specify boundaries over the application’s metrics. To fulfill these requirements, elastic applications change their structure and used virtual resources at run-time through reconfiguration actions. Due to this reconfiguration, we should not determine relationships based on absolute monitored values, as such relationships might not hold after a reconfiguration. Instead, we determine relationships based on the application’s behavior with respect to its elasticity boundaries, which, by abstracting from the absolute monitored values, can be used to describe the application behavior under different configurations. Thus, based on the previous model and the elasticity boundary concept, we define an elasticity relationship, as follows: An Elasticity relationship between one elastic element and a set of elements describes the change in the behavior of the first element w.r.t. its elasticity boundaries, triggered by a change in the behavior of the other elements.

Elasticity Relationships Analysis Service

Elasticity analysis is based on monitored information. Thus, to analyze elasticity relationships systems, first the system must be monitored. Using the MELA-DataService, the monitored data collected from the system must be structured and enriched according to needs. To reduce the analysis space, only the metrics important for describing the system behavior should be specified through metric composition rules submitted to MELA-DataService.

Using submitted system requirements, the MELA-Elasticity Analysis Service evaluates the application’s elasticity space, recording for all metrics collected by the MELA-Data Service, their “elasticity boundaries”, i.e. their maximum and minimum encountered values while the requirements where fulfilled. MELA- Elasticity Analysis Service also provides the possibility of visualizing and programmatically retrieving the historical monitored data of each application component, with their determined boundaries.

Elasticity Relationships Analysis Service RESTful API

 

Table 9: Elasticity Relationships Analysis Service API

Method Name	Type	Input Type	Output Type	Description
/{serviceID}/structure/json	GET		application/json	Returns the application structure in JSON
/{serviceID}/requirements	POST	application/xml		Used to submit the application requirement, used in elasticity analysis.
/{serviceID}/xml/ elasticitydependencies	GET		application/xml	Computes and returns the elasticity dependencies between all metrics collected at all levels for the elastic application.
/{serviceID}/json/ elasticitydependencies	GET		application/json	Same as above but returns in JSON format.
/{serviceID}/csv/ elasticitydependencies	GET		text/csv	Same as above but returns in CSV format.
/{serviceID}/json/time/ elasticitydependencies/ {startTime}/{endTime}	GET		application/json	Computes the dependencies using a subset of the monitoring data between specified start and end timestamps.
/{serviceID}/csv/time/ elasticitydependencies/ {startTime}/{endTime}	GET		text/csv	Same as above but returns in CSV format.
/{serviceID}/xml/ elasticitymetrics/ elasticitydependencies	GET		application/xml	Computes the elasticity dependencies only between the metrics which have requirements set on them.
/{serviceID}/json /elasticitymetrics/ elasticitydependencies	GET		application/json	Same as above but returns in JSON format.
/{serviceID}/csv/ elasticitymetrics/ elasticitydependencies	GET		text/csv	Same as above but returns in CSV format.