While installing and configuring vCloud Director recently, I kept thinking how to simplify it by removing un-necessary concepts and steps. To be fair, vCloud Director as of version 1.5 does a decent job to provide a high level abstraction for cloud infrastructure. Still it can be significantly improved just like every other new technology. Note that I pick vCloud Director as an example for the following discussion simply because VMware is the leader in virtualization space and what it does has ripple effects on other vendors.
To make things simpler, we have to answer a fundamental question on the marketecture: how should VMware position vCenter and vCloud Director in its product portfolio? Should their relationship be like application to application? Or should it be middleware to application?
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
I don’t think anyone has a clear answer, at least not yet reflected in the vCloud product itself. On one hand, it’s like and in fact intended to be middleware to application because vCloud Director depends on vSphere; on the other hand, it’s like application to application because you have to use vCenter to do all the basic configurations before vCloud Director can be installed and configured.
The current situation reminds me of early days of database as middleware: before you run your application, you first need to install your database separately and configure it manually to meet the requirements of the application, which includes manually run SQL scripts to create database tables in the database. You may wonder why not hide the database from the application administrators and users. Well, that is part of the history. Before it’s clear to everyone that database should be middleware, it’s natural to do that way.
I think we are at the similar turning point today in the virtualization management space where we should clearly divide the layers: hypervisors, middleware, and applications. For the hypervisors, there is little doubt. For the upper two layers, there could be confusions about what should go which layer, and more importantly where should be the right boundary of the virtualization management middleware and application.
Luckily we have a good example here. In my opinion, vCenter should be a middleware, and vCloud Director should be an application along with other applications.
The change of mindset is important. With that, we should first hide vCenter and any other related building blocks like vShield, just like in vCenter you don’t feel the existence of a database unless you intentionally dig into it.
Of course, you still need to install and configure vCenter, but do so within vCloud Director installer. Let me borrow an example from database world: your application installs a database and connects to it programmatically for creating new database tables and whatever preloaded datasets.
Following the same idea, vCloud Director should do the same: silently install a vCenter and create whatever provider datacenter programmatically. When that happens, I think the complexity exposed to the cloud administrators can be significantly reduced.
Although I used VMware as an example here, the principles are also applicable for other vendors like Citrix, Microsoft, Red Hat, and Oracle in their virtualization management stacks.
With the right separation of virtualization middleware, there could be a rich portfolio of applications merging in the marketplace, and driving virtualization and enterprise IT management to next level. Companies that do it right can further penetrate the market and win more market shares.
Note: this article talks about virtualization management middleware, not the middleware virtualization which is a different topic.