The difference in service virtualization for monolithic and microservice architectures?

We see our customers embark on a migration to microservices from monolithic architectures. 

We get asked often: How does Service Virtualization (SV) and API mocking fit into both worlds and what changes when you migrate from a monolithic architecture to a microservices architecture?

In the diagram below, we demonstrate how our customers typically deploy two instances of an SV solution in a monolithic environment. They would have a sandbox service virtualization environment used by developers and testers to create their virtual services and then a test service used by the development and test environments. See Figure 1.

Figure 1: Service Virtualization in a monolithic architecture

When moving from monolithic architectures to microservice architectures, we see our customers:

• Create production-like environments prepared on-demand using scripts instead of manually configured environments

• Use containerisation technologies such as Docker and Kubernetes (OpenShift, Rancher and similar) instead of running on bare hardware of virtual machines.

• They run production-like environments even locally on developers’ and tester’s laptops or desktops and in CI/CD builds and pipelines instead of development and testing in shared DEV, SIT and QA environments.

A distributed architecture with many production-like development and test environments on local machines, in CD/CI or Kubernetes (or OpenShift or Rachner), requires a service virutlaization tool that can be deployed in many of those environments as well. Those service virtualization tools allow for the new decentralised development and testing approach to be used throughout the lifecycle. This is demonstrated in Figure 2.

Figure 2: Service Virtualization while migrating to a microservices architecture

OpenSource tools like Wiremock or Mountebank allow for that usage pattern, as well as selected commercial offerings such as Traffic Parrot.

Once the migration to microservices has been completed, the centralised SV infrastructure can be deprecated and decommissioned, as demonstrated in Figure 3.

Figure 3: Service Virtualization in microservice architectures

Some of our customers ask us why would they not just use the existing SV approach in the new world of microservices?

Although using the centrally managed solutions in microservice architectures is possible, it comes with maintenance costs caused by:

• Cannot create production-like environments on-demand by programmable scripts resulting in increased maintenance costs

• Many laptops, CI/CD pipelines and K8S environments connecting to the same instance of SV create a bottleneck resulting in increased maintenance costs and a single point of failure.

• Investing in building SV artefacts in monolithic tooling that is costly to migrate to a fit for purpose microservice and container compatible SV tooling incurs long term migration costs.

If you would like to learn more about microservice architectures and what changes when moving away from a monolithic approach, see the introduction to microservices by Martin Fowler and the article by Paul Hammant on release schedules.