Recipes

Cloudify organizes configuration templates into recipes . On one hand, you have the application recipes – in Cloudify, an application is a generic term for all the services necessary for operating the application. For example, if you wanted to run a web platform that included phpBB, the recipe might go by the name of phpBB .

An application recipe consists of the definitions of several services that are necessary to achieve a specific purpose. For example, a phpBB service might require additional services such as MySQL. For a service to be manageable in Cloudify in the scope of PaaS, you thus need an appropriate service recipe; a cornucopia of recipes for most popular applications is available online [2] (Figure 4).

Figure 4: You can use the web interface itself to select recipes, which can then immediately be run as applications.

If you want to offer your customers the opportunity to run a web server, say, for their own blog, you will probably be happy with these prebuilt recipes. However, if you want to automate the process of deploying specific services in the cloud, you have reached the point where you will need to develop your own service recipe.

Service recipes have a relatively complex anatomy; for example, they support lifecycle events that are more important than they might seem at first sight. Ultimately, lifecycle events do whatever is essential for the deployment of a PaaS application: They ensure that service recipes follow the appropriate commands – triggered by specific events, such as starting and stopping an application. In other words, a recipe for the Start lifecycle event would need to ensure that the program is installed and started.

Terminology is important. The Cloudify developers distinguish between services and service instances in the application context. A service instance is a concrete incarnation of a service, whereas the term service refers to the instances of the same service available throughout the cluster. "MySQL" as a service thus refers to all instances of MySQL that belong to a Cloudify application; a service instance, however, would refer to a specific instance of the service that is uniquely identifiable.

All told, the concept of recipes in Cloudify is comprehensive and, in the beginning, undoubtedly complex. If you need a helping hand, check out the Cloudify documentation [3], which also contains case studies for the most important topics in addition to detailed explanations. For example, GigaSpaces describes in detail how you can use recipes to set up a Tomcat or a MongoDB system as a PaaS.

Integration with External Tools

Although Chef takes care of hosts rather than specific applications, the Cloudify developers leverage the power of Chef as a central management tool. Since Cloudify 2.2, it has been possible to use Chef to deploy applications on virtual machines. In fact, most of what you will find in Cloudify recipes can be achieved by integrating Chef Cookbooks.

Looking Forward: Cloudify 3.0

The current Cloudify version 2.6 has already been around for some time. GigaSpaces is working hard on a new version 3.0. Cloudify 3.0 will be a major upgrade, largely written from scratch. One reason for the major change is a strategic realignment directly related to the OpenStack project.

OpenStack support in Cloudify has plenty of room for improvement; this was to a large extent because OpenStack failed to issue clear guidelines for orchestration.

OpenStack Havana, however, has introduced a component called Heat that supports orchestration based on several different formats. Heat is basically a template-processing engine that reads environment descriptions on one side and then implements them on the cloud side. What does this mean for Cloudify? After all, the Heat component basically does exactly what Cloudify previously did, and in a very similar manner. Is it still worth putting time and effort into adapting Cloudify for OpenStack?

The developers believe it to be so: Cloudify 3.0 is drifting very clearly in the direction of OpenStack, according to information provided by GigaSpaces. Of course, Cloudify 3.0 will continue to support other cloud systems; the solution will therefore not become a piece of "OpenStack-only" software. Yet, Cloudify 3.0 will be closely meshed with OpenStack  – and this includes support for all APIs in OpenStack. Additionally, Cloudify 3.0 will not duplicate the functions that already exist in Heat; in fact, Cloudify will simply pass on the required steps to Heat, which will provide seamless integration of the two tools.

Also, the GigaSpaces developers are expanding the Cloudify policy engine. In Cloudify 2, the policy engine is responsible for ensuring horizontal scalability. The basic idea is to create definable workflows that carry out certain actions, triggered by specific events

Another major step in Cloudify 3.0 is a change in programming language: The tool has undergone a rewrite in Python, which is also probably attributable to the desired closer ties with OpenStack.