Category: DevOps and Open Technologies

Once you have established that implementing service virtualization (SV) as a means to remove the bottlenecks formed by critical yet hard-to-access dependencies in your test environments is the way to go forward, one important decision to make is which SV tools to use for the process. Most major testing solution vendors (including CA, Micro Focus, Parasoft, Tricentis and more) offer an SV tool as part of their product range. Next to that, smaller companies have emerged for which an SV tool is their primary offering (TrafficParrot, for example). Finally, similar to the test automation ecosystem, many open source offerings have seen the light of day, most notably including WireMock and Hoverfly.

Similar to what has been going on in the test automation world for a while now, open source SV tools seem to have become the default choice for many development teams when looking for a solution that satisfies their SV needs. In this blog post, I’d like to take a closer look at the pros and cons of this bias toward open source products, as well as provide some tips on how to decide what type of tool works best for your organization and situation.

Benefits of Open Source and Commercial Solutions

There are several benefits associated with the use of open source service virtualization tools in general, and these benefits apply equally to SV tools:

• There’s no risk of vendor lock-in when you’re using an open source tool.
• There are no license costs associated with open source tools, whereas commercial off-the shelf (COTS) tools obviously do.
• Open source tools can be extended with specific features in case you need them (and you’ve got the development skills to do so). With COTS tools, you can file a feature request with a vendor, but that’s no guarantee when your request will be addressed (and if it will be addressed at all).

COTS solutions, on the other hand, have benefits of their own:

• They come with a richer set of features out of the box, such as support for a wide variety of transport protocols and message formats, etc., whereas open source tools often focus on a specific protocol and/or message format.
• They generally have a lower level of entry, for example because they offer graphical user interfaces that make them accessible for a larger audience, whereas open source tools may require you to write code or other forms of technical specifications to get them running.
• Professional support, both online and in house, may be included in the license purchase price, whereas open source tools offer support on a best-effort basis only, most of the time.

This is by no means a complete list of the pros of both types of tools. Also, some of the benefits mentioned here come with a caveat of their own. For example, the lower initial cost of open source tools (no need to buy a license) is often being made undone by the additional effort it might require to build simulations that are as powerful as those that can be created by commercially licensed tools out of the box. Always consider the total cost of ownership when you’re looking to implement an SV tool, and don’t forget that this TCO extends beyond licensing fees.

One other important aspect to understand when comparing open source and commercial tools is that they’re typically sold to different audiences and therefore, their creators must appeal to these different audiences accordingly. Open source tools are generally adopted in a bottom-up manner: they’re downloaded and experimented with by a developer or development team and, when successful, might slowly be adopted by a larger audience within the organization. Commercial tools, on the other hand, are often sold to development managers or C-level executives instead, since they hold the budget that is needed to make the purchase of licenses possible. Note that this is a generalization, and it might not work this way in your organization, but in general, I feel the above holds true. (Footnote: I have to say thanks to Tom Akehurst, the creator of the open source SV tool WireMock, for pointing out this important distinction to me.)

So, now that we’ve seen some of the benefits of both open source and COTS SV tools, I’d like to give you some advice on how to choose the right tool for your organization and situation.

First of all, understand that no tool is inherently better than another one (even though some tool creators and vendors seem to think otherwise, judging by their promotional and social media outings). Tool A, however, might under certain circumstances be a better fit for a given situation compared to tools B, C and D. What tool works best for a given situation depends on many factors including, but definitely not limited to:

• The extent to which the required transport protocols and message formats are supported out of the box (better support makes for easier implementation).
• The level of experience with SV of the people that are going to wield the SV tool.
• The complexity of the behavior that is to be simulated.

When you’re looking for the best fit for your SV needs, it is wise to take into account a range of tools, both open source and commercially licensed. Don’t discard the latter category because of the seemingly high initial investment due to licensing costs. As I’ve pointed out before, it might just be that the ease of implementation and the richer set of features provided by a commercially licensed tool give you a return on investment that warrants the initial expense many times over. I’ve seen this happen in practice multiple times, and that’s the reason I now prefer to include a range of tools in my test automation and service virtualization training courses, rather than focusing on a specific tool. I sincerely believe there is no one-stop solution for every situation and I’d rather show people what’s available on the market and help them see what would be the best fit for their own organization than train them in a single solution (with the risk of giving them a hammer and making them see everything as a nail).

Also, don’t simply go with the first tool promoted by a Google search or a friendly sales representative, as there’s a good chance that it might not be the most efficient choice for your specific situation. Take the time to select a tool carefully. Conduct a proof of concept (or more than one, ideally) that demonstrates the actual value that a tool can bring you, and that proves that a tool fits your development and testing requirements and is a good match for the skill set of your development team (or anybody that is to be made responsible for creating and maintaining the simulations). Consider hiring an independent expert that can help you make the right choice.

The field of service virtualization has rapidly become mature in recent years, going through the same maturing process we’ve seen happen to test automation in the past. That means that it’s time to take the implementation of SV seriously as well. With software development becoming more distributed, more complex and delivery cycles becoming ever shorter, you can’t afford not to at least consider SV seriously if you want to be able to keep up.

Hopefully, this blog post has given you valuable information that can help you choose the best SV tool for your situation, no matter if that’s an open source or a commercially licensed tool.

— Bas Dijkstra