Cloudify is an open source TOSCA based pure play orchestration platform.
Cloudify is commonly used to orchestrate application a various clouds and even bare metal servers.
When I was asked to design SAS offering with a major partner that will feature TOSCA based application orchestration, Cloudify version 3 was already out with significant features and design tenets that made it extremely easy to extend and embed.
At the time, Cloudify was lacking some key elements that we identified as key to provide a large-scale SAS product:
- Multi users, multi tenant support and integration with external identity management services
- Horizontal scaling of the orchestration engine
- 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 although all of these elements were on the Cloudily roadmap, the product was extremely successful and with such success, come many customers demands and features requests and therefore the two months was too aggressive to rely on the product roadmap fulfilling our requirements.
The Approach we took 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 end keep the same RESTful API Cloudify expose, but make it a smart façade that will not only front the Cloduify managers, but will also provide the multi-users 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 tenants encoding into all of the engine keys (such as blueprint IDs and deployment IDs) and filter back to each tenant only it 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 to maintain the same user experience and use the same tools used by its customers.Both 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 by its own right, to ensure 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. On the first week it was using Cloudify orchestration engine RESTful API and on 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 about how we manage the operation of the service and it development. Due to the very short timeframe we operated at, 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 blueprint of the service front end and backend services and use 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 it new 3.2.1 release already supports some of the elements we built ourselves, but others are still in the work and the flexibility we have in fronting the orchestration engines, is something that we continue to take advantage of and leverage to tailor the service to our users.