Service virtualization is an increasingly popular tool in the software developer and devops toolkit. In this blog, we cover what it is, use cases, and how it works. This introduction is part of our in-depth series on service virtualization. Stay tuned and follow along for more content!

What is service virtualization?

The virtual service concept

Most web applications these days are connected to a number of dependent services (unless perhaps it is a system of record). For example, an eCommerce site may be connected to payment, inventory, and shipping and logistics software. This interconnectedness has made software testing challenging. Conventional methods at many engineering organizations often leverage a replica of an end-to-end production environment, but that soon proves to be too complex to manage.

Enter: service virtualization.

Service virtualization is the simulation of backend service dependencies in a service-oriented or microservice-based architecture. Each simulation is typically referred to as a virtual service.

By creating virtual services that represent unavailable APIs, costly backend systems, or services without the right data, developers can minimize delays and get around their current development and testing constraints.

The origin of service virtualization

Service virtualization is not a new concept. In fact, it’s been around since 2002 when it was first popularized by a startup at the time called iTKO. iTKO was responsible for “productizing” service mocking for the masses. Virtual services from iTKO were used to stand in for APIs, message queues, mainframes, and databases.

Since then, a number of new players have emerged in the space.

Service virtualization vs. service mocking

Engineers have been using stubs and mocks in the development process for years. While mocking involves testing specific software components with limited context, service virtualization is essentially a more sophisticated version of this. Service virtualization replicates systems at production scale for more robust testing. Generally, mocks are manually developed for each test case.

Engineers may use the terms service mocks, test doubles, and virtual services interchangeably – so just be aware.

Benefits of service virtualization

When services in end-to-end environments are unavailable, it can delay or even halt releases. But leveraging virtual services can circumvent problems in a timely manner. Now more than ever, preserving developer time is of growing importance in an age where highly-paid engineers bear multiple responsibilities. Ideally they are releasing customer-facing features that generate revenue and differentiate the enterprise.

Some specific benefits of virtual services include:

• Reduced reliance on complex end-to-end environments
• Increased availability of developer environments
• Broader data responses for more robust unit, functional, integration, and load testing
• Faster release cycles, since any unavailable systems can be simulated
• Simulated what-if scenarios to ensure cloud resiliency and scaling under high volume
• Peace of mind and confidence in releases

Scenarios and use cases for service virtualization

Simulating unavailable services

Service virtualization can simulate an API response from an unavailable service. There are several reasons why a service may be unavailable:

• The service is not built or updated yet
• The version in the testing environment has drifted from the version in production
• It is a 3^rd party service
• There is only one instance of it (e.g. it is a pay-for-use sandbox)
• The system of record which is the backend to the service has incorrect data

Inadequate performance of the real services

When the real API doesn’t perform the way you need, service virtualization can stand in. For example, if the external API responds with high latency, using virtual services would allow you to speed up response times or slow them down.

Or perhaps the real service can only scale to a certain TPS (transactions per second) that’s below the watermark you are trying to achieve. For example, a vendor-provided sandbox API for a payment gateway only goes to 10 TPS max, but your manager wants to see if your order processing API can go to 2,000 TPS in preparation for the holidays. Service virtualization would allow you to increase that limit.

The responses of the real backend do not meet developer needs

Development teams may feel stuck if they need to execute certain test cases, but they’re not able to get the specific response from the real service. For example:

• Developers sometimes need to solicit additional error codes from the backend
• The test data in the API only contains a few records, but you need several thousands
• The real backend (such as a third party) has a wide variety of responses that get triggered, but you only need a select few

These scenarios can be easily programmed into a virtual service.

Feature Spotlight: Service Mocks

Service Mocks–another name for Service Virtualization–are a critical component of development and testing. Learn the how & why behind our Kubernetes traffic-based mocks.

Service virtualization examples

Service virtualization is a common practice across many industries and organizations for different functional and performance testing purposes. Consider these examples:

• Gig rideshare and delivery companies such as DoorDash, Instacart and Uber need to simulate mapping APIs to pretend their drivers are en route
• Retailers need to simulate a payment gateway, inventory or shipping systems
• SaaS software providers need to simulate authentication and user lookup APIs
• FinTechs need to simulate online banking APIs, low-latency trade platforms or credit checks

How does service virtualization work?

Recording traffic

Virtual services are created by listening to traffic. Almost all service virtualization tools require a proxy to be inserted between two services, which requires temporary configuration or code changes.

More modern service virtualization solutions such as Speedscale allow for transparent proxy listeners like Kubernetes sidecars to be installed, requiring no changes for recording or playback.

Editing the service

After a service is recorded, most tools require the service images or data files to be edited. There is normally a UI editor or scripting format available, and creating service response logic can get complex. Be aware, when statefulness and data idempotence are required, services may take weeks to complete. 

Replaying the service

The virtual services or service mocks are typically deployed on a server, and require the client API to be redirected to interact with the virtual endpoint. When development or testing is complete, the changes must be reverted. Modern solutions such as Speedscale allow containerized virtual services to be deployed in any cloud/cluster, with unlimited instances.

Advanced service virtualization

There are many additional concepts, which we will explore in subsequent blogs, but virtual services can be a powerful accelerator for software development teams looking for more velocity. Some service virtualization tools on the market even offer more advanced features to take your software testing to the next level:

• Parameterized data values to augment fields with datasets
• Self-healing virtual services to keep pace with contract or schema changes
• Pass-through modes to avoid config/code changes
• Autoscaling virtual services to meet demand
• Adjustable latency
• Chaos responses

We’ll cover top tools in an upcoming post – stay tuned!

Next up: Advantages of service virtualization over mocking

Learn more about the differences between service virtualization and mocking, and why service virtualization may be the better option for development teams seeking more robust, complete testing.