OK. I couldn't resist given the recent eWeek article on The Dark Side of Virtualization.
I stipulate to the article's author and its source Bob Waldie, CEO of Opengear, that virtualization can bring some challenges. But, I would harken the situation as more like the picture of Dorian Gray than some amorphous dark side.
The challenges that come from adopting virtualization are mostly a function of the things you are already doing wrong. The reason IT is complex and expensive is certain fundamental IT processes are broken already - and putting them under the stress of the agility of server devices and the number of server devices that are possible is just too much. Businesses do not have a limited appetite for the number of problems they want to solve using IT, they have a limit to the amount of IT complexity they can manage. Thus, they fall far short of their business aspirations because of what amounts to being technology management limitations.
So, let's look at the bright side where using a platform like Elastic Server can help you win in the epic battles of good vs. evil, light vs. dark, and Matt Damon vs. Mark Wahlberg.
eWeek #1) Are you sure that virtualization will, in reality, deliver you a positive ROI? (Translation: Increased management and administration costs may prevent this)
This is the easy one. Even in the most minimal case - this is a no brainer of slightly lower admin costs - lower capital costs and a shift of capital costs to operating costs.
Here is an example:
- you have 20 physical servers - and you consolidate them into 20 VMs running on 10 servers
THEN:
- you have fewer moving parts that can fail and plugs that can be unplugged
- you have slightly higher concentration risk (2 logical servers fail in the event of one physical server fail)
- you have halved your floor space needs (ok think of a tiny datacenter with 20 towers standing neatly at attention)
- but you still have the same logical footprint of 20 servers (no increase, no dcrease)
- you did this consolidation as hardware reached the end of its lifecycle
- you didn't buy 10 new servers (you saved the money of new hardware)
- you saved the cost of installing the new hardware with specific applications on the hard drives
- when you acquire the next new machine, installation of the virtual machine capable software (the hypervisor) is installed by Dell (or in the odd event you don't buy from Dell, some other hardware vendor)
- when the new server arrives you plug it in, and filecopy the 2 virtual machines from the old server (basically filecopy of 2 files) to the new server during your maintenance window
- you fire the VMs up on the new server
- you unplug the old server
- you throw it away
"AHA" - you shout, "There is a dark side! What if I have a high turnover environment where we need to be re-building our servers all the time?" This is where things get bright. The more dynamic the environment the more likely what you want is not "P2V" - but "Z2V" (zero footprint to virtual servers).
This is the gist of what the Elastic Server platform can do for you. With a little bit of work you capture those server definitions as templates which can be easily modified and assembled on demand in the virtualization format of your choice - without there ever having been a physical server. There is no server, click a button, now there is a virtual server ready to roll out to your virtualized infrastructure. Magic!
eWeek #2) Do you have the IT staff to deal with increased complexity? (Translation: Virtualization is complex)
IT is complex. One of the things that drives this type of IT complexity is the practice and belief that servers are hard to configure and deploy (and redeploy). This is true but doesn't need to be true. Let's look at the timeline and how we got here:
1988: Compile C code into an executable, copy that single file to a server. Proc it up. Done.
1998: Pile a bunch of HTML files into a Apache, WAR up some Java code. Done.
2008 (V1): Gather up tens of thousands if not hundreds of thousands of files, 2/3s of which will never see a compiler, gotten from between a dozen and 100 open source and commercial source frameworks, each of which is understood by a subset of your development teams, and not very weel by your operations teams and consistently get those files into the right places on the server. (Magic files, in magic formats, deployed to magic locations on the hard drive, in the thousands.) The state of the art of the process ranges from "done by hand" to "maven scripts that almost any Tom, Delilah, or Harry can change".
2008 (V2): Incrementally import each of the libraries into the Elastic Server platform (into a private repository or a community repository). Capture the semantics of how you want them to behave in assembly time scripts or runtime scripts. Mix and match them for the server targets you want to create. Click "assemble" and minutes later you get a virtual machine. Copy the VM to the server. Done.
It has taken us 20 years but we have gone from homogeneous infrastructure-single file deploy, through a maelstrom of ever more heterogeneous infrastructure with multithousand file deploy, to heterogeneous infrastructure-single file deploy (the VM). The x86 virtual container is a pretty cool deployment mechanism.
If done right - virtualization can be a driving factor in dramatically reduced IT complexity. The opportunity now exists to assemble your software servers from parts not unlike how hardware servers are assembled from parts.
eWeek #3) Are you resourced to manage the likely increase in demand? (Translation: Virtualization will be so successful for you, that once you get used to the agility and ROI that it affords can you meet the demand?)
Again. Absolutely. With the automated assembly capability of Elastic Server, you can assemble virtual servers at will - in the format of choice. Resources to meet demand? How about having the Amazon Datacenter at your disposal? Take the same server template that you assembled in VMware format, now select Amazon format with your EC2 credentials. Done. Server ready in minutes.
eWeek #4) Are your datacenter layout and power and cooling facilities and management sophisticated enough to manage consolidation? (Translation: It might get hot!)
Ok. If you are doing virtualization consolidation on a massive scale - this becomes an issue. But at that scale I would argue you probably have the skills involved. Me - I am back to the cloud on this one. Take non mission critical systems and move them to the cloud providers. (Frankly, I am comfortable moving mission critical systems to the cloud.) For sure, I am comfortable with Amazon, IBM, BT, Flexiscale, etc. dealing with the power and cooling "hot spots".
eWeek #5) What impact will virtualization have on your level of service (Translation: With more virtual servers per physical server, what is your failover strategy?)
Sorry. I see this as a push. And maybe I'll do a whole post on this soon as part of the "cloudbursting" topic. Failover is complex in general. Virtualization gives with one hand and perhaps, perhaps, takes with the other. But virtualization + cloud + loosely coupled architectures + Z2V + a few other bits gives you great agility. Being quick on your feet is a key part of the failover equation.
eWeek #6) Do you have the tools to be able to monitor/ manage your new sensitive complex environment (rack-side and remotely)? (Translation: You still need traditional rack tools and do you want to lock into just a single vendor solution?)
I agree with the guys from OpenGear. I am sure there are cases where you need magic boxes to switch between displays for the different physical servers and have console access to the virtual servers. See their website if this rings a bell.
But lets look at it from the dynamic assembly point of view. An assembly process for virtual servers gives you un-paralleled control of what is in the bill of materials for each server. This allows you to ensure that your monitoring agents are in every assembly, that remote desktop software, if desired, is in every assembly, that network ports for terminal access are enabled properly in every assembly.
Additionally, the value of this approach is it is cloud-friendly. The folks at Amazon and Flexiscale (nice as they all are), aren't going to let you install magic hardware boxes in their datacenters. It would be quite uncloudy of them. But - using the Elastic Server platform you can ensure that the magic software boxes are ready, waiting, and chock full of ROI.
So maybe there can be a dark side, but I for one think it is a pretty bright day up in the clouds. Maybe with virtualization it is as simple as, "Do. Or do not...".
