Last week I discussed the possible cost savings from a virtualised setup, and although this would be seen as the main driver for a lot of people there are a host of other benefits that you gain. Although there are probably more reasons if you care to look into it for a specific situation I am discussing three here:
- Maximises hardware utilization
- Easier to support
- Enables rapid (or agile) deployment
Maximise Hardware Utilization In an ideal world, applications should be coded to run in the multi-threaded CPU world that is rapidly becoming the norm, and handle the resource management without any intervention from the hardware. This is not the case of course, with some applications being CPU bound, single threaded or unable to utilise all the available memory on a server. This is where virtualisation can help you out. You can effectively make a single piece of hardware that would normally run at very low load handle multiple instances of an application and therefore better utilise the resources available. This doesn't mean you should run your hardware at 100% CPU utilisation, far from it in fact. Different applications may become unstable, or start to display very high latency as the hardware is loaded. Determining the cut-off point would be application specific and only careful testing and monitoring would allow you to gain optimal use of hardware. There is also the danger of over virtualising for the sake of it. As soon as you define a service level against a platform you need to be able to maintain it, and the advantages of n+1 redundancy, and physical separation, come into play. To take an example here from the PlusNet network, the mail platform is split across two sites on multiple machines with the data replicated between them. We could get all the functionality onto a handful of very powerful machines, but then a single (and always inevitable) hardware failure would result in a massive customer impact. Maintaining this balance between service levels and your other savings is the trick here. Ease of Support This is another one that is often used as a reason to embark down the path of virtualisation. There are, however, a few gotchas so look out for. The main one is that you will actually end up with more 'servers' to maintain. Each virtual machine is managed, monitored and maintained exactly as if it was a separate physical server. On top of that you also have the underlying host for the virtual machines to look after. This also means there is another layer of complexity in your systems (read another thing to go wrong), and also another chunk of knowledge that your support staff need to know to manage the platform effectively. On the flip side, you will have less hardware failures, as you have less hardware (yes, the impact of a failure is higher but that does not really add to the support overhead). You also have the ability to standardise your hardware a lot more, rather than having bits and bobs from hundreds of different suppliers (which will improve your ability to support the hardware). Rapid Deployment The final reason for virtualisation I am going to discuss is rapid (or agile) deployment, which you could, in addition, chalk down as rapid re-deployment. The most important thing to consider here is that your ability to utilise the benefit is not really reliant on using less hardware, how much you save or even what virtualisation technology you are using but on the oft-forgotten art of planning your network architecture and design before you start building it, thinking about how the whole thing fits together and what you can gain from it. There are a number of ways that you can gain here. The most obvious reason is the ability to move capacity around in your network or to have dark capacity that can be used for anything - all you do is install a new virtual machine and plug it in. This means you can respond quickly to changing needs by upping the capacity on a service, or redeploy capacity from value-add services into core services if you are in the middle of some disaster or another. If you look beyond the servers and invest in a high availability Storage Area Network (SAN) then the operating system is installed onto remote storage, meaning it can be booted on any server with available capacity. This means you can move the virtual server about, upgrade it by booting it up on more powerful hardware and have it backed up (and recovered) by the storage itself - and all this from the comfort of your desk (or even your phone if your feeling up to it!). If the ability to cope with expansion and disaster recovery is considered when you first embark upon virtualisation you can really make your network work for you. I hope that some people have managed to read through all of that and make some sense out of it 
Personally I am excited about what is now possible with virtualisation as the technology becomes more widely adopted and supported, and have enjoyed the process of learning about new technologies from scratch massively. If I had to summarise everything I have said it would be that knowing where you want to get to when you start and planning (it sounds obvious, but you would be surprised) are the most important thing (more so even that cost, although the beanies would never agree to that). Once you have that you can tick off the pros and cons and decide whether it is the right solution for you.