Service Virtualization: It’s Not That Kind of Virtualization

If you’re used to thinking of virtualization as a way of getting 50 functional servers on one physical box, the term “service virtualization” is kind of confusing. It’s easier to understand what service virtualization is — and how useful it can be — if you think of it as service simulation. Briefly put, service virtualization is the simulation of a complex application, database or other computing service in a testing environment. Service virtualization should be used for testing when:
  • You can’t test in the real-life system you’re building for, because it’s outside of your organization — for example, a payments service that doesn’t offer a testing environment.
  • Your real-life system is so complex that you can’t practically test on it without disrupting normal business.
  • You shouldn’t expose real data to a potentially non-secure testing environment — customer data and patient information, for example, are too sensitive to risk, and putting enough security on these databases will create too many impediments for developers and QA engineers.
  • You need to test against another system that’s still under development and isn’t yet available to test against.
In an article on ServiceVirtualization.com, Mike Drago offers an interesting and detailed look at three different scenarios in which service virtualization got a telecom company past its complicated testing issues. The company “used virtualized services to meet ridiculously tight timelines on big projects, save big money on training and dramatically speed up releases in its retail management system,” Drago writes. Those are big benefits.

The how-to of service virtualization

If it’s possible to virtualize a service by installing it or running it locally in your test environment, that’s the best way to go, says Chris Price, a software engineer here at Puppet Labs. “You have your production version, and then you have an identical version for testing,” Chris said. “ Ideally you can export your database from production whenever you choose, and import it into your test database. This gives you the most realistic test environment.” You may not be able to import your data, though. If that’s the case, you can capture or record a representative portion of your real data from the production environment, and then build a mock service that returns this sample data. You won’t be testing against the real service, but when you write your own mock service, you can populate it with something that looks like real-world data. For web-based services, it’s easy to capture some sample data using a network proxy or debugging tools. Here are some examples from Chris:

Using cloud automation for service virtualization

Virtualized services are inherently a temporary need, so it’s natural to run them in the cloud. Whether you’re using your company’s private cloud services or renting cloud servers from a provider like Amazon, VMware or Microsoft, the quick, flexible self-service model that cloud provides is exactly what’s needed for testing. And you’ll want to use cloud automation tools to provision your virtualized services, to make sure they’re configured just like the real-life services they emulate. Learn more:
Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.