Virtualizing Over-Utilized Systems: Part 6 - Customer Examples & Conclusion

This is the sixth post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this issue we cover how companies are applying Service Virtualization to solve for over-utilization of core systems and services needed for testing and development.

Examples of how SV Answers the Challenges of Over-Utilized Systems:

Solving a Common Bottleneck – When each team can get their own replicated test environment and data provided as a Virtual Service at minimal cost, there is no longer a need to compete for testing time during a small availability window, much less secure a capital expenditure just to get access to a hosted service-based system.

Customer Example: A leading US airline replicated much of the functionality of a partner’s reservation system that charged high per-use fees when used for testing purposes, as well as restrictions on usage due to the fact that millions of transactions needed to be handled on the system daily. Switching to a virtual service model of the system allowed multiple teams to have their own stable environment and data for test scenarios, as well as saving millions of dollars annually (up to $12M)  in non-revenue-generating access fees for the live service.

Solving Improper Capacity – Trying to pinpoint the reason for functional errors and performance problems in a modern distributed software architecture is becoming increasingly difficult. IT departments can seek to throw more hardware and software at the problem, but that cannot solve the costly and time consuming software setup and configuration effort of enabling test and pre-production environments for multiple distributed teams to use.

Customer Example: A leading bank which has grown by acquisition found that they could not effectively load test middleware which tied more than 70 acquired systems together using their existing tools. They had several developers attempting to hand-code “stubs” and “responders” to replicate the environment for 2 years, with little success. Using Service Virtualization techniques, two test engineers configured realistic models of the current bank middleware systems.  They replaced the multi-year “stub” project in a few months and grew the practice to include another half-dozen teams across the bank. They have avoided up to $30M in costs for provisioning new environments over the course of a year.

Solving Inefficiency – Every business faces increased pressure to meet customer and regulatory demands with greater agility, and leveraging distributed software components and integration frameworks can add agility to our ability to deliver expected business outcomes. At the same time, the service-oriented approach to delivering software makes it harder to ensure service level performance and quality, due to an increased rate of change in the environment.

Customer Example: A US Federal agency needed to prove that their technology selections and architecture elements were performance ready, before they were put in place in the live environment. By virtualizing the rest of the environment and its expected response times and load variability, they were able to compare benchmarks and select the appropriate technology for their architecture, without needing to “bang” on critical live systems used for weather, air traffic and defense purposes.

Summary

Hardware virtualization is becoming ubiquitous in large enterprises, offering immediate cost savings and efficiency. While the concept of desktop and server virtualization has great value for optimizing less utilized systems, it is challenged in replicating heavily utilized or constrained systems such as mainframes, incomplete components, or third-party services.

Consider how much you invest in “under-utilized” hardware and desktop OS infrastructure, versus the high cost of integrating and maintaining traditional software test environments. There's a high probability that the development and integration cost of those traditional test environments exceeds your hardware costs by several orders of magnitude. The prohibitive expense of software test environments means applications are not tested early or often enough, which leads to even costlier failures in production. Virtualization of the behaviors of over-utilized systems can address this serious shortcoming.

Instead of copying the contents of a hard drive or replicating a piece of software running in an OS, Service Virtualization focuses on modeling the communication paths “between the boxes” – components such as web services, databases, RESTful services and asynchronous messaging. This lets teams break their dependencies on the bottlenecks which are preventing them from getting their jobs accomplished.

Development and testing teams need access to an ever-increasing number of services and systems of record that are not readily available. Service Virtualization is a strategy for letting teams take the principles of virtualization beyond the data center, simulating more distributed, complex environments, where significant value remains to be realized.

This concludes our series on SV and Over-Utilization. I'd like to thank Ken Ahrens for coming up with this unique way of looking at virtualization. We hope you find parallels of over-taxed and unavailable systems within your own environment that offer similar opportunities for efficiency improvement.