Editor's Note: This is part one of Mike Laverick's "Stupid IT" series. Take a minute and read part two on "Virtual could computing is not a panacea"
Disclaimer: No Yorkshiremen were unduly harmed in the writing of this article. No offense is intended to Yorkshiremen.
This article takes two sources as its inspiration. Firstly, VMware's avowed mission statement to "simplify IT processes." I'm a big fan of IT mission statements, not least because I take a perverse pleasure in the yawning gap of irony between the statement and the delivery. The more inspirational the mission statement, the more comical they become, in my experience.
Whilst I admire the directness and matter-of-fact nature of VMware's statement, my only problem is that I don't think we can simplify any business process until we stop being stupid. I believe in the old "garbage in, garbage out" adage, and there's no point in digital enabling and empowering our user basis (and other such mission statement verbiage) until we stop IT from being stupid. Much of what we do seems tangled up in stupid IT processes that have never been altered, because they "have always been that way."
The other inspiration for this article is a mini-spat between two bloggers who I follow -- Scott Lowe (EMC) and Steve Chambers (Cicso, nee VMware). The argument centers on the rights and wrongs of high consolidation ratios in a virtual environment.
In many respects, we are victims of our own success. We have so much redundancy that stuff hardly ever fails, and the only time users notice what we do is when it is broken.
Mike Laverick, Contributor,
In the red corner, Scott outlines how, despite the use of massive amounts of redundancy in hardware (multiple power supplies, network cards, host bus adapters) and software (VMware HA, VMware FT and in-guest availability technologies such as NeverFail and MSCS), folks are generally still anxious about placing too many virtual machines (VMs) on the same chassis because of the "eggs in one basket" idea that virtualisation inevitably brings to the table.
In the blue corner, Steve argues that many IT professionals still miss the point, in that failures normally stem from human errors, cultural failures and poor practice. Steve is quite flavorsome in his critique, indicating that "Scott isn't fully on board yet." Given that Scott has written a number of tomes on virtualisation and is one of EMC's VMware vExperts, I believe that jibe is unwarranted.
I'm hoping that much is lost in the translation across the pond (especially when it comes to the quaintness of British humor), and you should perhaps know that Steve is a "Yorkshireman" and they are well known in the U.K. as "wind-up merchants" who enjoy getting a rise from people! But joking aside, it would perhaps be a bit cynical to dismiss Steve's posts, given how he now works for a company who sell "tin" (UCS Blades), and indicate that this is the real reason for him making the argument for greater and greater densities of VMs on one form factor.
High consolidation ratios
As ever in these blogosphere spats, both parties have something useful to say, and I thank them for inspiring me to write this article. It's a subject close to my heart, and something I have written about previously for TechTarget. To some degree, I find myself agreeing with Steve's premise; where we diverge is in our conclusions, and it has everything to do with this concept I call "stupid IT."
Let's start with the basics. It's a truism of virtualisation that it creates an eggs-in-one-basket scenario. Whilst it's entirely possible to run one VM on one form factor, the licensing costs alone make this cost prohibitive. There are companies who can and will do this, but it involves forgoing the cost savings the server consolidation offers. In short, it seems difficult to have the cake and eat it at the same time. This is why so much money and effort is put into offering availability to both the hardware and software.
This kind of spending is much like the insurance policy on your house or car -- a monumental waste of money...until your house burns down or someone steals your car -- and if you're really having a bad day, both! It's very much the IT professional's life to see the world through glass-half-empty eyes and to become overly fixated about the potential failure of components. I think this is largely due to the fact that most businesses take what we do (IT infrastructure) for granted.
In many respects, we are victims of our own success. We have so much redundancy that stuff hardly ever fails, and the only time users notice what we do is when it is broken. For me, consolidation ratios have largely been constrained by two factors -- the amount of memory (or money) you have and the comfort zone of the ratio.
"At what point do you start to have sleepless nights" is perhaps the most common finger-in-the-air approach to the problem. Is it 15 VMs per box, 30 VMs per box or 60 VMs per box? For some time, we were able to avoid the question because the servers we were using were not memory-dense enough to take silly numbers of VMs.
To some degree this is still the case, with high-densities of memory still being a premium. But history shows prices will fall, and additionally we are facing a new virtualisation workload in the shape of virtual desktops, which demand as high-densities of VMs as you can muster.
In the world of client compute, where cost is a more palpable pressure, the more virtual desktops we can squeeze on the tin, the cheaper they become. Of course, as the ratios increase, so does the anxiety. The truth is that hardware and software components are so reliable and redundant they hardly ever fail. In fact, so much availability software is geared towards protecting the server from hardware failure that some of my peers are beginning to question why they even buy SKUs that contain VMware HA.
It's for this reason that we really must face this consolidation ratio argument square on. If we agree that the challenge is no longer in technology but in soft-human issues of how IT is managed, then we cannot shirk from that responsibility. We cannot limit the densities of VMs to host based on the collective failure of IT to manage the virtualization stack reliably.
It's for this reason that I'm inclined to agree with the premise of Steve Chambers, or, as he puts it in his characteristic way:
"The Mean Time Between Failure (MTBF) for high-end components are [sic] measured in years. The Mean Time Between Cock-up (MTBC) varies depending on how good your staff is at IT."
The essential message of Steve's article is one that sees that virtualisation is not a panacea for your ills. If your organisation is already exhibiting what I call "stupid IT," the business will merely translate its problems from a physical world to a virtual one, adding new problems and challenges along the way that your staff may be ill prepared for. After all no one wants to blow money on expensive training when it could be spent on hardware and software that is redundant in three years time. Do they? Steve continues:
"…if you were c**p at IT before virtualisation, you'll be even worse with virtualisation. You won't be able to do any of the risk mitigation listed above and, in your sad case, I wouldn't put all your eggs in one basket -- instead, you should give the eggs to someone else."
I think there's another not-so subtle point here. As we know, Yorkshiremen are renowned the world over for their subtlety. That is the argument that the best way to escape "stupid IT" is to head off into the fluffy yonder of the cloud. If your own staff cannot look after your precious Faberge eggs, then perhaps someone else should. It's at this point that I start to part company with Steve and his Tyke.
The reality is that IT has been stupid for some time. I don't personally think the cloud is a commercial proposition at the moment. There's much talk of the internal/private cloud being the first tentative step -- this is largely touted as a way of not scaring the living daylights out of big businesses, but a tacit admission that no business currently has any faith in an external/public cloud provider delivering the goods.
ABOUT THE AUTHOR: Mike Laverick is a professional instructor with 15 years experience in technologies such as Novell, Windows and Citrix, and he has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. In addition to teaching, Laverick is the owner and author of the virtualisation website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.