(MODAClouds) mOSAIC

Important

This document is part of the MODAClouds deliverable D6.1, thus superseded by it.

Important

This document was created in March 2013, thus its contents might be currently outdated.

Overview

Overall mOSAIC is an FP7 research project that touches multiple subjects revolving around cloud computing, from cloud brokering, interoperability up-to deployment and execution. For the purpose of the ModaClouds project we shall focus mainly on the PaaS-related outcomes from mOSAIC.

The main concepts, detailed in [mOSAIC-1] or [mOSAIC-2], are:

component

Represents the basic building block of a cloud application, the atomic deployment and execution unit, which is materialized as one, or a set of tightly coupled, OS processes that run in an isolated environment.

There are many types of components, each type mapping to an application tier, but they are treated the same by the platform. In general they fit in one of the following categories:

  • the "user" components --- which embodies the code developed by the user, and implements the needed logic;
  • resource or middleware components --- that provide usual generic services, like data storage (Riak, CouchDB, MySQL), message brokering (like RabbitMQ), etc.;
  • specialized components --- that are of particular use in the mOSAIC platform or in a cloud environment, like the HTTP Gateway serving as a load-balancer, or the credentials service that could hold and mediate access to sensitive information, like the cloud provider access keys;
controller
The orchestration service that initiates the deployment and controls the execution of the components. [mOSAIC-3]
hub
An bus-like or RPC-like system that allows components to discover each other, or exchange configuration messages. [mOSAIC-4]

Characteristics

type PaaS
suitability prototype
application domain web applications, generic applications
application architecture n-tier applications
programming languages any
programming frameworks any
scalability manual
session affinity dependent on the load-balancer
interaction WUI, WS
disponibility deployable (open-source)
portability portable
services RabbitMQ, Riak, CouchDB, MySQL, custom
monitoring none
resource providers Amazon EC2, Eucalyptus, custom
multi-tenancy single application
resource sharing n:1

Notes and limitations

Related with limitations, mOSAIC imposes little constraints on the running components. For example any component is able to listen on ports --- provided that it request access beforehand --- or receive inbound requests from the Internet, not necessarily limited to the HTTP protocol. Moreover the resources allocated to a particular component are configured by the operator, and could range up to the entire VM's resources. The only real limitations are that the component must run on Linux and not require root access.

Thus the support for programming languages and frameworks is virtually any that runs on Linux, the only customization needed is the interaction with the component controller and component hub to gain access to their services. On-top of that the components have access to native OS libraries and tools, either provided by the current used distribution, or prepared by the developer before deploying the application.

Although from a certain perspective it fits the same functionality as other PaaS's, especially Heroku or CloudFoundry, it differentiates in that one instance of the mOSAIC platform is dedicated to only one instance of a particular application, thus proving a good solution for private PaaS situations.

However unlike the aforementioned PaaS's, although mOSAIC usually shields the operator from the low-level details such as VM's, it does offer full access when needed, thus the operator is able to pin-point the VM where a certain component should be deployed.

Finally the software artifacts related with the PaaS aspects of mOSAIC are fully open source [mOSAIC-5], and are split into many quasi-independent software services that could be reused even independently of the PaaS.

ModaClouds integration

Because the many features of mOSAIC maps over the requirements of ModaClouds --- such as no multi-tenancy, minimal restrictions over run application, or fine grained control --- it could fit two different usage scenarios, both related with IaaS deployments:

  • for once it can be used to deploy and execute the user's application when targeting an IaaS solution;
  • and secondly, it could be used to deploy and execute the ModaClouds support services;

References

[mOSAIC-1]Dana Petcu, Ciprian Craciun, Massimiliano Rak: Towards a Cross Platform Cloud API -- Components for Cloud Federation; 2011
[mOSAIC-2]Ciprian Craciun: Building blocks of scalable applications; Masters thesis; 2012
[mOSAIC-3]mOSAIC notes -- Component controller
[mOSAIC-4]mOSAIC notes -- Component hub
[mOSAIC-5]mOSAIC BitBucket repositories