Heroku made reproducible builds and deployments a thing at a time people were used to ssh'ing in and scp'ing files around for deployment. While 12factor later become canonized it was built into Heroku since day 1. Heroku was created because you could spend a month building a MVP app in Rails, but then it'd take as long to deploy it as to build it. Deploying software was too hard. And today we're still trying to get back to that, sometimes very unsuccessfully by adding abstraction layer on top of abstraction layer. Did Heroku fail? We're still talking about it over 10 years since being acquired as a gold standard for developer experience.
Okay, fine, but it wasn't acquired for something like GitHub... While two very different companies Heroku was acquired nearly 10 years earlier. It was the first large scale acquisition out of YC. I do not know the internals of YC, but it's been commented by others that know it better the exit of Heroku helped greatly YC for the time and place it was. It was a different time. Heroku to this day generates revenue and likely it's different from what people expect.
Yeah this one is selfish, but you can largely thank Heroku for Amazon RDS. Way back in the day we had Rails devs asking for a database. We thought how hard could this be, it turns out it was much more work than we expected. We bet on Postgres because one of our engineers said it had a great track record of security and reliability (not playing fast and loose with data semantics)–it was the right choice. Years later when Amazon adding support for Postgres on RDS the team sent some personal notes that essentially said, this is because you made it so in demand.
Now... what went wrong.
Yes, several people left after the acquisition, some at 2-3 years, some at 4-5 years, some are still there and have been before the acquisition. Acquisition or not when some of the technical and product visionaries leave it's hard to replace that. Adam gave his absolute all, he was spent after. 12factor felt like his going away letter. But that void was never fully filled, some of us may have had a shot of it, but after long runs were also tired.
Was Heroku cocky at times toward Salesforce integration, at times yes. At times I don't think was always the case. Did we want to run 20GB J2EE apps when Rails/Django/Node were lighter-weight, of course not. Did we want to login to gus to open a support ticket on a VPN? No. Did we want to move into the SDFC offices that were cube farms vs. large ceilings with a lot of natural lighting?No. But could Salesforce help us make Heroku more available to customers and accelerate adoption? Sure. Could we have focused more on enterprise requirements around security and compliance to reach the enterprise audience? Yep. In retrospect maybe we should have proactively integrated a bit more, I know many of us there at that time feel that way, but there were pockets of integration. I recall hosting the Sayonara team at the Heroku office for a Friday happy hour. We made sure to have it well catered and make them feel as welcome as possible. There was good and bad in the integration, but a common metric of acquisition metrics is how many that are employed at time of acquisition are employed x years later. Heroku had a lot of us still there, 2, 3, 4, 5 and even beyond.
Was pricing and business model a factor? Maybe. But I'm not sure you can get what Heroku gives you out of a single employee. I'm excited for what others are building in this space now, but it's not about being a "cheaper" Heroku it's about creating some advancements about easier networking, packaging what defines as an app as multiple services, signed/secure builds.
I've spent the much of the last 10 years hoping that I once again get to be part of such a failure. It's such a rare opportunity to work with an amazing team of talented people who set a new standard for what a great developer experience is, how simple it should be to run containerized workloads, that a robust build pipeline can actually be easy to use, setting the precedent for what a tightly integrated SaaS ecosystem/marketplace looks like, review apps, buildpacks... things that improved the lives for literally millions of developers. And even a decade later continue to set the bar for what many aspire to.
An amazing legacy to have a product that has been so relevant for so long in what is such a fast moving industry. I wish everyone got to be part of such a failure at least once in their careers. It's something I'll cherish for the rest of my days.
Heroku was the biggest in a long line of developer tools. The PaaS and now FaaS models are still alive and well. A lot of developers want them. I know people are hot on containers and k8s but devs, who need to focus on code and business logic, have poorer productivity when they have to shift into thinking about ops.
Heroku inspired a lot including direct competitors (like Cloud Foundry). A lot of money has been made and people jobs make easier.
On the flip side, I keep seeing businesses not wanting to invest in developer tools that make their lives easier. PaaS is one of them. Did Salesforce fail to invest in Heroku so it stagnated? How many other places is this happening? Did Heroku make enough money and that was it?
There are a lot of unknowns.
I think we need more PaaS and FaaS. Make the jobs of developers simpler (hiding the ops complexity).
The article should, in my opinion, focus on why Salesforce allowed Heroku to stagnate and grow uncompetitive.
[Disclaimer: Salesforce employee, thoughts and opinions are my own]
From my point of view, as a mere customer of their mass-market product (a.k.a. cedar) with some insight into operation history, I think expensive or at least detailed investment in refurbishing or adjusting the mass-market product became, for whatever reason, difficult to (internally) justify expense for.
For example: the mechanisms that make "heroku run" work could have really used a new version that could let me change my window size gracefully, and maybe streamlining some authentication, by using SSH. As far as I know, it's closely related to the first version of that feature ever written, which somewhat naively ties the client machine's tty to a remote tty via TLS connection. This is fine for getting cedar off the ground in the first release, but at some later year (decade?), it seems like it should have gotten re-do so, finally, I could change my terminal emulator window size.
Ditto the holding of extremely powerful API credentials in the plaintext file `~/.netrc`, further exacerbated by a fairly weak authorization system for Cedar. There's still a place for .netrc (e.g. so curl can pick up the credentials automatically), but at some point, use of the keyrings on various operating systems (at least) and U2F hardware attestation should have shown up.
Passing along cost reductions in inputs (e.g. AWS servers) is another long-standing example.
Somewhat related to that, IPv6 is a lot more common than it used to be. So are VPCs or similar products on other platforms. Putting all that behind a "let's have a call" process -- and cost structure -- for "Private Spaces" is not in step with the times in 2022. And probably not 2018, neither.
As a counter-example, it does seem the web/dashboard login not only grew U2F, but Macintosh TouchID support. Whoever got this in: well done. But it's a noteworthy exception. And I kind of wonder if it has anything to do with the web authentication system being more trouble than it's worth to segment between Cedar and the Private Spaces product.
There's always a temptation to put new features into an upmarket product to increase the gap in segmentation, but realizing that at least some features are closer to adaptations to raising or at least changing standards of adequacy in industry does not come naturally. I don't think this is the only problem, but it seems like a problem to me. As it comes to projects that turn on minute details, such as improving "heroku run" in the presence of terminal emulator resizing, it probably says something about the bureaucracy's inability to grapple with details of that kind. That was already present when I left.
They might lose that position in the future due to many missteps, but at this point it's like asking "why did Microsoft fail?". It didn't. It might not be what it was, but it's still a pretty successful concern, and same goes for Heroku.
Having alternatives is very cool. I did migrate an app to Render, motivated by Heroku's recent security woes. But in the process of doing so, I realized that Heroku has accumulated a lot of plugins, conveniences etc. over the years. If Heroku dropped their prices to be a bit less egregious, I probably wouldn't bother moving.
It will take quite a while before anybody can match them on convenience, and eg. Render is definitely not there yet - it has the basics down and done right, and if the basics are enough for you, it'll work. But a lot of things you get out of the box one-click support for in Heroku will be a manual setup on the alternative PaaSes, with a community wiki article to guide you at best.
Obviously given the hype around k8s and the order of magnitude difference between the success of the hyperscalers and the scale of Heroku, there's some mismatch btetween what they did and the potential they had. I would say the same about App Engine and AWS's various iterations starting with Elastic Beanstalk.
Overall if we had to bucket the opportunity that still exists to do better in the space, I think it aligned with wrong product and something better than "git push heroku" better than with business model, whole product, or timing (which clearly had a role). Business model is an issue but not against stuff like render, the success of which also pushes against whole product (people are still adopting something very similar).
Agree with craigkerstiens that the next iteration is about apps vs. services, extensibility, and blending different service types (frontend/container/serverless/data) more fully than Heroku (which really only has one type of app) was able to. And is also about lifecycle and SDLC completeness (which helps a lot with security and compliance, too).
As I mention on all these Heroku threads lately, I'm the cofounder of Coherence (www.withcoherence.com) where I think we're taking an interesting stab at what the future looks like here, using first principles to go deeper than other PaaS and integrate dev more deeply, along with more support for extensibility.
A great deal of the movement to containers lies on the shoulders of the DevEx that Heroku pioneered.
There's a lot of new investment in a lot of new projects; it's cool to see. I hope they carry the torch forward and are successful in their own right. I am looking forward to deploying code on all of them.
there was seemingly no logical reason to do any of this-- the product was at an early stage with nearly no traffic. even if the product were to become immensely successful, the traffic would probably never require more than a single box.
but none of this seemed to matter. nor did the considerable amount of time making things just work. the ceo, who was at one point a technical engineer mind you, just wanted to be able to say his stuff ran on aws
situations like this are probably more common than you would think. it's purely a brand recognition thing for them
It has its weird limitations but it's... Good. (And I've gone pretty deep into aspects of the buildpacks, how it stores its git repos on S3, and more.)
I am myself maintaining a custom built webshop/ERP system for a local company that repairs smartphones. I barely find enough time to maintain the actual code. If I would have to dig through the weeds on AWS the project would definitely be dead right now. Instead I just "git push heroku main" and I am done. I can also provision a database or Redis through the UI, without having to worry that I made a mistake that could cost me thousands of Dollars.
Biased take from the founder of one of the next-generation companies mentioned: given how new Render and Fly are as companies and products, it's much more important to look at the growth in their adoption. Render's signups were already growing at a rapid pace, but more than doubled overnight after the Heroku incident; give us a couple more years before judging adoption!
Seems premature to assess adoption of fly.io when it's barely gotten off the ground.
The story in all of them was the same: Heroku is nice and simple to start with the free/lower plans, but gets too expensive as you grow a bit more.
Once we'd grown past the free/lower plans, we'd move on to somewhere else, that required a bit more work, but was substantially cheaper and way more flexible.
Also an issue was a reproducible environment for several devs. Using docker became super easy, but this didn't translate well into Heroku. We either needed to maintain buildpacks and dockerfiles in sync, or move to a platform where we ran docker. Not sure if this has changed since, but this was also a big reason to move elsewhere.
> for all that people worry and for all that the press loves to say, 'Ah, this happened; this thing is over,' and whip themselves up in this frenzy, it never actually kills the startup. It's a problem; people love to talk about it. And there's this schadenfreude of loving to hate on someone's perceived missteps or someone's problem. So people love to talk about it. But then they go back and they book AirBnB for their next vacation.
Econtalk Podcast: https://www.youtube.com/watch?v=JAYXUgNHHc4&t=16m25s
Heroku solved the problem very well for years but it's very costly and limiting at the same time.
Now it's time to replace Heroku with services that help you use the cloud providers which leads to substantial cost savings.
We're very soon launching https://www.utopiops.com which is an alternative for Heroku on AWS to address this particular issue.
* expensive to scale
* developer limitations
This limited it to smaller scale projects, MVPs, proof of concepts where paying a little more for a certain range of developer productivity makes sense. Such is the case with rapid development platforms in general. When you grow you shift to wholesale-priced primitives that give you more control.
E.g: Qovery.com is the Heroku-like experience on top of AWS
(I am co-founder of Qovery)
Heroku might be a bit long in the tooth, but has a solid company behind it and it a lot easier than fooling around with Capistrano, Ansible or heaven-help-us Kubernetes.
Trust me, I've tried them all, and for a fairly standard Rails app Heroku just works.
The lack of HTTP2 is a bit embarrassing though.
If being in every Fortune 100 company running some of the world's largest containerized platforms in production is failure, I want to fail like that
Any data to support this? I suspect Heroku is immensely profitable on account of its huge user base (4th largest cloud provider after AWS, Azure, and GCP), and very healthy profit margins.
The selling point was easy and reproducible deployment. But there are must cheaper alternatives, and dynos productivity didn't have enough benefits for the cost.