Virtualizing Over-Utilized Systems: Part 5 - Virtualize the Behavior

This is the fifth 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 the practice of Service Virtualization provides solutions for over-utilization of core systems and services needed for testing and development.

Hardware Virtualization Can’t Solve Bottlenecks of Over-Utilized Systems

We’ve reviewed why systems are becoming over-utilized, as compared to under-utilized. The problem is that the hardware and desktop/OS virtualization tools we have at our disposal are great for optimizing under-utilized resources, but they are often incapable of virtualizing the behavior of over-utilized systems.

Even the largest virtual server deployment and centralized management of VMs may not allow for the virtualization of 3^rd party cloud services or mainframe assets.  However, these same concepts of virtualization can be applied in new ways to eliminate bottlenecks in our overtaxed core services.

A Solution: Service Virtualization (or, "SV")

Service virtualization involves the simulation of software service behavior and the modeling of a virtual service to stand in for the actual system during development and testing. Think of it like a “stunt double” for your most constrained, critical applications. Service virtualization addresses each of the aforementioned hardware virtualization limitations such as:

• Providing 24/7, on-demand access to ready test environments managed on your terms
• Removing capacity constraints of over-utilized systems
• Addressing test data volatility across distributed systems and conflicts among teams
• Reducing or eliminating the cost of invoking 3^rd party systems for non-production use

While Hardware Virtualization focuses improvements on the systems an IT team can control, such as servers in the data center and desktop, the complementary practice of Service Virtualization is geared toward optimizing the distributed and shared types of applications that are resistant to being imaged as a hard drive in a hypervisor: the over-utilized systems such as mainframes, partner-managed services and components under development by other teams.

 Let’s look at a sample enterprise with 3 downstream dependencies after applying SV techniques (from the bottom up): 

• Mainframe access problem eliminated:  During an instance when the key transaction system is available, it is captured and reproduced as a sophisticated model of that behavior, which is then hosted as a virtual service and accessible 24/7 in a virtual service environment.
• Database access and data volatility eliminated: Rather than having to negotiate set up and removal of test data sets from multiple sources and partner systems, the team can get a stable set of data to validate scenarios without impacting the live systems or other teams’ test data.
• Mitigated an unavailable or incomplete system exposed through a Web Service: Construct a Virtual Service from a WSDL, SOAP documents, XML samples, and other artifacts, whether or not the service, or the back-end system is available for testing. If desired, the Virtual Service could be accessed as a “pass thru” to intercept test transactions, while allowing live transactions to continue through to the real service and legacy application.

Coming up: 6th and final issue in this Series: Customer Examples of SV in practice, and Conclusion.