Virtualization Automation – A Proper Virtual World

How Do You Say Good Bye?

October 29th, 2009

So The Old Virtualization Platform Is Just Not Doing It for You Still (Part 2 of 2)

I suggest reading the blog entry, When Is It Time to Say Good Bye? before continuing to read this blog entry. It is not required but recommended.

Now that the decision has been made to change virtualization platforms… What is important? What should not have been forgotten or lost? What must be reaffirmed to be successful? There are three (3) tasks key to saying good bye to the declining virtualization platform, and hello to the emerging virtualization platform. All are easy to itemize, two (2) are easy to complete, and one (1) is not painless, but should be a known path, providing the lessons learned in the past are not forgotten, and the skills developed in the past are not abandoned.

• Tell the original virtualization vendor… Goodbye! It was nice knowing you, you saved us money, thanks, but don’t let the door hit you in the ass on the way out!
• Tell the new virtualization vendor… You are wonderful, but unless you are cheap, do everything we want immediately, you are gone, and you have been warned. Oh, and we signed a multiyear contract, but don’t expect it to be renewed, dude, unless your platform is better than expected.
• Find all the documentation and people that implemented the declining virtualization platform, and get the ones worth leveraging, working on the emerging virtualization platform sooner than later. What? They were laid off? Reassigned? Or otherwise been regulated to a dark corner, and do nothing but drool and speak in a weird dead language no one has heard for 100s if not 1000s of years? Say it is not so!

Now of course, there is considerable humor implied in the above characterizations. Being professional precludes some of the semantic implications, so if anyone thinks said characterizations are realistic, my honest response is… What are you smoking, dude?

What is important? Moving to an emerging virtualization platform is a new platform, and although experience is important don’t let it bite you in the ass, because you don’t realize a new platform, is just that… a new platform. All the typical stuff, technical mumbo-jumbo, so no need to dive deep into that here, the new platform should have better or be reasonable in performance context to the declining solution. If not the scale will change in significant manner, vertical because better hardware is needed, horizontal if more virtual instances are needed to get the same performance to the end-users. This impacts cost of course. The cost avoidance model will change to some degree no matter what is done, so be prepared for that situation. From physical environmental factors to logical processing factors will change; don’t let this surprise anyone, including the customers. Again, this is a new platform, respect it as such. Engineering by Fact is a good concept to keep in mind. So is Management by Fact, so once the emerging solution is designed, tested, and implemented, expect surprises and differences based on actual results and situation. Unloading one hypervisor and loading another, even when stateless makes it simplistic, is just the tip of the iceberg. Management will want to believe otherwise, don’t let that happen.

What should not have been forgotten or lost? Some will disagree with this point, saying that things are not forgotten, well, yes they are. The skills that were needed to establish a viable and robust virtualization platform are not identical to those that maintain a virtualization platform over time. This is not a classic engineering versus operational scope argument. This is talent versus skill debate. Virtualization as many of you may recall, took insight and a bit of guess work, to get it off the ground. Yes, it was new and no one really knew what the upper limits were, etc., etc. Well, once again, that mind set is needed, walk before running, when running watch out for potholes. Scaled testing in a lab is never inclusive, but the temptation will be to rely on the past. That past experience will color the results that are gained in the lab, that is one of many potholes. Application designers and developers are not going to find the emerging virtualization platform easy to understand or deal with, build into the master plan for this confusion and frustration. Remember how some issues came out of nowhere when the declining virtualization platform was implemented? It surprised more often than not, right?

What must be reaffirmed to be successful? This is the ugly question. Why? Because what is already virtualized is, just that virtualized, and will be migrated in some fashion, be it virtual-to-virtual, or OVF, or whatever, beyond the performance and response differences, and the resulting marginal costing delta big or small, it is not low hanging fruit as once was the case. Those days are gone. If this migration is the first from the very first virtualization platform, this is going to be a culture shock event. Massive cost avoidance, beyond the savings (hope it is savings) of virtualization vendor licensing fees, is or has been accrued and tabulated in seconds, so that easy gainer is toast. Long term success now is based on incremental cost savings per host, per virtual instance, per flexibility of environment as managed, cough, cloud, or such, providing services and solutions on demand, with ease of availability.

How can ease of availability be enhanced, improved? A work-load-management solution, a deployment automation solution, and/or the use of a stateless model solution may or may not be opportunities for cost savings in the emerging virtualization platform. This is not a simple feat, if such components are or were already core to the declining virtualization solution, additional cost avoidance out of the cloud vapor, as such, may not be possible. In fact, adapting to the emerging virtualization might even increase expense sooner than later, ouch, taking time to net savings over time, ouch. Again, plan for this, control expectations, the emerging virtualization solution will need to mature and balance out within the organization, just as the declining virtualization solution did or required time to do, changing the culture of the organization, again. As my Mother, who was a manager for more than 30 years in a Fortune 10 firm was fond of reminding me… The only constant is change. To which my reply always was… Why does management always seem to forget that all change takes time? Do lt!

Entry Filed under: A Proper Virtual World