Jason English

We've talked a lot in previous posts about how the practice and technology of Virtualization really has legs -- it keeps moving forward, from hardware virtualization, virtual test beds, to virtual endpoints, to actually simulating the behavior of the software itself, which we're calling Service-Oriented Virtualization (or "SOV" if you need a TLA for it).

Now we are seeing the Performance Lab getting into the action on this practice. For interconnected apps like SOA and serious enterprise integrations, the guys with the load testing firepower have tools like LoadRunner and SilkTest in their lab, but they get left out of the process until very near the end, when an interface is available. SOV can break that dependency of waiting for "all the moons to align" before they can get a test window.

The initial uses of SOV were to allow the development and testing team to regain agility much earlier in the lifecycle - so they could do their needed functional and regression testing against Virtual Services instead of constrained live applications -- the essential services, databases and mainframes in the environment.

But that same virtualization is perhaps even more valuable in the performance lab, if you can apply serious load testing to it. The constraints of having a realistic environment and test data to test and develop against is holding these teams back from finding performance issues much earlier - so we can gauge SLAs (service levels) at the component level. And in SOA - where you are dealing with services and underlying systems that are distributed and constantly changing, replicating that whole environment is incredibly costly and time consuming.

With a virtual service environment, the performance team tests the component they are working on with their existing load testing tools, and virtualize the rest of the system dependencies and data away. Rather than add hardware and bandwidth, just virtualize all of that, then see if it is indeed the hardware, or more likely, something in their component or its response to variable, changing data that is causing the bottleneck.

We had a good conversation with analyst Theresa Lanowitz from voke - no stranger to advising companies on the application lifecycle and ensuring quality - about this concept. She's going to be co-hosting an upcoming webinar with iTKO's chief geek John Michelsen, and InfoWorld's Test Center editor Doug Dineley on this topic on May 28: http://www.itko.com/site/resources/vsewebinar052808.jsp

Hope you can join us for this event, if not, we've written a paper on performance testing in a virtual environment, and we'll continue to talk about this practice here.