Comment by asenchi
21 days ago
It remains the greatest engineering team I've ever seen or had the pleasure to be a part of. I was only there from early 2011 to mid 2012 but what I took with me changed me as an engineer. The shear brilliance of the ideas and approaches...I was blessed to witness it. I don't think I can overstate it, though many will think this is all hyperbole. I didn't always agree with the decisions made and I was definitely there when the product stagnation started, but we worked hard to reduce tech debt, build better infrastructure, and improve... but man, the battles we fought. Many fond memories, including the single greatest engineering mistake I've ever seen made, one that I still think about until this day (but will never post in a public forum :)).
It was a pleasure working with you bgentry!
I'm just going to chime in here and say thank you, there still really isn't in my mind a comparable offering to heroku's git push and go straight to a reasonable production
I honestly find it a bit nuts, there's offerings that come close, but using them I still get the impression that they've just not put in the time really refining that user interface, so I just wanted to say thank you for the work you and the GP did, it was incredibly helpful and I'm happy to say helped me launch and test a few product offerings as well as some fun ideas
This!
It absolutely boggles my mind that nothing else exists to fill this spot. Fly and others offer varying degrees of easier-than-AWS hosting, but nobody offers true PaaS like Heroku, IMHO.
The Heroku style of PaaS just isn't very interesting to most large businesses that actually pay for things. The world basically moved on to Kubernetes-based products (see Google and Red Hat)--or just shutdown like a lot of Cloud Foundry-based products. Yes, many individuals and smaller shops care more about simplicity but they're generally not willing/able to pay a lot (if anything).
2 replies →
I find render.com basically as good as Heroku and certainly much better than fly.io's unpredictable pricing
6 replies →
Heroku and Ruby, for me, was the 21st century answer to 'deploying' a PHP site over FTP.
The fact that it required nothing but 'git push heroku master' at the time was incredible, especially for how easy it was to spin up pre-prod environments with it, and how wiring up a database was also trivial.
Every time I come across an infrastructure that is bloated out with k8s, helm charts, and a complex web of cloud resources, all for a service not even running at scale, I look back to the simplicity we used to have.
I completely agree that there's nothing comparable to old-school Heroku, which is crazy. That said, Cloudflare seems promising for some types of projects and I use them for a few things. Anyone using them as a one-stop-shop?
For me Northflank have filled this spot. Though by the time I switched I was already using Docker so can't speak directly to their Heroku Buildpack support.
vercel goes a step further, and (when configured this way) allocates a new hostname (eg feature-branch-add-thingg.app.vercel.example.com) for new branches, to make testing even easier.
4 replies →
I’ve been using Render for close to 5 years, and it’s excellent. I can’t think of anything I use that it doesn’t do as well or better than Heroku did last I checked.
[dead]
I agree with everything you said, and can only thank the founders for their tremendous insight and willingness to push the limits. The shear number of engineering practices we take for granted today because of something like Heroku boggles my mind.
I am forever grateful for the opportunity to work there and make it an effort to pass on what I learned to others.
> by 2012 we were drowning in tech debt and scaling challenges.
> the greatest engineering team I've ever seen
How do these two things reconcile in your opinion? In my view , doing something quickly is the easy part , good engineering is only needed exactly when you want things to be maintainable and scalable, so the assertions above don’t really make much sense to me.
It is hard to explain the impact of such massive growth over a 2-3 period. New features were coming online while old ones were being abused by overuse. For instance, we launched PostgreSQL in the cloud, something we take for granted today. Not only that, but we offered an insane feature set around "follow" and "forking" that made working with databases seem futuristic.
I remember when we launched that product we went to that year's PGCon and there were people in the crowd angry and dismissive that we would treat data that way. It was actually pretty confrontational. Products like that were being produced while we were also working on migrating away from the initial implementation of the "free tier" (internally called Shen). It took me and a few others months to replace it and ensure we didn't lose data while also making it maintainable. The resulting tool lovingly named "yobuko" ended up remaining for years after that (largely due to the stagnation and turn over).
Anyways, that was just a slice of it. Decisions made today are not always the decisions you wanted to be made tomorrow. Day0 is great, day100 comes with more knowledge and regret. :D
In general, my impression has been that you don't want to architect your solution at first for massive scaling, because:
* You probably aren't going to need it, so putting the effort into scaling means slowing down your delivery of the very features that would make customers want your solution.
* It typically slows down performance of individual features.
* It definitely significant increases the complexity of your solution (and probably the user-facing tooling as well).
* It is difficult to achieve until you have the live traffic to test your approach.
Yeah I think there is a lot of truth here. You can't solve all the problems and in Heroku's case we focused on user experience (internally and externally). Great ideas like "git push heroku main" are game changers, but what happens once that git server is receiving 1000 pushes a minute? Totally different thought process.
Perhaps the thing I would add is that even with the tech debt and scaling problems we still had over a million applications deployed ready for that request to hit them.
An organization without “tech debt” is not good at prioritizing.
Yea it seems like not much thought was put into scalability.
Tell us more about some of these ideas and approaches that changed you as an engineer! We'd love to hear!
Well many of them you may know in that they made their way into so many systems (though arguably without the refined UX of Heroku) but the two that come up the most and I am teaching others:
* The simpler the interface for the user, the more decisions you can make behind the scenes. A good example here is "git push heroku". Not only is that something every user (bot or human) can run, it is also easy to script, protect, and scale. It keeps the surface area small and the abstraction makes the most sense. The code that was behind that push lasted for quite some time, and it was effectively 1-2 Python classes as a service. But once we got the code into our systems, we could do anything with it... and we did. One of the things that blows my mind is that our "slug" (this is what we called the tarballs of code that we put on the runtimes) maker was itself a heroku app. It lived along side everyone else. We were able to reduce our platform down to a few simple pieces (what we called the kernel) and everything else was deployed on top. We benefited from the very things our customers were using.
* NOTE: This one is going to be hard to explain because it is so simple, but when you start thinking about system design in this way the possibilities start to open up right in front of you. The idea is that everything we do is effectively explained as "input -> filter -> output". Even down to the CPU. But especially when it comes to a platform. With this design mentality we had a logging pipeline that I am still jealous of. We had metrics flowing into dashboards that were everywhere and informed us of our work. We had things like "integration testing" that ran continuously against the platform, all from the users perspective, that allowed us to test features long before they reached the public. All of these things were "input" that we "filtered" in some way to produce "output". When you start using that "output" as "input" and chaining these things together you get to a place where you can design a "kernel" (effectively an API service and a runtime) and start interacting with it to produce a platform.
I remember when we were pairing down services to get to our "kernel" one of the Operations engineers developed our Chef so that an internal engineer needed maybe 5-7 lines of Ruby to deploy their app and get everything they needed. Simple input, that produced a reliable application setup, that could now get us into production faster.
Anyways, those are just a couple.
Here[0] is a talk that shows off some of these tools. Mark led the way on many of these ideas internally.
[0]: https://www.youtube.com/watch?v=yGcaofDq8SM
Thank you so much for this!
Absolutely agree and likewise buddy :)