Monday, 6 October 2014

Service virtualisation

You may have heard of Service Virtualisation (SV) recently.  It's an idea that seems to getting some traction especially in the Continuous Delivery space.

Not to be confused with Operating System virtualisation technologies such as Hyper-V and VMware.

My personal definition of SV is the productionisation of stubbing (granted this is a bit simplistic).

Technically SV can mock too but I didn't really want to get into a discussion of what is a mock and what is a stub :)

Imagine you have an application that is a composite of multiple other systems you have in your company.  It retrieves data from a web service, reads a file from an FTP site and runs a SQL query against a database from a different application and imports the data.

That's potentially problematic as all these systems needs to be available.

What happens if the people running the web services want to take it down for maintenance?  Does that mean you can't develop and test your application?

What happens if you don't have all these interfaces all the way through your environment stack?

What happens if you are reliant on a change that isn't going to be ready for another 10 weeks in one of these interfaces?  Are you going to be blocked from development for 10 weeks?

These are all the kinds of questions that Service Virtualisation hopes to address.

It provides an abstraction of other systems (such as SOA platforms) or even resources such as flat files you might have not have access to.

It can record the interactions between your code and the other system so that it's easy and quick to create the stubbed interface.  Commonly SV applications also provide an interface so you can change the values in these recorded stubs easily through the GUI.

We are looking at implementing something over the next couple of months for one of our key systems.  In a complicated SOA environment with logic managed by different teams and in different geographic locations it's really killing their pace of change.  They are unable to test until a full stack is in place (system test) which can be days/weeks until after they have made the original change.

You really want very short feedback loops between dev and test.  Ideally none at all and the developer can do a lot of testing using automated regression tools on his/her local developer machine.

Service Virtualisation should help them accomplish this rather than the dev, deploy, test cycle that they are currently going through.  It should really increase the pace of change and expect some big cost and efficiency gains.

No comments:

Post a Comment