It’s true what they used to tell you in school: There are no dumb questions. That’s especially true when learning about new approaches to software development. In that spirit, here are some basic explanations of service virtualization techniques and best practices.
For absolute beginners, here’s an FAQ to serve as a primer to get you going:
Service virtualization is the practice of capturing and simulating the behavior, data, and performance characteristics of dependent systems and then creating a virtual copy of those dependent systems. 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.
Today, it’s pretty much for every viable company. Do you deliver services to customers over the internet? Then service virtualization is for you. Do you enable sales and services teams through software? Then service virtualization is for you, too. In fact, there are very few businesses today that do not depend on the ability to deliver the very latest software capabilities on an ongoing basis. In such a competitive environment, companies that fall behind are doomed to fail. That’s why the impact of service virtualization—the ability to turn around software iterations faster, better and cheaper—is so profound and far-reaching across industries.
Service virtualization creates an asset known as a virtual service, which is a system-generated software object that contains the instructions for a plausible “conversation” between any two systems.
It is important that there must be real software automation involved in the capture and modeling of the virtual service. Otherwise we are still talking about the time-intensive, costly “stubs” developers could manually code and maintain on their own.
Let’s say your team is developing an update to a key application that must make requests of a downstream mainframe and a cloud-based partner service (SaaS). Both of those downstream systems are unavailable for you to use to run your regression and performance tests throughout development. So you replace them with virtual services and get to work. Think of the virtual service as a reliable stand-in for those constrained and costly applications that you don’t want to expose to the daily grind and dangers of being set up, used, and reset for testing and integration purposes by developers.
The fundamental process works this way:
Remember, we say that a virtual service 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 virtual service to allow it to respond with enough intelligence to support the variability of needed usage scenarios. The virtual service 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.
Companies using service virtualization experience lower costs, greater software quality and faster delivery. Over the years, surveys have found companies realize:
Christine Bentsen is the head of DevOps marketing at Broadcom. She has extensive experience as both a product manager and product marketer, with over 25+ years of experience in technology.
bizops.com is sponsored by Broadcom, a leading provider of solutions that empower teams to maximize the value of BizOps approaches.