(MODAClouds) Cloudify

Overview

Coming from GigaSpaces, Cloudify is another open-source project, that fits into the same category as Ubuntu's Juju, handling application deployment and execution on-top of cloud or virtualized infrastructures. Although it fits into the same category as Juju it does set itself apart by having explicit support for managing multiple applications, it works on more cloud infrastructures, and provides basic monitoring and scalability features.

The concepts are the following [Cloudify-1]:

application

Defined as a set of services, that by working together provide the required functionality. As previously stated, Cloudify is able to explicitly manage multiple distinct applications within the same infrastructure.

service

Just as in Juju's case, it is a logical construct that contains all service instances which provide the same functionality. For example a database service might be a cluster of VM's that run the same distributed database management system, or the web-frontend that is composed of multiple VM's sharing the load.

service instance

An individual VM that runs the required software for the respective service type.

application recipe

It prescribes global characteristics, such as configuration, provisioning, or scalability rules, related to the application as a whole, and lists the set of services that compose it, together with their dependencies.

service recipe

Prescribes the characteristics of an individual service layer, again including details such as configuration or provisioning.

Characteristics

As said in the overview, Cloudify fits into the same category as Juju, therefore most observations made about Juju are also true for Cloudify, thus we'll just summarize them:

• the focus is on the operational aspects and not on the development ones;
• it does allow reusage of recipes between multiple applications, and customization through recipe parameters; (but see below for the drawbacks;) [Cloudify-4]
• it maps each service instance on an individual VM (thus a 1:1 mapping); (although there is the intention to implement a more complex sharing mechanism;) [Cloudify-5]
• it requires the same bootstrapping through a management VM; [Cloudify-3]

On the other hand it also sets itself apart from Juju in the following respects:

• although it seems to be only slighter older than Juju (2011 vs 2012), the developers of Cloudify state that it's production ready; (this however might not correctly reflect the maturity and stability of the solution;)
• interacts with a few more IaaS providers, including manually provisioning of the VM's, plus offering the opportunity to add other providers by implementing drivers for them; [Cloudify-3] [Cloudify-10]
• it features a more complex security model, including roles and groups for the users and for applications; [Cloudify-6]
• it has explicit support for running multiple applications managed through the same Cloudify instance;
• it allows basic monitoring and scalability rules; [Cloudify-2]
• it is not tied to a particular operating system distribution; [Cloudify-5]

However it does have major drawbacks, especially in terms of service reconfigurability and interaction, as we'll describe in the following paragraphs.

There is no global repository for recipes, and each application must provide within its file system hierarchy all the needed recipes [Cloudify-4]. On one hand this is good because we have in one place all the needed files to inspect and re-deploy another application instance with the exact configuration, thus enabling deterministic configurability. On the other hand it makes maintaining and updating the recipes quite difficult, requiring manually overwriting the files.

Moreover we cannot commission new services at run-time that were not described in the application's recipe, which means that any application upgrade can't be done in-place, because it requires a complete stop-start cycle. (The documentation doesn't explicitly state this issue, but after a careful review of the available documentation, available CLI commands and API operations, there doesn't seem to be support for such a feature.)

The way in which services are able to influence each-other, either to transmit configuration parameters (like endpoints, credentials, etc.) or to trigger custom behaviors, is rather cumbersome. Information exchange is achieved by attaching attributes at various scopes to various entities (the application, service layer, service instance, etc.), but the way in which this reconfiguration is observed is either through continuous polling, or by manually calling commands on the dependant services. [Cloudify-7] [Cloudify-8]

On the up-side the documentation does seem to touch all important aspects, and even touches the API or other technical aspects.

Another important feature is that related with monitoring, as it provides out-of-the-box basic metrics at service instance level (CPU, memory, paging activity, etc.) and support for JMX; plus the operator is able to write customized scripts or to install plugins that provide other metrics. [Cloudify-9]

On-top of all these there is also support for basic scalability inside the same service layer [Cloudify-2]. However the rules can use metrics belonging only to the current service layer, and can't capture global behaviours that involve multiple service layers.

There is also basic integration with either Chef or Puppet, that allows, on each machine, to run a stand-alone variant of those deployment solutions, thus enabling deployment of services described through Chef or Puppet recipes.

ModaClouds integration

In ModaClouds we could leverage Cloudify to deploy the applications over IaaS's, just as we've described in Juju's case. However it would provide less flexibility in terms of application reconfiguration, although it does provide basic monitoring out-of-the box, an supports a few more cloud providers.

References