6 ms·

I love this article but don't understand the conclusion. Heroku is dead as a doornail, of course. Salesforce's core product was on bare metal up to a couple ye

I love this article but don't understand the conclusion. Heroku is dead as a doornail, of course. Salesforce's core product was on bare metal up to a couple years ago. What they should have done is adopt Heroku as their internal Platform-as-a-Service. That would have solved three problems: 1) provided a ready and proven foundation for cloud adoption by Salesforce business units, 2) stimulated Heroku's product roadmap by giving it a very large and loyal design partner, and 3) eliminated the opportunity cost in terms of headcount, developer productivity, and poor imitation that came with the alternative "Falcon" aka "Hyperforce" project that became Salesforce's albatross and black hole for developer energy and goodwill going on 7+ years now.

zdragnar 7mo ago
> 2) stimulated Heroku's product roadmap by giving it a very large and loyal design partner This is very much a double-edged sword. I've seen products get killed because they had one outsized customer with outsized influence over the product design and made it too specific to that customer rather than building something for everyone the customer would have to adapt to. If they had, heroku would be very different today, since they aren't even doing enterprise contracts anymore (from what I saw of some other comments here). Maybe that would have been a good thing, maybe not.
ragall 7mo ago
> What they should have done is adopt Heroku as their internal Platform-as-a-Service From what I saw, Heroku was unsuitable for a serious large company. Deploy-on-push is a nice UX for a small company, but once you need something more structured, it wasn't enough.
- stickfigure 7mo ago
  That lacks imagination. There's no corporate workflow that can't ultimately translate to moving git tags.
  - ragall 7mo ago
    Perhaps, but why should one do it when it's a bad model ? Jury because it's possible ?
    - jeswin 7mo ago
      How did you objectively decide it's a bad model?
      - Daviey 7mo ago
        Because it's more enterprise to open a Service Now ticket and have Joe from IT upload the new content using FTP.
      - ragall 7mo ago
        I subjectively did based on my experience.
  - Bombthecat 7mo ago
    Except you want to track what went to production and what didn't and for how long
    - stickfigure 7mo ago
      Git is remarkably good at tracking history. CI systems are also great at showing history.
    - jononor 7mo ago
      Releases of a Heroku app is tracked by the platform, and both shown the the UI, in the CLI and available in the API.
- rubyn00bie 7mo ago
  Can you elaborate on your claim it’s not enough? PasS (platform as a service) has been transformative for modern infrastructure. Containers for better, or worse, have made deployments substantially “easier,” giving every org the ability to provide Heroku like services. But, Heroku provided this sort of ease, and more, long before containers ate the world. And regardless of containers themselves, I fail to see how something “more structured” would even exist. Deploy on push is still subject to being merged and everywhere I’ve worked has had no shortage of checks and approvals to merge.
- jbm 7mo ago
  I previously deployed stuff to Salesforce when I ran a very large Asia-Pacific Salesforce org. The previous way (prior to SFDX which was clearly influenced by Heroku) was terrible. 12 hour long deploys that end when one unit test times out-style terrible. No code history terrible. There is no way that Heroku was worse for integration. Whether they could have replaced APEX with Heroku is a different issue.

zdragnar 7mo ago

> 2) stimulated Heroku's product roadmap by giving it a very large and loyal design partner This is very much a double-edged sword. I've seen products get killed because they had one outsized customer with outsized influence over the product design and made it too specific to that customer rather than building something for everyone the customer would have to adapt to. If they had, heroku would be very different today, since they aren't even doing enterprise contracts anymore (from what I saw of some other comments here). Maybe that would have been a good thing, maybe not.

ragall 7mo ago

> What they should have done is adopt Heroku as their internal Platform-as-a-Service From what I saw, Heroku was unsuitable for a serious large company. Deploy-on-push is a nice UX for a small company, but once you need something more structured, it wasn't enough.

stickfigure 7mo ago
That lacks imagination. There's no corporate workflow that can't ultimately translate to moving git tags.
- ragall 7mo ago
  Perhaps, but why should one do it when it's a bad model ? Jury because it's possible ?
  - jeswin 7mo ago
    How did you objectively decide it's a bad model?
    - Daviey 7mo ago
      Because it's more enterprise to open a Service Now ticket and have Joe from IT upload the new content using FTP.
    - ragall 7mo ago
      I subjectively did based on my experience.
- Bombthecat 7mo ago
  Except you want to track what went to production and what didn't and for how long
  - stickfigure 7mo ago
    Git is remarkably good at tracking history. CI systems are also great at showing history.
  - jononor 7mo ago
    Releases of a Heroku app is tracked by the platform, and both shown the the UI, in the CLI and available in the API.
rubyn00bie 7mo ago
Can you elaborate on your claim it’s not enough? PasS (platform as a service) has been transformative for modern infrastructure. Containers for better, or worse, have made deployments substantially “easier,” giving every org the ability to provide Heroku like services. But, Heroku provided this sort of ease, and more, long before containers ate the world. And regardless of containers themselves, I fail to see how something “more structured” would even exist. Deploy on push is still subject to being merged and everywhere I’ve worked has had no shortage of checks and approvals to merge.
jbm 7mo ago
I previously deployed stuff to Salesforce when I ran a very large Asia-Pacific Salesforce org. The previous way (prior to SFDX which was clearly influenced by Heroku) was terrible. 12 hour long deploys that end when one unit test times out-style terrible. No code history terrible. There is no way that Heroku was worse for integration. Whether they could have replaced APEX with Heroku is a different issue.