Service Virtualization Strategy (Sandboxing) for Microservices

Service virtualization is an alternate to stubbing and mocking. Service virtualization strategy for microservices is one of the key elements for testing and sandboxing. Service virtualization provides developers and testers with tools to quickly simulate the services of a complex production environment.

Service virtualization involves creating and deploying a "virtual asset" that simulates the behavior of a real component. Most of our services are dependent on other systems for business logic or data integration purposes, the question of testing and sandboxing the application functionalities without these systems arises. We had limitations on rapidly rolling out capabilities of the product due to dependent system infrastructure limitation.

Service virtualization emulates the behavior of software components to remove dependency system constraints. Such constraints occur in complex dependent system environment:

• Available for testing only in limited capacity due to cost involved to buy actual devices
• Dependent system services are not ready to consume
• Controlled by a third-party or partner
• Difficult to provision or configure in a test environment
• Needed for simultaneous access by different teams with varied test data setup and other requirements

One of our Next-gen applications is built based on Microservice design principles. We were in the process of identifying the right service virtualization strategy to test/demo our system capabilities without any dependent system.

Our application has two different channels—portal and API. We experimented with the below approaches and finally selected the right service virtualization techniques.

Approach 1 (Mock Using Browser Local Storage) 

We mocked all the UI calls in the portal using pouchDB browser local caching and none of the services were called. This helped the mock application to run with limited infrastructure and almost zero setup.

We have started seeing limitation after enabling new channel API.

Approach 2 (Classic Mock Approach)

We ended up mocking backend implementation using the classic mock approach. We extended each external class and created a mock object by recreating in the code. This worked well for simple use cases for both Portal and API and each release developer needs to work on the mocking. It brings up the maintainability and operation complexity to the platform.

This approach solved some issues and introduced other issues. For each release, the team has built the application and the corresponding mock services as well. This was increasing the timeline of each release. We realized that it time to improve the approach, as mock became part of design and project planning. The new approach to Service Virtualization should support all the use cases with minimal to zero code effort for each release. Mocking via dependency injection is often a messy endeavor.

In a classic approach, we usually mock them through unit test or functional test. But, still something can break on the way because of the application stack down to the network layer.  

Approach 3 (Service Virtualization) 

We have seen great success with Mountebank, a lightweight tool for stubbing and mocking HTTP, HTTPS, SMTP, and TCP. Mountebank is the open source tool to provide cross-platform multi-protocol test doubles over the wire. Test Double is a generic term for any case where you replace a production object for testing purposes.

Setting up is as simple as pointing our microservices to mountebank test double endpoint, instead of the real dependency and pretend as these services are real services with traditional stubs and mocks. This helped our customer to create demo/sandbox environments and explore the product capabilities without any real dependency services.

Mountebank fakes each external service calls by creating set of imposters which behave as live sandbox API’s and can be controlled through live mock switch. Using proxy, the automated data seeding happens and can be utilized further for sandbox testing. Mountebank can be configured to round robin and random algorithm-based responses using predicate and filters. Custom client scripts or remote workflow scripts can be executed by dynamically injecting custom Java scripts. The results can be asserted and matched with certain predefined response to validate minimal unit cases.

Node.JS, AquaJS, & Service Virtualization

Aqua JS is an application development framework for Node.js that is organized, flexible, and developer friendly. It provides an end-to-end development tool-set for applications and APIs by leverages some of the proven components and provides a quick and organized way to start developing micro-service architecture based applications.

Below are some of the Benefits:

• For Business: Accelerates application development reducing time-to-market of products
• For Developer : frees from overhead of managing software infrastructure
• For IT Operation: Cloud-in-a-box application development. Vendor agnostic and cloud-ready application development–provides ability to move between clouds without changing code or deployment processes

Register for beta @ https://www.aquajsio.com/

Conclusion

Service virtualization enables our organization to obtain a virtual service layer that is more cost effective, flexible, and able to deliver applications faster to market.

Based on our experience, external mock services with a large mock database can be defined using Mountebank where the server can be built by using container technologies like Docker and integrated in the continuous integration/deployment pipelines.

Mountebank approach for mocking external services is the perfect choice for Microservice service virtualization strategy.