Jiri’s Notepad

There are few pain points in the world of infrastructure management. One of the biggest ones are how to increase the deployment time and how to improve utilisation of your assets.

1. Faster server builds are something everyone wants. Today, it is not an exception when a testing schedule allocates 20 days to the build of the test infrastructure and 3 days to the actual integration testing. You must admit this is rather ridiculous.
2. The second problem is utilisation. The average utilisation of servers is somewhere in the region of ten to thirty percent. The remaining 60% is sitting there idly, discs spinning, just in case the application needs more capacity. This may not see as such a waste, but it is using up the capital investment that could be used for something sensible rather than warming up the planet.

Virtualisation is a technology that can help a lot with both of these issues.

The concept of virtualisation is relatively simple and will be rather familiar to anyone who came across mainframes. Rather than installing a number of smaller servers, you use a smaller number of bigger physical boxes that can run a number of virtual servers. Virtual servers behave in the same way as physical servers, except that they are not tied directly to a hardware platform, but are running on top of a virtualisation host.

Because the servers are not physical, there is no need for a lengthy ‘build’ phase and the deployment is just a matter of copying an image of a standardised pre-built server. Developers like virtual servers because they take away the awkwardness and limitations of physical development environments. Testers love virtual servers because they allow a quick iteration of code between various environments. Infrastructure managers like virtualisation because they make it so much faster to increase a server CPU or a memory.

Whereas the technology is relatively straightforward to implement, the big challenges are around management of virtual environments. Without addressing these, implementation of virtual environments can turn into an expensive mess. I reckon the key issues are as follows:

• How to keep track of virtual servers? The error rate of inventory processes is often more than 10% and that is for physical assets. If you can lose the track of 10% of the physical things in the warehouse (or data-centre) the chance of losing something that does not exist in the physical world is definitely higher.
• How to manage virtual server images? With a variety of configurations going back and forward between various pre-production environments, it is way too easy to mistake one image for another.
• What is the virtual server unit and how to upgrade? Theoretically, there is an infinite opportunity to tweak performance and capacity of virtual servers. But from an operational perspective simple is good. Ideally you want to define classes of virtual servers and then a process to upgrade between those when needed.
• How do you manage capacity and performance of the physical boxes? Because utilisation of physical boxes hosting virtual servers is an aggregate of the utilisation of a number of systems, it is much harder to understand. Whereas for traditional server estate, performance and capacity management is the ‘best practice’ that most happily ignore, understanding and managing capacity and performance of virtualisation hosts is a neccessity.

Despite the potential issues, most people I spoke with have no doubts about whether virtualisation should be done or not. Their concerns were more about where it should be done, how much and how quickly. When you combine this with an extremely optimistic view of the stock markets on the value of virtualisation software vendors, it is pretty obvious we are at a full speed towards a virtualised future.