Continuous Delivery Suicide = Building App Architectures with Microservices, but without Service Virtualization

In today’s application driven economy, the name of the game is speed.  The game being played in every industry is that of trying to bring new digital innovations to market faster than competitors, delivering new code to production that helps you “stay up with the Jones’s.” Everything is moving quicker as companies try to achieve first-mover advantage or become fast followers.  Companies that didn’t call themselves a tech company before, now find their success depends on the speed of their software development … and being good at it.

Enter Microservices.

Microservices are the shiny new developer tool to help deliver software faster.  The growth and interest in microservices is real.  Organizations such as Netflix, LinkedIn, and Amazon have gone on record about their use of microservices.  Retail, financial, and manufacturing companies are also some who have moved to this application development architecture.

I did a quick Google trends search on this topic, and was surprised to see the spike in interest in just the past two years.


Why the popularity?  Microservices can be thought of as single-purpose applications that collaborate using APIs to deliver services.  These small services can then collaborate with other microservices on the same server.  Even internal development teams can interact with microservices through APIs.  When changes need to happen, you don’t need to rewrite the entire application.  Instead, you can add new features/code pushed as microservices, and plug them into the existing application.

Jason Bloomberg recently wrote a great blog on how these microservices are a lot like Lego building blocks, helping developers “mix and match various bits and pieces, building flexible applications by simply snapping their components together.”   Another article on InfoWorld gives a great example of how these microservices come together to create a search result in an online shopping scenario – kicking off over 170 applications to deliver images, matches, recommendations, reviews, transaction, etc. all based upon that search.

That’s all very cool stuff from the customer standpoint.  But, how do you ensure all those microservices come together to actually deliver a high-quality experience?  How do you test against this and follow the transaction flow?

Microservices just increased complexity 10 fold.  There are more dependencies on other services than ever before. All these microservices are dependent on each other.

These complexities and dependencies are the antithesis to speed. Developers don’t have time to wait in a DevOps shop that must continuously be delivering software and doing so with paramount quality.

Enter Service Virtualization (SV).


Service virtualization simulates constrained or dependent systems across the software development lifecycle (SDLC), allowing developers and testers the ability to test complex applications faster and more comprehensively.

And in a microservices world, SV becomes that much more relevant.  Now, virtual services can be created to simulate the various API dependencies of microservices, providing a testing sandbox to make sure all the microservices are working together.   Now you can replicate your Lego-like application building blocks, and make sure it all works.

Additionally, you can leverage technology that provides end-to-end deep transaction tracingacross these microservices to give you visibility into your actual environment and dependencies.  That technology then automatically creates accurate test beds and production-like virtual services.  With this actionable insight, agile teams can then kick-off automatic test creation to accelerate their SDLC.

In other words, service virtualization helps enable testing at continuous delivery speed.

This point was driven home to me a couple of days ago during a conversation I had with one of our senior technical consultants.  He was telling me how a very large clothing manufacturer has gone “all-in on microservices.” Everything their developers do is around speed to market.  But, he said they know that if they aren’t focused on the customer experience they are flat out dead.  As a result, they’ve implement service virtualization to remove all the complexity of microservices testing. As he relayed to me, the customer said, “Continuous delivery without service virtualization will not work!”

Cloud Ready

As microservices are spun up quickly, service virtualization will need to keep up.  service virtualization can’t become the bottleneck developers are waiting on.  They’ll need access to virtualized microservices immediately.  The trend is pointing to SV being spun up from the cloud and accessible on demand, where and when developers or testers need it.  SV in the cloud becomes game changing.

If you’d like to learn more about microservices virtualization, please join a webcast I’ll be hosting June 24 with Jason Bloomberg, president of Intellyx, as we discuss how to “Share the ‘Shared-Nothing’ of Microservices.”  Should be a good one.  Hope you’ll join us.

I’d also love to hear your comments on this topic?  Do you think service virtualization and mircoservices will be part of your application delivery process?