A new generation of orchestration tools is rising to the challenge of configuring VMs in complex, real-world scenarios. Cloudify [1] is an orchestration solution that promises customers an easy and uncomplicated approach to leveraging the benefits of services in the cloud.

With other tools, such as Chef or Puppet, admins can build a cloud environment from scratch with just a few mouse clicks. The cloud platform takes care of the details, leaving the users to just start and stop the VMs.

Although starting and stopping VMs might not seem like very much work, it can quickly escalate, especially when customers want to put the features of a cloud to optimal use. For example, assembling an environment for web servers would mean starting the individual VMs from the designated images and spending a full day configuring them. If you turned off this configuration and needed it again a year later, the work would start all over.

Chef and Puppet only work well with more static setups, where it's clear in advance what the configuration should look like at the end. The open source Cloudify truly automates the process of configuring VMs in the cloud, supports various types of public clouds, and is under active development.

Start as PaaS

GigaSpaces, the company behind Cloudify, began developing the tool in 2012. Cloudify was originally designed as a tool for Platform-as-a-Service (PaaS) applications (although the boundaries to SaaS are fluid). The basic idea was to give users a quick and easy way to start specific programs or services within a cloud computing environment.

Currently, Cloudify targets customers who launch prebuilt appliances in cloud environments and want to operate their own services quickly without dealing with the technical underpinnings. The vendor offers prebuilt templates and images that you can enable in Cloudify to run the commands stored on them in a cloud.

Under the Hood

You can experience Cloudify for yourself relatively easily if you run Windows or Linux on your system. The Cloudify website offers you the option of downloading Cloudify to a local hard disk and running it as a local cloud (Figure 1).

Figure 1: Using Cloudify shell, starting a local cloud is a breeze, although this is intended more as a demonstration and test object.

For a better understanding, it is important to know that Cloudify itself is always present as a separate instance within a cloud. No matter how you design your configuration, Cloudify needs to operate through a master VM. In the case of a local cloud, the master VM runs on the local machine. Cloudify handles the complete bootstrapping of its own local cloud, which does not require access to a public cloud provider and thus imposes very few requirements.

The Cloudify tarball is a heavyweight at 160MB, but the user initially only has to interact with precisely one component: the Cloudify shell, which gives admin the ability to send specific commands to Cloudify. The Cloudify shell is important because Cloudify itself receives its commands from a RESTful API. The shell sort of translates commands from users to JSON format, thus enabling the effective use of Cloudify. Incidentally, the rest of Cloudify is in Java and thus requires a current JDK (Java Runtime Environment is not sufficient, as the Cloudify developers explain in the documentation).

If bootstrapping of the initial cloud works, whether as a test installation on a local system or a genuine deployment in a public cloud, the Cloudify web front end is then available (Figure 2). The front end has the ability to start PaaS deployments; you can also discover the performance values of the current deployment and extract monitoring information. The web interface always runs on the management VM, which admins will most likely prefer to the Cloudify shell because it works in any web browser.

Figure 2: On the basis of application groups, the Cloudify dashboard displays how it assesses the state of an application.

Modular Structure

Cloudify consists of many parts, and the modularity of the solution continues down through the individual components, which in turn consist of several subcomponents. The main engine handles communication with a specific public cloud through its own "cloud drivers" (Figure 3).

Figure 3: The Cloudify shell can deploy a physical appliance in a public cloud; the appropriate drivers make it possible.

This design helps users who want to use Cloudify to handle the orchestration of VMs in public clouds – which is probably the vast majority of Cloudify users. The list of supported clouds includes all the key players: Amazon, Rackspace, Microsoft Azure, and everything that is compatible with OpenStack. With the same instance of Cloudify, it is possible to manage multiple public cloud access points at the same time. Even multitier clouds that span multiple cloud environments are possible.

Cloudify includes some features that make using the tool a very pleasant experience. Among other things, you can define load limits for individual PaaS applications. During operation, the Cloudify master instance uses its own logic to discover the load generated by the PaaS application on the VMs. If the current load exceeds the limits set by the admin, Cloudify automatically makes sure that more instances of the application are started. This feature keeps the load time for users of the app at a tolerable level; however, the system is automated, thus requiring no intervention on the part of the administrator.