An Open Alternative to VMWare vRealize (VRA)

VMWare vRealize Automation (vRA) promises a streamlined automation platform for the provisioning of infrastructure and workloads on multiple hypervisors and the major cloud platforms including AWS, Azure, GCP etc..  It integrates with tools such as Terraform, Ansible, and Puppet, and provisions from a centralized catalog of blueprints.  All this should sound familiar to Cloudify users who enjoy these features on an open platform built to be extensible and flexible.

Organizations deciding on a multi / hybrid cloud automation platform need to plan for the growth, and place great value on extensibility. The foundation of a successful cloud strategy is an open orchestrator that can support future growth into public clouds, containers, and anything else that appears.  This is the essence of the “orchestration first” approach.  In order to facilitate a best of breed approach to orchestration, whether it be public/private clouds, deployment and configuration tools, or DevOps integrations, the flexibility and openness of the orchestrator as an integration platform is paramount.

Openness vs Meta-lockin

vRA is a traditional closed-source product that inserts a vendor controlled layer between enterprises and their cloud assets.  This produces a sort of ‘meta-lockin’, where customers are at the mercy of VMWare’s release schedule and priorities.  Prior to VMWare’s multi-cloud strategy, the only lock-in you needed to worry about was in relation to the VMWare ecosystem of products.  VMWare’s pivot to multi-cloud support has amplified the lockin, extending it beyond the VMWare ecosystem to the underlying cloud and container providers it supports.  Beyond that, the product isn’t user extensible to support arbitrary toolsets and APIs that arise on an almost daily basis.  

A truly open and agnostic platform like Cloudify doesn’t play favorites with its integration support, and is fully user extensible.  While Cloudify has a supported list of plugin integrations, it doesn’t limit users to them, permitting the use of arbitrary technology stacks.  At its core, Cloudify has a TOSCA based workflow engine which is also user extensible, permitting the automation of arbitrary day-2 operational scenarios – a capability requiring the purchase of vRealize Orchestrator (and also not open).   All of this makes Cloudify a truly user extensible automation platform free of vendor lock-in concerns.

One side effect of this openness is the synergy of tools, and this includes vRA and vSphere (and any other VMWare tech).  Cloudify’s “Orchestrator of Orchestrators” architecture means existing VMWare ecosystem investments need not be discarded, but instead they themselves can be plugged into the orchestration tool chain and used for what they are best at.  The lack of lock in also future proofs your automation, allowing you to consume arbitrary public cloud services, container services, serverless technology, etc., along with private cloud, devices, and bare metal platforms.

Pluggable vs Abstract Multi-Cloud

vRA supports multi-cloud via a cloud abstraction approach.  Abstraction always means “loss” in exchange for uniformity.  In this case, the uniformity being attempted is between resources on cloud providers.  This approach can be powerful in simple use cases, but quickly falls apart once cloud specific features are needed, which is almost always the case.   Note that vRA has to standardize across every cloud it supports; this is a disadvantage, not an advantage.  With every cloud API that is included, the abstraction gets dumbed down further.  The user has to pay this price, even if deploying to two clouds.  In fact, early versions of Cloudify chased this dream, but eventually abandoned it in favor of a plugin model.  

The plugin-based approach, which permeates Cloudify well beyond cloud infrastructure modeling, is tightly coupled to TOSCA model resources which represent cloud resources, and is cloud specific.  The plugin model provides the most flexibility.  TOSCA itself is highly extensible.  If you want an abstraction combining a couple of clouds, you can create TOSCA types to accomplish that.  If not, you can access the full power of the diverse cloud APIs using the supported plugins.  And note that Cloudify supports service level abstraction that can provide a more meaningful level of cloud abstraction.

Day 2

vRA by itself doesn’t address day 2 operations.  These responsibilities are handled elsewhere in the vRealize suite (vRO + LifeCycle manager). These introduce significant cost and complexity.  One of the key benefits of a TOSCA based approach, is that a true deployment model is defined.  The value of that model is the ability to infer day 2 (and of course day 1) operations without writing workflows.  The deployment model itself provides enough information to properly heal, scale, execute operations, and tear down deployments.  No need for a separate workflow engine or complex workflows to maintain, but custom workflows are supported if needed.  Note also that Cloudify integrates natively with Nagios for telemetry collection and automated operations.

What Now?

To conclude, for those attracted to the vRA concept, but wanting a truly open, self-contained, scalable, and extensible orchestrator, Cloudify fits the bill as a viable VRA alternative.  For those invested in the VMWare ecosystem, but wishing to future proof and expand in arbitrary directions without being tied to the VMWare release cycle, service teams, and VMWare costs, Cloudify fits the bill.  Cloudify offers a free trial to explore what a truly open orchestrator can provide.