PaaS is cool but IaaS sells
Waiting for PaaS to graduate from a good product to a viable business
One common sentiment in cloud application development is this:
Application developers don’t care about infrastructure. They want to focus on building features, not on patching Linux machines.
Another equally common but different point of view is this:
Serious developers have no use for abstracted platforms. They want deep control since they build more than just “Hello World” apps.
Which is true? Maybe both.
The concept of PaaS is almost as old as IaaS
It helps to look at some history.
We have all heard stories about how AWS began as an attempt to “rent out” spare computing capacity in Amazon data centers, so the orientation was heavily IaaS.
However, at least two major hyper-scale cloud providers (Azure and GCP) started their cloud journey with PaaS products, only to quickly realize that real money (and loads and loads of muscle and institutional memory) was still in infrastructure. So, they pivoted to being IaaS-centric (like AWS was at the time).
On the other hand, many interesting PaaS solutions have been created over the years by non-hyper-scale cloud providers - Heroku, Netlify, Vercel, Render, etc.
For this article, I am also making a simplifying assumption that Kubernetes - even the managed service provided by cloud providers - is just IaaS since it is just a better way of doing infrastructure.
By now, we know that control vs. productivity is not an either/or question but more like a continuum discussion. The reality is that different companies have adopted different orientations when building their respective IaaS or PaaS solutions. They choose which of the following they are solving for:
“fundamental operational problems” around hardware, data-center (DC) operations, network backbone, reliability, availability, latency, performance, geo-redundancy, etc. This is usually considered the domain of IaaS.
OR,
“developer experience problems” - ease of getting started, abstraction, automation, inner-loop, outer-loop, quick iterations, etc. This is usually considered the domain of PaaS.
A case for specialization: infra-operations or developer experience
Erik Bernhardsson, in his HackerNews-worthy article - Storm in the stratosphere: how the cloud will be reshuffled - even theorizes that the bottom layer of the cloud (the infrastructure) should be handled by the large cloud providers, whereas the “up-stack PaaS problems” are better handled by people who are closer to those domains - applications frameworks, Databases, Data-warehousing, Analytics, etc. He argues that selling lower-level infrastructure (i.e., “commodity”) doesn’t necessarily reduce the power of large cloud providers. This is because, practically, for most customers - heavy usage of IaaS is as lock-in-inducing as any PaaS. Besides, more PaaSes running in the world will invariably need solid IaaSes, thereby generating compute, network, and storage consumption from large providers.
PaaS vs. IaaS - swimlanes are disappearing
Earlier in the cloud journey, the rule was clear:
IaaS = Innovating in DC and hardware
PaaS = Innovating in developer experience
There have been some important exceptions to the rule, though:
Companies like DigitalOcean decided that this IaaS thing was cool but not accessible to everyday developers. It felt more like a Corporate IT thing. So, they invested in the “developer experience for IaaS” and discovered a LOT of demand for that among developers and small tech companies.
Similarly, in recent times, some companies have been creating engaging PaaS experiences not running on a hyper-scale cloud but on their own global infrastructure footprint. They are even arguing that this “edge-enabled-PaaS” is what developers really need.
So we end up with a matrix like this:
Good PaaS products vs. profitable PaaS businesses
It is interesting to see that the companies that have truly come to be known for excellent developer experience are usually pure-play PaaS providers - those unburdened by data center operations. Despite all its recent problems, Heroku is still considered the gold standard of developer experience. There is something about the undivided focus on developer workflows that creates truly productive experiences. Besides, if developer experience is your only selling point, you’d better shine.
However, none of this has prevented the hyper-scalers (AWS, Azure, GCP) from investing in PaaS. They are making big money from lifting and shifting infrastructure workloads from on-premises to cloud VMs. Still, in their big flashy customer conferences every year - you hear mainly about the shiny new managed products. Companies who operate their own DCs (especially large providers) can afford to (and do) invest in both DCs and developer experience. Owning the infra, in fact, gives them better cost efficiencies while building PaaS solutions.
What does this mean for the future of PaaS?
While I am a big fan of PaaS products (having worked on a few), I think there are some problems with PaaS as a business. Many of those problems have been very eloquently articulated (and debunked) in the excellent write-up - PaaS Is Not Dead - by Matt Butcher.
There are two problems that I still feel aren’t fully addressed in any of the narratives I have seen so far: pricing and ceiling.
PaaS pricing
Say what you will about how boring and old-school IaaS is. However, the truth remains that most businesses know what they are getting when buying IaaS and are generally comfortable paying to rent CPU hours in someone else’s data centers. With PaaS, however, they need a little more evidence.
Usually, the argument for a PaaS platform is that it takes a significant portion of the work away from customers, and in return, customers pay a premium. But PaaS providers also know that people need a quick taste of what the experience looks like before they are willing to pay a premium. As a result, a lot of PaaS pricing looks like this:
Note that the PaaS we are talking about here is primarily aPaaS (application platform as a service) - basically “Definition 3” from Matt’s article.
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.”
If we consider a broader definition of PaaS and include things like Database-as-a-Service (DBaaS), then obviously, there are other kinds of premiums that the provider will charge for also (beyond experience and management). For example, companies like Snowflake, CockroachDB, PlanetScale, etc. have done significant innovations on the core technology itself - Databases, storage, warehousing - for which customers are willing to pay an extra premium. That is a separate topic in itself, so not addressed here.
PaaS ceiling
The economics of PaaS is such that at a certain level of usage, most customers (at least commercially minded ones) feel that they are overpaying for the PaaS premium. Especially if your team is already doing other infra-ish things as a part of their operations, then extending that do-it-yourself (DIY) argument to your apps is a reasonable thought.
So a combination of these pricing and ceiling challenges leaves a lot of PaaS providers with:
a long tail of customers who have low monetization value, and
some larger customers with reasonable monetization value but who are always at churn risk.
This churn risk, as mentioned earlier, is not necessarily from better competitors but mostly from customers’ desire for deeper control and lower costs.
I would love to see more pure-play PaaS providers come in and continue to teach the industry a thing or two about developer productivity. However, I am equally excited that Microsoft is trying to create a subsea data center, that DigitalOcean is simplifying infrastructure for developers, OR that fly.io is using their own hardware to run full-stack apps on microVMs around the world. Exciting time to be in Cloud!