What we call Cloud computing today has evolved over many years. It had other names before and many technologies are involved in it. Virtualization, utility computing, and grid technologies are among the most representative.

Cloud offerings can be classified according to the resources they offer ‘as a Service’ (XaaS): Infrastructure as a Service (IaaS) that allows the allocation of virtual machines and storage capacity; Platform as a Service (PaaS) providing users with remote software platforms to run their services; and Software as a Service (SaaS) where applications are moved to the Internet and accessed through web interfaces.

Cloud frameworks on the other hand can be seen as the software environments in which Cloud services can be deployed. Most of the frameworks have automatic and elastic management solutions included: they control the life cycle, placement and Service Level Agreements (SLAs) of a service.

Different frameworks have arisen in the recent past, including commercial proprietary and open frameworks like those developed in the European Commission funded Framework Programme 7 Projects RESERVOIR and SLA@SOI. They consist of similar modules and layers but have different basic architectures. They can be messaging based or client/server, and have a focus on IaaS or SLA management. The different foci leads to different architectures. SLA@SOI targets SLA-driven management, and monitoring the life-cycle of services such as software and infrastructure services. It can also be applied to human-based services. RESERVOIR concentrates on federated clouds, and focuses on the management, interoperability and optimisation within such topologies.

Despite these differences, however, Cloud frameworks typically include a layer to deploy virtual workloads on infrastructure. Allowing frameworks interoperate also enables the use of each other’s unique abilities and functionalities. For example provisioned services could be moved to the Cloud framework which would best fit their needs and their characteristics.

The need to interoperate helps fuel the demand for standards. Only if the frameworks support certain standardized interfaces, can interoperability be achieved. The accompanying paper tries to show the overall setup and ideas behind two Cloud frameworks and includes the description of an upcoming Cloud standard. An architecture which combines all three aspects is also proposed.

Technical Report: Using Cloud Standards for Interoperability of Cloud Frameworks

Design-time prediction, as part of the SLA@SOI framework, aims to estimate performance and reliability indicators of a service infrastructure. This includes estimates of a service’s

• completion time,
• throughput,
• resource utilization, and
• reliability.

The approach provided as part of the prediction architecture is model-based: different models are employed to capture an entire system, i.e. structural aspects such as its service components and allocation to (virtual) machines and behavioral aspects such as usage of services.

What is modeled?

Different roles contribute information to the set of models used to predict a service’s performance. This situation is depicted in Figure 1.

Figure 1: QoS Model and involved roles

• Software providers create abstract models of their service components.  These include information about service interfaces and an abstract behavioral description of how the components use the available hardware and software resources (Service Component Model)
• Infrastructure providers specify the execution environment on an abstract level. Important performance-related information includes processing rates etc. (Infrastructure Model)
• Service customers indicate the intended service usage (e.g., the maximal number of requests per minute). From this information, a model capturing the system usage profile (Usage Model) can be derived.
• Service Providers integrate the separate models and provide the prediction service with an initial allocation of components to nodes (Allocation Model)

And how does the actual prediction work?

Design time prediction is based on the modeled service / usage properties only, i.e. it can be performed before the service is actually deployed and running. The various models are transformed into a format that can be processed by the Palladio Component Model (PCM) framework [1]. This comprehensive framework allows for generation of different analysis models such as stochastic regular expressions or a queuing network, which in turn provide capabilities to derive the desired performance metrics.

What’s the use of QoS prediction in SLA@SOI?

Both the provider and the customer of a service will benefit from the integration of design-time prediction into the SLA management framework.

• Transparency: A priori simulation based on multiple scenarios (allocation / infrastructure / usage) allows the service provider to offer clear and concise statements about the service parameters in an SLA. This helps the customer during the selection process and promotes the negotiation process.
• Flexibility: Multi-round negotiation of an SLA can be assisted by iteratively calling the prediction service with modified inputs. This applies in particular to different usage scenarios provided by the service customer.
• Efficiency: Based on the simulated resource demands, infrastructures can be dimensioned efficiently balancing costs and QoS levels.
• Dependability: Careful modeling of the architecture under study leads to high-quality predictions of its performance and reliability.

Martin Küster, FZI Forschungszentrum Informatik, Karlsruhe

[1] Becker, Koziolek, Reussner: The Palladio component model for model-driven performance prediction. Journal of Systems and Software Vol. 82 (1): 3-22 (2009)

To provide effective monitoring support when such changes happen it is necessary to be able not only to check whether the monitorability of the required SLA terms and conditions is affected by the changes but also to modify the deployed monitoring infrastructure in order to ensure the continuous execution of the required runtime checks. These capabilities, however, are not offered by existing monitoring environments and approaches. To address this gap, SLA@SOI is developing a novel SLA monitoring framework, called “SLA Management for Monitoring” (SLAM4M). A key characteristic of this framework is the separation of the actual service monitoring from the assessment of SLA monitorability, and the dynamic set up of the monitoring resources (i.e., event captors and monitors) for checking an SLA.

SLA Management for Monitoring: Overview of the new architecture

A key characteristic of the approach underpinning the design of SLAM4M is the distinction between two key layers in service provision, namely the SLA management and service management layers as illustrated in Figure 1. The SLA management layer is concerned with SLA management activities (e.g. SLA specification, negotiation, modification) and the service management layer is concerned with the software stack required for making a service manageable according to an SLA. From a monitoring perspective, the SLA management layer incorporates the mechanisms required for performing the SLA monitorability checks and the dynamic set up of monitoring infrastructures that can enable the monitoring of an SLA whilst the service management layer incorporates the Event Captors and Monitors required for service event capturing and performing the actual SLA checks, respectively. Given this distinction, SLAM4M belongs to the SLA Management layer, as shown in Figure 1.

Fig 1: Scenarios for dynamic setup of monitoring infrastructures

Figure 1 shows the two scenarios for dynamic service monitoring setup in SLAM4M. In the first scenario (see Figure 1a), the managed service is provided with both Event Captor(s) and a local Monitor and has, therefore, both event reporting and SLA checking capabilities. Thus, when it receives an SLA, SLAM4M checks if each guarantee term in it can be monitored locally, according to the capabilities exposed by the Event Captor and the Monitor. In particular, in order for a Guarantee Term to be locally monitored, the Event Captor should be able to provide the required events, while the Monitor should support the language used for expressing the Guarantee Term.

The second scenario (see Figure 1b) applies to the following two cases:

1. The Event captor provides the events required for monitoring a Guarantee Term, but the Monitor does not support the Guarantee Term language; and
2. the managed service has only an Event Captor but no associated local Monitor.

In the second scenario, SLAM4M first assesses if the required events are available from the local event captor of the service and then tries to identify an external monitor that can support the Guarantee Term language. This identification takes place through a monitor registry that is accessible to SLAM4M and, if an appropriate external monitor can be found, SLAM4M submits the guarantee term to the external monitor and instructs the event captor of the service to provide events to this monitor. It should be noted that the external monitor may be available at some URI on the network and, therefore, an engagement protocol and an event communication infrastructure are required for establishing and realizing the communication of events between the service event captor and the external monitor.

In the prototype implementation of SLAM4M, we use a “publish/subscribe” event communication infrastructure designated as “Event Bus” in Figure 1b. More specifically, after locating a Monitor, SLAM4M gets from it a token designating an event channel of interest and uses this token to subscribe the monitor to the Event Bus. The same token is passed to the Event Captor to be used when it publishes events to the bus so that these events can be forwarded to the appropriate monitor.

For more information on our monitoring architecture, please see the accompanying SLA@SOI Technical Article. Additionally, further details including a discussion of the implementation of SLAM4M and some initial experiences are being published in “Dynamic Set Up of Monitoring Infrastructures for Service Based Systems”, at the track on Service Oriented Architectures and Programming at the 25th Annual ACM Symposium on Applied Computing to be held in March 2010.

George Spanoudakis, School of Informatics, City University London

The software illustrated in this video is currently being modified to accommodate the requirements of the use cases, and we are working to open-source it by Summer 2010. Please stay tuned for further updates!

In SLA@SOI we have identified the following aspects of business that need to be addressed within SLAs:

Functional description: The offered service must be detailed in terms of the features and functionality supported and available to customers.

Business model supported: All the information referring to the selling process must be defined and described in detail, to avoid ambiguity for the customer. The business model description should detail:

• Offer types associated with the Quality of Service supported
• Pricing model
• Billing and payment constraints
• Modification and alteration of prices  if applicable
• Restrictions and constraints

Penalties: Detailed specifications about the penalties incurred when problems arise in the consumption of the service. This information is attached to the guarantee terms definitions that explain in detail how the different agreed terms are used.

Termination clauses: The termination clauses have to be automated and they have to accommodate both parties in the contract. The termination of the SLA can be triggered by certain customer aspects as well as by certain service provider constraints.

Service information events and reports: It must be possible for the final customer to select the kind of information that they wish to obtain automatically. This information is defined in terms of events monitored as well as reports associated with the customer’s service. For instance a customer that uses a storage service may want to know how large their storage consumption is per day. These Key Performance Indicators (KPIs) may not be related to the guarantee terms fulfilled by the SLA.

Support mechanism and contact details: It must be possible to specify the kind of support offered to the customer should they have a problem or inquiry. The support information provided should include timetable details as well as details of the different support channels available.

Disaster recovery and data security in IT Systems: It must be possible to define Backup/Restore policies in order to guarantee the persistence of information, if the service offered to the customer manages and stores data. Also it must be possible to define the security mechanisms that are employed by the service.

Changes to terms in the service: The process to update the service conditions or characteristics must also be considered. It must also be possible to define the mechanism used to inform the customer about such changes.

Customer/Provider requirements and constraints: In many cases, it is necessary for the customers or providers to express some requirements in terms of limits or constraints in the service consumption. Usually these aspects are related to legal constraints to be followed by the customers or providers of one specific country, because they are imposed by the relevant Regulatory Authority. Example constraints include:

• Personal data storage cannot to be stored outside the country
• Maximum prices and/or quality shall apply
• Restrictions in sharing of personal data with third parties associated with the service provider
• The prohibition of delivery advertisement
• Personal data usage restrictions for specific tasks (e.g. data mining)

As we can see, the variety and complexity of business  concerns is both broad and deep. However, we have found that each specific business has their own kind of restrictions and bounds.

In the SLA@SOI project, one of our main aims is to create a business framework that supports the realities of the business world. In our Business Management focus area we are actively researching these aspects, building a strong foundation to support a wide range of grounded, industry-driven use-cases.

Juan Lambea Rueda, Telefónica Investigación y Desarrollo

The full details are presented in an accompanying technical paper,  Challenges in SLA Translation, but the overall framework is illustrated here in Figure 1.

Figure 1: Observables (metrics) and configurables (parameters) in SOA layers, with different types of translations.

The framework distinguishes four main translation types:

• C2C (Configuration to Configuration): this type of translation mostly relates to the dependencies within a layer or between layers. Such dependency graphs are useful in configuration management and problem diagnosis.
• M2C (Metric to Configuration): this type of translation translates higher-level objectives to lower-level system parameters. It can also be referred as “top-down” translation or SLA decomposition. It is useful for sizing and capacity planning, mostly at design time.
• C2M (Configuration to Metric): this type of translation predicts higher-level objectives from lower-level system parameters. It can also be referred as “bottom-up” translation or performance prediction. It is useful both what-if analysis at design time and predictive management at run time.
• M2M (Metric to Metric): this type of translation correlates a high-level metric with lower-level metrics. The translation can go both directions, namely decomposition or prediction, depending on the usage scenario. It is useful for forecasting and problem diagnosis at run time.

Additionally, we have also identified and described the fundamental research challenges that need to be addressed to turn the vision of holistic and transparent SLA translation into reality. These research challenges are

• Realistic workloads and usage patterns
• Tradeoff-analysis for scalable approaches
• Innovation and integration of methodologies
• Model integration and transformation
• The definition of layers and layer interfaces
• Business values and reference benchmarks

To found out more about this proposed conceptual framework and these research challenges, please see the accompanying technical paper, Challenges in SLA Translation.

Hui Li, SAP Research

• D.A1a Framework Architecture
• D.A2a Business SLA Management
• D.A3a SLA-aware Service Management
• D.A4a SLA-Aware Infrastructure Management
• D.A6a Predictable Service Engineering Methodology
• D.B2a Adhoc Demonstrator
• D.B3a ERP Hosting
• D.B4a Use Case Specification Enterprise IT
• D.B5a Service Aggregator
• D.B6a Use Case Specification eGovernment
• D.B7a Use Case Specification Financial Grids
• D.B8c Annual Review of External Collaborations

You can find links to all of our  deliverables under Deliverables,  whilst pointers to relevant deliverables have been added to each Focus Area page.

As always, we encourage you to contact us if you would like to connect with any of the research described.