> the team now functions as an internal infra team for Salesforce

This is definitely false. Though some internal apps are deployed on Heroku, it is not the primary deployment target for new projects. Heroku staff work on Heroku. Salesforce has a large internal infra program and team that has no overlap with Heroku. past codename projects have been proposed to change this, but none have ever come to be.

(Former Herokai) It is definitely not false but you misunderstood what they meant.

You understood it as running sfdc code on Heroku which is not happening—but was proposed as part of Shinrai (a failed project). What has happened is many if not most Heroku employees have moved away from working on Heroku and are now working on Salesforce Functions aka Evergreen.

Since you seem to have some insight into this, I interviewed a former Heroku eng a while back and he said that they deploy Heroku infra on Heroku, essentially dogfooding their own product. I also see a lot of claims that Heroku has essentially stagnated on features. I'm curious how do internal teams reconcile this (do they just work around the stagnation?) and is there a layer that is a choke point for product improvement that also affects to internal teams (if so that would seem demoralizing)?

Most of their attrition is due to the slow rate of product improvements. So yeah, it's demoralizing for sure.

I've heard this as a reason for leaving for almost a decade though so it hasn't been a new problem but it seems to get worse every year.

There are a bunch of internal only feature flags that Herokai use internally. Making internally visible feature flags is less of a political fight than making externally visible features.

Even if the parent comment is wrong, there must be a public relations problem if so many people believe the product to be abandoned.

> All of the most talented engineers at Heroku left

There are still plenty of talented engineers at Heroku.

I used to do architecture work and support for enterprise customers and I knew the whole support team. Heroku support engineers are all devs or former devs; I am surprised at how passionate they can be about their work (ex: Jason, who STILL keeps the subreddit updated in his spare time).

I do think there are situations where support can't help, but those are usually situations where Heroku is probably not the right place to host a service. They can't help you setup crypto miners on the platform, or to setup a redirect service. If you don't like how the platform works, they can drop in suggestions on what to change, but they aren't going to be able to implement them overnight. You might get ideas on restructuring your app to work better on Heroku, which I admit is quite frustrating for a customer; but limiting the problem domain is part of building a service like Heroku.

Heroku's support structure didn't have a half dozen escalations, which was good IMO.

If you run into an issue on the platform, there is usually the support engineer and then engineers who developed it. This might have changed around when I left (my team was mostly eliminated during the pandemic), so I'm not particularly up-to-date on recent changes. However, the system they had in place when I was there felt much better, as a developer who needs help, than the support I currently get from (large IAAS provider), despite myself doing work for a major customer of theirs.

> I do think there are situations where support can't help, but those are usually situations where Heroku is probably not the right place to host a service.

This hasn't been my experience at all. Mysterious performance issues are met with "We can't help, just install NewRelic" (the issues don't exist when running the same code on other services). Billing questions have yielded delayed and cryptic responses. Table stakes customer support simply isn't being addressed. And I don't blame the support agents, I just don't think they have the tools or resources to help.

By comparison, AWS has managed to answer almost all of my questions within one or two messages. Hell, even Amazon has admitted when there's a bug on their end. That simply doesn't happen at heroku anymore.

I hate that I missed this response because it's a fair criticism.

Yeah, there are definitely details Heroku didn't have; for example, we only had something like the past 500 (or was it 100?) lines from a customer's logs; you would need to have an add-on to retain them.

There were no internal logs to consult about app performance; the New Relic install requests were probably to see if there is an issue related to the app. If the issue went deeper, we would work with the engineering team for the feature in question; but with the volume of tickets, we would have to categorically rule out an app issue first as 99% of issues happened while I was there. I think it is fair to say Heroku's support tried to embrace the "teach a man to fish" strategy, and that wouldn't work if the problem wasn't with the app.

I can't really speak to the billing issues, but that team was tiny; two or three people. I could definitely see them getting overwhelmed, and I heard about the lack of detailed billing support.

(Out of curiousity, were you using Heroku's docker product? I could definitely see that as having caused the sort of problems you mention as Heroku's docker platform was not vanilla docker.)

You support folks were absolutely stellar. Great at working with customers but also adept at coding enough to resolve an incredible amount of customer problems.

If anyone is ever in a position to hire support staff and you see "Heroku" on the resume, definitely consider that a strong positive signal.

This is a bad take without much internal context. Heroku is not thriving as it stands today. It takes a lot just to run Heroku and the engineers still around care deeply around it. I'm excited for a lot of the new offerings like Fly and Railway, but they aren't operating at the same scale as Heroku.

It does feel like there continues to be a fading at a leadership level about developer experience and what it means. There may not be strategy for what makes Heroku the next Heroku whether engineering or product, but the team that is still there is a solid set of engineers, not 100% there for Salesforce internal stuff, and kudos to them for still keeping afloat what is one of the better ways to deploy an app.

(Former Herokai) Heroku is beyond the point of recovery at this point (barring a sale to Github or something). Those dedicated engineers need to give up because at this point they're harming everyone:

* The industry – suffering because Heroku holds market share that should go to competitors capable of innovating.

* Customers – suffering because their platform will die but their vendor isn't being transparent about that fact.

* Herokai – suffering because they could be doing something better with their careers, even if it is on another sfdc product.

Make sunset plans now and let customers know what the timeline will look like. "Trust is the #1 value" at sfdc, right?

For Fly.io I need to create a docker container? Why would I want to do that when I can just push to Heroku?

I can see this argument but at the same time Dockerfiles for my preferred framework (Phoenix) are more or less muscle memory for me at this point. The better question is: why don't frameworks come with a Dockerfile by default? The effort:reward ratio on containerization is huge, it gives you your app in a runnable, dependency-free format that you can build reliably and deploy on an extremely diverse set of platforms.

Dependency free? Isn’t Docker a dependency itself? And it’s the most annoying one — no other dependency constantly keeps a core going at 15% on my machine, or considers not upgrading a premium feature, or incessantly interrupts my work with NPS pop ups even when I’m doing nothing related to Docker.

If anyone at Docker is reading this, I mark “100% no” when you interrupt me with pop up asking if I’d recommend your product to a friend when I’m in the middle of working on something entirely unrelated to your product. I don’t know anyone who wouldn’t.

Docker Desktop is a development dependency, but you can also use Podman or minikube. I just use Podman these days, I prefer it. The container format is all standard these days, you don’t actually need anything Docker to use it. Fargate and Fly don’t even actually run the container directly, they convert it to a VM with Firecracker first.

Running containers make me feel like I need production hardware on my development machine. It's slow, clunky, and uses too much memory. I'd rather boot it up without docker.

There's no requirement to use Docker while developing, it's just useful when you need to deploy.

> but they aren't operating at the same scale as Heroku.

As someone who said "I'm sure it can't get any worse" with heroku for many years and was proven wrong over and over, I genuinely don't know what you mean by this. Lots of stuff just doesn't work. Updated buildpacks don't get released on a useful timescale ("just make your own" isn't an answer). The platform is plagued by bizarre performance issues and noisy neighbors, and the pricing doesn't support it. In my time on Heroku, I couldn't break three nines of uptime one year entirely because of platform issues, including one incident where the DNS provider Heroku uses just stopped working in Israel (which Heroku gaslit me about for over a week). I don't know what "operating at scale" means to you, but if the service is consistently bad compared to the competition, it doesn't matter what scale they operate at. It's a meaningless metric.

> Render, fly, even Netlify

Pretty sure none of these can run any JVM applications. Heroku can, very easily.

They can, by using docker.

And yet, this is why Heroku is around. It is _still_ the easiest way to deploy your application to the cloud. Just do a git push and call it a day.. it has tons of integrations, can easily scale, has great backup and redundancy, integrated pipelines, review apps, great CLI..

People here underestimate the cost of wasting time setting up docker containers and fiddling with configuration files. Heroku is about delegating 90% of your Dev-Ops and actually focusing on your product and it pretty much works flawlessly with many stacks.

I looked at all the alternatives that people mentioned here and none of them hold a candle to Heroku (yes, even in its current degrading state). Perhaps eventually they will, but so far, I am not impressed.

Now if you excuse me, I have a product to build :)

Lol. So can my $2 VPS, then.