Why IaaS beat PaaS

From the people who were *there*

Most people who come across the IaaS vs PaaS debate conclude that the early PaaSes were “just too early”. That was my own premise in Cloud Distros (start there if you are new to IaaS vs PaaS, then head to my take on AWS) — and it was a little too convenient.

Technology progresses in a series of back-and-forth switchbacks, not a monotonic straight line. In the year since I wrote that essay I’ve learned that the real story is a lot more nuanced than simple “timing”.

Learning 1: PaaS was the “Old” way

Here is Amazon CTO Werner Vogels, on choosing to offer “tools instead of platforms”:

It was slightly controversial, because most technology companies at the time were delivering everything and the kitchen sink, and it would come with a very thick book and 10 different partners that would tell you how to use the technology. We went down a path, one that Jeff [Bezos] described years before, as building tools instead of platforms. A platform was the old-style way that large software platform companies would use in serving their technology.

If you would go from Win32 to .NET, it was clear that the vendor would tell you exactly how to do it, and it would come with everything and the kitchen sink — not small building blocks but rather, “This is how you should build software.”

A little before we started S3, we began to realize that what we were doing might radically change the way that software was being built and services were being used. But we had no idea how that would evolve, so it was more important to build small, nimble tools that customers could build on (or we could build on ourselves) instead of having everything and the kitchen sink ready at that particular moment. It was not necessarily a timing issue; it was much more that we were convinced that whatever we would be adding to the interfaces of S3, to the functionality of S3, should be driven by our customers—and how the next generation of customers would start building their systems.

IaaS was a conscious choice by AWS - it wasn’t simply that we hadn’t developed the underlying technology to build good PaaSes. AWS had the core insight that whatever would be successful in the cloud era would be materially different than with desktops (where Microsoft’s platform approach with Windows ruled).

Even this insight wasn’t immediately obviously correct. AWS’ first launch, SQS, was in 2006. Balaji Srinivasan notes: “It wasn’t until Instagram in 2012 that everyone took AWS seriously as a way to build a billion dollar company.”

Learning 2: We have failed at building IaaS before

Balaji also noted:

“Many people had scar tissue from trying to do IAAS a few years too early, before the Xen hypervisor. It’s an extremely capital intensive business and Bezos nailed the timing.”

He includes this passage from Ben Horowitz’s recap of the Loudcloud/Opsware years:

During this period, Loudcloud/Opsware had over 20 direct competitors. Almost all the competitors from the Loudcloud era went bankrupt, including MFN/SiteSmith, Exodus, LogicTier, Williams Communication, Global Crossing, WorldCom/Digex and Storage Networks. Those that survived got bought with valuations of less than $100 million (e.g., Totality) or still have very low valuations (e.g., Navisite).

So if the late 2000’s were “too early” for PaaS, you could also have made the case that the early 2000’s were “too early” for IaaS. Betting on IaaS the way AWS did, at the time that it did, was not at all obvious.

Learning 3: Single Layer PaaS was too restrictive

Heroku was by no means a failure, but it certainly disappointed relative to its IaaS contemporaries, which today take in tens of billions a year.

Jason Warner, GitHub CTO and Heroku’s former VP of Engineering, observed this about Heroku:

It should never have been a PaaS; it should have been a multilayered cake of PaaS with various escape hatches to build out with Kubernetes or go multicloud, but that wasn’t what was to be.

Today, most IaaSes have “worked backward” and innovated forward - much as AWS originally offered S3 and EC2 and CloudFront and VPC, it now offers DynamoDB and Aurora and Elasticsearch and Lightsail and Elastic Beanstalk and Lambda and a couple hundred more ways to consume the underlying storage, compute, and networking services. Same for GCP and Azure.

The IaaSes, being lower level by nature, were in a better place to build up the multilayered cake, than the PaaSes were able to break themselves up.