Service Virtualization for Microservices
Learn how to use Service Virtualization to make testing your microservices a breeze
What is Service Virtualization?
Service Virtualization is a way to simulate the behavior of different services and components in a software solution. Below is a list of some real world use cases for Service Virtualization.
Using a virtual service while the real one is not available
Let’s say that your frontend team is working on a feature that has a backend dependency. If you use a virtual service such as a mock HTTP server while the backend development is still ongoing the frontend team can keep working without having to wait for the backend feature to be in place.
Another scenario is that your application relies on a third party service that might be unavailable or unreliable. If you decide to create a virtual service using a tool for Service Virtualization you can work independently of whether the third party service is up or not.
Independent testing
When testing an application you do not typically want to be dependent of external services since you want to test your application and nothing else. By creating a virtual double of the external services that your service uses you can test in completely independently. This enables you to test and release faster.
Providing a virtual service for end users
If you are delivering a platform for developers it is possible to provide a virtual version of the service instead. This way you do not have to develop and maintain a working test environment for the developers to use.
Create proof of concepts
If you want to create a proof of concept rapidly one way is to use virtual services instead of real ones. This way you do not have to develop and deploy a custom application for each proof of concept. Typically tools used for Service Virtualization enables you to quickly create and deploy a virtual service.
What are Microservices?
Microservices is a rather new way of developing backend applications. Earlier we used to develop applications as a single package of code – a monolith. This comes with a number of drawbacks including:
Deployment
A single large application can take longer time and be more complex to deploy than a small one. Small changes to the application also typically requires a full blown deploy of the entire monolith. This makes it harder to ship features to your users fast.
Maintainability
A large code base makes it hard to do upgrades without affecting large parts of the application. It is also hard to refactor since it is becomes hard to grasp how the different parts of your application affect each other as it grows.
Scaling up
A growing team working on a single code base can become troublesome. When a lot of new changes are introduced as the codebase grows it is harder to understand how they affect each other which might produce critical bugs.
Complexity
As an application grows so does the complexity. A large code base can be too complex for a single developer to fully grasp in a short time. This makes onboarding harder and can affect the performance of your team members.
Reliability
If something goes wrong in your application it is the single point of failure.
To remedy these drawbacks the microservices architecture was invented. The idea is to split your application into multiple small interconnected services which are developed, deployed and tested completely independently of one another. Let’s take a look on how microservices remedy the drawbacks described above:
Deployment: Since microservices are deployed independently this greatly increases the speed and agility of your deployment. If you want to introduce a new change to a microservice it should be possible to deploy it to production in minutes.
Maintainability: Smaller code repositories means easier maintenance work. It is easy to get an overview on what might break when upgrading package or refactoring a class.
Scaling up: In larger organizations it is common that one team is responsible for a single microservice. This makes it easier for developers to grasp the codebase and it’s functionality.
Complexity: A smaller code base means less moving pieces to keep track of as a developer. A smaller size means it’s easier to grasp as a developer.
Reliability: If one microservices goes down the rest should be able to work as usual. This removes the problem with a single point of failure as we see with monolithic applications.