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!
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!
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.
So what kind of services can you simulate? Well, basically anything carried over TCP/IP. The most common services are of course web services such as SOAP and REST, but inter-platform communication as JMS, MQ and database connectivity over ODBC/JDBC can be simulated just as well. Have you got a business suite with a proprietary protocol, such as SAP or an Oracle system? That works too!