These days virtualisation seems to be all the rage. There are some benefits to it. It’s a way to increase the utilsation of your hardware just as pipelining increases the utilisation of the processor’s execution units. But as pipelining it comes at a price. You might increase the throughput, but the latency gets higher. Furthermore the response times become highly random, as they now depend on all the other users on the machine.
Especially in the context of development this poses a few risks. I have been working in environments with the build servers using virtual machines and shared database servers. This leads to variable build (and test) times – usually not shorter ones though!
It leads developers to ignore the time the code takes to execute, because there is no reliable feedback and all problems tends to be blamed to the environment or the database. In the worst case it leads to integration tests being ignored and abandoned, because they fail for timeouts, which result from dead slow code and unreliable system performance.
It is often said that code is to be read by humans. This is true. But it is also true and to be borne in mind, that code is run on machines. Virtualisation is clearly obscuring this fact.
Update: Dale was making the interesting point, that virtualisation is giving you a more controlled environment, because you can save your virtual machine and go back to defined points. This seems like a good thing and makes things easier in the first place. I think this is a double edged sword. In my experience you actually start incurring dependencies to that very environment. In my opinion software should be written in a way that it manages and contains it’s state. I have seen projects where you had to install database servers into the operating system (registry!). Then install stuff into the database server. Of course you also needed an application server. Everything needs to be configured. Then you run another obscure unscriptable utility to get your test data into the database. There is a huge temptation just doing these things manually and then save a snapshot of your vm. The actual problems like the use of side-effect-laden tools, resource-leakage during runtime, and poor setup-scripts remain untacled.
Writing a system that can’t work without a reboot is not a good practice. It should be a good citizen in the operating system or on the virtual machine it runs on.
Leave a Reply