Archive for March 15th, 2010

VMware API Performance AWOL

Virtualization Critical Evaluation – Chapter 13

Now, having been a developer off and on in my information technology career, I have come across both good and bad IDEs, good and bad SDKs, etc. And I have seen more CLIs than most. Of course logical structure, ease of use, consistent presentation of design, performance, etc., are important, and when this is not the case developers tend to be rather vocal and critical. Oh to be honest, developers can be downright nasty and brutal when something is subpar.
Of course the VMware API/SDKU has some fans and enemies. Using the vSphere API is a love and hate relationship for me as well. Using the PowerShell CLI or the Remote Perl CLI for vSphere promotes this positive and negative perception as well for me. Nor is my view, a minority from those that I have queried on this subject. Every single developer I have discussed the situation with that has any significant experience with the VMware API/SDK, states with routine if not eerie consistency the VMware API, is, well, just odd. Yes the term odd is often quoted. There are other comments that are made as well, including difficult, confusing, complex, horrible, powerful but crippled.

I would not call the VMware API or SDK the hardest I have ever used, but it is by far, one of the most frustrating APIs I have experienced thus far. I find often that when using calls in the VMware API, it is clear that something is missing in the logical design of the API, that it often takes multiple iterations of the API calls to get the most obvious features functional, if not gain access to basic information. Layers upon layers, object upon objects. This raises the question, which I have heard voiced many times by others and thought so myself; something to the effect… hey, just who or whom is talking to the developers in the greater VMware developer community? Is the message not getting to the right people in VMware?

For the sake of discussion, given that API/SDK design evaluation can be subjective unless compared to other APIs/SDKs. The single most important design factor for the vSphere API should have been performance, and if it was, it did not translate well into the CLIs or appear to be so when dealing with vCenter. VMware has trouble with this as well, the performance lost is translation that is, and acknowledges it to an extent as well, if indirectly, if you don’t believe me look at the knowledge base article at the following URL:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003708.

Of key interest to me, is the quote… The KB is currently in review. Please check back later for updated information. Thank you for your patience. What impression should result from this statement? Since this web page states that KB article #1003708 was updated August 14, 2009. It is now almost 6 months later? I really hope this was an oversight, given that the title of the article is Performance Improvements with Virtual Infrastructure API 2.5. Yes, of course this is 2.5 and not 4.0, but I have yet to find a similar document specific to the vSphere API. If it does exist, I would love for someone to show it to me, post the URL, something. I cannot believe that VMware is silent on API performance, that would just be, to be explicit… wrong, if not bad form.

Why am I concerned with VMware API performance? In other words, I am concerned about vCenter scaling, and have been for some time, it is not improving in any realistic sense from my perspective. Scaling is only as good as the performance, and to be bunt and frank, vCenter, since version 1.3, just has not been a performer, and given the feedback I have received, VirtualCenter a.k.a. vCenter, has been dogged by performance issues both from an automation perspective, via API/SDK, as well as a GUI context since 1.3. This is fact not fiction. Moreover, as the scale increases, regardless of hardware thrown at the situation, vCenter has issues that cripple its future benefit with each successive development and release of the vCenter component of VMware virtual infrastructure, without radical change.

The vast expanse of vCenter enhancement products, solutions, and frameworks do little to help the situation. In fact, these various add-ons further aggregate the situation. The solution of course, is to change the architecture of vCenter, and at least consider changing the operating system platforms that support vCenter, be it Windows or Linux, each operating system scales from foundational design induced constraints. Thus such limitations bind vCenter, in its current iteration, to a finite scale and scope that is enterprise in name only, never mind cloud oriented scale. Some have suggested that a Linux based vCenter server is one possible solution. Or that the current vCenter architecture is under review. Well, these options need serious consideration, no, these options need to be explored and implemented. Enterprise, moreover, Cloud customers are not thrilled with vCenter and its quirky performance and inconsistent behavior at advertised and thus approved/supported greater scale.

It is not ironic that the greater strength of the vSphere environment, vCenter is also, with considerable credibility from a rather diverse group of developers and users, its weakest link? Consider that the ultimate virtualization survivor will be the one that scales at enterprise scale at a minimum, and realistic cloud scale, where 100s of hosts under extensive load, with 1000s of virtual instances doing real stress level work, and performs better than expected. Cloud computing demands this, requires this. Unfortunate, but true for VMware, the arguable industry leader appears to be struggling with these goals. HA & DRS needed real work to work at any serious cloud significant scale, and the API/SDK is showing its limitations when driven as an automation appliance. It is clear vCenter cannot handle multiple entities or even multiple sessions demanded via MOB, SOAP, etc., context for cloud computing. So, the question is, will this be the key issue that allows KVM, RHEV, Oracle VM, or Hyper-V, nail VMware against the wall? The wall of obsolescence? VMware has painted a rather large target on its self which sooner rather than later, some other competitor is going to score a hit dead center on? Virtualization is moving to a Wal-Mart style, or volume based model. PODs, Clouds, etc. all require this, and the actual design of vCenter, and the associated API/SDK, at least from my perspective is still a boutique style solution, it does not perform great, not as easy to use as it should be, and as VMware adds features without redesign of the foundation?

Well, only time will tell. DeltaCloud and similar solutions by other providers are looking down their collective sights at that large painted target on VMware, and their respective ability to aim, is improving all the time. I would not be surprised if someone has a replacement for vCenter in development if not nearing release, such that it drives ESXi better than VMware does? What a radical idea. Would that shake the virtualization world? That someone other than VMware has unchained the potential of the VMware API, such, that their respective solution out performs vCenter. Wow, that would make quite a few VMware customers ecstatic! Talk about a state of bliss.

Add comment March 15th, 2010




Calendar

March 2010
M T W T F S S
« Feb   Apr »
1234567
891011121314
15161718192021
22232425262728
293031  

Posts by Month

Posts by Category