[This is the 2nd Part of John's article on "Why Stubs Don't Work." For "Part 1: Producers & Consumers" read here.]
The last (but certainly
not least important) audience that must weigh Stubs versus Virtual Services, is
the Performance profiling team – the folks charged with
measuring and tuning an application to meet customer expectations or SLAs in
production.
Of course, a developer creating a stub “responder” would
write that simple object to return a given response as quickly as possible.
Yet, many of the most complex scenarios that would want to consume that stub are
in the performance lab – so the team can do capacity planning, and get a feel
for how the targeted application will perform or behave, before it’s all fully
assembled and delivered to production.
You need a pretty sophisticated instrument to vary the
responsiveness and handle all the variety of performance profiles that are
needed to support tuning.
For example, I may have “What-if” scenarios -- where I want
to performance test my system, with all the back-end services stubbed out. Now,
I want to see what happens if those back-end systems respond 20% faster, or, 20%
slower than they are supposed to be. With a stub, I can only get an immediate response
about as fast as the network can deliver it, which is unfortunately not how the
live downstream system is going to perform.
And I certainly don’t have the ability to vary that
performance in an “adjust the slider” kind of way – not without, again,
building a pretty sophisticated framework for that simulation. And this creates
– you guessed it – a whole group of people charged with coding stubs to respond
at certain times or with certain payloads. There must be a better way.
Thus the need for
LISA Virtualize, and Virtual Services.
Virtual Services are the technology we built on top of the
LISA Virtualize framework to bring dynamic behavior to this functionality. LISA Virtualize allows Virtual Services to be automatically modeled or captured from live traffic, flat files or definitions, and then quickly adjusted for data or performance characteristics without coding. Here's a basic picture of how that happens:
Virtual
Services have proven, time and time again, that development teams can get out
of the stubbing business, and that consumers of these services can take control
of their own destiny, and produce their own Virtual Services instead of waiting
for a stub.
That’s important, because the producer or Developer
of a given service should not be responsible for infinitely providing stubs to
Consumers -- every Consumer is going to have their own requirements, and need
to validate different scenarios for how they use the service. If there is only
one stub available, then consumers will be missing the responsiveness they
need.
From the other side of the equation, if Consumers are responsible for
building their own Virtual Service models from downstream services,
they will understand the kinds of performance levels, data scenarios and
business processes they need to validate. And, they would know better how that
service would need to integrate for their required scenarios with other downstream
systems that are available.
Conclusion: The
Tipping Point for Virtual Services is here…
Just like the “roll your
own” database I used to make years ago, the requirements for this functionality
have reached a tipping point. Once the requirements for stubbing or
mocking reach the point where they become an item in your project plan, with an
associated timeline and resource cost, you need to think about productizing and
looking for solutions rather than building one.
One of the largest telecoms in the world, and a company I
respect greatly, was talking about this in their Architecture Review meeting a
few weeks ago. I was there, and one of their resources said “I hear where you are coming from - we thought
of stubbing and mocking as a simple activity, but we have now evolved an entire
career path out of people becoming simulation developers!”
There were literally scores of people whose work function
was architecting, developing and maintaining simulation artifacts, or “stubs.”
Think about it – what company (other than a couple software vendors) would
split off an entire category of developers to go build their own database? The
person who runs technology for this entire telecom would not make that kind of
investment, without serious scrutiny for finding a better solution off the
shelf.
So this is the awkward tipping point we find ourselves in
today, moving from stubs and mocks to Virtual Services. People who have been
building stubs for a long time out of necessity, are finding it harder and
harder to keep this up. Our LISA Virtualize happens to be the first (and,
without exaggeration, the only) solution on the market to handle this
particular challenge.
Now customers are doing the math -- and rationalizing how we
used to do it versus this new paradigm with Virtualize. By no means will
Virtual Services create a career problem for so-called “simulation developers”
either – I have yet to encounter a profitable enterprise that is seeking to do
LESS development, or deliver LESS functionality to the business. What ends up happening is better aligned
development to the business needs, both within the company, and with partners.
That is of course the goal of any healthy IT organization.
Long story short: I hope this provided some useful perspectives
you can apply when thinking about using Virtual Services versus stubbing and
mocking in your software development going forward.
