A Tale of Two Platforms

August 27, 2019

Tweet This:
Share on LinkedIn:

By Steve Kaplan, Kovarus, SDDC & Cloud Management

Over the last two months or so, I’ve seemingly been having this conversation more often, so I thought it was time to sit down and write up my thoughts on what VMware is doing in the cloud management space, particularly as it relates to seemingly having two of everything. The focus for the moment will be on vRealize Automation (vRA), which runs on premises, and Cloud Automation Services (CAS), which runs as SaaS.

A Little Backstory

Going back 2–2.5 years, VMware kindly opened the secret lab just a little bit and invited myself and others to participate in the Design Partner Program (DPP) for their next-generation cloud management platform (CMP) that was in development to eventually be the successor to vRA. Internally, this was known as “Project Tango”; if you’ve seen my laptop in recent months, you’ll notice the tango logo in sticker form.

Eventually, we moved past just the monthly calls, and actually got to try these features! Between December 2017 and May 2018, I participated in two on-site betas where we gave a lot of feedback on what we were seeing / working on via labs, etc. directly to engineering, UX, and product management. If you ever have an opportunity to participate in an on-site beta with VMware, I highly recommend it.

Things got even more fun over the course of the summer, when Kovarus was part of a select group that was provided access to actively use the Tango platform to play in and provide feedback on. I wish I’d been able to dedicate more time during this stage, but life has a way getting in the way.
This is a very long way of saying that we were honestly very deeply involved in the ongoing evolution of CAS. DPP calls still happen monthly, and we routinely have anywhere from 2–5 people on them providing feedback on the featured area of focus for that month.

So, which one is right for me?

I really like this graphic as a starting point in trying to figure out which is right. There’re things today that vRA does really well and others that just aren’t so great. The decision making here boils down to asking some questions and defining requirements in assessing the right short- and long-term answer. For the purposes of this post, I’m going to focus on three primary questions I always tend to open with:

  1. What are the infrastructure providers and services that need to be integrated?
  2. What resources and services need to be consumed on that infrastructure?
  3. What governance capabilities needs to be available?

There’s a ton more topics we could include here, but usually by the time we’ve gotten through these three, we have a pretty clear handle on which way things need to be leaning.
So, let’s take a look at each of these!

Infrastructure Providers

First, let’s ask the most basic of questions: Where do provisioning operations occur? Is it an on-premises vSphere environment or consuming public cloud? Is there an ITSM tool like ServiceNow to integrate? Is NSX part of the picture? What platform is being used for configuration management?

All of those things, amongst others, become essential in sorting out whether vRA or CAS is a better fit right now. If your organization is mostly concerned with vSphere/NSX on premises and/or via VMC on AWS, vRA might be a better option. This swings even more in that direction if your organization is shifting to doing more through ServiceNow or the like, as there’s an excellent plugin for rolling up blueprint content from vRA to SNOW.


Where things get a little bit murkier is if you’re more concerned with public cloud and those services. vRA, today, frankly doesn’t offer much here beyond provisioning basic instances, whether that be AWS or Azure or GCP. Want to consume other AWS services within a native blueprint in vRA? Not happening today… but, CAS does offer a pretty wide array of cloud native services for both Azure and AWS right now, and I fully expect that GCP will catch up over time.

That being said, there’re always ways to get the job done with extensibility capabilities in vRealize Orchestrator or working with other third-party orchestration tools to consume cloud services APIs.


I have this section in here because one of the most common things that comes up with customers is that they don’t necessarily have an ITSM strategy, or they’re really looking at their CMP to provide that catalog of services and capabilities. In plain speak, that generally means having a handle on ensuring proper approval workflows are in place for catalog requests and being able to provide costs for services, whether that’s in the form of showing or charging back to the relevant entity within the organization.

It’s pretty simple here: if you care about this capability within your CMP, CAS is not going to be right for you. As of this moment, there are no approval workflows in Service Broker, the catalog component of CAS. There’s also nothing really from a costing standpoint.

In closing

This really is more of an opening / intro / primer on a few of the characteristics we’d use / talk about when working through making selections on tooling. All of these subjects could probably be their own post that goes more into depth, but these are all topics I’ve spoken with customers about in just the last 3–4 weeks, so the concepts are fresh in my head. Think of this as an opening for having a conversation about goals, both in the short and long term, as you and your organization begin having conversations around cloud strategy.

Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.

Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.