Today’s Blog is a guest blog by Brian Emerson, Sr. Director of Product Management for our BMC Cloud Lifecycle Management solution.
I just got through watching the VMworld EMEA keynote online (having to miss a trip to Barcelona) and it has left me wondering, in fact, wanting to see more. A big part of the keynote was focused on the announcement of VMW’s “next generation” management suite. Well, I guess in fact the next generation comes after the previous generation and the circle of life continues.
Overall it seemed to be a rehash of what everyone already knew minus the extremely cool new name for DynamicOps. Are you ready for it? Automation Center. But don’t worry, this is a different automation solution – different from vCloud Director. And compared to vFabric Application Director. And also vCenter Orchestrator (previously Dunes). And also vCenter Configuration Manager (previously ConfigureSoft). So I’ve got three questions:
- Why does a “next generation, only VMware really gets cloud management” suite include 5 overlapping automation products?
- How are customers supposed to weed through the differences?
- Is this really what a cloud management platform should be?
So let me try to address these one at a time:
Because it can. Lets face it. VMW has a mass amount of developers they need to keep busy. And what better way to do this than creating disparate automation tools? But seriously, the problem is based on misalignment with customer expectations over the years on what management really means. This is my take on how it all went down:
Lab Manager had self-service but was not a “cloud,” so they built vCloud Director, which actually solved almost the same set of use cases as Lab Manager (and I won’t even get into Stage Manager and Lifecycle Manager, both now dead to the world)…but it is now “Cloud.” vCD was a closed system that did not integrate with outside tools, and in particular processes that customers deem critical to IT operations…oops. So, vCenter Orchestrator to the rescue as a way to integrate vCD with backend systems.
But what about the front end governance for self-service? No problem, we’ll create VMware Service Manager (now also dead after only a year…didn’t they announce this as a new product at the last VMWorld?) as a policy based front end to vCD. But Service Manager was really a last ditch effort to save the Infra assets (where are those now by the way?) and was too limiting to be of any real value to customers.
So, plan B (or is it C, D or E?). Acquire Dynamic Ops as our “next generation” Seriously? And there is one more wonderful thing to add…Dynamic Ops doesn’t solve the application provisioning problem. No worries, we have App Director to handle that piece.
Welcome everyone to the world of next gen cloud management. So my final answer to this question: they had to pull together a story fast to stay in the management game and had no other choice than to pull from their existing bag of tricks. But I will give them credit on weaving a marketing message that obscures the product madness …abracadabra!
#1 translates into not just a problem for VMware, but also for VMware customers. Outside of the arm-waving marketing of an integrated suite, customers are left filtering through multiple self-service portals, different configuration tools for each solution, and overlapping functionality.
Now granted, many management vendors have suffered from the same problems and have spent years bringing together their disparate tools (and many are not there yet and may never be). But VMware is just getting started on dealing with this mess. And unfortunately there is no short-term answer to this question other than: Be prepared to wade through it.
And we now come to one of the biggest issues. The challenge with the disparate tools approach to management is that it becomes hard, if not impossible, to create a centralized way of delivering highly available services that can be consistently governed by IT. For example, a provisioning request through a tool like DynamicOps can be controlled via IT policy that might say, for example, that approval is required. But if you now want to provision an application, you’d go to vFabric App Director, which would not conform to the same governance model defined within DynamicOps. If you provision through just vCD self service you also miss the same level of governance
So the bad news is that true service governance will now rely on IT tracking policies and rules for different provisioning scenarios in a manual way. And that is just the governance piece for a VMW only stack…what about non-VMW platforms?
I could continue on how this approach also makes it extremely challenging for IT Ops to consistently manage operations and health around service provisioned in the cloud. But I will hold that for a future post.
For now, let’s use this as a succinct lesson on why management vendors are different from platform vendors. Here’s to next-gen cloud management! Cheers!