Archive for March, 2010

VMware and the Future of Open Source Interconnected?

Where will VMware be in 2015?

Yes, if you have not read the subtitle, stop, and read it. Yes, it really does say 2015! Why does it say 2015? Because the IT industry has blinders on, because the IT industry is so buried, wrapped, fascinated, engrossed, paranoid, and infatuated with Cloud computing, it will dominate thinking for years to come. Everyone is chasing the clouds, busting clouds.

What is cloud computing as a strategic concept? Cost reduction? Resource reduction? Efficiency? Effectiveness? Ease of use, ease of provisioning and deployment? No to all of these at least for now. Ever notice that no one is publishing financial numbers on cloud development and implementation? IBM has even pulled its aggressive cloud oriented commercials that were everywhere a year ago? Why? Because getting a cloud to float skyward, to defy gravity, rather than sit like a rock on the ground, is one step short of magic straight out of a Harry Potter story, and takes real money, lots of real money to make it happen. And that money is hard to find outside of a few Fortune 50 firms given the current economic instability and the squish expectations for the next couple years, no disrespect to the Obama administration, all wearing rose colored glasses. There are more slap-stick-happy vendors hawking capacity, provisioning, and control application frameworks to corporate IT organizations than ever before, and some are making big money at it, if you believe the vendors are not eating their own dog food, by providing clouding enablers or clouding building blocks, not complete cloud solutions, not complete monolithic cloud frameworks. No one vendor can be all things to all customers is the true theme of cloud busting, cough, cloud design, no disrespect to IBM, but IBM cheats, IBM has so many products in so many areas, they are in a unique position, to appear to be one vendor, but at least from my perspective, operation as many individual solutions under one label.

Even Google and Amazon have stated in various ways, an odd speculative silence, by not explaining some aspects of their respective environments, stating competitive advantage or corporate secrets? However, it may be that building a true responsive resource driven dynamic balancing computing organism , took many years to establish, quantify, qualify, and perfect, well if not perfect, at the least a viable construct, with a reasonable expectation of positive ROI plausible at some point in the future. Most of what the rest of the IT industry has seen, is just results of 5 or realistically closer to 10 years of effort. The actual results from top of the line design, enlightened, vaporous dream before concrete substance in architectural engineering and operational implementation of computing. They guessed, and guessed right. It could have gone wrong, very wrong. It could have been a great solution still looking for a problem if, Google had lost the search engine wars, if Amazon had continued to bleed capital as it did from 1995 to 2001 .

Clouding, is expensive, complex, and it eats careers like five year olds going after candy when a piñata is cracked open wide by a broom handle, or even better a baseball bat. I have watched grown men, collapse into mumbling masses of Jell-O before my conference call virtual eyes, at the words… Work-Load-Manager.  Planning to move is one thing, and doing the actual move to cloud based computing is another ( Clouding is an example of easier-said-than-done to be sure.

What does this have to do with Open Source? Well, clouding is incompatible with (classic or traditional) open source! Oh, geez, I can hear the naysayers now… yelling at me, that is just bullocks, cough, bollocks, plain and simple! However, before you go into the garage and look for that jar of tar you have been saving to use on me, and decide to recycle that old feather pillow in a responsible manner. Or think of burning the A Proper Virtual World blog title in 6 foot letters made of good old Southern Pine driven into the ground in my front yard, wearing funny shaped hats popular by crazy radicals about 60 years ago, hear me out.

I am concerned that the loser in this Clash of Titans as it might be objectively classified, not to be confused with the fantasy B class movie of the same name in 1981, will be Open Source. Sure, the pillars of the many cloud solutions will have aspects of components, tools, and such, that where once open-source by origination, but corporate IT does not lay out millions on open-source solutions that do not have at some point a commercial and accountable entity that can be called out on the carpet to respond for bugs, issues, never mind a solid and significant long term strategy for design, development, and implementation to achieve consistent and considerable value for dollar longevity, that the various elements any cloud environment must integrate. For example, DeltaCloud ( is a great idea, but it is not a complete solution. Moreover, unless some commercial entity is in real control, and is successful in getting anyone to adopt it? Ideas like DeltaCloud have a future that is questionable, and that very sense of accountability, ownership, and control that is demanded, defeats the flexibility of open source. So is open source that is managed and driven like a commercial solution still viable as open source? Red Hat for example, has Fedora Linux, it is a flavor of open source but could be classified as an open beta or long lived release candidate platform perfecting features expected to be integrated to the commercial solution, Red Hat Enterprise Linux. Don’t believe it is so, fine, your rose colored glasses are sliding off your nose.

Clouds once implemented will be around for decades, not just years, efficaciously maturing and growing in complexity. The commitment of time, effort, etc., if not energy, does not make sense unless the cloud will be strategic and a stable entity in its own right once alive. Furthermore, in computing terms… geological in speed, in reference to change, clouds will not change integrated components fast. Change in a cloud is more like moves between tectonic plates. No, I am not talking about growth of the cloud scope in reference to capacity, logical enhancements, etc., but change of the actual foundational vendors and solution components, upon which an enterprise scale cloud is built upon. For example, moving from VMware to KVM, or even Hyper-V, it takes a long time.

So, why did I mention VMware in the title? Get your game on, because I am about to crack open the piñata… VMware has a unique opportunity, but will miss it unless a few critical things happen, now, changing the current mindset, so that new ideas are reflected, in the solutions that materialize in the future:

  • First and I hope it is sooner than later, VMware changes vCenter. VMware has hinted at this, but for 2 years of hints nothing has resulted. The enterprise view or federated view? Please that was nothing, from a customer perspective, but an additional plug-in in context. Every single negative comment I heard for the last 2 VMworld sessions, had somewhere and in some part a reference to vCenter and its current as well as past history of performance issues, stability issues at enterprise scale, and the completely horrible performance of the published VMware API (SDK). Note for the record, the term horrible is a not my characterization but those of several developers/publishers either overheard or which volunteered the term as a negative descriptor in informal and unprompted conversation. Many of these developers are also, by chance open source active, very active in some cases.
  • Second VMware has two very real and significant threats coming on fast. Which yes, I have warned of months ago or longer. RedHat RHEV, which is plagued by some real issues, but by 2012 should gain market share fast. RHEV is aimed right at VMware, right at its foundation… ESXi. Microsoft Hyper-V R2 with the Clustered Share Volume (CSV) feature, and almost as good Live Migration in direct comparison to VMotion, only needs to support NAS, I would say specifically NFS, to scare VMware silly. Some still say Hyper-V comes up short, but since VMware has given Microsoft 4 years to get something plausible to the table, 2 more years does not seem that long does it? Just imagine what Red Hat will or could do in 6 years with RHEV? Neither Hyper-V nor RHEV (well KVM at least) are locked into their respective management solutions as the only realistic control surface, to the same extent that ESX and to a further extent ESXi are to poor vCenter.

VMware is not a cloud creator or framework owner, but a cloud component, to think otherwise is nearsighted. Streaming of applications and services will gain ground, the importance of all OSes, will be similar to what the OS is now on cell phones today, something no one even thinks about. So will the hypervisor become over time, if not less significant. Virtual machines will get thinner and lighter because of stateless deployment methods and application streaming, than anything strategic or radical in the design in the next generation hypervisor. In truth, I wish EMC would sell VMware to a cloud component vendor. Such a deal would be one way for VMware to get through the pain of changing its view of its-self. VMware should be focusing on being a very good cloud component technology and nothing more, changing its cost model from that of Neiman Marcus to Wal-Mart, becoming a key, but cost sensitive element of a total cloud solution retargeting as their strategic focus. The days of being all things to all are over for VMware. VMware vSphere was an interesting idea, at least to the VMware marketing brains, but it is already showing its age. Monolithic ownership both horizontal and vertical is a dinosaur in corporate IT, much too heavy for the cloud mindset of the future. Single vendor solutions just are not as flexible as they once were. Maybe corporate IT has outgrown the one vendor, one-point of accountability mindset, lost is zeal for expensive, restrictive frameworks that force customers to follow the vendor roadmap or timeline? Remember what happen to the dinosaurs?

Even if VMware changed direction the very second this blog is read for the first time, it would be 2015 before VMware would realign its strategic direction, and have viable solutions for sale based on the speed at which VMware moves looking at past VMware evidence of change. Wal-Mart, as a high volume low cost organization, is nailing the competition world-wide, is that a lesson that VMware can ignore? Open source will always exist, but the variants of open source that enterprise customers purchase will be in the hands of a few significant commercial firms? Maybe not. VMware will have to be a leaner, meaner, organization in 2015 to survive if not hold market share. Focusing on a strong and well understood niche would allow VMware to combat RHEV and Hyper-V toe to toe. Undercutting the most significant advantage that RHEV and Hyper-V have, less cost than VMware.

Does VMware want to mature like Apple Computer? Have great solutions, but only about 20% of the market? Apple may own the mobile music market, but not the mobile phone, or laptop market. Is total cloud ownership realistic for VMware? That is what VMware tried to do.  Don’t let anyone tell you different. The vSphere concept was aimed at cloud ownership, to position vCenter as the authority of a cloud, maturing into the dominate entity in the cloud. Anyone that says otherwise is not seeing big picture from the VMware perspective over the last year, and the next few years. Unfortunately vCenter its-self, never mind the published VMware API/SDK, is not sufficient to interconnect even the few vCenter enhancement/add-on vendors needed to establish the most basic of clouds. I think VMware thought they would have more time to get vCenter right.

Nope. So, vCenter becomes little more than a communication proxy driven by force, top down, since no other option is possible, if ESXi or ESX is to be used. This leaves a wide open opportunity for any other hypervisor to improve its interoperability within a cloud. In a sense, vCenter has not protected VMware, nor has it established a solid foundation for VMware to move into a cloud ownership position, but backfired on VMware.

1 comment March 30th, 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:

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


March 2010
« Feb   Apr »

Posts by Month

Posts by Category