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

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!

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.

1. Hui Li, Giuliano Casale, Tariq Ellahi. SLA-Driven Planning and Optimization of Enterprise Applications. 1st joint ACM WOSP/SIPEW Intl. Conference on Performance Engineering, San Jose, CA USA, Jan 2010. With an acceptance rate < 25%, this is a premier forum in the performance community.
2. Hui Li and Daniel Scheibli. On Cost Modeling of Hosted OLTP Applications. 1st Intl. Conference on Cloud Computing (CloudComp), Munich, Oct 2009.

Congratulations to all involved!

vfhea42rsm