PaaS Is Not Dead
Matt Butcher
paas
saas
cloud
I am troubled by a few loud voices recently claiming that Platform as a Service (PaaS) is a failure. I am not bothered so much by the idea that PaaS might not have lived up to expectations. What frustrates me is that people are claiming this as if it were fact, but without evidence.
PaaS, it turns out, is not dead. We’ll look at a few ideas of what failure is, apply them to PaaS, and then evaluate whether PaaS has failed. The conclusion is resoundingly clear: PaaS is a highly successful endeavor, alive and well, and likely to be so for quite some time.
Platform-as-a-Service: Definitions and Examples
What is PaaS? The term was once a little ambiguous, though now a clear definition seems to have emerged. We’ll look at two older definitions before focusing on the definition that seems to enjoy consensus use today.
Definition 1: Anything that Runs on IaaS
Back in the early days of cloud, I worked at HP Cloud. We considered PaaS to be any service that ran atop Infrastructure as a Service (IaaS). Therefore, hosted databases, message queues, and email services were all PaaS. Analysts occasionally still group all non-IaaS services into one PaaS category, which is then subdivided into segments such as DBaaS (Database as a Service) and APaaS (Application Platform as a Service). In this parlance, APaaS is the same as Definition 3 below.
Definition 2: An Application Building and Deployment Tool
Somewhat later, thanks to Heroku and CloudFoundry (both excellent platforms), the term PaaS was sometimes used to describe a source code building and deployment environment. I can recall a few conversations with folks who suggested that PaaS was actually the same as CI/CD. The critical point, here, was that build packs (again, prominent features of Heroku and CloudFoundry) did something along the lines of what we now do in our GitHub Actions. But this definition of PaaS also seems to have fallen out of use.
Definition 3: Developer Self-Service for Deploying Apps
These days, the most common definition of a PaaS is that a Platform as a Service is a cloud-based hosting environment into which a developer can deploy their own application, and have the platform manage configuration, deployments, releases, logging, and other operational concerns. Frequently, people will characterize PaaS as a “developer self-service tool.”
Frequently, a PaaS provides features for versioning, packaging, monitoring, and debugging applications. Most feature Web-based dashboards of some sort. Some include facilities for compiling or building apps on the server (like Heroku build packs). Some PaaSes support many different languages or frameworks. Others support just one or two specific languages.
Because of confusion with the earlier definitions, some have started using the term Cloud Application Platform, which I prefer (I often describe the Fermyon platform as “The Cloud Application Platform for WebAssembly Microservices”). However, the term PaaS does seem to remain more widely used.
Examples of Definition 3
The original PaaS cast includes Heroku, Stackato, CloudFoundry, and Deis. New examples include Vercel, Railway, and even Deno’s new Deno Deploy. Given that it is a deployment platform for a variety of CMS systems, I think Netlify also is close enough to meet the definition. OpenShift is considered by most to be a PaaS, and some even consider the Kubernetes opinionated framework Knative to be a PaaS. It is also true that major cloud providers have proprietary PaaS systems. Google has AppEngine. Amazon has AppRunner and Fargate. And Azure comes in with several, including App Service, Azure Spring Apps, Azure Container Apps, and Web Apps for Containers.
The list above is in no way exhaustive. I can think of at least a few more to add. But the above is surely a representative sample including the more commonly known PaaSes.
Now that we know what we mean by PaaS, and we have some examples to look at, let’s turn to the question of whether PaaS, as a category, is a failure. (Again, we’re sticking to definition 3 here.)
Defining Failure
The claim that has been made is that “PaaS is a failure”. What constitutes failure? Let’s take a look at several options and see if PaaS (as a category) meets these definitions. We need to be careful, though, of the salience bias, in which we might be tempted to say that because one or two big names failed in a particular way, the category itself is a failure.
Not Enough People are Using It
One definition of failure may be that something “failed to take off,” by which what we really mean is “didn’t get any customers,” or even more modestly, “didn’t get any users” (regardless of whether they paid).
In a way, this one is the easiest to assess. Companies with no customers go away, and do so quickly. There are PaaSes that did not make it into our collective awareness. But it is not evident that this problem is systemic. With a backward glance at the PaaS examples above, most of them are still thriving. Stackato (acquired by HP) and Deis (acquired by Microsoft) are no longer around, though perhaps not for lack of users. Some, like EngineYard, have lost users over time. The rest persist.
The likes of SalesForce, AWS, and Microsoft are not going to keep around costly services unless they have customers. In fact, the data suggests that the PaaS market in 2020 was $27.7B USD, and is projected to grow to just under $320B by 2030 (though the above stats seem to include DBaaS and Business Process as a Service (BPaaS) in their projections). Others suggest PaaS spending will hit $100M USD this year. And while I am somewhat skeptical of the data, one report suggests that as of August 13, 2022, 667,734 of the top 1M sites on the internet are running on a PaaS.
So at least based on our list above, PaaS is not failing for lack of users or customers.
Not a High Valuation
Fermyon is a venture-backed startup, so we are well aware of the importance of the question of valuation. Essentially, a company’s valuation is an estimate of what this company is worth on the open market (vague, yes, but that’s capitalism for you!).
As a company matures, its valuation should increase. That is an earmark of success. While companies have dips in valuation (just as publicly traded stocks go up and down), the general trend line is considered a strong indicator of market viability. A startup that hits a valuation of $1B USD is said to be a “unicorn,” a rare sight.
Now, to be fair, there are some notable examples of PaaS companies whose valuations were not rosy. When Deis was acquired by Microsoft, it was part of EngineYard, whose valuation had dropped because of the decline of Ruby on Rails. When SalesForce acquired Heroku, they paid around $200M, which many consider to be unsatisfactorily low.
But even now, PaaS companies seem to be fetching top-shelf valuations.
Vercel (which has raised several rounds of funding) is estimated to be worth $2.5B USD. Netlify is worth over $2B USD (Crunchbase reports them as between $1B and $10B). And Deno and Railway both recently raised new rounds of funding, so things are looking good for the emerging players as well.
Clearly, PaaS is not failing on the valuation front.
The Technology Is Declining
This one is particularly susceptible to the salience bias. But also, we should be aware of what it would look like if PaaS itself is in decline.
On the salience bias side, one common argument that PaaS is failing has to do with the claim that “Heroku is in decline, illustrating that PaaS is dying off.” I scanned through SalesForce’s earnings reports but Heroku earnings are not reported independently. (They grouped in with SalesForce’s other platform offerings.) So I am not sure whether it is accurate to say that Heroku is in decline.
But assuming for a moment that it is, what does that tell us about PaaS platforms in general? Probably nothing. As I pointed out above, other platforms are clearly ascending. Gartner’s research pegs PaaS as a rapidly growing service. When I was at Deis, then part of Engine Yard, I got to experience firsthand what it was like to see a PaaS gaining traction while another lost traction. Engine Yard was once a hugely successful Ruby on Rails PaaS. But as the technology passed its prime, the PaaS platform lost substantial revenue. Meanwhile, on the Deis side we were seeing the opposite. Our container-oriented Kubernetes-powered PaaS was growing (that is, gaining users) to the day that Microsoft acquired us.
The point here is that salient declines (such as the possibly true rumors of Heroku) might not particularly be an indicator at all that PaaS (as developer self-service) is in decline so much as that individual technologies come and go, and the associated PaaSes follow along.
Our final definition of PaaS used the shorthand idea that PaaS is developer self-service. If PaaS as a technology is in decline, there is one trend that we can watch for: the diminishing acceptance of the notion that the developers should deploy their own code (or, related, that the developer should use a platform to deploy). This is not a trend I have seen evidence for. At one point adherents of GitOps claimed this was coming. The narrative was that GitOps or CI-based deploys would replace PaaS. It is certainly possible that an unquantified number of developers moved in that direction, but not enough to impact PaaS acceptance.
While GitOps certainly has its adherents, it does not seem to be encroaching upon PaaS. A quick look at Google Trends shows that the search term paas is still outpacing gitops 28 to 1 in the US (and by more worldwide).
The conclusion is again clear: PaaS is not a technology in decline. It is not failing by this measure.
The Technology Never Reached Peak Users
This is the first argument where the form of the argument is itself problematic.
The form of this argument is usually something like “There are X potential users, and PaaS only reaches Y.” This analysis is often used for individual offerings to assess their success in their field (by comparing Total Available Market (TAM) to their own acquisition numbers).
This method works well for assessing the success of an individual offering within its field. For example, “There are X potential cereal eaters, and Chunky Bites is eaten by Y of them.” This gives a clear way to analyze whether Chunky Bites is outperforming Frosted Sugar Bombs. But this does not work as clearly when trying to analyze a category instead of an individual offering.
The argument would have to proceed something like this:
- There are X users who would use a PaaS
- But there are only Y users who do use a PaaS
- Therefore, PaaS is failing
But this seems to actually suggest not that PaaS is failing, but that the market will support something else that does not yet exist — some technology that has not made it to the potential users. (Or perhaps, more bleakly, it indicates that there is some other external barrier to PaaS.) In either case, the conclusion (PaaS is failing) does not follow from the premises.
A better question would be what is the TAM for PaaS? And is that notable in comparison to the TAM for cloud services in general? Statista suggests that PaaS accounts for 20% of cloud services. That would suggest that 1/5th of the total cloud market is TAM for PaaS. And that is huge.
Perhaps a more nuanced argument would be that a substantial portion of PaaS systems never reach their peak users. This argument would be more interesting: PaaS platforms grow to a point, but then something stops them from continuing to net new users. We will consider this point next.
But our conclusion for reaching peak users is that the TAM for PaaS is sizable, and in absence of any other relevant measure, we must conclude that PaaS is not failing by this metric.
Individual PaaS Platforms Peak (Because of Technical Limitations)
While we concluded above that PaaS is certainly reaching a huge number of users, one might construe the argument to be that PaaS platforms grow to a point, and then users “outgrow” them. We could rephrase this to suggest that PaaS is a failure if as users become more successful they stop using the platform because their needs extend beyond what the platform can offer.
Here’s a concrete example: Version 1 of an app is built and deployed on a PaaS and functions great, but when Version 2 comes along, it needs a new data service that is not easily managed or integrated into the PaaS. Therefore the users migrate Version 2 off of the PaaS and on to something else.
We are left with one curiosity regarding this argument: I have hunted for statistics on PaaS attrition rates, but have come up empty. The gist of the argument (that people leave PaaSes after a while) seems to be bereft of all but anecdotal evidence. Therefore, if this is a real problem, it is an unsubstantiated one. But let’s assume for a moment that a non-trivial number of developers move their applications off of PaaSes because of technical limitations.
There are two responses to this.
One is trite, but also true: It is normal for some users to outgrow some technologies. In fact, this notion is deeply embedded in software. Programming frameworks help developers build apps fast, but developers later find them constraining, and move on. Graphical code builders let the user easily build a simple program, but it must be converted to code when it hits certain levels of complexity. Web pages can be written using ready-made style libraries until the developer wants to style something differently, then they choose to write their own CSS. In none of these cases is the tendency of some developers to move on considered a failure of the technology. Perhaps PaaS is like this, too. Sure, some percentage (potentially even a sizable percentage) decide at some point to move on.
The second response, though, is less trite and more aspirational. Perhaps one of the shortcomings of many PaaS systems is that they stop at the “good enough” cases and don’t tackle more sophisticated cases. Consequently, they drive users away as the users’ needs become more sophisticated.
This would certainly be a pitfall to be avoided. And as someone who once migrated off of Heroku when I hit limitations, I can agree that this does happen sometimes. But it is not clear whether this problem is endemic to PaaS or if it is just an oft-repeated shortcoming of various providers.
In the end, the fact of the matter is that PaaSes continue to be popular, profitable, and prolific. Left with no evidence to the contrary, we must conclude that PaaS is not failing due to developer attrition.
More Than the Average Number of Companies Failed
The idea here is that PaaS companies fail at a substantially higher rate than others. I imagine that this could be a useful metric, but to my knowledge there are no metrics that would point one way or another.
At best, all we can say at this point is that there are enough companies that are successfully profitably operating PaaS systems that it seems like the market supports the technology.
The Kitchen Sink Argument
This definition of failure is patently unfair, but does get used sometimes. The argument goes: If a product meets any definition of failure, it is a failed product. And if a group of products each meet any definition of failure, then the entire segment is a failure.
So one might say:
- Knative failed to reach its peak users
- Heroku had a low valuation at exit
- EngineYard was attached to a market that declined
Therefore PaaS is an unqualified failure.
The problem with this mode of argument is obvious if you apply the converse: What if any definition of success qualified a product as successful? Then we could equally argue that because Heroku has many customers, Knative is attached to an ascendant technology (Kubernetes), and EngineYard reached a huge number of users in its potential market, then PaaS is a raging success.
We end up with a sort of reductio ad absurdum that failed projects are successful projects, and thus PaaS is both an unqualified failure and an unqualified success.
Conclusion: There is Room for More
PaaS has been successful, but there is still room for improvement. Here are some other ways that new PaaS systems can outshine predecessors and achieve new levels of success.
- As the great technological machine inches forward, new technologies emerge that are not yet served by existing PaaS systems. This may be as simple as a new language, or as complex as an entirely different cloud platform.
- Cost is a surprisingly often overlooked reason that teams migrate from one platform to another. And PaaS systems have historically been expensive. New systems that undercut older pricing models or make it easier to control cost can also find room in the PaaS sphere.
- Security and performance increase in importance as a site scales or as an enterprise grows. PaaS systems that make regulatory compliance, performance optimizations, and high security easy are likely to find purchase in the market.
- PaaS is and always has been about developer experience. How do we make life easier for the web application developer? For the microservice developer? For the ML developer? For the new or seasoned or specialist or generalist….? How do we improve debugging or logging or language support or deployments? Shaving down the friction points of software development makes a PaaS stand out.
- While developer experience has been a focal point, operator experience has not. There is huge room to make PaaS better for SREs, DevOps, and platform engineers.
PaaS is not dead. In fact, it doesn’t even seem to be suffering. From startups to niche providers to the major cloud providers, there are successful PaaS offerings of a variety of shapes and sizes. And yet, there is still room for innovation.