Info

"We hear this all the time … this live connectivity to everybody (remember that white board I just mentioned a minute ago?) Live connectivity to all of these boxes creates a large amount of friction or construction barriers, if you will, in the road. "What we can do, by isolating ourselves from that through virtualization, is we can parallel that development activity and, of course as a part of our final integration testing we go from virtual back to live services. Once we are all live, we can obviously make sure that everything inter-operates the way we expect. The value here is that instead of having to wait for my dependencies to complete, I can run in parallel with my dependency and get it done faster. "A quick example of this is: If I'm asking you to implement a new feature in your service, I have two choices: I either ask you to make that change and wait for you to make that change, test that change, produce that change into a build for me and make it available, or I can use a virtual service. "I can make the change in the virtual model very quickly (we are talking minutes to do this with our product) … and I can be developing in parallel against the virtual version of your service just an hour or two later. Meanwhile, you'll take weeks to produce a new version but I'm developing against the new version in parallel in a virtual world. Once your service is complete, I can point my application away from the virtual edition, and instead to the live edition, and we can make sure that it actually works as we expect." Mike: "When it comes to testing in this area, we certainly want to simulate as many data set combinations as possible to see how effectively that this solution is working; how robust would release be in that area in terms of being able to simulate data set combinations?" John: "We've spent a lot of time on this. It turns out … as we embarked on this virtualization strategy, we knew that virtualizing data layers would be a big thing, but I can't tell you how many times I've heard our customers say "this is the big thing. It's because of all this data synchronization, and all of this volatility of data - every team wants to reset the database every time they run their test and every time that they do a development cycle, and that means that no two teams can be sharing the database at the same time, and it's always a mess! We've spent a lot more time here than we've even thought and we've solved a lot of problems here. "A classic example of this is: When you are working on the purchase ordering system, and the supplier system is your partner, you don't actually produce the supplier's service, but you talk to a supplier … and yet you're supposed to build an application that tightly integrates with your supplier … how do you do this? Well again, you virtualize either at the behavioral layer or the data layer. And, why do you virtualize at the data layer? "Think about it … the supplier could respond to a PO request by supplying all of the requested goods at the requested date with no issue; but the supplier could just as easily split the order, could partially cancel, could respond to you that these items were no longer carried, could warn you with a credit check, could warn you … The number of possible data scenarios in the response to a requested PO -- it reaches the point where we wonder how we can possibly test all these out. "Since we can't drive data scenarios in live systems, we can't drive data scenarios with our partners -- at least we can't effectively -- we need to virtualize that database so that we can drive all those. I can make certain that every kind of possible response to a PO request is available to me all of the time. That's what data virtualization does for us. It makes me able to make certain that every time I need the stars to align a certain way for me to make a certain condition occur, I can do that. I'm certainly not strong enough to literally make the stars align but, in a virtual world I can, so in that way I can always make sure that everything works the way I expected." Mike: "There are a number of load and performance testing tools such as LoadRunner or SilkPerformer, and a lot of companies have made investments in those technologies, so how can they leverage those investments that they've made and expand on those with LISA Virtual Service Edition?" John: "That's absolutely true Mike, there's plenty of successful LoadRunner shops and SilkPerformer shops and others, and LISA does load testing, but we're certainly not interested in trying to fix what's not broken. We're certainly quite comfortable with working with companies who are doing load testing with LoadRunner. A number of our virtual services environment customers are doing exactly that. "In fact, if you picture in your mind: the left-hand side of the graphic is Load Runner generating a load on a system in the middle of this graphic and on the right-hand side of this graphic is LISA Virtual Services environment. What we do is enable more and better load testing even with the tools that we did not provide. What we're doing is we're freeing the system that you're testing from its constraints. We're not eliminating that system nor are we trying to affect the load test product itself. We're actually trying to virtualize away the constraints on the right hand side of the graphic. "So, it's LoadRunner, versus the System Under Test, which can be LISA … and that triad, if you will, makes for a very powerful load testing combination. What we have found is that you have to have production hardware or at least a reasonable production performance lab for your own application.