By Alok Mehta, Padmanabhan Venkatesh and Chris Cox
IT organizations are always looking for ways to streamline their processes to improve efficiency. This improvement can take many different forms such as optimizing process, documentation updates, as well as technical improvements to applications.
Organizations can also help streamline their development lifecycle using service virtualization.
To break this down: A service is defined as an Application Programming Interface (API), Web Service, Real-Time or even a batch integration. When an application calls for the use of an external code, for the purposes of this article that’s called a service. So, at a high level, service virtualization is the process by which a software engineering organization creates a virtual version of a service to emulate the functionality of that service. As illustrateded below, a virtual service replaces an external call to a vendor API with a mock response that mirrors what the vendor API would have returned.
This virtualization can provide an array of benefits such as:
- Cost Savings: One area that we have found service virtualization to be especially useful is whenever a project has integrations with third-party vendors or APIs. These integrations can often be expensive to test and can lead to increasing capital expenses. Service Virtualization can help reduce costs by reducing the number of times a third-party vendor or external service is called.
- Performance Testing: An additional benefit to service virtualization is the ability to facilitate more accurate performance testing of APIs. Performance testing is a core piece of testing software applications and services. Organizations want to stress their applications so they can feel confident in how they will respond in the most difficult circumstances. But performance testing can often face challenges such as test environment instability or difficulty interacting with third-party vendors. A service or application that interacts with a third-party vendor presents a unique set of challenges for performance testing. The application team can’t guarantee the third party’s API will perform at a consistent level, and additionally can’t guarantee that the performance test data used will always return the desired response from the vendor’s API. Both issues can be solved by utilizing service virtualization. A virtual or mock service can be created to assist with these performance issues. By removing the direct call to the third-party API and replacing it with a call to the virtual service, you can remove any concerns about latency or poor performance from the vendor side of the transaction. The virtual service can take in a request and return a properly formatted response to the calling application without ever making a call to the third party. This allows the development team to gather truly accurate performance metrics on their code without fear of the metrics being distorted by poor vendor performance. The service can be further optimized by measuring the average vendor response time in production and then programing the mock service to pause for that average response time before responding. This optimization will allow the developers to accurately simulate production response time and thus gather real, accurate data about how their application will perform under load with realistic response times from whichever third-party API they are utilizing.
- Remove Dependencies: It can help to remove hard dependencies in software development projects by allowing applications to mock any integrations they need, rather than having to wait on another team to fully code those integrations. Let’s take an example: Team A is working on a large transformation project and adding a new integration to one of their applications via an API exposed by Team B. Rather than having to wait on Team B, Team A can mock their integration with Team B via service virtualization. This gives them the ability to proceed with their development work without being dependent on Team B coding their API. Team A can send the actual payload the API is expecting and simulate the response they would get back, allowing them to fully code their side of the transaction without being dependent on Team B. This should allow for software development projects to be operated with much more efficiency by removing many of the hard dependencies that often exist in these large efforts.
- Data Integrity: A virtualization service can also assist with performance issues surrounding test data. Oftentimes it is up to the development or testing teams to coordinate with vendors for specific test data to facilitate their test cases. This approach can often suffice for manual testing, but it can present obstacles to successful performance testing. If the vendor does a regular data refresh, the test cases will have to be manually updated to coincide with vendor data refreshes. A virtual service can help to avoid this issue by allowing consistent data responses based on specific requests since the data is housed internally, within the service or its corresponding database. Any vendor data refreshes would subsequently have no impact on performance tests since all the data would be handled in house.
- Vendor Management: Once consistent performance tests with your virtual service are established, you can use the data you gather to help negotiate vendor contracts. But first, you must be able to baseline the SLAs (Service Level Agreement) via mock services. An SLA breach can be identified by turning on and off the mock service and measuring the performance. The delta between the two can give IT a great way to see where the SLA breach is occurring. This in turn can allow your organization to negotiate better SLAs with vendor partners if the breach is occurring on their side of the transaction.
Let’s discuss some of the best practices when designing a mock service:
- Technology Considerations: – When designing your mock service, it’s important to consider your specific use case and technology stack. Your service should be created following your organization’s best practices and be made so that it can be extended to other teams quickly and easily. A Dockerized, or more efficient, version of the service that can be easily pulled down and implemented by other teams is a great place to start. Utilizing .yaml or other consistent configurations can also help new teams quickly add their implementation to the service.
- Data Considerations: One of the major decisions with service virtualization is what data you will respond to requests with. There are many ways to have your service respond. For simple use cases, a static response or list of responses will often suffice. As you iterate and improve your service, you can expand its data capability by configuring it to respond with random responses from a larger list, or weighted responses based on real production data. You can also implement keys that when passed in a request will automatically generate the desired response. It is important to consider your specific use case when deciding on a data model.
- Integration with other projects: Making the service easy to use is a critical component if you decide to build a mock service in-house. It is crucial that the service has good documentation with a template to follow for any new teams who wish to utilize its functionality, otherwise you will risk losing much of the efficiency a mock service can bring. As discussed in the Technology Considerations section, utilizing an easily extendable tech stack for your service will help facilitate the transition to other teams who may want to interact with the service.
- Build vs Buy: When deciding whether to build or buy a virtualization solution you will want to consider your use case and how much traffic you expect to direct to the virtualization service. If your organization is already utilizing a toolset that includes a virtualization offering, it may make sense to utilize that offering. We have found that the benefits of building the service in-house can include increased customization, and the ability to utilize the functionality enterprise wide without the associated licensing costs when buying a solution.
Conclusion:
Service virtualization can provide an IT organization with many benefits, including those listed above. We especially believe that the performance testing space provides many great opportunities to utilize virtual services. We encourage you to explore this technology and some of the tools associated with it, beyond what was discussed here, to see what can best fulfill the needs of your organization’s specific challenges.
Alok Mehta is CIO for Business Systems at Kemper
Padmanabhan Venkatesh is VP of IT Business Systems at Kemper
Chris Cox is Senior Manager of IT Business Systems at Kemper