6 ms·

AWS may be the gold standard for hosting but I still recommended most startups start with Heroku for their hosting, especially since they add the code pipelines

AWS may be the gold standard for hosting but I still recommended most startups start with Heroku for their hosting, especially since they add the code pipelines. The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.

ksec 6y ago
Amazon really should have bought Heroku instead of Salesforces. I continue to wonder why Salesforce bought it in the first place. And if they are willing to unload it.
- detaro 6y ago
  Heroku not being AWS might be a feature. I'm not sure if AWS wouldn't try and integrate them and "break" something in the process. Whereas now, they still get money from it (Heroku runs on AWS) and can offer their own "alternatives" as part of the larger AWS offering.
  - ksec 6y ago
    The idea would be to allow Heroku working independently while offering their solution at literally AWS cost (without all the discount), or even AWS Graviton2 cost. This would pretty much directly compete with Linode and DO on a value proposition. And a lock in to AWS ecosystem.
    - darkr 6y ago
      Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. Many of the Heroku addons also run on AWS, so customers may lock themselves into without knowing it. Additionally, customers are free to further lock themselves into the AWS ecosystem via "private space"/VPC peering. And they have a competitor to Linode/DO in their Lightsail offering (though how successful it is in competition I'm not sure)
      - darkwater 6y ago
        > Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. I fail to understand this. If Heroku is on AWS, Heroku is selling its services at price X. AWS is getting from Heroku Y money, where X > Y (or it should at least, if Heroku is not operating at loss). If Amazon owns Heroku it could sell its services still for X, eating Heroku's margin plus the margin it already had on the AWS offering.
        darkr 6y ago
        > I fail to understand this Parent was proposing that AWS sell Heroku services at cost. As you say, my point was it doesn’t make sense
        ksec 6y ago
        Heroku Buy AWS services at standard AWS Price (X) * (Substantial) Discount. HeroKu Sell their services at (Y) where currently Y is >(X). If they had acquired Heroku by Selling it at AWS Price (X), Amazon is still earning where they previously were not earning from those heavy Discount. At the expense of the Operational Cost of Heroku Team. And the benefits of further lock in and additional market segment which is currently not very well served by AWS.
      - sprite 6y ago
        Did not even know VPC peering was a thing. In the past I've often used Amazon RDS with Heroku Web servers for hosting Rails apps. For my current project I initially started out with Aurora Serverless which is VPC only, so I thought my web servers also had to be in the same VPC, so I decided to use Elastic Beanstalk instead of Heroku. I do wish Amazon had an offering like Heroku. While Elastic Beanstalk works pretty good it's nowhere near as nice or easy to use as Heroku. It has gotten a bit better with Amazon Linux 2 [Procfile, platform hooks], but still leaves a lot to be desired. I wish I could scale up/down faster like you can with Heroku. There is probably a way to improve it, but right now the way it's set up any deploy, config change, etc bundles the gems and precompiles the assets which take a while. So deploy/scale up take around 8-10 minutes. It's been a while since I've used Heroku but from what I remember it's pretty much instant to add more dynos. I also ran into a couple of other annoying issues with EB. 1. There is a bug if using Amazon Linux 2 Ruby 2.7 deploying a RoR app where assets are not precompiled on configuration changes. It was an easy fix, just needed to add a script to .platform/confighooks/predeploy but it should have just worked. 2. When migrating to Amazon Linux 2 I deployed a version of the app that needed some code changes to work on Amazon Linux 2. There is no way to disable rollback on failed deploy on EB. Setting the "Ignore Health Check" option to true does not help here. I ended up in a situation where I needed to both push a code update and update some environment variables. However any code update I would push would fail because of the missing environment variables and rollback and any configuration change to update the environment variables would rollback because the current code had an error. I ended up having to tear down the environment and recreate it to get out of this loop. 3. Another minor issue is the Monitoring/Health dashboard. It will show warning/degraded/severe during scaling operations. For example when you trigger a scale down event it will complain: "Environment health has transitioned from Ok to Warning. ELB processes are not healthy on 1 out of 6 instances. ELB health is failing or not available for 1 out of 6 instances." Like of course it's not responding, the autoscaling group just terminated it. I feel like Elastic Beanstalk really could be a Heroku competitor if AWS cared enough to put the work into it. It just needs some polish and quality of life improvements, but I guess this way they still make their money and Heroku has a good business middle-man'ing it. I'm wondering if perhaps I would be better off using ECS or EKS, or if that's what AWS wants me to use hence why they are not putting much effort in EB.
  - blacktriangle 6y ago
    Heroku not being AWS might be a feature, but Heroku being Salesforce is straight-up terrifying. I'm probably not moving my apps off Heroku anytime soon simply because they're running just fine maintenance free, but I'm not going to risk running any future apps on a Salesforce platform.
    - phxrsg 6y ago
      Not sure I follow this. Salesforce bought Heroku over a decade ago and Heroku is still improving in its areas of expertise, with no signs of changing that. If anything, Salesforce has been moving more of its core developer experiences over to the Heroku model rather than trying to make Heroku more Salesforce-y.
      - macintux 6y ago
        After a short exposure to SFMC I can see why someone would be concerned about the impact they would have on Heroku, but it is good to hear there are reasons for optimism.
        phxrsg 6y ago
        Funnily enough, SFMC was also an acquisition, and it was acquired after Heroku. SFMC is easily the worst Salesforce project from a dev experience / integration point of view, agreed there.
granshaw 6y ago
In terms of the raw pieces yes but AWS UX (or lack of it) leaves a lot to be desired. It's basically – "Here! Here's the raw pieces and API – have at it!" and you have to build or bring in external tooling to use it seamlessly. There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.
- laurent92 6y ago
  Yes. I have spent $4000 on consultants to set up our AWS project and it’s still not easy as “git remote add prod ssh://heroku.com/my-app”. This “git push” is a killer feature — maybe it doesn’t really make sense security-wise or in a real architecture, but it makes it very sexy.

ksec 6y ago

Amazon really should have bought Heroku instead of Salesforces. I continue to wonder why Salesforce bought it in the first place. And if they are willing to unload it.

detaro 6y ago
Heroku not being AWS might be a feature. I'm not sure if AWS wouldn't try and integrate them and "break" something in the process. Whereas now, they still get money from it (Heroku runs on AWS) and can offer their own "alternatives" as part of the larger AWS offering.
- ksec 6y ago
  The idea would be to allow Heroku working independently while offering their solution at literally AWS cost (without all the discount), or even AWS Graviton2 cost. This would pretty much directly compete with Linode and DO on a value proposition. And a lock in to AWS ecosystem.
  - darkr 6y ago
    Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. Many of the Heroku addons also run on AWS, so customers may lock themselves into without knowing it. Additionally, customers are free to further lock themselves into the AWS ecosystem via "private space"/VPC peering. And they have a competitor to Linode/DO in their Lightsail offering (though how successful it is in competition I'm not sure)
    - darkwater 6y ago
      > Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. I fail to understand this. If Heroku is on AWS, Heroku is selling its services at price X. AWS is getting from Heroku Y money, where X > Y (or it should at least, if Heroku is not operating at loss). If Amazon owns Heroku it could sell its services still for X, eating Heroku's margin plus the margin it already had on the AWS offering.
      - darkr 6y ago
        > I fail to understand this Parent was proposing that AWS sell Heroku services at cost. As you say, my point was it doesn’t make sense
        ksec 6y ago
        Heroku Buy AWS services at standard AWS Price (X) * (Substantial) Discount. HeroKu Sell their services at (Y) where currently Y is >(X). If they had acquired Heroku by Selling it at AWS Price (X), Amazon is still earning where they previously were not earning from those heavy Discount. At the expense of the Operational Cost of Heroku Team. And the benefits of further lock in and additional market segment which is currently not very well served by AWS.
    - sprite 6y ago
      Did not even know VPC peering was a thing. In the past I've often used Amazon RDS with Heroku Web servers for hosting Rails apps. For my current project I initially started out with Aurora Serverless which is VPC only, so I thought my web servers also had to be in the same VPC, so I decided to use Elastic Beanstalk instead of Heroku. I do wish Amazon had an offering like Heroku. While Elastic Beanstalk works pretty good it's nowhere near as nice or easy to use as Heroku. It has gotten a bit better with Amazon Linux 2 [Procfile, platform hooks], but still leaves a lot to be desired. I wish I could scale up/down faster like you can with Heroku. There is probably a way to improve it, but right now the way it's set up any deploy, config change, etc bundles the gems and precompiles the assets which take a while. So deploy/scale up take around 8-10 minutes. It's been a while since I've used Heroku but from what I remember it's pretty much instant to add more dynos. I also ran into a couple of other annoying issues with EB. 1. There is a bug if using Amazon Linux 2 Ruby 2.7 deploying a RoR app where assets are not precompiled on configuration changes. It was an easy fix, just needed to add a script to .platform/confighooks/predeploy but it should have just worked. 2. When migrating to Amazon Linux 2 I deployed a version of the app that needed some code changes to work on Amazon Linux 2. There is no way to disable rollback on failed deploy on EB. Setting the "Ignore Health Check" option to true does not help here. I ended up in a situation where I needed to both push a code update and update some environment variables. However any code update I would push would fail because of the missing environment variables and rollback and any configuration change to update the environment variables would rollback because the current code had an error. I ended up having to tear down the environment and recreate it to get out of this loop. 3. Another minor issue is the Monitoring/Health dashboard. It will show warning/degraded/severe during scaling operations. For example when you trigger a scale down event it will complain: "Environment health has transitioned from Ok to Warning. ELB processes are not healthy on 1 out of 6 instances. ELB health is failing or not available for 1 out of 6 instances." Like of course it's not responding, the autoscaling group just terminated it. I feel like Elastic Beanstalk really could be a Heroku competitor if AWS cared enough to put the work into it. It just needs some polish and quality of life improvements, but I guess this way they still make their money and Heroku has a good business middle-man'ing it. I'm wondering if perhaps I would be better off using ECS or EKS, or if that's what AWS wants me to use hence why they are not putting much effort in EB.
- blacktriangle 6y ago
  Heroku not being AWS might be a feature, but Heroku being Salesforce is straight-up terrifying. I'm probably not moving my apps off Heroku anytime soon simply because they're running just fine maintenance free, but I'm not going to risk running any future apps on a Salesforce platform.
  - phxrsg 6y ago
    Not sure I follow this. Salesforce bought Heroku over a decade ago and Heroku is still improving in its areas of expertise, with no signs of changing that. If anything, Salesforce has been moving more of its core developer experiences over to the Heroku model rather than trying to make Heroku more Salesforce-y.
    - macintux 6y ago
      After a short exposure to SFMC I can see why someone would be concerned about the impact they would have on Heroku, but it is good to hear there are reasons for optimism.
      - phxrsg 6y ago
        Funnily enough, SFMC was also an acquisition, and it was acquired after Heroku. SFMC is easily the worst Salesforce project from a dev experience / integration point of view, agreed there.

granshaw 6y ago

In terms of the raw pieces yes but AWS UX (or lack of it) leaves a lot to be desired. It's basically – "Here! Here's the raw pieces and API – have at it!" and you have to build or bring in external tooling to use it seamlessly. There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.

laurent92 6y ago
Yes. I have spent $4000 on consultants to set up our AWS project and it’s still not easy as “git remote add prod ssh://heroku.com/my-app”. This “git push” is a killer feature — maybe it doesn’t really make sense security-wise or in a real architecture, but it makes it very sexy.