Because of the large number of different types of service level agreements (SLAs), computing resource markets face the challenge of low market liquidity. The authors therefore suggest restricting the number of different resource types to a small set of standardized computing resources to counteract this problem. Standardized computing resources are defined through SLA templates. SLA templates specify the structure of an SLA, the service attributes, the names of the service attributes, and the service attribute values. However, since existing approaches working with SLA templates are static so far, these approaches cannot reflect changes in user needs. To address this shortcoming, the chapter presents a novel approach to adaptive SLA matching. This approach adapts SLA templates based on SLA mappings of users. It allows Cloud users to define mappings between a public SLA template, which is available in the Cloud market, and their private SLA templates, which are used for various in-house business processes. Besides showing how public SLA templates are adapted to the demand of Cloud users, the chapter also analyzes the costs and benefits of this approach. Costs are incurred every time a user has to define a new SLA mapping to a public SLA template that has been adapted. In particular, it investigates how the costs differ with respect to the public SLA template adaptation method. The simulation results show that the use of heuristics for adaptation methods allows balancing the costs and benefits of the SLA mapping approach.
TopIntroduction
Non-functional requirements, e.g., application execution time, reliability, and availability, are termed as quality of service (QoS) requirements and are expressed by means of service level agreements (SLAs). In order to facilitate SLA creation and SLA management, SLA templates have been introduced. SLA templates represent popular SLA formats. They comprise elements such as names of trading parties, names of SLA attributes, attribute metrics, and attribute values (Risch, Brandic, & Altmann, 2009). Sellers use SLA templates to describe their supply of resources. Buyers use them to describe their demand for resources.
However, as computing resources are described through different non-standardized attributes, e.g., CPU cores, execution time, inbound bandwidth, outbound bandwidth, and processor type, a large variety of different SLAs exists in the market (Risch & Altmann, 2009). The success of matching offers from sellers and bids from buyers becomes very unlikely, i.e., the market liquidity (the likelihood of matching offers and bids) becomes very low (Risch, Brandic, & Altmann, 2009). The same problem persists in Cloud federations, when different Cloud providers, who also offer and buy resources from each other, stick to their own SLA templates.
Approaches that tackle this plethora of SLA attributes include the use of standardized SLA templates for a specific consumer base (Amazon Elastic Compute Cloud, 2010, Google App Engine, 2010), downloadable predefined provider-specific SLA templates (BRAIN, 2010), and the use of ontologies (Oldham, Verma, Sheth, & Hakimpour, 2006, Dobson & Sanchez-Macian, 2006). These approaches clearly define SLA templates and require users to agree a priori on predefined requirements. In all these approaches, the SLA templates are assumed to be static, i.e., they do not change nor adapt over time due to market conditions.
Consequently, the existing approaches for the specification of SLA templates cannot easily deal with demand changes. Demand changes of users can be caused through different factors. For example, the emergence of multi-core architectures in computing resources required the inclusion of the new attribute “number of cores”, which was not present in an SLA template a couple of years ago.
In this paper, we apply adaptive SLA mapping, a new, semi-automatic approach that can react to changing market conditions (Risch, Brandic, & Altmann, 2009). The adaptive SLA mapping approach adapts public SLA templates, which are currently used in the Cloud market, to the needs of users using the SLA mappings of users. These SLA mappings bridge the differences between existing public SLA templates and the private SLA template, i.e., the SLA template of the user. In our context, private templates do not necessarily imply that they are inaccessible to others, but the word “private” is used to differentiate it from the “public” SLA template of the (public) registry. Therefore, all consumers’ and providers’ templates are called “private”, whereas the registry’s template is called “public”. Since a user cannot easily change the private SLA template due to internal or legal organizational requirements, an SLA mapping is a convenient workaround to integrate an external resource.
Our adaptive SLA mapping approach can use different adaptation methods. The benefit of using an adaptation method is decreased through some cost for the user for defining new SLA mappings. Within this paper, we investigate these costs. In particular, we investigate how public SLA templates can be adapted to the demand of Cloud users and how the costs and benefits differ with respect to the public SLA template adaptation method used.
After introducing a reference adaption method for our analysis, we compare two additional adaptation methods, which differ in the heuristics applied. The heuristics have been introduced in order to find a balance between the benefit of having a public SLA template that is identical to most of the private SLA templates and the cost of creating new SLA mappings and new public SLA templates. As the metrics for assessing the quality of the adaptation method, we use the overall system net utility of all users. The net utility considers the benefit of having the same attributes and attribute names in the public SLA template as in the private SLA template, as well as the cost of defining new SLA attribute mappings.