With Heroku, there’s always a “but.” For 15 years, I’ve heard Heroku described as “magical,” as the gold standard for developer experience, as the manna from heaven that the Israelites ate while wandering in the wilderness.
But …
For all its impact, Heroku always seems bigger in its mythology than its reality. I don’t mean to say that its impact hasn’t been substantial in terms of other services and products it has inspired, but why is Kubernetes and not Heroku the increasingly default way to build and scale applications? Some suggest Heroku was simply ahead of its time. Maybe. Or maybe the price of that magical developer experience was too constrained to work in the modern messiness of enterprise computing.
A golden age of developer experience
Heroku is back in the news because it recently announced the elimination of its free tier. Why? As it turns out, it was simply too much work to keep up with the graft that followed a zero-cost tier: “Our product, engineering, and security teams are spending an extraordinary amount of effort to manage fraud and abuse of the Heroku free product plans,” said Bob Wise, general manager of Heroku and executive vice president at Salesforce, which acquired Heroku in late 2010. Instead of playing Whac-A-Mole with crypto fraudsters, the company hopes to better invest in its customers—of which there probably aren’t as many as there should be.
That sounds like criticism but isn’t. Perhaps it’s the crowd I follow, but I’ve never heard Heroku mentioned except to praise how it revolutionized deployment of applications. Prior to Heroku, it would take as long or longer to deploy an application as to build it. With Heroku, deployment was as easy as a Git push.
The problem, as Jason Warner, who led engineering at Heroku between 2014 and 2017, argues, is that “Heroku was never finished.” Getting acquired by Salesforce didn’t help, as Scott Carey covered in his article in 2021, because it effectively froze Heroku development in time: a gorgeous, snowglobe-like experience that could never be more than what happened within the globe. As Warner says, “Heroku was magical for a set of applications; a finished Heroku could have been magical for many more.”
Again, this doesn’t change the fact that “for many years [Heroku was] the most beloved dev tool for many folks, particularly those just starting out,” Warner stresses.
But …
Closed off from innovation
For all that industry impact on what a great developer experience looks like, Heroku seems to have gone into a resourcing black hole within Salesforce. “I don’t know for sure, but I suspect Heroku headcount today is less than five years ago,” says Crunchy Data (and former Heroku) product lead, Craig Kerstiens. This is somewhat surprising, given that more apps are running on Heroku today than five years ago. Arguably, Heroku was always a bit orthogonal to Salesforce’s primary business, making it difficult for Heroku to get the internal funding it needed.
It’s also probably true, as Warner suggested, that Heroku should have open sourced more. As a pristine but closed developer experience, Heroku could never be more than Salesforce chose to make of it. There was no chance of outside investment, which proved a problem as Kubernetes began generating significant community engagement. “It had a ton of potential and was more intuitive than [Red Hat’s] OpenShift v2. If [Heroku] had gone open source around the time Kubernetes came out, we’d probably all still be taking it seriously,” suggests developer Scott Williams.
This is a problem with enterprise computing. As Google’s James Ward posits, “By far, the biggest issue was the lack of an escape hatch. When a team/org reached the limits of Heroku, the only option was to do all the things Heroku provided—infra automation, ops, etc.” (Not everyone agrees.) By contrast, Kubernetes offered a range of “escape hatches” and alternative deployment options. With Heroku, you had to be all in. With Kubernetes, you didn’t. Option value is big in enterprise computing.
Hence, developer Jeremy Chone arguably gets it right. He says, Platform as a service (PaaS) “makes projects easy to start [and] hard to finish.” Enterprises tend to bet on magic that is a little messy: An enterprise developer may like a PaaS that is highly opinionated and makes a class of application incredibly easy to build, but an enterprise development team needs to think of the ability to extend and customize tools to account for the messy reality of existing and future infrastructure.
Copyright © 2022 IDG Communications, Inc.
