Creating a scalable blueprinting service using Cloudify

OpenStack VMware | VMware OpenStack | Hybrid Cloud | vCloudAir | VMware Public Cloud | vCloud Cloud | SaaS | TOSCA Orchestration | Orchestration Engine | Multi-tenant | Multi-tenancy
Recently I was asked to design a SaaS offering with a major partner that will feature TOSCA orchestration for applications. Cloudify version 3 was already out with significant features and design tenets that made it extremely easy to extend and embed; enabling it to be commonly used to application orchestration on various clouds and even bare metal servers.

Blueprinting as a service – now possible with Cloudify.  Go

However, at the time, Cloudify was lacking some key elements that we identified as key to provide a large-scale SaaS product:

  1. Multi-user and multi-tenant support, alongside integration with external identity management services.
  2. Horizontal scaling of the orchestration engine
  3. Minimal footprint (in terms of resources) per application deployment and VMs within the deployment

We had a goal of releasing the service in two months and while all of these elements were on the Cloudify roadmap, the product launch was extremely successful…and such success is often times a double-edged sword – as with success comes many customers, and their specific needs and feature requests. Therefore, the slated two months was simply too aggressive to rely on the product roadmap fulfilling our requirements.
So I decided to take on the challenge myself. The approach we took to achieve this, based on the above, was the following:
Utilize Cloudify managers as our service orchestration engine, but wrap it with a facade that will – on the one hand keep the same RESTful API Cloudify exposed, yet still make it a smart façade that will not only front the Cloudify managers, but will also provide the multi-user multi-tenancy functionality our service required, as well as the horizontal scaling. The third point, minimizing the deployment footprint was the only point we left for the core product to address in the short timeframe we had.
We designed the multi-tenancy by using our partner’s token-based identity service. We created separation between tenants in a single orchestration engine, by creating a hash algorithm that adds uniquely identified tenant encoding into all of the engine keys (such as blueprint IDs and deployment IDs), and filtering back to each tenant only its own private data.
We handled the horizontal scaling, by allowing all tenants to access a single point (our façade), and load-balance between multiple orchestration engines on the backend. We also added stickiness to the load balancing. Since this service is part of a large public cloud offering by our partner, we were interested in maintaining the same user experience, and using the same tools used by its customers. Both the CLI and UI were addressed. The CLI support was added by adding command verbs to the existing CLI tool. Even though Cloudify has an impressive UI in its own right, to ensure an optimal user experience, we built a new UI from the ground up to match the existing cloud UI. The amazing part here is that due to the easy RESTful API that we had, the UI was built in a couple of weeks in parallel to the work on the façade. In the first week it used the Cloudify orchestration engine’s RESTful API and by the second week, once the façade API was ready, the switch was nearly transparent and took a couple of hours.
Another interesting point I wanted to bring up is how we managed the operation of the service and its development. Due to the very short timeframe we operated in, we managed the development in weekly sprints and each sprint resulted in a deployment to production of that sprint functionality.
To allow us this aggressive deployment process we basically drink our own Kool Aid. We created a blueprint of the service frontend and backend services and used Cloudify to orchestrate the deployment and scaling of our service itself.
Looking back, I am extremely happy with the approach we took.
The Cloudify product has improved in these couple of months and its new 3.2.1 release already supports some of the elements we built ourselves. Others are still in the works, but this challenge afforded us flexibility in fronting the orchestration engines, which is something that we continue to take advantage of and leverage in order to tailor the service for our users.


    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Back to top