By Bastian Koller

Flexibility, interoperability or adaptability are just some of the well known buzzwords which come across when dealing with Grid or Cloud computing technologies. Even though these technologies are driven from different (end) user and provider groups, at a certain point they all face similar problems.

One of these is the limitation of existing  implementations with respect to their adaptability and extendibility in terms of the logic and capabilities they provide. Looking at the area of business relationships, a prominent example is the use of Service Level Agreements.

Current Cloud Infrastructure Services such as Amazon S3 or EC2 provide SLA capabilities, but in a very simple way.  They give its users the possibility to choose within a pre-defined set of service description the best fitting, but they provide no flexibility at all with respect to the (re-) definition of terms themselves or on how the agreement is reached. When you want to have a service, you can either take it with the pre-defined terms or leave it. There is no alternative.

Looking at current research activities, the aims are different. With the experience from handling Service Level Agreements within the Grid, it is obvious that this simple negotiation approach is needed, but it is not the “casus sui generis.”

Already heavily discussed, the list of potential ways (and by that protocols) how to reach an agreement is manifold and existing solutions are addressing a variety of them, but never all of them. Additionally the extendibility of these solutions is often not addressed adequately.

Imagine a Service Provider X which has installed an SLA Negotiation framework realizing negotiation protocol A (e.g.  Discrete Offer Protocol).  In parallel there is a potential Customer Y which is interested in X´s services, but has installed a framework, providing exclusively multi-phase SLA negotiation capabilities. By being restricted to their respective technologies (and inheriting their limitations), both entities would not be able to enter a business relationship, covering the delivery and usage of a service from X.

Generally speaking, this is only one case out of many.  Looking at the overall lifecycle of a service, it is not only about SLAs, it’s about Security, Workflow Management and many more aspects that might need this enhanced adaptability.

Lets make a mind experiment:

What may be a solution is the split of logic and base functionalities of components and structure the framework  as loosely coupled components, following the SOA paradigm. Coming back to the SLA Negotiation, an SLA Negotiator component providing capability A is in some parts similarly realized as a SLA Negotiator providing B. So why not taking out this base functionality (call it a fragment) and keep this as a stable basis for all further developments and enhance this with mechanisms to adapt this component during runtime with a logical bit.

So in our case, Service Provider X could adapt its negotiation component with logic B and by that enable interoperability with Customer Y. After successful negotiation, the provider could re-configure its component back to A.

Looking at this, there is a definitive need to perform research with respect to adaptability (and by that flexibility). If a solution like discussed in the mind experiment would exist, business relationship handling could be improved and the establishment of those relationships could be enabled, that were not possible before.

It will be a long way, but at the end, such a solution needs to be there or we won´t be able to benefit at a maximum from all the capabilities of the Cloud.

By Ignacio M. Llorente

Future enterprise data centers will look like private clouds supporting a flexible and agile execution of virtualized services, and combining local with public cloud-based infrastructure to enable highly scalable hosting environments. The key component in these cloud architectures will the cloud management system, also called cloud operating system (OS), being responsible for the secure, efficient and scalable management of the cloud resources. Cloud OS are displacing “traditional” OS, which will be part of the application stack.

Flexibility in Cloud Operating Systems

A Cloud OS administers the complexity of a distributed infrastructure in the execution of virtualized service workloads. The Cloud OS manages a number of servers and hardware devices and their infrastructure services which make up a cloud system, giving the user the impression that they are interacting with a single infinite capacity and elastic cloud. In the same way that multi-threaded OS define the thread as the unit of execution and the multi-threaded application as the management entity, supporting communication and synchronization instruments; multi-tier Cloud OS define the VM as the basic execution unit and the multi-tier virtualized service (group of VMs) as the basic management entity, supporting different communication instruments and their auto-configuration at boot time. This concept helps to create scalable applications because you can add VMs as and when needed. Individual multi-tier applications are all isolated from each other, but individual VMs in the same application are not as they all may share a communication network and services as and when needed.

A Cloud OS has a number of functions:

• Management of the Network, Computing and Storage Capacity: Orchestration of storage, network and virtualization technologies to enable the dynamic placement of the multi-tier services on distributed infrastructures
• Management of VM Life-cycle: Smooth execution of VMs by allocating the resources required for them to operate and by offering the functionality required to implement VM placement policies
• Management of Workload Placement: Support for the definition of workload and resource-aware allocation policies such as consolidation for energy efficiency, load  balancing, affinity-aware, capacity reservation…
• Management of VM Images: Exposing of general mechanisms to transfer and clone VM images
• Management of Information and Accounting. Provision of indicators that can be used to diagnose the correct operation of the servers and VMs and to support the implementation of the dynamic VM placement policies
• Management of Security: Definition of security policy on the users of the system, guaranteeing that the resources are used only by users with the relevant authorizations and isolation between workloads
• Management of Remote Cloud Capacity: Dynamic extension of local capacity with resources from remote providers

OpenNebula is an open cloud OS that provides the above functionality on a wide range of technologies. However, in my view, the main differentiation of OpenNebula is not its leading edge functionality but its open, modular and extensible architecture that enables its seamless integration with any service and component in the ecosystem. The open architecture of OpenNebula provides the flexibility that many enterprise IT shops need for internal cloud adoption. Cloud computing is about integration, one solution does not fit all. Moreover, as pointed out in the CloudScaling “Infrastructure-as-a-Service Builder’s Guide“, the right configuration and components in a Cloud architecture also depend on the execution requirements of the service workload.

Interoperability at the Cloud Management Level

The IEEE defines interoperability as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” and Wikipedia introduces  interoperability as “the property referring to the ability of diverse systems and organizations to work together (inter-operate)“. Being the core component in any cloud solution,interoperability is crucial for the success of a cloud management system. We can compare the cloud OS with a the kernel in “traditional” operating systems. The cloud OS represents the basic functions in a cloud and requires a well defined communication with underlying devices and interface to expose administration and user functionality.

At the cloud management level, interoperability means:

• Modularity and flexibility to easily interface with any service or technology in the virtualization and cloud ecosystem, and
• Standardization to avoid vendor lock-in and to create a healthy community around

In fact interoperability should be evaluated from three different angles:

• Infrastructure User Perspective: Users, application developers, integrators and aggregators are requiring a standard interface for the management of virtual machines, network and storage. OCCI is a simple REST API for Infrastructure as a Service based Clouds that is being defined in the context of OGF. This interfaces represents the first standard specification for life-cycle management of virtualized resources. OpenNebula has been the first referent implementation of this open cloud interface, and also implement the Amazon EC2 API.
• Infrastructure Management Perspective: Administrators are requiring cloud OS to inteface into existing infrastructure and management services, so fitting into any data center. OpenNebula provides a flexible back-end that can be integrated with any service for virtualization, storage and networking.
• Infrastructure Federation Perspective: Administrators are requiring cloud OS to manage resources from partner and commercial clouds

With high-end computing demands, cloud operating systems will continue to be a very active field of research and development. An open and flexible approach for cloud management ensures uptake and simplifies adaptation to different environments, being key for interoperability. The existence of an open and standard-based cloud management system like OpenNebula provides the foundation for building a complete cloud ecosystem, ensuring the new components and services in the ecosystem to have the widest possible market and user acceptability.

OpenNebula is being enhanced in the context of the RESERVOIR project, flagship of European research initiatives in virtualized infrastructures and cloud computing.