Problem solve Get help with specific problems with your technologies, process and projects.

It's time to virtualize

Setting a virtualization plan helps you make better use of limited resources, and you can skip endless reformats and reinstalls.

By now, most developers know about virtualization software. The most prominent applications in this class are VMware and Microsoft Virtual PC, though there are some others. What surprises me, though, is how few developers (VB or otherwise) actually use virtualization software to make their lives easier. Setting up an effective virtualization strategy is one of the best ways to make better use of your limited resources, and to avoid wasting your own precious time on endless reformats and reinstalls.

I'm partial to VMware myself, but you can use Virtual PC the same way. One caveat: You need to understand the licensing implications of having lots of virtual machines (VMs) installed. Typically, you'll need to invest in a MSDN subscription to keep yourself legal. I will describe some of the ways I've used virtualization software over the years.

Keep Your Development Environments Separated: If you're like many of us, you end up working in a variety of different development environments. Maybe you still do some work in VB6, some in VS.NET 2002, some in VS.NET 2003, and soon some in VS2005. Perhaps there's some Java work in Eclipse in there, or Ruby or Perl or what-have-you. Maybe one project needs BizTalk installed and another requires you to spin up SharePoint Portal Server. Trying to keep all of your development tools installed on a single computer without conflicts has become increasingly difficult as the tools have become more complex. Instead, give each project its own home in a separate VM. When you need to work on the VS2005-and-BizTalk project, you just fire up that VM and get to work, without anything else getting in the way. There's another benefit to this strategy, too: if you need to switch gears to look at a problem in a different project, you can suspend the work you're doing and switch VMs. Then later you can come back directly to the point where you left off, without needing to go through a lot of setup effort.

Keep Betas Out Of Your Hair: You probably like beta testing as much as I do. VMs are great for beta testing, because they ensure that the beta software won't blow up and destroy the stuff that you actually depend on to make a living. Keep those shaky versions off in their own little universe where they can't harm the critical data and you'll still be able to play with them to your heart's content.

Improve Your Testing: Even if you have a QA department to test your applications, you probably still do some of your own testing. If you don't have the QA department, of course, you're stuck doing all of your own testing. With VMs, you have much more ability to set up different test environments to replicate customer scenarios. Typically, I keep VMs with a variety of flavors of Windows around for testing desktop applications, and ones with half a dozen different browsers installed for testing Web applications. If someone complains that something doesn't look right in Opera, it only takes me five minutes to fire up my dedicated Opera VM and check it out.

Sort Out Those Servers: Somehow the number of servers I need to use keeps increasing - source code control, continuous integration, Web servers, database servers. It's convenient to shove those things off of my desktop, but I don't really want to build separate physical servers for all of them (though that does help keep the office warm in the winter). On the other hand, trying to get everything running on a single machine is an exercise in frustration. The answer is to virtualize: Get yourself one decent server and use it to run all of your backend stuff in separate VMs. Particularly with everything wanting to use Web-based interfaces these days, it's much easier to deal with the servers when they each think they have port 80 all to themselves.

Archive Your Work: Finally, if you're supporting customers with one-off installs, it can be very convenient to build VMs to match as closely as possible the software that you've deployed to the actual customer site. Then suspend that VM and don't use it for anything else. If -- OK, when -- you get a support call, fire up the appropriate VM and you've got everything all ready to look at with the correct versions in the right environment. Troubleshooting is much easier if you don't have to remember how to get to the starting point.

Overall, the minimal investment it takes to buy and learn to use virtualization software is something that will pay off quickly for nearly any developer. As you get comfortable with the technology, you'll find it provides you with flexibility and a safety net that you never dreamed of before - and you'll wonder how you ever did without it. If you haven't taken the plunge yet, it's time to get started.

Mike Gunderloy is an independent developer and author working in eastern Washington state. His recent books include Painless Project Management with FogBugz (Apress) and Coder to Developer (Sybex). You can read more of Mike's work at his Larkware Web site, or contact him at

Dig Deeper on .NET Architecture Best Practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.