Hacker News new | past | comments | ask | show | jobs | submit login
The Story of Heroku (leerob.io)
129 points by leerob on May 30, 2022 | hide | past | favorite | 35 comments



> James, the Co-Founder and CTO of Heroku, coined the term 12 factor app

That would be Adam Wiggins, not James Lindenbaum, who published the 12 Factor App :) I know this because I was there when it happened, but also if you check the bottom of the 12 Factor website it’s quite clear:

> Written by Adam Wiggins

Also, this is not at all accurate:

> GitHub (formerly hosted on Heroku)

GitHub used Heroku for some stuff back then (like their original status site) but they absolutely never ran the core of GitHub on Heroku.


GitHub was hosted on Engine Yard[0] in the early days, and as part of that deal had an Engine Yard banner in the footer. We then moved to Rackspace[1] for a few years until the first funding round in 2012 when we built out our own datacenter in earnest.

[0]: https://github.blog/2008-05-07-rolling-with-engine-yard/ [1]: https://github.blog/2009-09-15-github-is-moving-to-rackspace...


Thanks, I've updated the post!


Article doesn't mention the original name "Heroku Garden". It was a playground for Ruby on Rails development. You could go from thought to deploy in matter of minutes.


In 2008 I was a junior in high school learning RoR in my free time, and the teacher of my required Intro to Computers class let me essentially skip the class work if I could build a basic social media site in the semester.

The computers were always locked down tight but using Heroku Garden and its web editor for Rails apps I made it work. I've always been super appreciative of that exact functionality at that exact time, even as they grew into a more traditional hosting company.


[Author here] I did not know that! Thanks for sharing, will add it. I started using Heroku in 2012 for context, pre in-browser IDE form.


As a note. There was a popular Rails book at the time that was being released, I believe it was Michael Hartl's, but it may have been another one back then. The opening of the book was "open your web browser and go to herokugarden". On the day the book was released Heroku decided to pivot away from web based IDE towards the platform. Back then pivots weren't as common as they are now, believe Adam gave a talk at this at one of Eric Ries conferences.


Ironically, we still need a modern hosting company that can easily and cheaply run Ruby on Rails applications as well as hybrid SSG/SSR frameworks like Bridgetown, plus scale across multiple regions without headache. Render seems like the best candidate at present. Keeping my eye on Fly as well.

I sure wish Heroku's architecture and pricing structure had stayed competitive. I appreciate the stability of a company's offerings—especially a hosting company—but there's a difference between stability and fossilization!


Why the requirement for multiple regions as opposed to multiple zones?


Because it's not that unusual for a whole region to experience an outage.

https://news.ycombinator.com/item?id=29473630

https://www.techradar.com/uk/news/live/aws-is-down-again-her...


Guessing this is a response to the article I wrote that showed up on HN last week "Why Did Heroku Fail" [0]

I'm glad the author touched upon some of the outsized contributions Heroku made to DevOps and infra. I don't think many will argue with that. I was actually thinking of Vercel when I wrote the piece. What does a PaaS need to look like in 2022 to succeed? The author briefly mentions the current state of Heroku -- I think we all will also agree they deserved to capture more of the value that they created. The bigger question (in my mind) is how?

[0] https://news.ycombinator.com/item?id=31372675


PaaSs were always sort of a funny in-between category that were sort of defined by not being IaaS or SaaS--though I'm not sure the NIST definitions are super-useful at this point. As the article says, a PaaS like Heroku made it easy for developers to get going. OpenShift started as something similar (although polyglot) from the Makara acquisition. However, enterprises, by and large, found they were too limited.

I agree with the gist of the article that some subset of PaaS or would-be PaaS users went to serverless. And many others went to Kubernetes-based container platforms--whether on-prem, hosted on a cloud, or some cloud-native service like EKS.


Great story.

While it might seem that the world has moved on, the core developer experience on Heroku is still pretty awesome.

One aspect that I loved, loved on my recent project was the ability to seamlessly clone a Postgres database. I would set up a follower, have it suck in all the data from the leader, then stop the following and voila, I'd have a copy, e.g. for debugging production issues. All that with a few simple CLI commands.

I think Heroku is still a great fit for monoliths that only need a few dependencies like a database and Redis.

Once you need more, there's the Heroku marketplace, and yes, you have an add-on for everything but the fees add up quickly. And while an enterprise customer might not even notice four to five figure monthly bills, a scrappy boot-strapped startup or a solo developer surely will.


This is a very good framing of Heroku


> Rails made developers incredibly productive at building applications, but it was still painful and time-consuming to get them deployed. Developers might spend weeks (or months) just on deployment.

I’ve never used Rails. What made it so hard to deploy? I always thought it was similar to PHP: setup a DB, maybe fill in a config file or two, and copy the code to the web server. was that not the case?


One difference was that PHP was specifically designed to be launched by or embedded in a web server and Ruby wasn't. Getting that glue to an unfinicky, unclunky state took some time.


There was frequently more than just a DB; one thing Heroku made easier was adding things like mail serving, memcache, Redis, etc.

The major issue in early Rails deployments though was the dependency hell you got pre-Bundler (equivalent to something like Yarn in the JS world). Most of the fighting with deploys I did was along the lines of "it works on my machine, why doesn't it work on the server?"


Oh, man. I remember that. It seemed like no matter how careful you were, your machines would not be the same, and you'd hit issues.

We went to VMs to get things consistent.


Lots of developers just weren't/aren't good at deploying things, I don't think Ruby was any more difficult personally.


It was common to use Phusion Passenger at the time and it had a similar deployment story.


My one engineer/admin/technical interaction with Ruby on Rails was as the person responsible for overseeing the design, and then the testing and deployment using Passenger on Apache, for a completely bespoke application at a nonprofit.

It left an odd taste in my mouth overall, but it was a valuable learning experience and the application itself was neat. Getting it to run was sorcery.


I miss the old "Heroku Garden" in-browser code editor!! learning Rails using nothing more than the portable browser running of my iPod's hard drive on my high school library's computers was pretty magical at the time.


[flagged]


I prefer to explicitly call it out, even if I believe this post is a fair summary of the story of Heroku. Are there points you disagree with or that are inaccurate?


It’s well written and interesting, no issues at all imo. Thanks for calling it out; no problem with that. Some people conflate working for a competing tech with bias, and while there could be some, the important thing is to mitigate.

As a contrary example, there’s another Heroku story on the front page right now that’s not interesting or thoughtful at all and is just marketing copy for what they’re selling.


It's a great practice, if there's one nit - it's probably better to put things like that closer to the beginning of the piece so people are less inclined to fish it out of the bottom and use it for messageboard battle.


It's great you disclosed this information, and you wrote an excellent article imo.

I hope it's fair to say that you work for a direct competitor to Heroku, and that the intention of the article is to share how you've learned from the parts of Heroku that people loved and are working to build on these ideas in the work you're doing (which is great!). I'd prefer knowing that the article is written by a competitor at the start versus casually towards the end.

I hope I didn't offend you by my comment! :)


You should just write something like this the first time around because just pasting a random line from the article ends up looking like the sort of thing the guidelines harumph about:

Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.


Thanks for that feedback, you're absolutely right. I'll do that.


really wouldnt say vercel is a direct competitor to Heroku, insofar as HN is a pretty discerning crew as to how a serverless-only platform differs from one that lets you run servers.


Yeah, we have quite a few customers who host their frontend on Vercel and their backend on Heroku.


Leerob, why hasn't vercel shipped postgresql db's with connection pooling built in?

I know you have the marketplace and I could connect to PlanetScale... but I don't really want to. Why should I have to switch to MySQL from PostgreSQL?

Or even a better question: why can't I use a single host provider for my whole app?


You can always provision a Crunchy Bridge DB and connect to it, we've got a ton of customers using Vercel and connecting their app to us. With built-in connection pooling it tends to work quite well.


This is a great option :)


We also have Postgres database providers in our marketplace like Supabase. Have you tried them before?


I also think serverless-friendly managed DBs are the missing piece of the puzzle of Vercel's offering. Would be so nice to have the whole stack hosted on Vercel instead of needing external platforms for that last bit, and complicated pooling setups. Hopefully that's somewhere in your guys' roadmap!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: