Maybe it’s just that I’m slow on the uptake, but I didn’t get the whole hype over using virtual machines for development up until I actually started doing it. After all, why use virtual machines when you have a perfectly good physical box sitting right there and ready to go? I get that it saves money and power and is easier to administer, but that’s an administrative reason to use virtual machines, not a reason for me to put my server set up on a VM rather than the computer sitting right here next to me.
Like I said, I realized the error of my ways when I started using virtual machines when I do development. To be clear, I don’t write the code on a VM, rather, I code on my local machine and deploy it to VMs I have running servers processes on. I could do the coding directly on a VM, but I don’t like to code directly on a server if I can get away with not doing it. From my experience, there are 2 primary benefits to using VMs for development – they’re cheap and easy to set up, and taking (and reverting to previous) snapshots.
Not only are virtual machines cheap and easy from a system administration perspective, but it makes setting up servers cheap and easy for development too. As a matter of fact, they’re so cheap and easy there’s no good reason not to be using them for anything that would be on multiple machines in production. Heck, with VMs, there’s no excuse for running any server process on your machine. If it’s going to be on a separate machine in the real world, then it should at least be on a VM in development, if for no other reason than to make your development setup more accurately reflect how your software runs in real life.
Even though VMs are easy to set up, so putting a server together for anything takes minutes, especially with a template I can just clone from. But that’s not even the biggest selling point. The biggest selling point to VMs is this – holy crap snapshotting is awesome. I can tweak and modify my server setups, code, and the data stored on them with reckless abandon (not something I could normally do, given my personal problems getting servers up and running). Is your server FUBAR? Revert, and all is well. It’s just that simple. Granted, this strategy only really applies if you take frequent snapshots (I don’t do it nearly as often as I should), but it’s incredibly comforting to be able to hop back to a machine state that worked, and do it quickly and easily. No more wasting time trying to go back and manually undo all the things you’ve done that probably contributed to busting your machine – a few mouse clicks and a few minutes are that’s between you and being up and running like nothing happened (which, as far as your VM is concerned, is precisely the case). Compare that to the alternative, which is breaking something on your actual machine and wasting hours trying to get it reconfigured or re-installing your server setup from scratch, hours that could have been spent doing something useful and productive instead. Go through that once, and then revert to a previous VM snapshot once, and you’ll swear by VMs for the rest of your life.
If you want to spend more of your time doing development, and less of your time trying to debug why your server won’t behave, you need to be using virtual machines. If you’re experimenting with anything, like a new version of your programming language or common library, use a virtual machine, and just trash it when you’re done. Trying to upgrade your server? Use a virtual machine so you can easily undo any screw ups. Trying to mirror a real-world setup for development? Virtual machines for everyone! In fact, virtual machines for everyone, period! You may not get why at first, but if you start using them, odds are you won’t ever agree to stop using them.