Let's imagine that we are developing and testing an application whose environment is separated into smaller parts. Let's imagine that each part is managed by a different team, in different countries and with different testing methods. Let's imagine that different developments depend on other teams delivering modifications to their project 'piece', that multiple teams are working in the same environment, and that both the testing part and the development teams depend on this whole system working with a certain degree of precision. Let's imagine, ultimately, the chaos.

For some this will be a bit exaggerated ... for others, beyond a small excess due to the literary context, it is part of our day to day.

And the question is,where service virtualization has a place here? Virtualization is, simply put, the simulation of the behavior of a component. It is a method that will allow us to avoid all those complications that arise when testing in a real system.

Service virtualization makes us configuration independent, allows us simulate casuistry virtually impossible to reproduce in a real environment, it facilitates independence of tests in shared environments, facilitates tests on systems with dependenciesAllows test unfinished services or evolving ... It is, in general, a way to reduce time-to-market and facilitate DevOps and continuous integration.

It seems somewhat unusual, however, service virtualization is not a new concept at all, but rather a concept consolidated with the arrival of microservices.

Many of you will have already worked with mocks and with stub, but unlike the former, service virtualization allows us a dynamic simulation that emulates behavior with context-aware responses, with easy maintenance and high reusability.

In short, it offers us a simple and dynamic way to implement a limited copy of the behavior of our environment.

And this is just one of its strengths: the virtualization of services allows us to implement a limited copy fully adapted to our needs. Unlike other heavier virtualizations, service virtualization allows us to simulate only the behavior required for our development or for our tests, thus reducing its complexity significantly.

In this way, instead of working in an environment that is sometimes saturated, unfinished, fragmented and chaotic, we have the possibility of implementing a copy of it adapted to our needs. At this point it is important not to confuse "virtualize the service" with "adapt the service", since it is not a question of adapting the response of the service to that required for our developments, or for our tests, but rather of creating a copy of the real response ignoring everything that is not useful to us.

Of course there are downsides to this process. In order to achieve this work situation on a virtual environment and to measure it is obviously necessary to implement it. This fact can be seen as a 'waste' of time, taking into account that we start from a real environment that already exists. But let's think for a moment about all those delays that occur as a result of the aforementioned deficiencies in the real environment.

While it is true that virtualization takes time to learn and implement, these disadvantages are far outweighed by the benefits that come with it.

In line with the implementation of our virtual service, it should be mentioned that today there are numerous applications on the market that can facilitate this work. Thus we can find, among others, applications such as:

• SmartBear, perhaps one of the most powerful tools today.
• WireMock, quite complete product and in continuous evolution.
• Hoverfly, easy-to-use free tool.
• API simulator, similar to HoverFly, improving manual implementation versus HoverFly's increased need to capture real traffic.

In summary, today it is possible to overcome the obstacles that we find in real environments by doing our work, whether development or testing, in virtualized environments created based on our needs. To do this we just need to choose a tool and a short 'introduction to virtualization' period.

Thus, once the bases of this methodology have been presented, it only remains to ask one thing:

Do we virtualize?