Working with leading Systems Integrators has led me to an interesting conundrum around the whole area of virtualisationl. I was reminded of the problem by listening to another “Virtualisation Panacea” the other day. In my time with my previous company we did a study – Gartner have done the same – to determine whether a virtualised and thin client estate is more cost effective than a well managed thick client and discrete estate. The resounding answer was Yes BUT … marginally!
The problem centres around the fact that the Total Cost of Ownership (TCO) takes into account the effort involved in managing the desktop or virtual server estate and that cost is often rooted heavily in manual effort. We all know that labour intensive operations are expensive, hence the desire to automate desktop builds, desktop updates and patches and fixes.
Theoretically the whole Virtual Server concept is a great idea – harvest the unused CPU cycles in machines that are only 20% utilised. The software (such as VMWare) and the Hardware (such a BladeFrame) solutions provide a convincing argument to go down this route and run more than one virtual server on a single physical server. Clearly this should be a benefit, however, problems begin to surface when you start looking at the costs of patching all these virtual servers.
In other words, the problem is deeply rooted in the Operating System vendor space. If all operating systems required no patches, no updates and no security fixes, then virtualisation would be a much more enticing option. I dare say that the choice of operating system will make a difference even in the current environment especially if the choice is based on the amount of patches and updates that must be applied on a regular basis.
Critically, automated software update techniques require the servers involved to be up and running at the time that they poll to find which servers need updating. Since there will be “live” servers that are “dormant” at the time of polling then they will get missed in that patching process.
Another issue is that since the operating system clearly needs the most manual intervention and attention, then software vendors should be looking at ways of de-coupling their applications from the underlying operating system as much as possible. We all know that most pieces of software that run on Windows make use of DLLs that are resident in the System and System32 directories which means that they are tightly coupled to the OS. There was a time when an application would load its own DLLs into its own directory but that caused conflicts and doesn’t really look like an elegant “re-use” type of environment.
Damm Small Linux (DSL) has come close to creating this type of de-coupled environment, but then most of the current business applications don’t run on Linux! With DSL you can configure applications to run on the desktop from special image files that could be held on a USB key. That means that the desktop can be standardised and then each user would have a USB key with their own applications loaded onto it. The Desktop OS build is now de-coupled from the applications and all of a sudden a level of automation can be built into the OS patching etc.
So virtualisation is not the panacea that we all expected it to be although some brave souls have been out and started down the track claiming some success. I think the Gartner assessment was correct that a thin client estate was almost as cost effective as a well managed thick client estate. The key is that those organisations that have claimed success in the desktop space have potentially had a less than well managed estate.
Where do we go from here … I think de-coupling is going to be key to this, except that OS vendors need to make this happen in the way that it used to happen in the mainframe world. Call me a dinosaur, but why is that world still considered to be resilient, robust and reliable?
