Yesterday, I joined some colleagues on a webcast where we had a chance to talk to some of our users about the technical concepts behind WebSphere solutions for building, consuming, and integrating clouds. We discussed ways to enable autonomic, policy-driven runtimes, construct elastic, in-memory data grids, and integrate on-premise and off-premise applications. It was all fun stuff to talk about, and hopefully the webcast participants got a good look at how cloud computing is taking hold in WebSphere. Having said that, for me, one topic stood out above the rest and that topic was pattern-based middleware for the cloud.
Ready for an understatement? Configuring, and subsequently deploying enterprise middleware environments is not trivial. When I talk about enterprise middleware environments, I am referring to a collection of application infrastructure deployed in support of a particular business service or application. If you were not familiar with the makeup of these environments, the number of different components involved would likely surprise you. Consider a standard web application, one that, for all intensive purposes, is a simple CRUD application. It would not be at all surprising to find proxy servers, application servers, and database servers deployed in support of this seemingly simple web application. In all truth, these are just the basic components, and it would not be beyond the norm to see more complex integration solutions such as enterprise service buses in play.
Simply put, there is a lot of work and knowledge that goes into setting up middleware application infrastructure in support of business applications and services. Think about what we are asking of users. We are asking them to understand what components are necessary, and more importantly, we are asking them to understand how to make all of those components work together to achieve the desired result. It is a lot to ask, especially considering these users really just want to support the thing they are most interested in, their application.
Now, one of the big focuses of the cloud movement is making it easier to deploy these kinds of complex IT environments. In fact, if we look at advanced virtualization techniques commonly used in the cloud, we see that they make deploying complex units like application servers and databases a lot easier. Virtualized units encapsulate the installation, and in most cases, quite a bit of configuration for these components. Users simply step through some activation process for the virtualized unit, and voilà, they have their service.
Clearly, this approach makes things easier on the person whose job it is to deploy these services. They get their services deployed fast, and consistently, without having to do mundane install and basic configuration. However, there is still a missing link. In many cases, users still are responsible for the more complex inter-product integration work. They have to configure the servers to talk to the database, and they have to setup the web servers to route to their worker nodes among other things. Now, you may say, ‘Why not put the complete application environment in a single virtualized unit?’ After all, if that were the case you could not only install everything into the unit, but you could also capture the integration of the different components. While it sounds good, it is often impossible or undesirable to do for a number of different reasons. So, how can we make this integration work easier on the end user then? I say the answer is patterns-based middleware.
A patterns-based approach to middleware allows users to build or consume deployable units that represent more complete middleware application environments. Instead of having one unit for an application server, another for a web server, and yet another for a database, users have a single unit that represents all of these together.
The pattern, often times by utilizing the individual virtualized units, encapsulates not only the basic installation and configuration of each part in the environment, but it also represents the more complex integration steps required to make the environment meaningful. Ideally, these patterns also provide extension mechanisms to allow users to include their own resources as part of the deployable unit (think applications & their configuration). Put simply, patterns represent completely configured and integrated application environments, and they are an atomic, deployable unit for a virtualized or cloud environment.
I really believe the patterns-based approach to middleware tackles many of the consumability issues around application middleware environments. It removes the days of tracking down problems in your application environment that are nothing more than configuration/integration issues. In addition, one could envision a marketplace from a vendor or community that offered several different solutions-oriented patterns. This would be a huge advantage for those users who knew what they wanted to achieve (i.e. a highly available web application environment), but not necessarily what combination of components was necessary to achieve it.
There is a lot of promise in patterns-based middleware approaches. We have been talking about it for a while now with our users, and I suspect other providers are talking, or soon will be talking, about the same basic concept. What do you think about this approach to constructing and delivering application middleware environments?