3 ways to deploy and share virtual services and API mocks

There are three common ways you can deploy and share your virtual services or API mocks.

The first one is where you reuse the same hardware and virtual service across many users, see Diagram 1.

What you see in Diagram 1 is an organisation that uses a DEV environment to deploy a Legacy Banking Application. That application needs to connect to, among many others, a payment service. The DEV environment is connected to a payment virtual service, that is running in a service virtualization tool deployed on a virtual machine. That same virtual service is shared with two more users (or agents if you wanna call them that). The Jenkins slave is running build jobs (pipelines) of that same Legacy Banking Application and connects to the shared Payment virtual services. We also have a QA that is testing a new microservice on her laptop, that requires connectivity to the Payment service, and she is using the same shared Payment virtual service.

The second one is where you reuse the same hardware but create a copy of virtual service per user, see Diagram 3. The three users/agents (DEV environment, Jenkins Slave and the QA) are using three copies of the same Payment virtual service, running on the same shared virtual machine.

The third option is where you use a copy of virtual service per-user, but deploy it per-use instead of using a shared environment, see Diagram 3. In this case, each user/agent uses a copy of the Payment virtual service that is for their exclusive use. So, the DEV environment is connected to a Payment virtual service running in Docker on OpenShift in the internal cloud. The Jenkins Slave is spinning up a Payment virtual services just before running the tests of the Legacy Banking Application. And, the QA is spinning up a Payment virtual services on her laptop.

Please keep in mind, these are only examples to demonstrate what our clients do, the details can differ and will be specific to every organization.

Traffic Parrot is not recommended in Diagram 1 and 2 style deployments

Firstly, if you want to do Diagram 1 or Diagram 2 shared deployment style, we recommend using other commercial service virtualization tools instead of Traffic Parrot. It is possible to use Traffic Parrot in those environments, but we do not recommend it.

Traffic Parrot is recommended in Diagram 3 style deployments

If you would like to use distributed deployment, similar to the one described in Diagram 3, we recommend using Traffic Parrot.

If you would like a recommendation of how to deploy the virtual services or API mocks specific to your project, please contact help@trafficparrot.com and we will be more than happy to assist you.