In this part of the article, we will go into some more direct examples on how to implement Service Virtualization, and some related use cases. However, the concept of Service Virtualization can be applied to solve many other issues, and some of them will be covered in the next post.

This is the most straight-forward use case! How often do you lack proper integrations in your test environment? Is there some component or system which you can't access during unit tests because of some constraint or restriction? 

Typical constraints can be:

• Availability. A system which is lacking a test environment. This is common for legacy systems and Mainframes.
• Cost. You can't integrate costly external APIs or integrations in the test environment, as some providers will charge you for transactions against their test/sandbox environments, or limit the amount of transactions that you may provide.
•  Capacity. If you have a core ERP, such as a CRM-system, Sales system, SCM-system or such, they may not be able to accept test runs during peak hours, and you have to perform all integration testing during evenings, nights and weekends.
• Data Synchronization. It's common to move transactional data to a System-of-Records (SoR) periodically. But in a test environment, the SoR is not always available, making data validation tests very difficult. Also, when using a distributed architecture such as SOA, it is a lot of work making sure that all independent databases are in the correct state, with the correct data load, for the tests to be successful and meaningful.

Handling the data set in test environments is a headache. Non-completed test cases have a tendency to not restore the data set once executed, leading to duplicate entries and records in an inconsistent state. On top of this, restoring test data is time consuming, either because the data sets can be rather large and take a long time to import, or because the department responsible for data loading also have other, more prioritized tasks. And while the QAs wait for the Operations department to restore the test data, the whole test process comes to a grinding halt.

The key concept of working against a simulation instead of a physical test platform, is that there is no database behind it, and thus, there is no data set to corrupt with invalid test cases! Still, the simulated service will always give you a proper response so that you can verify your integration, which is what most tests aim to achieve. 

However, this does not replace full-out testing using a proper physical environment, where you have tests down to the database layer. But using a simulation, developers and QA can start doing integration tests much earlier in the development life-cycle, so that once the deep-layer database tests start, most of the integration issues are already solved.

And hands on heart, how many of your software bugs stem from the database server not reading/writing the correct data, compared to the issues which stem from issues in the communication and system integration? Do you really need to do all that database reading and writing to isolate your most common bugs?

Traditionally, software development has been a rather sequential process. Developers wrote bits of code, and when they thought it was mature enough, it was deployed to a test environment, for QAs to evaluate. Any bugs found would be sent back to the development team for patching, and then the process was repeated again until QA was satisfied with the quality. This process caused developers and QAs to spend a lot of time waiting for each other to complete their tasks.

In the last couple of years, Continuous Integration (CI) has become a staple of software development. By validating the code base as soon as new code has been produced, developers will be aware directly if they have provided a faulty artifact. As soon as new code is committed to a code repository, a set of automated tests are executed. The automated CI validation usually rely heavily on unit tests, and other forms of module testing. If the new code artifact doesn't pass the automated tests, the developer is notified - usually by an e-mail or by a status screen. As developers now will be aware of code issues almost instantly, and don't have to wait for QAs to discover them later in the testing phase, the development process is shifted left, that is, moved to an earlier stage of the Software Development Life-Cycle (SDLC)

​If you go back to the first two articles, you should get a feeling for which problems that Service Virtualization can provide a solution to. It's all about breaking constraints; enabling developers, QA and Platform Engineers to model services which are not available.

Services may be unavailable for a number or reasons, for instance that a module is still in the development phase, or a that third-party service is too expensive to make available to QA in early tests. Other times test environments may be available, but the test data is constantly corrupted, so the tests don't create any actual value. You probably have heard the phrase "the application usually behaves like this in the test environment, but it should work when we get the artifact to production" a million times.

In this article, we will cover the key concepts of Service Virtualization; what it is, how it works and what it can do for you.

What is a Virtualized Service?
In short - it's an intelligent simulation of a service. It's an API, or some other form of end-point, which acts in accordance with the rules of some sort of contract. The virtualized service is aware of parameters and data-types, and knows which requests are valid, and which aren't - and responds accordingly. So when you request the simulated service, you get a response which is valid according to the specified contract, just as if it would have been a non-simulated service. 

Why should I Virtualize Services?
Well, there are several reasons for this. But as stated earlier, it's all about breaking constraints, no matter if they are technological or financial. Common problems which can be resolved by simulating service include: 

• Test Environments  - How much time do developers and QA spend just waiting for access to the test system? And when Dev get their turn, QA has to wait - and the other way around. It is usually the Operations department which is responsible for deploying the correct artifacts and loading the proper test data, and when they are occupied with important production issues instead - everyone has to wait for the test environment to become available or restored.
• Test Data Management - The data set in test environments is easily corrupted. A single test case which fails to restore the test data once it's completed will cause errors relating to duplicate data the next time it's executed. And again, there is usually a dependency on the Ops team to take the time to restore a corrupt test environment. 
• Identify Issues early in the SDLC - Software issues should be found as early as possible in the Software Development Life-Cycle (SDLC), as mitigation costs increase rapidly the later you discover them. If you can give developers and QAs access to systems which usually are not available until integration testing, or even the production system, how many more issues can you then find earlier in the SDLC?
• Integration Costs - External providers may charge not only for using their production system, but also for the UAT/Sandbox environment. Even if the per-transaction fee may be low, it can add up to quite a cost if you want to run a load test on your system. 
• The Problem with Mocks - The issues relating to mocked services, or "stubs", are covered in the next section. Mocking a service may seem like a easy way to validate integrations, but there are some problems associated to it.

Why not just write a Mock instead?
​To mock a service means to develop a stand-in, or stub, for the service. When you request the mock, it will respond with some sort of data. This sounds similar to a virtualized service, so why not go for the mock instead? Well, virtualizing the service actually has some key benefits:

• Automatic Creation - A mock needs to be programmed by a developer, whereas a simulation can be created by anyone.
• Rely on the Simulation - A mock needs to be maintained by the developer as well. Running tests against a mock integration which is not up-to-date with the live integration, may cause false-positives in testing, which will not be detected until the artifact has reached production. With simulations, changes in the integration can be updated by anyone - or even automatically.
• Let Developers Develop -  Software Developers should be doing what they do best - transforming business requirements into software solutions. Writing and maintaining mock integrations will consume valuable resources, and lower over-all output.
• Rich Test Data - Mocks are usually quite stupid. They may respond with "everything is OK!" no matter what data you provide to them, which is useless for negative test cases. It's not uncommon that a mocked service responds with the same data, no matter which data you request it with - making request/response and parameter validation almost impossible.
• Test for Performance - Also, mocks are usually too good at what they do! They respond almost immediately, since there isn't any processing of business data going on in the background. So how do you know how your application behaves when the service you are integrating towards, isn't behaving perfectly? 

Which Services can be Virtualized?
As a concept, Service Virtualization is not bound to any specific set of services. All communication which is based on Requests and Responses, and carried over the standard internet protocols TCP or UDP can be simulated.

It's common to simulate Web Services wrapped in HTTP, such as SOAP and REST, but other Internet protocols such as SMTP, IMAP or SNMP works just as well. This means that you can simulate anything from a Web API to a Mail Server or even the performance reports from a Network Router. Is your SMS Provider charging you for sending text messages in their sandbox environment? Then you can set up a simulation of their SMPP-based end-point instead! You can create simulations of media protocols as well, such as RTP, to create a virtualized voice or video service.

Proprietary protocols works just as well. If you have a business solution from SAP or Oracle, or maybe an internal legacy business system, you can simulate those integrations too.  Actually, legacy systems are usually very beneficial to simulate, as their test environments often are limited, or completely unavailable. 

Furthermore, the concept is not bound to external modules, you can simulate an internal Java component, or even a SQL database. Any sort of constraint, and any sort of unavailable dependency, can and should be simulated!

How do you Create a Virtualized Service?
You can create a simulation in many different ways, but the most common ones are:

• Using an API Specification - This is very useful when simulating Web Services where WSDL or XSD files may be available to describe the rules of the communication.
• Using Live Data - If you haven't got an API Specification, you can provide the simulation with sample data from a test or live system. The system will listen in on the requests and responses in the communication, and start building a set of known functions, and their associated parameters.
• Using R/R Data - If you for some reason can't listen in on the communication, you can feed the simulation from known Request & Response Pairs. These data pairs can usually be extracted from a test environment, or from the logs of a live system.
• Manually - Of course you can create the simulation data from scratch, but this is usually very time-consuming. 

So what is Service Virtualization not?
It's important to remember that a simulation is not a database. So when you add a data record using a virtualized API, the record will not be available to retrieve from the virtualized API later on, as the simulated service will not keep it.

But is this really an issue? When you perform testing of a module, you are usually not interested in if some external service could add a record to its internal database or not. Instead, you want to verify that your module-under-test can integrate properly towards the service. And this is exactly what a simulated service can provide for you!

In the next article, I will provide examples of typical use-cases where Service Virtualization can help you out, including Test Data Management, External Integration, Compliance, Performance Testing and Verification Environments.

What is Service Virtualization and why is it needed?
Service Virtualization is a concept where services are virtualized - or as I prefer to call it - simulated. In short, it's a way to replace an integration point with an intelligent recording of the service. It's a simulation which you can request, just like any integration point, and you will retrieve a valid response.

So why would you like to simulate a service? It's quite straight-forward, it's all about breaking constraints. It doesn't matter if you're a developer or in QA, you have probably - just as me - been limited in your work because you don't have access to some specific resource. It could be a testing environment where you're waiting for the correct test data to become available, or access to some third-party API.

And hands on heart, how often haven't you been aware of integration issues until the artifact has been deployed to your live system? Then your options are either to roll back the release, or roll forward with patches. Both options will cause you downtime and a dent in your SLAs. The main benefit of service virtualization is that developers as well as QA can get access to environments much earlier in the Software Development Life-Cycle (SDLC). Problems which otherwise would be found in a late stage of testing, usually integration, system or acceptance testing, can now be found during either development or initial testing! 

It's all about SOA!
About a decade ago, Service Oriented Architecture (SOA) became the accepted way to replace older monolithic systems. The core concept of SOA was to decouple and isolate single services, so that the system as a whole can continue to work even if a single service would fail. This technique led to methods we today take for granted, such as load-balancing and other forms of scalability, where you can increase the capacity of a service, by just adding another instance.

But as a consequence, SOA created systems with a high rate of dependencies. As each service was decoupled, it depended on a multitude of other specific services to work. At this point, system integration became a headache for engineers and architects alike. And as platform design became more complex, so did the maintenance of the systems. Most developers and QAs are aware of faulty test environments, and not being able to develop against the third-party integration points - you might have a half-decent mock, at best. 

Today, the API Economy has really taken off, and modern applications rely not only on internal dependencies, but also on one or several external service providers. This means that developers as well as QAs have to struggle with both internal and external dependencies, and the Operations department have to spend time on restoring test systems, time they could otherwise have spent on what they do best - maintaining production systems to keep SLAs!

What can Service Virtualization do about this?
By simulating specific dependencies, either web services or other forms of communication, you can give developers and QA access to systems earlier in the software development life-cycle. Developers can work against third-party APIs which otherwise would not be available, QAs can start working against APIs which have not been developed yet. Platform engineers can create test and UAT environments with fully functioning integration against third-parties. 

When you are working against a virtualized service, you're not working against a physical platform with a core database, where the test data can (or rather will) be corrupted. This is the whole point - when you test your module against an external system, you are not interested if the recipient was able to add your record to the data set. You are only interested in that your module can integrate correctly with the external system, in accordance with the system specification. And that's the beauty of Service Virtualization - no faulty test data, no waiting for test environments to become available, no issues with test environments holding the wrong software version. Instead, you always have accurate integrations at the tip of your fingers!

And there are many other ways Service Virtualization can be used in your organization, I will get back on that in later posts.