We just put up a new version of iTKO's Cloud paper "Service Virtualization and the DevTest Cloud" that helps clarify that there are two separate solutions we call Service Virtualization (SV) and DevTest Cloud, and while it makes sense to SV in its own right in any integration or testing project, there are also very good reasons to specificially use it for DevTest Clouds. Here's what we mean:
- Service Virtualization (SV) is the practice of capturing and simulating the behavior, data and performance characteristics of unavailable or incomplete systems or services that constrain the progress of development and test teams.
In essence, this is a "productizing" of the very time-consuming custom stub-and-mock process teams used to try to do for systems they couldn't get access to or easily copy or virtualize in their own enviroments. Obviously this capability has a very broad set of projects where it could be applied - it can speed up a step in a conventional waterfall-type software project, or really streamline things in an agile, SOA/BPM, decoupled approach. Virtual Services can act as stand-ins for functional and performance testing with almost unlimited repeatability, and little setup time and cost. But by the time you get to Cloud, teams invariably find they have even more dependencies, which calls for something new... - DevTest Cloud is a platform for doing software development and testing in a Private or Public Cloud. By nature, this Cloud-based environment allows the computing resources and infrastructure to be provisioned with complete flexibility - elastically consuming them in an on-demand way to allow the project to proceed with less overhead. A DevTest Cloud contains a Provisioning tool for deployment, and conventionally virtualized hardware and system capacity, but it also contains Service Virtualization capabilities.
Without Service Virtualization, that Cloud-based lab would be subject to the same constraints as your in-house test lab environments: dependencies or "wires hanging out" that constrain teams when needed systems are unavailable or unready for development and testing. With Service Virtualization, these components can be simulated to respond with highly configurable response behaviors and times, along with a near-infinite capacity for high-volume performance validation.
I hope this helps explain why we needed to make the distinction in the whitepaper. Service Virtualization is useful to any complex, composite application development and test project, whether or not that happens in a Cloud-based environment. But within a DevTest Cloud, the practice of Service Virtualization is the catalyst that makes it a truly elastic platform without constraints.
Comments