Skip to Content

Role of service virtualization in DevOps

Capgemini
December 18, 2020

As per a DevOps survey, most delays occur during the testing phase of SDLC. Some of the reasons are:

1. System constraints: 80% of teams experience delays because of unavailable dependent systems
2. Parallel development and testing: 56% of the critical dependencies are unavailable when the development and the testing teams need to work on them in parallel
3. Third party: 79% of teams face restrictions, time limits, or access fees on third-party services.

Service virtualization helps companies achieve DevOps goals by eliminating barriers that impede access and responses from key systems during testing.

A GARTNER SURVEY of 500 companies indicates:

  • A dramatic increase in test rates using service virtualization
  • 33% of companies reduced their test cycle times by at least 50%
  • Nearly half of respondents saw a reduction of total defects of more than 40%

Service virtualization: What is it?

Service virtualization is the concept of simulating the behavior, data, and performance of the dependent systems and then creating a virtual service of the dependent systems. The virtual services thus created can be used instead of the live systems which behave very much like the live systems. Developers, testers, and performance teams work in parallel, leading to faster delivery, lower costs, and higher quality of applications. Behavior simulation is carried out using virtual services, which are pieces of software that mimic application behavior in some way.

Service virtualization: How does it work?

Service virtualization has three steps:

  1. Capture: In this step, the SV listener is deployed between the application under test (AUT) and the dependent systems. The listener then performs the below steps between the AUT and the downstream dependent systems:
    1. Record traffic between existing systems or
    2. Create from engineering specifications
    3. Draws data from sources such as log files, sample data, packet capture, etc.
  2. Process: In the process step, the service virtualization solution performs these steps:
    1. It evaluates the data and the protocol details that was captured in the capture step.
    2. Co-relates them into virtual services which are live-like models.
    3. The virtual services are the conversations of the request and response pairs, which can be further used for development and testing.
  3. Model: The virtual services created in the process step are deployed in this step for the teams to use instead of the dependent systems. The model step enables:
    1. Living, breathing, “live” model
    2. Contextual and sophisticated behavior
    3. Automatic handling of dynamic behavior.

Context diagrams – before and after service virtualization

The figure below shows the context diagram before and after service virtualization.

Service virtualization benefits

Reduction in release cycle time

Virtualizing the frequently failing third-party services improves the overall test-and-release cycle time by reducing testing wait time.

Cost reduction

  • Virtualizing the transactional services reduces the cost involved in using them during the testing phase
  • Eliminates environment sharing and hence drastically reduces cost.

Quality improvement

  • Virtualizing third-party services early in the delivery cycle enables shift left of integration and NFR testing to improve quality and reduce risk
  • Allows negative test coverage
  • Provides stable test environment.

Productivity savings

  • Potential savings up to 50–60% on total productivity by applying service virtualization
  • Reproduces production defects early in the lifecycle
  • Enables parallel development and testing.

Service virtualization implementation approach

Apps NA DAQE practice has the required expertise in implementing service virtualization and has come up with the approach below to conduct initial assessment and pilot in the customer landscape which can help them evaluate the return on investment leveraging service virtualization.

For further queries and discussion, please reach out to Deepa Talwaria (deepa.talwaria@capgemini.com) and Anil Kumar (anil.j.kumar@capgemini.com) from Apps NA DevOps COE team.