Virtualization Adoption Strategies Visited
Virtualization Critical Evaluation – Chapter 12
Fired up the good old iPod, old since it is an original Video iPod via iTunes, which compared to the iPod Touch, is more than obsolete, try comparing a Ford Model-T to a SmartCar, and although they seem similar in some ways they are worlds apart. The iTunes semi-randomization or shuffle playlist selected Depeche Mode, Music for the Masses, which has a number of songs that just happen to match the topic for this blog entry. For those that are not Depeche Mode fans, the song…Never Let Me Down Again…is the song I am referring to among others. This specific song always seems to come to mind when I look at general release code that something-dot-zero. What is it about 1.0, 2.0, 3.0, etc., as a concept, which always freaks me out? It is not as though .0 releases are always good, bad or ugly, is it? What is the old axiom from my business undergraduate degree days? Oh, yes… Never buy an automobile from Detroit that was made on Monday.
There are, from my perspective three (3) basic scenarios for adoption of a new architecture/solution/infrastructure. This is not rocket-science more Common Sense, versus Profit Driven, versus how should I say this… Just-Must-Have? The definitions of the three approaches are outlined below per my perspective.
- Common Sense – Cool your jets cadet, what many would call a late-adopter strategy. That really does describe the concept. Let someone else break their teeth on the newest release. In the case of VMware, which I would call middle of road in the quality of release code, it is Update 1 or version .0.1, which achieves the next order of magnitude, and is a reasonable bug-less state. No I am not saying VMware, Xen, or even Microsoft released horrible release code, which at times they have done, only that every code shop must at some point declare a .0 release as done, and prioritize any remaining issues for resolution in the next incremental release. In virtualization, this is significant, because of the eggs-all-in-one-basket issue with virtualization hosts. An issue on a host is always a factor times 16, 20, 24, or more, since multiple virtual instances are often impacted. It is not uncommon for some firms to let a general release, that is .0, mature, 90 or 120 days. In the case of ESX 3.0, given some nasty issues, and a major change in the ESX OS for a number of reasons, I know of one firm that waited more than 6 months to adopt a well patched ESX 3.0.1 before leaving ESX 2.5.2 after several years on 2.5.2. Yes, 2.5.2, it was stable and consistent for them, so moving to ESX 3.0 soon was not reasonable.
- Profit Driven – This is similar to an early-adapter model, with the motivation specific to the situation. There can be a situation where a given general release has features or even fixes that the older major version just does not have or will never achieve, the newest version must be leveraged. Or the situation is such that to wait for a less painful implementation is a significant opportunity cost, or even competitive advantage issue. What pain is encountered with the .0 release is deemed acceptable because a significant feature is critical to near future success? The term bleeding edge is sometimes referenced for this scenario, but that is misleading, at least from my point of view. I would define the bleeding edge as implementing production on release candidate code, rather than general release code. Microsoft at times has done this, on their internal infrastructure, for example this was done with Hyper-V, since Microsoft deemed the later versions of Hyper-V stable enough for such action before the official general release was out the door.
- Just-Must-Have – This approach is often confused with the Profit Driven approach. Management is profit driven, but there are personalities in the command structure that just want the latest and greatest, or the next wonder solution, because they can mandate it. Of course all the official communication will define the demand for action in a profit justification, the market share versus competitive feature set, buzz words inclusive. But in truth somewhere in the dark, someone just wants the latest new toy. New toys cost real money, in training, issue resolution, and mistakes, throughout the entire vertical product stream, from OEM to customer. Consider that there is always someone, somewhere, that needs the latest and greatest. Think about it, was there not someone you knew that had a High Definition (HD) television that was $10,000 or more, and there were at most a handful of television shows in HD? And how often did that wonderful HD unit fail? Was the service contract at least 10% of the total purchase cost, if not more? Now the same basic television, about 5 years later is around $600, and still HD television is not universal across the board? Thank goodness virtualization assimilation is not quite that slow!
Now, I am sure some are wondering what my strategy is? Well, let me explain it this way. Yes, I own a SmartCar. No, I did not get it right away, so I did not exhibit the Just-Must-Have approach. Although, I have a close relative that did get a SmartCar very soon after they came to the United States, and yes, they experienced some issues about 1 week after they got it. Some will say, but the SmartCar has been around in Europe for years, true, but driving in Europe is not the same as in most of the United States. So, did I exhibit the Profit-Driven approach? Yes and No. Yes, in that I decided and ordered my SmartCar when fuel costs where well over $4.00 US. No, in the sense that the SmartCar had been in the United States for about 18 months before I got mine, given that there was about a 6 month queue between order and receipt of a SmartCar. So I would say my approach was part Common-Sense, but not completely.
As for virtualization adoption, specific to .0 releases? I never recommend anything but the Common-Sense approach. This is regardless of the vendor, the situation or the environment selected. Virtualization should be stable, safe, and consistent, if not, it generates more headaches than anyone should have to deal with, never mind the endless-seeming long days, and very odd hours on the phone with vendor technical support, where we are all scratching our heads. True, I often get yelled at for this, and at times it has been at the expense of my personal standing or reputation! However, history has proven, I have been right, and the very same individuals that absolutely hated my view on virtualization adoption, with reluctant, grudging omission, noted I was after all, correct. In the course of time, those that disagreed have been mollified if not thankful for my stubborn stance on late adoption of virtualization, when it comes to .0 release implementations or infrastructure migrations to same.
Some will ask, why this topic now? That is a good question. With the recent release of vSphere 1.0 (insert polite cough here), including vCenter 4.0, ESX/ESXi 4.0, etc., moreover, Microsoft Windows 2008 R2, with some key features that support improved Hyper-V platform use and function, for example, the Clustered Shared Volume (CSV) 1.0 feature coming into its own. Not to ignore, RHEL 5.4 with KVM .83, .84, or maybe even .85, thus approaching KVM 1.0? Now seemed a reasonable.
3 comments June 9th, 2009
