While my title is a little facetious, I’ve been meaning to discuss VMware vCloud Director from the big picture and what it means for our Providers and cloud consumers.
To start out, this is my opinion only and not a reflection of my employer. I am also going to stipulate that I’m bringing a newer opinion to vCloud Director as I’ve only immersed myself into vCD for the past year or so.
During my tenure at VMware, it seems there’s a common thread or opinion where many people (internally and externally) believe vCloud Director is no longer a viable or supported product. After understanding some of the past decisions, I can understand some of this perception, but this is definitely not the case. In this post, I’d like to “clear the air” on a few items I hear quite often.
This is going to be boiled down to the following points:
- So, is vCloud Director dead?
- vCloud Director is hard to use.
- But what about vRealize Automation / VMware Cloud on AWS vs. vCD?
- vCD is not about IaaS anymore.
So, is vCloud Director dead?
It is not. Currently, vCloud Director for Service Providers (vCD) is only available for new providers inside of the VMware Cloud Provider Program. There are some exceptions (entities that owned vCD before there was a directional change) but this is the only way to procure vCD at this time.
Moreover, the development lifecycle has significantly increased in the time I’ve been here. When I joined VMware, we just released vCD 8.20. Since then, we’ve had version 9.0 and 9.1 come out with some significant additions – this presents a picture that one should expect vCloud Director additions every six months. Below is what we’ve delivered in the past few years –
While I won’t comment about futures of vCD, one can already see the direction VMware is going with vCloud Director – enabling ease of consumption in a multi-tenancy architecture.
vCloud Director is hard to use.
I’ll agree with this commentary – in the past. Starting with 8.20, VMware introduced the Advanced Networking HTML5 interface as the first foray into a newer, streamlined interface that’s not based on Flash.
Within version 9.0, the first phase of the HTML5 Tenant UI was rolled out. 9.1 added additional content along with the first (albeit limited) release of the Provider UI. 9.1 added the HTML5 web console, HTML5 OVA import, and integration with the VM Remote Console – mitigates most of the complaints I hear from end-user experience.
The overall goal of the interface is to provide a streamlined user experience. Currently, there are advisory boards going on reviewing what’s needed from the provider and tenant UI experience. I can tell you this is top of mind for everyone in the team.
Here are some of the tenant experiences from the 9.x interface –
We can see the multi-site view from here –
While 9.1 now has the Provider UI. Again, the first iteration but gives you a feel for what’s available today –
As you can see above, I’m highlighting the new integration of vRealize Orchestrator (vRO) inside of vCloud Director. This allows us to provide XaaS which many of you are well aware of its comprehensive capability inside of vRA and other automation solutions.
But what about vRealize Automation / VMware Cloud on AWS versus vCloud Director?
Let’s nip this in the bud – it should NOT be about competing solutions when we discuss use cases. Today, many of our Providers run BOTH vCD and vRA in their environment serving different use cases! Both have great use cases and are based on what the design requirements dictate. I can think of one provider I collaborate with that utilizes vRA for dedicated private cloud environments while allowing their tenants to carve out VM’s when required in their vCD environment.
With the newest release of the VMware Cloud on AWS Managed Service Provider (MSP) platform, this will also be another function for Providers. It should not be about either-or, but more of how does it solve X…
Ultimately, this comes down to two things:
- Use Cases
- Customer Experience and Expectations
First, let’s cover vRA –
Today, vRealize Automation and vCloud Director can integrate with one another. vRA can call vCD as an endpoint and automate vApp/VM creation. Moreover, they serve two different landscapes from a provider experience. I wouldn’t disagree that vRA has refined services platform capability but today it cannot provide provider-level multi-tenancy. Let me make this clear – vRealize Automation and vCloud Director are great products. It just boils down to what you’re trying to achieve.
Below is a comparison sheet I’ve used in the past when talking to Providers about the differences between vCD and vRA – some of the points can be argued either way but gives a high-level idea of the capabilities between the two solutions. Advanced Services Designer (XaaS) has a half check mark for vCD since it’s not as comprehensive as vRA.
Let’s briefly talk about VMware on AWS. This is an amazing way of providing an entire Software-Defined Data Center (SDDC) stack inside of a hyperscale environment in a matter of a few hours – from start to finish. This also fills a need for Virtualization teams that want a vCenter-like user experience in a cloud environment.
However, in the context of vCloud Director, couldn’t this just be another Provider VDC we could call on to gain additional resources? Please do not take this as a directional statement as it’s not (and not supported today) – but the point I’m making here is vCD with VMware Cloud brings quite a bit of possibility.
The point is vCloud Director can add value to any type of elastic model. Who knows what the future can bring?
vCD is not about IaaS anymore.
Sure, vCloud Director got its start around Infrastructure as a Service. I think we can all agree that the technology field as changed quite a bit when the first iteration of vCD was released.
I see vCloud Director evolving into this Services Platform that is much more than just IaaS. I believe this is a fair term, especially on what was released with the most recent versions. Let’s go into some of the details on why I believe that.
vRealize Orchestrator Integration – XaaS anything
This is a big one. We can now provide native integration to any type of vRO workflow – think of the possibilities:
- Ticketing System
- Backup Request
- Provision a Service
I know our team is working on bringing additional examples to market, so stay tuned for those.
Container Service Extension / Python CLI and vCD CLI
To cover the Container Service Extension (CSE), vCD 9.1 introduced the ability to support lifecycle management of K8s clusters through this extension. Cluster nodes are treated the same as VM’s while adding provider and tenant authorization, authentication, and metering per tenant.
Moreover, this is another net new line of capability inside of vCloud Director that Providers can harness.
The Python SDK and vCD-CLI were revived with 9.1 and updated on the GitHub locations (Python SDK here and vCD-CLI here). This allows admins and tenants to perform operations from the command line while getting full support for these operations.
The intent was to open-source this to get community feedback. If there’s something you’d like to see, please tell us!
This will evolve as this will be a play for our ecosystem partners. As I understand it, this is an Angular framework that can allow integration for pretty much anything inside of vCloud Director. Below is an example of a Ticketing system integrated into vCloud Director.
This will continue to evolve, but a Provider can use this framework and integrate pretty much anything inside of vCloud Director to provide a seamless experience.
So for those of you that tl;dr’d this blog post, let me sum it up – #longlivevCD 🙂
In all honesty, I’m very excited to see what the VMware Cloud Provider team brings next to vCloud Director because it continues to get better and better. This isn’t just me saying it too – talk to your network of Cloud Providers.
Cheers, and long live vCD!