Interoperability in the cloud: mOSAIC and Frascati

mOSAIC

mOSAIC is a European project supported by the European union [Dan10]. The target of the project was to build a unified Application programing interface (API) for Cloud services that is not only available in Java but also for other languages. mOSAIC is platform and language agnostic. It supports a large number of platforms for this approach. The mOSAIC framework itself is a middleware that runs on top of each cloud provider and abstracts provider specifics. The platform then exposes it’s own API to clients.
The mOSAIC project is built in a layered architecture. On the lowest level, there is the native API or protocol. This is either a ReST, SOAP, RPC or a language-specific library. On the next level, a driver API is found. This API can now be exchanged easily with different platforms such as Amazon’s S3. On top of that is an interoperability-API that allows programming language interoperability. Cloud resources can be access via the connector API. This is also the entry-point for developers, as they access specific models and resources from that API. On top of the connector API is a cloudlet that provides a cloud compliant programming methodology.

Frascati-based Multi PaaS Solution

Frascati is an infrastructure solution that runs on 11 different cloud solutions: Amazon EC2, Amazon Elastic Beanstalk, BitNami, CloudBees, Cloud Foundry, Dot-Cloud, Google App Engine, Heroku, InstaCompute, Jelastic, and OpenShift [Par12].
Frascati follows 3 core principles: An open service model, a configurable Multi-PaaS infrastructure and several infrastructure services. The open service model is an assembly of loosely coupled services based on a Service oriented Architecture. The configurable federated Multi-PaaS Infrastructure is a configurable kernel. Infrastructure services take care of the node provisioning, the deployment of the PaaS service, the deployment of the SaaS service and a federation management service. The Frascati services are installed on top of existing IaaS-services. To work with these services, it is necessary to have access to virtual machines (either Linux or Windows).
This post is part of a work done on Cloud interoperability. You can access the full work here and the list of references here.

Interoperability libraries in the cloud: Apache jClouds and Libcloud

Apache jClouds

Apache jclouds is a framework provided by the Apache Software Foundation. The framework is written in Java and serves the purpose to provide an independent library for typical cloud operations. At present (November 2014), Apache jclouds provides 2 kinds of services: a compute service and a blob service [Apa14b]. Apache jclouds can be used from Java and Clojure. The library offers an abstraction for more than 30 cloud providers, including AWS, Azure, OpenStack and Rackspace.
Apache jclouds is primarily built for infrastructure interoperability. As for the platform layer, only blob storage is currently supported. The focus of jclouds is to support a large variety of platforms over implementing a large variety of services. The Blob storage in Apache jclouds works with the concept of Containers, Folders and Blobs. The library supports access control lists for objects. The upload of Multipart objects is also supported, which allows jclouds to handle large files. [Apa14c]

Libcloud

[Apa14d] Apache libcloud is similar to Apache jClouds. The library is developed as an abstraction to different cloud providers. Libcloud currently supports more than 30 different providers. Libcloud is available as a Python library.
Libcloud is infrastructure-focused with most of it’s implementations done for computing, DNS and Load balancing. There is also an object storage implementation available.
This post is part of a work done on Cloud interoperability. You can access the full work here and the list of references here.

Standards in the Cloud: Open Cloud Computing Interface and DMTF

Open Cloud Computing Interface (OCCI)

The Open Grid Forum created the Open Cloud Computing Interface (OCCI). They claim to have one of the first standards in the cloud. OCCI was initially built to deliver portability and interoperability for IaaS platforms. In its initial implementation, it was used for different tasks around deployment, scaling and monitoring for virtual machines in the cloud. The library also supports common tasks for other cloud layers such as SaaS and PaaS [Ope14a].
OCCI is not a specific library that enables interoperability and portability. Hence, it is a definition of standards that can be implemented by individual platforms. The standard exists of 3 elements: the core description, the infrastructure description for the IaaS domain and a rendering description. The rendering is used to provide a REST HTTP service [Ope14b].
OCCI is implemented by a large number of cloud platforms. Major platforms such as Apache Cloudstack, OpenStack, OpenNebula and Eucalyptus implement that standard. However, large public cloud providers such as Amazon Web Services, IBM, Microsoft and Google don’t implement that standard [Ope14c].
The OCCI standard focuses on IaaS. At present, it supports compute, networking, storage, and infrastructure templates. Storage does not define blob storage, as it is about the storage of virtual machines [Met11].

Distributed Management Task Force (DMTF) initiatives

Distributed Management Task Force proposed several standards for cloud computing [Dmt09]. The key focus of the DMTF is to improve standards around IaaS solutions. As a key standard, the DMTF developed the Open Virtualization Format (OVF). However, there are no standards for APIs and platform services available.
This post is part of a work done on Cloud interoperability. You can access the full work here and the list of references here.

Current initiatives in cloud computing interoperability

Gonidis [Gon11] defines an approach on how to enable interoperability for PaaS solutions. It is about building a standard for existing cloud platforms. However, this is a challenge given that every platform provider has it’s own proprietary API. Furthermore, services available on the one platform aren’t available on the other platform. In the following posts, existing interoperability frameworks, solutions and standards for Platform as a Service are evaluated.

Standard initiatives

Current standard initiatives are the Open Cloud Computing Interface (OCCI) and the Distributed Management Task Force (DMTF) initiatives. In the next posts, I will outline them in detail.

Libraries and Frameworks

Libraries and Frameworks for Cloud Interoperability are: Apache jClouds and Libcloud. They will be described in the following posts.

Middleware solutions

Middleware Solutions for Cloud interoperability are: mOSAIC, PaaS Semantic Interoperability Framework (PSIF), Frascati-based Multi PaaS Solution and SimpleCloud. They will be described in the following posts.

Interoperability Solutions for the Cloud

Interoperability Solutions for the Cloud


This post is part of a work done on Cloud interoperability. You can access the full work here and the list of references here.

Interoperability challenges for Platform as a Service

On the IaaS layer, work on cloud interoperability was already conducted [Ste13a], [Ste13b]. The authors described in “Challenges in the Management of Federated Heterogeneous Scientific Clouds” the problem and a feasible solution to migrate virtual machines between providers. Another challenge identified is the layer between the vendor API and the user. This problem is addressed by the same authors in the paper “Building an On-Demand Virtual Computing Market in Non-Commercial Communities”, where a market is introduced to handle that problem. The concept of the market is then described in “Take a Penny, Leave a Penny Scaling out to Off-premise Unused Cloud Resources” [Ste13b] in detail, where a solution is presented that allows users to use different cloud vendors with one abstract API.
Gonidis et al. [Gon11] give a first hint at challenges addressed for Platform as a Service interoperability. Platform as a Service gives the promise of speeding up application development [Mei11] by utilizing services. Platforms such as Microsoft’s Azure, Amazon’s Elastic Beanstalk or Google’s AppEngine offer a large number of services. The possibilities range from object storage, databases, messaging to analytics. A comprehensive overview is given in section 4. However, this leads to new challenges in terms of vertical interoperability. The challenge with PaaS is not like with IaaS, where one has to move the virtual machine. Now, it is about moving individual services and the corresponding data. The leading PaaS providers such as Amazon, Google and Microsoft provide their own frameworks and tools to access their platforms. When a customer decides to move the application to another provider, this becomes a challenge.
Loutas et al. [Lou11b] describe similar challenges. First, it is stated that cloud providers promote their own, incompatible formats over standards. This is largely due to the on-going battle of dominance in the cloud. Since each provider has their own standard, new and smaller providers cannot enter the market easily as there is no common standard yet. It is stated that interoperability is the missing element so far, even though it would benefit both – customers and providers [Lou11b].
Stravoskoufos et al. [Str] define different cloud interoperability challenges on each of the cloud layers. On the IaaS layer, interoperability is about controlling the infrastructure-specific services. For platform as a service, interoperability is about using the APIs and services. For Software as a s Service, the challenge is to exchange messages and data.
This post is part of a work done on Cloud interoperability. You can access the full work here and the list of references here.