The following was meant to be ready in time for the Platform conference last week, but travel. While it’s belated, however, the following may be of interest to those tracking the PaaS market. At RedMonk, the volume of inquiries related directly and indirectly to PaaS has been growing rapidly, and these are a few of the more common questions that we’re fielding.
Q: Is PaaS growing?
A: The short answer is, by most measurements – search traffic included – yes.
The longer answer is that while interest in PaaS is growing, its lack of visibility on a production basis is adding fuel to those who remain skeptical of the potential for the market. Because PaaS was over-run in the early days by IaaS, there are many in the industry who continue to argue that PaaS is at best a niche market, and at worst a dead end.
To make this argument, however, one must address two important objections. First, the fact that the early failures in the PaaS space were of execution, not model. Single, proprietary runtime platforms are less likely to be adopted than open, multi-runtime alternatives for reasons that should be obvious. But perhaps more importantly, those arguing that the lack of production visibility for PaaS today means that it lacks a future must explain why this is true, given that history does not support this point. Quite the contrary, in fact: dozens of technologies once dismissed as “non-production” or “not for serious workloads” are today in production, running serious workloads. The most important factor for most technologies isn’t where they are today, but rather what their trajectory is.
Q: How convenient is PaaS, really?
A: That depends on one’s definition of convenience. It is absolutely true that PaaS simplifies or eliminates entirely many of the traditional challenges in deploying, managing and scaling applications. And given that developers are typically more interested in the creation of applications than the challenges of managing them day to day, these abilities should not be undersold.
That said, PaaS advocates are frequently unaware of the friction relative to traditional IaaS alternatives. Terminology, for example, is frequently an object of confusion: the linguists of infrastructure-as-a-service, which is essentially a virtual representation of physical alternatives, are simple. Servers are instantiated, run applications and databases, have access to a storage substrate and so on. Would-be adopters of PaaS platforms, however, must reorient themselves to a world of dynos, cartridges and gears. Even the metrics are different; rather than being billed by instance, they may be billed by memory or transactions – some of which can be difficult to predict reliably.
Is PaaS more convenient, then? Over the longer term, yes, it will abstract a great deal of complexity away from the application development process. In the short term, however, there are trade offs. It’s akin to someone who speaks your language, but with a heavy accent or in a different dialect. It’s possible to discern meaning, but it can require effort.
Q: What’s the biggest issue for PaaS platforms at present?
A: While the containerization of an application is far from a solved problem – some applications will run with no issues, while others will break instantly – it is relatively mature next to the state of database integrations. Most PaaS providers at present have distanced themselves from the database, for reasons that are easy to understand: database issues associated with multi-tenant, containerized and highly scalable applications are many. But it does present problems for users. PaaS platform database pricing has typically reflected this complexity, with application charges forming a fraction of the loaded application cost next to data persistence. And many platforms, in fact, have openly advocated that the data tier be hosted on entirely separate, external platforms, which spells high latency as applications are forced to call to remote datacenters even for simple tasks like rendering a page. Expect enhanced database functionality and integration to be a focus and differentiation point for PaaS platforms in the future. This is why several vendors in the space have invested heavily in relationships with communities like PostgreSQL and MongoDB.
Q: Where do the boundaries to PaaS end and the layers above and below it begin?
A: This is one of the most interesting, and perhaps controversial, questions facing the market today. In many respects, PaaS is well defined and quite distinct from other market categories; the previously mentioned lack of database integration, for example. But in others, the boundaries between PaaS and complementary technologies is substantially less clear. Given the PaaS space’s ambition to abstract away the basic mechanics of application and deployment, for example, it seems logical to question the intersection and potential overlap of PaaS and configuration management/orchestration/provisioning software such as Ansible, Chef, Puppet, or Saltstack. PaaS users, after all, are inherently bought into abstraction and automation; will they be content to manage the underlying physical and logical infrastructures using a separate layer? Or would they prefer that be a feature of the platform they choose to encapsulate their applications with?
If we assume for the sake of argument that, at least on some level, traditional configuration management/provisioning will become a feature of PaaS platforms, the next logical question is: what does this mean both for PaaS platform providers and configuration management/orchestration/provisoning players? Should the latter be aggressively be pursuing partnership strategies? Should the former rely upon one or more of these projects or attempt to replicate the feature themselves?
From the conversations we’re having, these are the important strategic questions providers are asking themselves right now.
Q: What’s the market potential?
A: We do not do market sizing at RedMonk, believing that it is by and large a guess built on a foundation of other guesses. That said, it’s interesting that so many are relegating PaaS to niche-market status. Forget the fact that even those companies serving conservative buyers such as IBM have chosen to be involved. Consider instead the role that PaaS was built to play. Much as the J2EE application servers abstracted Java applications from the operating systems and hardware layers underneath them, so too does PaaS. It is the new middleware.
Given the size of the Java middleware market at its peak, this is a promising comparison for PaaS. Because while it is true that commercial values of software broadly have declined since traditional middleware’s apex, PaaS offers something that the application servers never did: multi-runtime support. Where middleware players then were typically restricted to just those workloads running in Java, which was admittedly a high percentage at the time, there are few if any workloads that multi-runtime PaaS platforms will be unable to target. Which makes its addressable market size very large indeed.
Disclosure: IBM and Pivotal (Cloud Foundry) are clients, as is Red Hat (OpenShift), MongoDB and Salesforce/Heroku. In addition, Ansible, Opscode, Puppet Labs are or have been clients.
