The iTKO SOA Testing, Validation & Virtualization Blog

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.