Creating Sustainable PaaS Systems

A while back, I wrote about the importance and benefits of patterns-based middleware solutions for the cloud. You can check it out here if interested, but the gist is that by representing middleware application environments as patterns, we target traditional inefficiencies when dealing with these kinds of environments. Specifically, with the right kind of patterns-based approach, users can derive the following benefits (in addition to some of the table stakes cloud benefits):

- Persistent, deployable units: Patterns represent application environments, but what really sets them apart in my mind is that unlike diagrams or models, they are deployable units. Users do not have to translate a pattern into a running environment. They simply deploy it.

- Rapid provisioning: Patterns represent complete application environments, and as such, the deployment process automates most of the installation, configuration, and integration of the target environment, thereby eliminating time wasted by manually executing each discrete step. In addition, employing virtualization as a delivery model for the pattern can serve to further accelerate delivery times.

- Consistent deployments: Patterns take the guesswork out of deploying an application environment. Again, the pattern encapsulates installation, configuration, and integration of the environment, thus taking it out of your hands. This means less of those hair-pulling moments due to botching step 153 out of the 250 required steps to setup an application environment.

In an area as tricky and unforgiving as middleware environments can be, these are certainly welcome benefits. Further, this is not what the future of what a patterns-based approach promises to deliver. Rather, it is what the users I talk to and work with on a daily basis are getting out of this approach right now.

Okay, between the post I referenced earlier and that little spiel above, my position on patterns-based middleware solutions for the cloud and their benefits should be clear. However, not only do I think this approach has benefits in the here and now, I also think it has significant benefits as cloud computing continues its march toward application centricity.

Obviously, patterns bring a needed coherency to the way users represent and instantiate application environments. Over time, even as users migrate toward a more application-centric view of their deployments, the application infrastructure will still be there. Something will still be responsible and focused on the application infrastructure, and that ‘thing' will be PaaS system. Much the same way that patterns bring coherency to users, they can do the same for PaaS solutions.

In the incantation most people agree on, PaaS is fun to talk about. I mean, we are talking about systems that allow users to provide an application, describe characteristics of the application, enumerate requirements for the application, push a button, and then voila! The PaaS system completely abstracts and renders the necessary application infrastructure to support the application provided by the user. What should be quite obvious is that this is a tall task for the PaaS system. The PaaS system is in charge of distilling those application characteristics and requirements, and then mapping those to a particular configuration of application infrastructure. This involves knowing what infrastructure components to pick, how to optimize each component accordingly, and finally how to integrate those components to create a meaningful runtime. All of this contributes to why application-centric PaaS systems tend to work with a very constrained set of application infrastructure.

Ideally, the industry should be able to ‘dumb down' PaaS with respect to its knowledge of application infrastructure. I am not advocating making PaaS systems any less capable, but I do not understand the advantages, from both a provider and consumer standpoint, of PaaS systems that require intricate knowledge of how to arrange, configure, and integrate application infrastructure. From a provider's standpoint, this sort of model is simply not sustainable. At some point, you will run out of the capacity to continue to add knowledge about various application infrastructure components into the PaaS system. Eventually, this shows up as a constraint to users in two ways.

First, they will have limited options in the type of infrastructure used to support their applications. You may say this should not matter since the PaaS system abstracts that layer, but it will. A majority of users are not even ready to commoditize operating systems, so I suspect the PaaS market to be quite evolved before they are ready to commoditize the middleware tier of their environments. Second, the inability to continue to add application infrastructure knowledge into a PaaS system will constrain the usage scenarios supported by said system. At some point, a lack of knowledge of how to configure or integrate some piece of infrastructure will manifest itself as a functional limitation that could detract users from a given PaaS platform.

I think patterns can deliver relief to these constraints. In effect, patterns can become the glue between the PaaS and the application infrastructure. When a user provides an application and describes its requirements, the PaaS system in turn searches some pattern repository for a pattern that meets those requirements. The pattern represents the already installed, configured, and integrated application environment, the PaaS system simply drives the deployment of the pattern, and in some way, the deployment of the application on top of that infrastructure.

Viewing this very idealistically, patterns could become something of a standard way of representing application infrastructure, thus enhancing user choice and fostering a competitive market. For instance, multiple different application infrastructure providers could provide OLTP, highly available patterns. Thus, PaaS systems could pick from a wide variety of implementations based on user choices such as price, performance, serviceability, etc.

I know that the patterns-based approach to delivering middleware application environments is not an industry-wide trend, so you may dismiss this as pie in the sky talk. However, it is my blog, and I think it is fun to both talk and write about!

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at http://dustinamrhein.ulitzer.com. You can follow him on Twitter at http://twitter.com/damrhein.