July 11, 2019

What is Service Virtualization in DevOps?

Service Virtualization

Service virtualization is a hot topic! But do you know what it really means — and how to leverage it? Find out in this blog! 

Back to top

What is Service Virtualization?

Service Virtualization is a method of capturing and simulating the behavior of constrained or unavailable systems. The litmus test of a Virtual Service is that the system consuming the service cannot tell it is not the real system. 

Time-to-market, development costs and application quality are top priorities for organizations developing software. Constraints remain a fundamental challenge to timely, cost-efficient, high quality software development and delivery. 

One area of focus for many development teams is mocking and/or stubbing of application code to reduce dependencies on components of the application environment. 

Three options traditionally utilized for solving this constraint problem are in-house, developer-written code, proprietary tools, or open source tools including Mockito. Service virtualization is also a great way to resolve this constraint problem, but is usually less well-known.

Back to top

When to Use Service Virtualization


The primary use-case for Service Virtualization is when the application you are developing and/or testing is dependent on some other service.

Whether this other service is third-party or in-house, your application or module depends on it and is a dependency on your testing flows.

Since this is not always practical, the obvious choice is to virtualize these services (dependencies) and isolate your dev and testing efforts from real environments to avoid impractical or overly difficult situations.

Back to top

Service Virtualization vs. Object Mocking

Service virtualization is often compared to object mocking. Object mocking is a well-known and heavily adopted concept in the world of virtual services. Mocks are best utilized when doing unit testing, where it is very handy to be able to mock particular objects from the object model that your application is using.

With the right objects mocked, the unit test can focus on what needs to be tested instead of setting up various objects properly for different test scenarios. 

However, the nature of unit tests and object mocks isolates these techniques from proper and robust integration testing. For example, in the case of dependencies based on HTTP APIs, you may want to know what happens if particular HTTP responses are returned. This scenario is much more complex than merely isolating mocked objects on a higher level of abstraction.

This is where service virtualization (SV) comes in. With a service virtualization solution, you can create virtual endpoints that simulate the behavior of the real service.

Services on which your application depends may be an unstable system that is not accessible all the time and that could potentially be a bottleneck in your testing process. With service virtualization, you always have these dependencies available.

Back to top

Service Virtualization in Testing Leads to Full-Stack Integration Testing

Here are some real-life examples of when service virtualization can help your development team:

  • Testing dependencies during development. Let us consider a situation where another team is in the middle of developing a dependency on your component. Your work may be done according to the API spec you received, but you have to wait until something else is ready. With service virtualization, you can begin testing against a virtual version of the dependency. 

  • Testing code behind a firewall. In this case, you cannot access production dependencies unless the code is in some higher environment or production. This scenario will either force you to do trade-offs in your testing, or spend time fixing this issue. 

  • Paying for volume after load testing. You have to pay for every hit and volume of the performed operations against the dependency of your application. But you do not need it during load testing, which can generate a significant number of requests to the dependent service.

But it is not only about having the dependency available. With service virtualization, you have the entire behavior of the dependency under your control. 

  • You may return responses that contain test data that is very hard or impossible to load to the real service. 

  • You may return responses that represent various failure scenarios that may be very hard to reproduce using the real service - as the service is not yours, you cannot break it at will just to be able to test whether your app could recover from such a state. 

  • With service virtualization, you can also have the response time under your control, which is very useful for performance testing your application. This is especially useful when you want to test the performance of your app and not your app’s dependencies. In other words, you are interested in whether the latest code change really improved the performance and in order to validate that, you don’t want your tests to be affected by network glitches or unpredictable performance of the dependency.

In addition, you can use service virtualization to stretch your app to figure out how it behaves if the dependency returns responses slowly. 

Back to top

Service Virtualization Testing for Shifting Left

Service Virtualization is an essential concept for successful shift-left testing. This means testing earlier in the development lifecycle to save costs by identifying issues earlier in the life cycle. 

In order to help developers really implement the shift-left paradigm, they have to have the right tools that will enable them to perform various types of testing as early as possible during development. This  is typically the issue that leads to various trade-offs, low coverage, or robustness of the test. 

One typical example is how to perform integration or performance testing if the test scenario depends on something that is not under the development team’s control (for the reasons we stated above).

Service virtualization helps resolve this common roadblock and lets developers focus on the tests themselves and not about how to get access to various environments or third-party services.  They don’t need to force real services to behave the way they need in order to perform specific test scenarios.

Also, artifacts defined by developers for their tests - the definitions of the virtual services - could be used later in the life cycle by different teams who may be responsible for regression testing or turning everything in automated and reproducible CI/CD flows.

Back to top

Service Virtualization Tools

There are multiple options for tools to help successfully adopt service virtualization. When comparing service virtualization tools, developers often compare their personal preferences and how their development processes are driven.


First, the experience closest to developers’ nature is in-code virtualization tools like CodeSV where developers could define virtual services directly in the code using Java. This is the smoothest way for developers to adopt the concept of service virtualization, as they can define the virtual service in code using fluent API and leveraging all benefits of IDE like code completion.

Service Virtualization: Community Edition (SV CE)

Another easy to adopt option is Service Virtualization: Community Edition (SV CE). It is a desktop application that allows you to define and host virtual services based on HTTP/HTTPS and also to record traffic to real service and create the virtual service based on the recorder traffic. Using SV CE, developers could spin up individual virtual endpoints that may be used for integration testing within the team.

Legacy Service Virtualization Solutions

Another powerful option to choose from is found in traditional, commercial service virtualization solutions. By simulating the behavior, data, and performance of dependent systems, these enterprise service virtualization solutions can speed up testing and reduce the costs associated with access to live systems.  

But traditional service virtualization also comes with an array of challenges that makes it less suitable for organizations looking to shift left. Not only are these solutions very costly to own, but they are also only available on-prem and less user-friendly.

BlazeMeter Virtual Services 

BlazeMeter Virtual Services (also known as BlazeMeter Mock Services) offers a streamlined approach to virtual services that addresses the challenges posed by legacy service virtualization solutions. Mock Services provides a cloud-based, automated, maintainable, and deployable virtual services option that helps teams test at earlier stages of application development.  

BlazeMeter offers the best of both worlds when it comes to service virtualization: the benefits of traditional service virtualization implementations without the complexity.

Watch the webinar below to take a closer look at BlazeMeter Virtual Services and see how it works:

Back to top

Bottom Line

Service virtualization has played a vital role in the software development and testing ecosystem for over 20 years.

But enterprises need a lightweight virtual services solution that is simpler to use and more cost-effective, while fully integrating with the rest of your testing. Organizations need to eliminate the bottlenecks that come with traditional options and shift service virtualization to the left.  

Try BlazeMeter Virtual Services today to see how you can bring service virtualization into the era of agile. 


Back to top