One objective look at the current PaaS market provides all the evidence you need to conclude that we are in but the infancy of development for this technology. I want to be clear here, there are some really cool (and more importantly value-providing) offerings out there, but there is a long way to go. Specifically, I am not convinced anyone can make a case that we have solutions today that comprehensively address two concepts that will become mere table-stakes in the PaaS play space.
First, there is effective abstraction and commoditization of infrastructure. Users should have to go through considerable gymnastics to even see, much less configure, the underlying workhorses like the servers, storage, switches, routers, etc. Ideally, all users need to do is provide an application with service level policies. Providers can either meet them or not, but don’t force users to provide configuration information for these physical resources.
To be fair, in many cases I believe we have not seen more complete abstraction for cultural reasons. Many users simply are not yet comfortable without some level of control over the configuration of the physical resources at some level. At the very least, many are still concerned with defining the compute capability of a given server (i.e. the small/medium/large instance methodology), the speed of switches, etc. In this respect, users hold PaaS solutions back, but at some point, these systems have to forge ahead and provide assurance that they can determine the necessary infrastructure better than the user.
The second of the two basic concepts for PaaS is application management capabilities. One of the most talked about features in this category is application aware routing and distribution. Everyone wants this, many systems claim to provide it, but I am not convinced that they do so at a meaningful depth. For instance, take the oft-provided option of scaling a system up and down based on average application response time. It seems simple, but have you ever really thought about how a system provides this? Is the system measuring average application response time at only the web server tier, or is it measuring throughput at both the web server tier and the application container tier?
Certainly the latter is more difficult to achieve (typically it requires more intimate knowledge of the application container), but in the case the application is not meeting service level policies and it is time to scale up, having measurements at both tiers removes any ambiguity about which component should scale. I’ll leave it at this, but I am ignoring the fact that ‘measuring at the application container tier’ is vague. Depending on the application, you may want to measure throughput at an even finer-grained level in the application container (i.e. web container, EJB container, web services engine, etc.).
Of course, PaaS systems will have to go beyond intelligent routing and distribution when it comes to application management capabilities. Since the PaaS system becomes the control plane for managing and delivering applications, users will also expect things like application edition management. In other words, provide a means to roll out new versions of an application, gradually route incoming requests to the new version, and eventually take the old version out of service. Edition management is just one of many things users will need to effectively manage their applications, other things that come to mind are policies that proactively take action (other than scaling up or down) based on the relative health of an application, application-level usage data to enable charge back, a whole host of application related security services, and much more.
As I said earlier, there are certainly some compelling and valuable PaaS solutions on the market today. However, there do not seem to be many that provide comprehensive coverage of the two basic concepts mentioned above: effective infrastructure abstraction and robust application management capabilities. For the record, I think existing offerings cover the former capability far better than the latter. As with all things though, this is a point in time statement that providers will soon (over the next few years) address. The question is which providers are best suited to conquer the PaaS landscape?
There is no easy answer to that question. Can IaaS providers move up the stack and effectively provide PaaS? Well, if the industry pioneer in IaaS, Amazon, is the measuring stick, it is unclear. There is not much to indicate Amazon has a short-term interest beyond IaaS capabilities. While there has been a plethora of new development activity coming from Amazon, most of it seems to center around adding to an already robust IaaS offering. That is not to say we can count Amazon, or any other IaaS provider out of the PaaS race though. The most intriguing possibility is that an IaaS provider acquires or partners with a PaaS company already building on top of their infrastructure. Presumably, this would spur a tighter integration and possibly push along the evolution of PaaS capabilities.
What about application integration/middleware companies (such as my employer)? In general, I think these companies are in the opposite position of current IaaS providers. I believe they are in a good position to deliver on the various application management capabilities mentioned above. The challenge to these companies will come in effectively abstracting the underlying compute infrastructure. This means building a layer that can communicate with various underlying IaaS infrastructure, or alternatively, building their own IaaS infrastructure and layering on top of it. Neither of these is an easy proposition, and for many of these companies, either choice will mean treading on new ground.
To this point, I have not mentioned the obvious contender for the PaaS market: existing PaaS providers. I might concede these companies, owing to their early entry point, are in a good position to dominate the PaaS landscape in the future. However, many of the existing players have a significant ways to go in robust application management capabilities. It is unclear if they can catch up here, or if the path forward for many of these providers will be partnership with, or acquisition by, vendors that have significant (years and years) of experience in those types of capabilities.
The bottom line is I think the PaaS market is in store for a flurry of acquisitions and partnerships. In this respect, I believe the VMware/Salesforce.com was the spur the market needed. The question is who makes the next move and what is that move? I’ll be watching, what about you?