Fifteen years later, developers are still trying to recreate the developer experience of Heroku. Yet, those who do not learn from history are doomed to repeat it. Why did Heroku fail? Was it just incompetent management? Was the idea too early? If developers demand Heroku, why haven't they (or a competitor) figured out how to make it viable?
Here are four hypotheses about Heroku's successes and failures and why they may be wrong.
Market Timing Hypothesis.
Heroku was acquired too early and suffered brain drain. Heroku's product was too early for the market.
The company was started in 2007, a year after AWS launched EC2 (Heroku built on EC2). It was also perfect timing to launch a hosted Ruby on Rails service (see Getting to Market with Rails for a list of startups that launched on rails).
Yet, Engine Yard was spun up around the same time and offered a similar PaaS. They continue to exist as a private company but spun off part of its team to Microsoft in 2017.
If Heroku and Engine Yard were too early, we would have seen more widespread adoption of next-generation PaaS (e.g., fly.io, Render). Containers (introduced in 2013) also changed DevOps and software deployment landscape. Yet, container-native PaaS (e.g., OpenShift) also failed.
Whole Product Hypothesis.
PaaS customers scale until they miss key features, for which it is not a "if" but rather a "when" of moving to AWS, Azure, or Google Cloud.
Even in the first few years of AWS, there was a Cloud 2 hypothesis that PaaS abstractions would layer above the cloud and capture margin (the 2006 version of AWS is a Dumb Pipe). This hypothesis never materialized. Heroku, built on AWS, could not competitively offer the auxiliary services necessary for adopting the core product (see whole product concept), such as VPCs, observability, service discovery, and global availability.
This hypothesis is partly disproven by the trajectory of App Engine (started in 2008). App Engine went further than many PaaS products before it and had the engineering power of a hyperscaler behind it (even though it predated Google Cloud). Furthermore, AWS and Azure have failed to build a competing product.
Business Model Hypothesis.
Heroku's business model was incompatible with its product. They could not sell cloud primitives while being built on cloud.
If this were true, we'd either see (1) a hyperscaler recreate Heroku as a managed service or (2) an open-source, bottoms-up Heroku alternative.
Render and fly.io are cheaper, but fundamentally offer a similar model (managed infrastructure and RAM/CPU-based tiers).
Wrong Product Hypothesis.
Heroku built the wrong product. Recreating it, even under different conditions (timing, business model, feature set), will not work.
This one is the most difficult to test – what-if Heroku's push-to-deploy model is "wrong"? What if the developer experience many have been chasing for 15 years is a false prophet? Of course, Heroku would need to look slightly different today (support for containers, functions, cloud-native, etc.), but many continue to try the same thing.
As someone who worked on Kubernetes for many years, a PaaS was always the elusive next step. So many imagined someone would build a successful PaaS with the primitives provided by Kubernetes (and many tried – Knative, Kubeflow, OpenShift, etc.).
Many of the missing pieces have fallen into place – cloud development kits that let us version and declaratively deploy infrastructure, GitHub actions for git-flow CI/CD, etc. But the standard for deployment has also drastically risen – the reliability and observability you can get through a hyperscaler continues to be unmatched. The surface area of what an application is and needs to be deployed continues to increase.
Maybe we ironically have much longer to go to build what we believed to be the PaaS developer experience. Building abstractions often needs to be done form the bottom up, using First Principles.