The Story of Heroku | Hacker News Reader

The Story of Heroku

leerob.io

129 pointsleerob35 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.

Thanks, I've updated the post!

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...

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.

[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.

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.

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.

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.

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

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.

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.

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!

Reply on news.ycombinator.com