Many cloud applications are cooperative relationships between application-specific software components and general...
application resources, such as database servers, application servers, Java virtual machines (JVMs), and other transaction processing and cloud Web service tools. Because these tools appear to be "above" standard operating systems and below applications, they're often called middleware.
IaaS deployment may bind these middleware components to applications 1:1, even when they're deployed in separate virtual machines (VMs). This can increase the total number of VMs, reduce efficiency and utilization in the cloud, and erode the business case. Virtualizing middleware is the logical answer, but insight about how to do that can be hard to find.
Like many things in IT, middleware virtualization has a cloudy and expanding definition, and the issues with middleware deployment in virtual and cloud environments are already broad. A cloud and software architect should understand the basic middleware virtualization issues, look at representative tools in each category, and understand where their own application evolution will take their middleware needs.
Much of the middleware today is based on Java, which requires JVM deployment on VMs and application deployment within JVMs. Most middleware virtualization discussions have revolved around the Java-hosted middleware model used by some of the early cloud applications -- a Web server, application servers and database servers. This model can be tremendously wasteful in the cloud because of middleware replication.
Ramping up efficiency
One path to resolving efficiency problems is to take advantage of the fact that JVMs are almost virtual OSes, and deploy them on a hypervisor without a guest OS. That would save resources and make the middleware as virtual as the guest OSes are today. This is one path recommended by Oracle, with WebLogic Server Virtual Edition (a combination of WebLogic Server and JRocket Virtual Edition).
Virtualizing Java directly would seem a logical approach, and that's another direction the market is taking. Java, in its native form, is not truly multi-tenant, so while it's possible to treat a VM as a multi-tasking host, the tasks could interact in ways not favorable even to a single enterprise building a private or hybrid cloud. Java also includes features such as garbage collection and application scheduling that might collide with similar features in the hypervisor.
Making Java multi-tenant is the goal of tools such as Waratek, which provides a "Hypervisor for Java" hosted on a JVM that is then hosted by the "real" hypervisor. Java applications are managed by the Java hypervisor, which makes Java multi-tenant by creating "child JVMs" that partition applications from each other and link tightly to the real hypervisor for better control and efficiency.
ElastiCat offers similar capabilities using Java virtual containers based on Apache Tomcat's servlet containers. IBM has introduced Java multi-tenancy in its own JVM at R7. In all cases, the JVM is virtualized and made multi-tenant in one step.
It's possible to code Java applications to be multi-tenant (in at least most senses) by controlling programming practices and namespaces, and by using some special Java libraries. This option could be suitable for companies that can develop or modify their app-server and DBMS-server middleware, but it's vulnerable to failures to conform to the multi-tenant model.
When Java is not the middleware platform, middleware virtualization can be accomplished by migrating middleware into the hypervisor. This is already being done with some data path acceleration software, but so far it has been somewhat a one-off activity without a single guiding framework. Such a framework has been proposed by Usenix's VAMOS, which presents a model for extending the hypervisor to include middleware features, which are then connected by a fast internal pipe to each guest VM.
Another way to approach this goal is to use a soft form of virtualization that's based on OS containers rather than on VMs. These containers can be made to provide roughly the same level of tenant component isolation as the Java virtualization approaches, but they can still access some of the services of the host OS.
The third, more general, approach is to build middleware as a service (MaaS), which means a set of service APIs would represent the middleware service to applications, which would call these APIs as needed. Behind the APIs (which are essentially façades), the actual middleware resources can be instantiated as needed.
MaaS is easiest to apply if the applications are being built or rebuilt because its essential middleware services are packaged to be multi-tenant in implementation. It still might be necessary to adopt other middleware virtualization techniques to permit efficient horizontal scaling of MaaS components. Finally, building applications based on the notion of MaaS may be more complicated.
Oracle's model for this approach is the virtual appliance, which is built using its Virtual Assembly Builder. This tool captures the configuration of applications built using the typical Web-server-to-app-server-to-DBMS-server model, and then packages them into a deployable unit. This approach simplifies the deployment of applications built in part with middleware.
Cloudify and Cloud Foundry can also help deploy MaaS. In effect, the goal of MaaS is to create a composed PaaS that includes the middleware features. These tools can help deploy such features efficiently and can ensure applications can locate the façade that represents the middleware service needed.
A final point: Vendors such as IBM, Microsoft and Oracle have their own middleware stacks and strategies for virtualization. Hypervisors and OS vendors may have specific tools. Where a commitment is given to a vendor, careful consideration should be given to that vendor's capabilities in middleware virtualization. Don't be afraid to mix and match where it's indicated, and remember, the best solution to middleware virtualization might still be waiting in the wings.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.