Most production environments today are running in some form of private (or public) cloud. With hardware performance and capacity increasing and costs decreasing it’s hard to argue that virtualized servers make sense. But why stop at servers? Why not virtualize your development environment? This is a question I posed about two years ago. I challenged myself to work exclusively in virtualized environment. To my surprise, a number of my daily tasks became much easier, faster and I was able to service more projects with less down time. As always, there a few disadvantages to consider before making the plunge, but I’ll describe my setup and you can decide if it’s for you.
As developers we have a tendency to install all of the software we need, a lot of the software we might need, some of the software we want to check out, and maybe a few applications we installed by accident. These applications tend to include running services which take up machine resources even when we’re not using them. Additionally, developer workstations tend to be specced to the hilt with more horsepower than most of us use (or should be using). Sure, if you have a dozen Visual Studio IDE’s running at the same time you’re hosting a with SQL Server and editing massive Excel spreadsheets, you might be one of the rare few pegging your machine’s resources. For the rest of us, it’s nice to have the ability to turn off the development services with the click of a pause button can free up a bulk of resources so we can watch a movie or surf the web without hiccup.
By creating virtual machines for your tasks, it’s easier to stay focused on the task at hand. If you have a VM set up for development, with your development related bookmarks in the browser and none of the games installed, it’s easier to keep moving forward on the development tasks without as much distraction and temptation.
Snapshots: The Magic Eraser
There’s no a worse feeling than programmatically trashing a system folder, borking system permissions, installing a malicious app, or any of the other oops moments that cause the well known sound of a developer’s head hitting the desk. By taking snapshots at regular milestones, catastrophic mistakes can be undone in seconds rather than a day to reinstall and reconfigure a development machine. Windows has “System Restore”, Mac has “Time Machine” and Linux has a variety of snapshot-style apps, but none works as quickly or completely as a restore of the entire disk to a previous point in time.
Pause helps keep it green!
Shutting down my machine at the end of a work day is a routine I’ve adopted to help my brain transition from work to home. But what happens when it’s quitting time and you have a dozen docs open, a debugger running that finally hit the break point you needed with valid data… you the the idea. Closing all of that down would be a pain and it’s a challenge to pick up where you left off in the morning. In a virtual environment, the machine can be paused in its current state state. This allows the physical machine to be powered off without state or data loss. The next morning you power on the machine and everything is exactly as you left it! It’s energy efficient and developer efficient. Does it get any better?
Hardware gets faster, smaller, and better all the time. If you’re one of the fortunate developers working for a company that regularly upgrades equipment, it’s great to get a new development machine. However, to setup all of your apps, migrate all of your data and information, and get your preferences and configuration just the way you like it is a time consuming process. If you’re in a virtual environment, the VM files can be copied from the old machine to the new machine in a minute or two. Spend a minute or two bumping up the hypervisor host if necessary, but even with a coffee break you can be up and running on the new machine in under 20 minutes.
As I type this, I have my Windows 7 VM running Visual Studio with a Web API project running in debug as well as a Linux Mint VM with Android Studio running an emulated Android device that’s calling the API. To do this several years ago, I’d need two (or more) physical computers either with a KVM or full setup. This not only takes up more physical space but it’s more difficult to bounce back and forth from machine to machine. Being able to run any number of configurations in a virtual environment is huge for developers. I can’t tell you how many times I’ve seen bugs come across my desk telling the take of an antiquated version of IE on Windows XP is showing the website differently than any other browser. Traditionally, we’d try to find an old machine to install XP and do our best to emulate the specs. With luck, this can be accomplished in less than a day. To set up a VM with these specs, I can use my state of the art developer workstation to create the image in a fraction of the time if necessary. If we’ve thought ahead and have a virtual machine image that has the same or similar specs already assembled, I can fire it up on my development machine and verify the bug in no time.
Those are just a few of the highlights that sold me when I started down this path. I’d be lying if I said there weren’t challenges along the way. It’s a different mindset from having everything installed on a single machine. However, running this setup for as long as I have, I’ve not only gotten used to it, but I’ve become dependent on it. Having the freedom to move between operating systems and configurations quickly and easily is awesome and daunting at the same time. But the true power is in setting up your virtual development environment to serve your needs. Let’s get to the goods. I’ve covered a few aspects of development virtualization in the following posts and have added helpful tidbits from my experiences. Hope you find it as valuable as I have.