Virtualization 2.0 will go beyond server consolidation, making applications more agile and scalable to fit a service-oriented architecture.
They're two of today's hottest technologies, and for good reason. Server virtualization provides cost savings on top of flexibility, while a service-oriented architecture affords application reuse and fast response to business needs. But the benefits of combining them can be less obvious.
SOA helps with virtualization by breaking applications into smaller chunks that are more easily spread across multiple servers or CPUs, even off-loaded to outside service providers. Through common runtimes like Java and XML standards, SOA shields APIs from the underlying hardware or operating system. In return, virtualization simplifies SOA by easing provisioning of new hardware resources.
They're the ultimate power couple. Too bad so many obstacles stand in the way of togetherness. Virtualization management apps have communication issues when it comes to SOA, while their Web services equivalents aren't good at setting boundaries for virtual machines. But just because we have a way to go before this marriage of agility is a done deal doesn't mean organizations investing in SOA, virtualization, or both shouldn't anticipate the matchup when making buying decisions. Big application vendors, including BEA Systems, IBM, Microsoft, Red Hat, and Sun Microsystems, have SOA/virtualization synergy on their minds, and so should you.
THE REPORT: SOA Simplicity
Enterprises looking to link their SOA and virtualization initiatives must streamline. Here's how
Server virtualization makes most IT pros think consolidation, and it's easy to see why: One machine taking over tasks that previously required two or four or 10 equals powerful cost savings, both in hardware and in management, heating, and cooling. But consolidation is only the first step. The greatest benefit of virtualization will come from increased flexibility realized by chopping up servers into smaller units of resources like CPUs, memory, and disk space, which are then pooled and allocated to apps on demand.
What virtualization does for hardware, SOA does for software. Programmers need no longer develop each application separately; SOA lets them build apps from simple services that can be used over and over. Those programmers are, increasingly, business analysts who use model-based development environments and never have to write a line of code.
Problem is, the reuse that makes application development much faster also may strain the underlying hardware. When a service is reused, the server it runs on demands a lot more computing capacity.
Virtualization is an obvious solution, simplifying SOA by easing provisioning of new hardware resources. Unfortunately, obstacles abound. SOA's variable loads require server allocations that vary from a small fraction of one server's capabilities to the need for many servers to provide the service. On the virtualization side, most of the industry is still at the consolidation stage, focused on splitting a single server among multiple operating systems. Pooling the resources of multiple servers requires moving in the opposite direction, toward something closer to grid computing or clustering than what VMware and Xen offer today.
A truly agile infrastructure also needs VMs that can move quickly among servers, which entails the use of virtual storage and virtual networks. Most important, management capability must be integrated throughout the whole software stack. Virtualization vendors offer management tools that make VMs easier to set up and tear down, but they're not yet integrated with application management and SOA governance.
When it comes to SOA, virtualization can help in two main categories: middleware and the underlying services. Most products broadly classed as SOA fall into the first group, including enterprise service bus, management, governance, and security software. However, the greatest flexibility gains in SOA virtualization come from the second category, which includes Java and .Net servers as well as connectors to legacy platforms. This is both because services use more computing resources than middleware and because the demand for particular services is more likely to fluctuate.
(click image for larger view)
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.