What PaaS vendors can learn from the application server market

0 Comments

Today I had an interesting discussion with the CEO of a popular Java application server on how the application server market has changed over the last few years. He mentioned that the traditional application server vendors are looking at ways to capitalize on the IP they’ve built over the last decade. It made me think of how many of these vendors are logically positioned to lead the PaaS revolution. Except Red Hat, no other Java application server vendor has invested in a PaaS solution. IBM hasn’t done much with the WebSphere in the PaaS world. The same is the case with Oracle, who currently sits on three popular application servers: WebLogic, GlassFish, and Tuxedo. VMware’s attempt to package Spring with vFabric and Cloud Foundry is a step towards that.

I also happened to read a post on comparing PaaS with application servers by Sinclair Schuller, CEO of Apprenda, one of the few .NET PaaS companies.

Sinclair concludes his article with the following:

“The future of PaaS is bright, but PaaS vendors have to get out of their own way and begin delivering on a vision that catalyzes the next 10 years of development, not on commodity “deploy and scale” value.”

So is private PaaS just an incarnation of the old application server?

An application server or a container was designed to provide certain abilities to the application during its execution. Developers were expected to follow specific patterns to exploit these capabilities. For example, J2EE containers provided pooling, caching, messaging, and an efficient life cycle management of components. These expensive application servers were sold with a promise that the developers can focus on the business logic without ever worrying about the infrastructure management and the required plumbing. With each version, the J2EE specification evolved to support various capabilities to include messaging, web services, and management extensions.

Let’s look at the promises that the PaaS players are making today.

  • Faster time to market
  • Control over data
  • Efficient infrastructure management
  • Standardized application development
  • Compatible execution environment across public and private clouds

Most of these capabilities are similar to those of the application servers. Technically speaking, private PaaS is the new generation polyglot application container that supports multi-tenancy and persistence along with a set of additional services.

Looking back at the J2EE application server adoption, only a few developers leveraged the full potential of these containers. One of the key reasons for lack of adoption of J2EE was that it was too prescriptive. Developers love flexibility and simplicity, and that’s one of the reasons that Spring’s market share grew at the expense of JEE. Spring provided a clean separation between the infrastructure and the application layer while offering a light weight approach of development and deployment.

Like the J2EE containers, private PaaS is also prescriptive. For majority of the enterprise applications, developers are forced to refactor and redesign the applications. This is one of the critical factors that acts as a barrier to adoption. PaaS vendors might argue that developers can simply push their code and the resources get provisioned. This is true for simple 2 tier applications, but when we try to deploy a multi-tier line-of-business application that talks to an ERP and a legacy inventory system, it just becomes challenging.

If private PaaS has to become successful, it should make developers life easy. It should be less perceptive and more flexible.

Comments are closed.