We've seen a growing phenomenon of misdirection going on lately in the market of Service Virtualization. Fortunately, last time we looked up Service Virtualization on Wikipedia - someone got the definition right. Thanks to everyone who updated that page and understood the bigger picture here. It can be difficult to maintain perspective when there are so many sources touting different meanings of the words "service" and "virtualization" used together.
What is the reason for such a masquerade, and why would someone describe things that are not virtual services as virtual services? Perhaps this is simply an unintentional mislabeling, but just as often this means someone is selling software or delivery capabilities that are either not ready, or never will become what we define as Service Virtualization.
Here's the top 6 kinds of "Fake Virtual Services" we are not looking for, but getting anyway:
1. Test Stubs as Virtual Services: This is by far the most common fake VS we find lately. The market for Software Testing tools is very crowded and tough, so you will find that any testing tool that allows you to enter a request/response pair as a step within the context of their test, will start calling that stub a Virtual Service. That's a far cry from dynamically built and intelligent virtual services that support stateful transactions, performance characteristics, etc.
2. Virtual Machines as Virtual Services: Conventional virtualization still pops up as a compare-and-contrast with SV. Indeed, those hardware or server virtualization solutions can "Virtualize an Entire Environment" for software development -- IF AND ONLY IF the entire environment is in scope. While they can image hard drives, desktop software and CPUs very productively, VM's cannot handle the heaviest and most constrained assets in your enviroment, nor will they be able to image or replicate anything that is "out of scope" for your team.
3. Manually Built Libraries as Virtual Services: This one may be hard to identify, as it often comes from within your own company or its partners. You may have a team of engineers who have painstakingly coded and maintained their own "Responder Framework" of mock services intended to support the other end of a needed transaction. Inevitably these manually coded elements are brittle and require an ever increasing amount of maintenance over time - leading to the question "Is my team spending time developing and assuring useful functionality -- or managing stubs?"
4. Service Directories as Service Virtualization: Around the time we were rolling out the first SV systems for end customers in 2006-2007, there was another definition floating around among integration vendors that basically called UDDI directories with "pointers" or dynamic links to the locations of given web services objects Service Virtualization. That was correct on the "Service" part and nice for governing or managing services, but it didn't really represent virtualizing anything except for being able to change a link to a WSDL.
5. Cloud-Covered Service Virtualization: This is the latest fad in fake SV. Cloud is great, it is on-demand, has virtually unlimited elastic capacity, instantaneous deployment of servers, reduced cost etc. But it won't eliminate dependencies by itself. If you are doing any heavy enterprise integration work leveraging Cloud, you will also need a robust enough Service Virtualization solution to solve the "wires hanging out" that will still constrain capacity for any serious enterprise software implementation.
6. Outsourced Labor as Service Virtualization: Of all these mind tricks, this one actually made the most logical sense and was the easiest to spot. It simply means you get people somewhere else to be your "virtual assistants" and do things for you. Still popular in practice but fortunately we stopped seeing services firms call it SV or virtual services. I think they just call it outsourcing or contracting services again.
Service Virtualization must cover a lot of ground in order to eliminate the most complex constraints, because they don't happen at any one single point in your architecture. Your best defense is to understand that while virtual services are lightweight, they are not simply generated via a quick slight of hand or misdirection.
Virtual Services should be based on very detailed and intelligent observation of everything your teams must connect to, and scaled to industrial readiness through automation.
Educate yourself on Service Virtualization. You can't fake out a professional faker. Once you are aware of the above "mind tricks," and ask for delivered proof of the real core capabilities of SV, you will much more easily be able to spot fake virtual services when they are presented to you.
And then you can go about your business.
