In the beginning, Platform-as-a-Service (PaaS) was an easy to understand category of software, even if it wasn’t called Platform-as-a-Service initially. In its earliest incarnations, PaaS was a seamless if tightly constrained fabric which abstracted and made opaque the infrastructure running underneath it, from database to operating system. The promise to developers was, in strictly functional terms, serverless. No longer would developers have to concern themselves with operations minutiae like server instances. Instead, they deployed applications against a given platform and from there on out operations were, at least theoretically, the platform’s problem.
Since those first tentative releases in early 2007, PaaS has become more complicated to explain, both because the category itself has expanded its ambitions and because other, competitive layers of abstraction have emerged.
Most obviously, there is the container-led DIY infrastructure phenomenon, a phenomenon that has so far not been gifted with its own PaaS-like acronymn.
This chart represents worldwide searches for Docker the computer technology. Of note here is the timing; the technology began taking off in 2013, which follows as the initial release of the project dates to March of that year. Docker neatly packaged up, and thus popularized, container technologies, helping to drive widespread interest and adoption of the technology. Adoption at rates that are faster than almost every technology tracked over the history of RedMonk.
PaaS as a category was roughly six years old at the time containers burst onto the scene; Cloud Foundry and OpenShift were around two years of age. For reasons of execution more than model, the growth of platform technologies was anemic relative to its slightly older infrastructure competition. Nor did interest in PaaS ever spike in the way that it has for containers.
This chart, in turn, represents another emerging high-visibility technology trend. The blue line represents searches for the containerization search topic; red is web searches for serverless. Originally a market limited to AWS’s Lambda service, competitive services from Google to IBM to Microsoft are expanding the category and interest in it dramatically. Time will tell whether it not proves to be a force on par with containers, but there’s little question that at present serverless is capturing developer interest.
The question moving forward is what the future is for the PaaS term. Containers are distinct functionally and in terms of ambition from traditional PaaS offerings, clearly. Serverless has some similarities in terms of high level positioning, but takes a materially different approach again than traditional PaaS offerings.
All three, however, and their attendant ecosystem members (e.g. Kubernetes) represent layers of abstraction that enterprises are increasingly evaluating, if not exactly side by side, relative to one another. “What are the virtues of serverless versus a traditional PaaS?” is a question that is being asked more and more. The same question, but for container-led DIY infrastructure is even more common.
There would appear to be two paths for PaaS moving forward. Down one, it becomes a catchall, and thus compromised, term for a host of unlike technologies. This will lead to PaaS evaluations that will attempt to compare in apples to apples fashion, say, Cloud Foundry vs Docker/Kubernetes vs Lambda. On the one hand, all can serve in some capacity as foundations for applications. On the other, the way they go about this and the tradeoffs they imply are entirely distinct.
Down a second path, however, PaaS gradually becomes deprecated as a term. The Cloud Foundry ecosystem, for example, has seemingly retired that term in favor of messaging around Cloud Native. Google App Engine, for its part, mentions Platform-as-a-Service in its page title but nowhere else; Heroku uses the term not at all on heroku.com. Apprenda and OpenShift, however, use it far more prominently.
In either case, PaaS will persist as part of the industry lexicon for the foreseeable future. How it’s used, however, and by whom, will go a long way towards determining the utility it has remaining.
