Generally speaking, the interoperability problem has three dimensions in the case of Cloud computing domain:
mOSAIC is dealing mainly with the first dimension, ensuring an abstraction level for vendor-agnosticity. While is not tackling explicitly the migration or federation, it allows on-demand re-deployment of the supported application in various Clouds.
The portability problem has also three dimensions (all tackled by mOSAIC):
The main requirements of portability (following the comprehensive list from [146]) are met by the mOSAIC solution as indicated in Table 3.
There are currently several technical approaches to deal with portability and interoperability: open APIs and protocols (like jclouds [147], libcloud [148], OpenStack, OCCI [149] or δ-Cloud [150]), standards (like OVF [151], CDMI [152] or CIMI [153]), frameworks (like for SLAs from SLA@SOI project), semantic repositories (like UCI [154]), or domain specific languages (like CloudML [155]). mOSAIC is an integrated solution that offers an open API with a high level of abstraction, and uses OCCI, SLA@SOI framework and semantic processing.
There are several reasons for the use of services from multiple Clouds. The ones motivating mOSAIC are the following two: (1) ensure the avoidance of vendor lock-in by relaying upon the services from two or more providers; (2) support Hybrid Clouds build from Private and Public Clouds in order to deal with peaks or customer requirements.
According to the NIST report [156], multiple Clouds can be used sequentially or simultaneous. The sequentially usage is related to the migration from one Cloud to another driven from economic reasons (e.g. cost reductions, emergencies, back-ups etc). The simultaneous usage of services from different Clouds can also have several benefits like high availability and fault tolerance. mOSAIC is mainly targeting the first scenario, while is not excluding the second one.
According to [157], two delivery models can distinguished for multiple Clouds. The first one, the Federated Cloud, assumes a formal agreement between the Cloud providers. The second model, of Multi-Cloud, assumes that there is no priori agreement between the Cloud providers. mOSAIC is targeting mainly the Multi-Cloud, establishing only at deployment phase the needs in terms of services and the contacts with the Cloud providers.
According to [158], the term Multi-Cloud denotes the usage of multiple and independent Clouds by a client or a service. Clients or their software representatives are responsible for managing resource provisioning. In the same paper Multi-Clouds are classified in two categories. The first category is that of libraries allowing the usage of multiple clouds in a uniform way (including brokers that directly take care of provisioning of services across Clouds). The second category is that of services for provisioning resources which are hosted either externally or in-house by the clients, and which usually includes a broker. In this case the clients are entitled to specify a service level agreement or a set of provisioning rules and the service performs accordingly the deployment and execution. As the authors of [158] have correctly noted, mOSAIC can be mapped to the second category, of services.
We should remind that in the category of libraries, the most known products are the Python library Libcloud, the Java library jclouds, the REST API δ-Cloud, the PHP API Simple Cloud [159], or C++/ Python/Java API SAGA [160]. These libraries can be used as Drivers in mOSAIC. Moreover, mOSAIC’s API libraries are available for Java, Python, Erlang and Node.js.
In what concerns the Multi-Clouds based on services, we consider that there are two categories: hosted services and deployable services. mOSAIC belongs to the deployable category.
Three hosted services are most relevant in this moment: RightScale, Enstratius and Kaavo. RightScale [161] offers a Private Cloud management platform for control, administration, and life-cycle support of deployments across multiple Clouds (it supports Amazon, Eucalyptus, GoGrid, VMware and FlexiScale); server templates are available to automatically install software on supported Cloud infrastructures. Enstratius [162] allows configuration management, monitoring, governance and automation and it supports Amazon, CloudStack, CloudSigma, Eucalyptus, GoGrid, Joyent Cloud, OpenStack, Rackspace, vCloud, Azure and others. Kaavo [163] allows also the deployment and management of distributed applications, workloads, and environments in various Clouds enabling resource management across Public, Private, and Hybrid Clouds (it supports Amazon, Rackspace, OpenStack, Eucalyptus, Cloud.com, Terremark, Logicworks, HP Cloud and IBM Cloud).
In terms of number of Cloud providers that are supported, mOSAIC is similar with the above mentioned hosted services, but with a clear preference for the support of European Cloud providers. In terms of GUIs the mOSAIC Web oriented one is considerably different, as designed to serve applications, not resource management: the user does not control the resources distribution or consumption (provider interfaces can be used for this purpose), but instead controls the processes of the application that are running (an application oriented view, instead a resource provider view).
The current deployable services for Multi-Cloud are in prototype phases as results of different research projects. Two main competitors for mOSAIC are currently available: Aoleus and Optimis. The RedHat’s Aoleus [164] is an open-source Cloud management software written in Ruby for Linux systems. It allows users to choose between Private, Public or Hybrid Clouds, using δ-Cloud library. The Optimis Toolkit [165], result of the project with the same name and funded by the European Commission in the same work-programme as mOSAIC (in parallel with it), offers a platform for Cloud service provisioning that manages the lifecycle of the service and addresses issues like risk and trust management. Compared with Aoleus, mOSAIC has the advantage of including more than a resource management middleware (not restricted to the δ-Cloud list of providers). Compared with Optimis, mOSAIC is weaker in terms of trust and risk management, or even in brokerage process due to the reduced set of policies; however the semantic processing support, the SLA-based negotiation mechanisms, or the application tools are the main comparative advantages of mOSAIC.
A comprehensive analysis of mOSAIC positioning versus the research prototypes for Federations and Multi-Clouds, complementary to the above one that is mentioning software products, was recently exposed in [166].
A Cloud Federation or a Multi-Cloud that includes at least one Cloud Broker and offers dynamic service provisioning is an Inter-Cloud. In the case of Multi-Cloud, the Broker is often part of the service or library. This is the case also for mOSAIC. According [158], the brokering mechanisms are: SLA-based, i.e. requirements are specified by clients in the form of a service level agreements; or trigger-action, i.e. rules are becoming active, triggering an action, when a predefined condition considering the externally visible application performance indicators becomes true. Evidently, mOSAIC has a SLA-based brokering mechanism. However, taking into account its event-driven orientation, part of its behavior is based on rules and triggered-actions.
The most relevant representatives for SLA-based brokers for Multi-Clouds are SpotCloud and Stratos. SpotCloud [167] provides a marketplace where service providers sell the extra capacity they have and the clients can select the ’best’ service provider at a certain moment. WSO2 Stratos [168] provides core services and building blocks for federated identity and single sign-on, data-as-a-service and messaging-as-a-service, and monitors SLAs, CPU, memory and bandwidth utilization and automatically scales up or down depending on the load. The mOSAIC brokering, monitoring, scaling or messaging mechanisms are rather simpler compared with SpotCloud and Stratos ones. However, its component-based and open-source design has the comparative advantage of easy updates and customization according to user’s needs.
mOSAIC has not been yet able to establish a market place, as SpotCloud, but it does not exclude the idea. A Cloud platform supporting applications composed of software components can come with a component store which provides components for common tasks. Using such a store, developers should be able to build new applications and services by configure and compose the existing components, or by extending them with new functionalities. Moreover, a dynamic recomposition of software during execution, i.e. adding, removing or reconfiguring components within an application at runtime, should be possible. A case study of using mOSAIC and a component market for the design of a Bussiness-Process-as-a-Service is sketched in [169].
As described earlier, mOSAIC exhibits some characteristics of a PaaS. Despite the fact that is not a hosted service, but a deployable one, it offers several tools and facilities to develop, deploy and control at run-time new applications. We consider here only two significant PaaSs to be compared with mOSAIC’s PaaS. While the PaaS offer is quite diverse, the selection is based on the usage spread, respectively closeness to mOSAIC.
Google’s Application Engine (GAE) is one of the most known PaaS. While the deployment facilities are more complicated in mOSAIC due to the need of the user final decision in selecting the Cloud provider, several limitations of GAE are avoided by mOSAIC. For example file-system write access are forbidden in GAE; applications are not allowed to make arbitrary network connections to the Internet and HTTP requests must be made only through a special library. All data handled by GAE must be stored in a columnar database, and even though the developer has a query language resembling SQL, it is very limited in what concerns filters. Moreover, in GAE the requests should be handled within one minute or less. All of these restrictions are not encountered in mOSAIC approach.
From the long list of hosting PaaS, Heroku [170] is the most closest to mOSAIC concepts. Its features have inspired not only mOSAIC, but also most of the recently emerged PaaSs. The reason is its simple scheme to handle development, configuration, deployment, and management. It supports a variety of programming languages (Ruby, Python, Node.js, Scala and Clojure), as well as arbitrary executables either as binary or scripts. However, there are several improvements that mOSAIC has been able to provide. For example, it is actually impractical to mix multiple languages in the same Heroku application, while in mOSAIC components can be written in various languages if they are able to use a message passing system. Any update of component of a Heroku application needs the complete shutdown of the application. In mOSAIC components can be stopped, started or updated during the execution of the application, as the messages are waiting in the queues. Several other advantages are comprehensively discussed in [171].
As earlier mentioned, mOSAIC is included in the category of services for Multi-Cloud. However there are other open-source middlewares that are deployable, while not necessary designed with the Multi-Cloud in mind, still able to deal with homogeneous distributed resources. A comprehensive comparisons of them and mOSAIC positioning is presented in [172], including ConPaaS, the Contrail [173] solution for Federations. In the same paper are provided a series of criteria that can be used to compare PaaSs.
We mention here only VMware’s Cloud Foundry and Red Hat’s OpenShift [174], developed in the same time as mOSAIC. Both are dedicated to Web applications, while mOSAIC scope is more broader. mOSAIC is stronger also in terms of data support, the number of Cloud providers that are supported, the interfacing variants, the SLA and brokerage mechanisms, as well as portability on other Linux system than VMware or RedHat provided ones. However is weaker in terms of performance analytics or integration with other development environments than Eclipse.
Beyond Optimis, Contrail and MODAClouds that were mentioned earlier, there are several other Cloud computing projects that have run in parallel with mOSAIC and have provided close related solutions. A snapshot of the landscape covered by these projects in the late 2011 was provided with mOSAIC contribution in [175] in the book [176] that collects reports on the states of more than twelve such projects. The positioning of mOSAIC in relationship with several Multi-Cloud projects was expressed more recently in [177].
We remind here only few projects offering alternatives to mOSAIC approach or complementing it. 4CaaSt [178] is building a BluePrint for registering Cloud services in an e-Market. Cloud4SOA [179] is dealing with semantic based interoperability at platform level. Cloud-TM [180] is proposing another programming paradigm for Clouds. Remics [181] is dealing with migration of legacy applications to Clouds through model-driven engineering. TClouds [182] is offering security, privacy and resilience mechanisms for Multi-Clouds. Vision Cloud [183] is looking in details to the issues of data management in Federations and Multi-Clouds.
