From VMWare Virtualization to Public Cloud. Now Hybrid Cloud.

vCloud, OpenStack & Cloudify

VMWare has been in the front of the virtualization space for many years and is by far the most popular enterprise virtualization solution.
In the recent years, as cloud technology became popular, VMWare released its vCloud product line to target private clouds.
More recently, VMware entered the public cloud space too with its vCloudAir product.
We’ve demonstrated in many posts how Cloudify, has broad support for orchestrating applications on many different clouds with the most popular being OpenStack based clouds and EC2.

Hybrid cloud orchestration – VMWare to OpenStack and back with Cloudify.  Go

Obviously adding support for the vCloudAir cloud was an important target for us.
VMWare vSphere & vCloudAir plugins allow for provisioning resources on vCloudAir as well as hybrid cloud support in heterogeneous environments that are running VMWare/Openstack clouds side by side.
It can even orchestrate applications that span across VMWare and Openstack in the same deployment.
Examining the vCloudAir API it became apparent that the vCloudAir API was heavily influenced from the traditional VMWare products and customer base.

Compared to OpenStack and EC2, it is much IT operations focused than developer and DevOps focused.
This means the API exposes tremendous amount of customization and control power, but at the same time, completing an operation that takes a couple simple api calls, translated to many more calls in vCloud.
In order to support a new cloud in Cloudify, we have to create or customize a plugin that will expose the different objects and interfaces/operation we can do with this cloud.
In my case, as time was short and I wanted to get going as quickly as possible, I chose to use an existing plugin which exposes Apache LibCloud, which itself lets you interact with different cloud APIs from python.
Cloudify already has a LibCloud plugin that was used for EC2 API.
I just extended it to expose the vCloudAir objects too.

This is a work in progress and I currently have just the server objects (server_plugin) exposed as can be see here:
Libcloud Plugin
While testing the work I have done with an actual vCloud account, I found that some of the functionality I used in the LibCloud vCloud driver (version 0.15.1) did not agree with the API used for my account. For example, getting network details did not work for me, but listing the networks did work.
Because of this, I had to fork the LibCloud repo and make a few changes to bypass these issues.

My modified version is at:
Modified Libcloud
I used the node-cellar Cloudify blueprint example.
All of the code stays the same and the only difference was focused on the blueprint YAML:

The rest of the YAML stays exactly the same. I just took out the security groups and floating IPs definition I did not have ready yet in my vCloud plugin.
Since Cloudify lets you define your cloud application orchestration in an independent fashion than the actual cloud IaaS the application would run on, it is very easy to run the same application on different clouds with almost no change.

Using common management and orchestration as an abstraction to both VMware and OpenStack provides a common management and deployment infrastructure.
The application is kept aware of whether it is running on OpenStack or VMware. However, since the calls to each of the infrastructure components are now centralized into one driver per environment, it is managed once for all the applications.

Additionally, there is a default implementation for the built-in types, so in most cases the user will need to deal with the details of implementations of each element type only for specific customizations.