Virtualisation will save problem-solving time

Developers will benefit, says Tom Yager

There are only a few markets ideally suited to virtualisation. One of them is software development. As the scene is usually painted, the developer sits at his or her desk, compiles new software, and launches it in a virtual machine so that when it crashes, it doesn't take the whole box down.

We hear of developers who keep a Linux instance open on Windows, or vice-versa, either for the sake of cross-platform productivity or to strike a blow for religious freedom.

But as long as virtualisation is viewed as a tool of convenience for individual developers, the IT sector isn't likely to stay very excited about it. The larger reality is that once we get to the point where we can assume virtualisation is a standard component of every OS, major changes with bottom-line impact will take place far away from any one developer's desk.

As a former developer, I get excited about it. Now that I know I can do with virtualisation what I always wished I could, I can't imagine architecting, developing or doing QA on SOA and other distributed solutions of scale without virtualisation as a core OS component on every machine my solution might touch.

When a development lead hands a project to QA, technical writers, tech support or anywhere in any direction in the development chain, the project should always be passed along as a virtual disk image that's ready to roll.

That means the virtual disk image would have the OS configured with all of the application's dependencies in place, the application itself, and the sample data and scripts required to test it thoroughly.

If I could do that back when I worked in development, I might have stuck with it longer.

If I were still working in IT, I'd declare that any software solution pitched to me could not get through my door as a stack of install discs, a quick start guide and a "give me a call if you run into any trouble".

Leave me with a DVD that has a VM image I can copy to my local drive and execute with the OS's default virtualisation engine. If it's a client/server solution, give me two VM images to launch side by side; I can handle that. If it's SOA, give me one image I can launch multiple times. I can handle that, too. That's the kind of task I could hand over to a junior member of my technical staff.

I would have taken a lot more demos from vendors — and taken looks at a lot more intermediate builds — if I could have just double-clicked on a virtual disk image with 100% certainty that the OS and application would just run.

For reproducable problems, the turnaround time between the reporting of the problem to developers, contractors, tech support or even website designers and their response could be cut to next to nothing. You'd run the problematic application or site in a VM, drive it to the point where the error occurs, freeze the virtual machine, and ship its image and the file containing its running state to the responsible developer or support tech.

They will be just one click away from experiencing the problem exactly as you saw it, and they will be able to instant-replay it as many times as suits them, with no chit-chat about what you did to get to that point, and (dare we hope?) no argument about whether the problem can be reproduced on their end.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags technologyvirtualisationdevelopers

More about Linux

Show Comments