A Preview – Service Virtualization
Before I demystify service virtualization, let me preface my comments with the definition of a “service" in this context. Here a service is not only a web service, but also any form that can communicate with other software applications. A service, a contract, a protocol, it runs the gamut of all the interfaces, integrations, API’s we deal with in technology today. Another word “virtualization” is a source of contention, so let’s break that down, virtualization here is not a virtual machine/VM’s, but a copy of the “service”, got it? A copy, a virtual copy, a simulation, or emulation, so real that it can copy and mimic the behavior, data and performance, with high accuracy or negative accuracy, just as the original “service” themselves, or sometimes better.
Service Virtualization is a practice that can be implemented by virtual services. Virtual service is that copy which behaves, performs and has data like the original “real” service. Those virtual copies, which behave precisely as a live system, can then be used independently of actual, live systems to develop software without any constraints. Thus, software can be developed and deployed faster, with lower costs and higher quality.
Gone are the days of waiting to test software-in-development against dependent systems or waiting to test software until the end of development. Testing becomes an ongoing part of development.
Remember, we say that a VS is “simulating” the constrained system for purposes of development and test, not “replaying” it in terms of a step-by-step sequence, as you would a recorded video. Sufficient dynamic logic must be captured and modeled into a VS to allow it to respond with enough intelligence to support the variability of needed usage scenarios. The VS should resemble the live system closely enough to make upstream applications and test users think that they are interacting with the real thing for most needed scenarios.
Within DevOps, and the practice of Continuous Delivery, the need for automation is paramount, however, the best test automation solutions or release automation solutions will be crippled without a stable environment and working applications. To bridge the gap when applications are not available, virtualizing and stabilizing becomes a key step in the success of continuous delivery and automation.
To draw an analogy, service virtualization applies a concept we see in the aviation industry. When Boeing builds an aircraft, several teams, in disperse geographic locations, and with different technologies build the parts. Take the team that builds the engine. Those mega engines although build in a silo are tested in a simulated environment, a wind tunnel before Boeing sums up the parts and flies the aircraft for the first time(the alternative, if it mimicked the SDLC, Boeing would test every component for the first time in it’s maiden flight, and if the plane crashed, would replace the pilot). For software engineering, if you modularize your applications and teams, but set them up for success with simulated environments, you will be well on your way to build applications efficiently with higher quality and at a lower cost.
Next up: The Many Hats of Service Virtualization
