9 ms·

People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database

People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick). Want to scale up? Click a button, you're now scaled up. Want a entire review system with staging links and everything? Setup the review process line and you're done. Everything is beyond easy and requires very little actual knowledge. You don't need a bunch of silly yml configs or knowledge of how containers work. You just pick a button and setup your git repo and it deploys your app. Want to SSH in? Install the CLI tools and type heroku ps:exec, want to see the logs? Go to the logs error to type heroku logs. They have a perfect dev environment, fairly decent CLI tooling, bulletproof battle tested deployment setup (minus they fact they go down basically every 2 days if you aren't on the paid plans), and very little you need to understand.

gwbas1c 6y ago
On top of that: It's very easy to create an open-source project and put a "Deploy on Heroku" button right on the Github page.
sytse 6y ago
I agree Heroku has the perfect dev environment, not much to improve there. We’re trying to make the perfect production environment. Most people end up hosting at a hyper cloud (edit: like AWS). We’re trying to make the app on a hyper cloud in production as easy as Heroku is in development. We’re still building that, it is t done by any means. And the article doesn’t do a good job of showing what we are trying to make easier. Setting up managed services on AWS is time consuming and that is what we want to solve. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template https://gitlab.com/gitlab-org/5-minute-production-app/deploy... The contents of the blog post doesn’t warrant the title. We regret it.
- capableweb 6y ago
  What does "hyper cloud" mean in this context? Searching only shows a headset with the name "HyperX Cloud" but I'm sure that's not what you are referring to.
  - boleary-gl 6y ago
    In this context "Hyper Cloud" means one of the major cloud vendors - AWS, GCP, Azure.
  - parasubvert 6y ago
    Hyperscaler = Google, Amazon, Microsoft, Alicloud
  - sytse 6y ago
    In the West it means AWS, Azure, or GCP. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template#hypercloud https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
- fnomnom 6y ago
  but isnt that what AWS does with elastic beanstalk? elastic beanstalk always seemed to me as a "heroku with more dials"
  - boleary-gl 6y ago
    I think that lots of the clouds will have their own offering, but having an open source based offering across clouds is what we're going for. Also it's very early stages - but the goal would to be better than Beanstalk
    - rad_gruchalski 6y ago
      As long as it is faster than gitlab itself, sure. Every time I go to the hosted gitlab, I cringe. I like the product but the whole thing is sooo slow. First, 5 seconds wasted to "check if my browser supports gitlab", then the lag on every click. Hopefully your heroku will have a better experience than your gitlab.
      - brodock 6y ago
        Isn't that "5 seconds" a cloudflare thing?
        rad_gruchalski 6y ago
        Why should I care? I click sign in button, which takes me to https://gitlab.com/users/sign_in https://gitlab.com/users/sign_in and I see the message. Who cares where it comes from.
  - runako 6y ago
    Oh my goodness, no. Beanstalk is a very poor clone of Heroku. Context: I have used Elastic Beanstalk in real production apps for years. For my Rails side project, figured I would use Beanstalk instead of Heroku so that I'm using the same platform (although I have also used Heroku in prod settings). Quick summary is the AWS tutorial for launching their Rails sample app in Elastic Beanstalk doesn't work at all. I though maybe my Rails install was borked somehow, so I tried launching a sample app at Heroku. Worked on the first try. Heroku really spends time making sure everything works out of the box, and that's what you're paying for.
- Trasmatta 6y ago
  It would be helpful if the post was a bit clearer on that. FWIW, I've used Heroku as a production environment at multiple jobs. It works great there as well. The primary issue in my experience is cost. If you need to serve a lot of traffic, Heroku gets very expensive very fast. But it's still easy to use. That cost can be offset by the fact that you may not need to hire a dedicated devops engineer right away, and your other developers spend much less time dealing with server setup and debugging.
  - sytse 6y ago
    I agree the blog post isn’t clear on that. I agree a simple production app can be great on Heroku. However besides being costly it is also hard when you want a managed service that isn’t on the platform. There are other reasons, https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template#hypercloud https://gitlab.com/gitlab-org/5-minute-production-app/deploy... lists 9 in total. While a production app on Heroku isn’t hard it isn’t trivial either. We’re trying to make the 5 minute production app faster to set up than Heroku for production apps by automatically configuring a bunch of services. We’re not there yet but that is the goal.
    - edoceo 6y ago
      We hear you. But it looks like you're losing focus.
    - llbeansandrice 6y ago
      > Hypercloud Why list all of these reasons and then make no use of them in the infrastructure code? The code doesn't scale, has huge downtime, you recommend granting Admin access to the CI jobs, the free tier is only for the first year the account exists. The purpose and focus of this repo isn't clear to me at all.
- gjhr 6y ago
  I am not a Heroku user so cannot assess how this compares to their offering but as someone who spends ~4 hours a day looking at Terraform and the AWS console this does not look "production" quality at all. * The web app is deployed to a single AWS EC2 instance which cannot be scaled horizontally. * The web server is deployed from an AMI filter, when a new AMI matches this filter there will be downtime to redeploy the instance entirely. * There does not seem to be any considerations for patching the web server. * Everything shares a single security group. Although this is probably fine because you are using managed services for redis and postgres its still weird to allow port 443/22 from anywhere on your database. I'd be happy to be proven wrong on these points. There also seems to be quite a bit of assumed knowledge about AWS and Terraform. You mention the free tier a lot, but that only applies for the first year since your AWS sign up. After the free tier is up this infra is going to cost $40+ per month.
- llbeansandrice 6y ago
  > See https://gitlab.com/gitlab-org/5-minute-production-app/deploy https://gitlab.com/gitlab-org/5-minute-production-app/deploy... This code is awful. > Terraform which has the following advanatges: > 1. Terraform is the most popular What an awful reason to pick a technology. I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? None of the others are particularly compelling for a "5-minute" setup either. > 5. You avoid the cost and complexity of Kubernetes But k8s is popular so why not use that? >If you are not sure what correct permissions are then use AdministratorAccess as a temporay solution. Aside from all of the spelling errors in the README I hate this advice. You have the infrastructure code, you know what's going to be provisioned. Create an IAM policy and add it to the code or README. Telling people to give their little app Admin access is a terrible idea. In addition to all of the issues another commenter mentioned. This is hardly "production" quality code or infrastructure. Production should be able to scale, that's the entire point of using HyperCloud providers.
  - throwaway823882 6y ago
    > I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? They don't really mean "because it's popular", they mean because it's the industry incumbent and de-facto standard. You can't use anything else, because nothing else makes sense. You need to standardize on one tool, especially if your infrastructure / teams grow. If you want to deploy something on AWS using an API with a minimal graph of dependencies, there's just Terraform. Pulumi isn't totally free, you have to write more code, there aren't nearly as many providers, not as many people know it, etc. There's basically nothing else. As a result, it's "popular".
- jrochkind1 6y ago
  What are you saying is lacking in heroku's production environment? "Setting up managed services on AWS is time consuming and that's what we want to solve." Right, that's exactly what heroku has solved. Are you saying you don't think heroku has solved it as well as you have or you can? > The contents of the blog post doesn’t warrant the title. We regret it. OK, what SHOULD the title be, what's it actually about? Trying to build a heroku competitor?
ksajadi 6y ago
Totally agree. The ease was the reason for us as well (although now running Cloud 66). This post seems a bit disingenuous. Gitlap + Terraform + AWS != Heroku.
jack_riminton 6y ago
"there is no CLI involved" Well that's annoying, seeing as I've just done everything else on the CLI
- Trasmatta 6y ago
  You can do the majority of Heroku interactions on the CLI if you prefer.
  - jack_riminton 6y ago
    I know, and I do The quote was from the blog. Making it seem like doing things off the CLI was a plus point Right now I have a git alias that does everything, including pushing to my heroku master, in one command. Why would I want to go off the CLI?
    - deleted 6y ago
      [deleted]
emdowling 6y ago
Agree with all of this. It is just such an easy environment to work in. Pipelines, team management, etc are a breeze. When it gets too expensive, Cloud66 is a great migration path and offers the best of both worlds. It's a fairly simply transition too.
- rgharris 6y ago
  Heroku CI, Pipelines, and Review Apps made for an awesome continuous deployment setup for me in the past. Easy promotion of builds to staging/production after your tests pass and apps created automatically per pull request for testing in an environment just like all of your other environments.
rcarmo 6y ago
Yep. Heroku's workflow is why I created Piku (https://github.com/piku/piku https://github.com/piku/piku). I wanted something dead easy for deployments and updates when iterating.
- ctas 6y ago
  Interesting. On Dokku installing postgres and redis takes just two commands. How would the equivalent look on piku?
  - rcarmo 6y ago
    There isn't one. Piku does not concern itself with back-end stores, only apps (it was designed to run on ARM hardware, without containers and with minimal packages).
sytse 6y ago
I fully agree, this should have been about it production app, not a development app which is already great on Heroku. Also see this post by the author https://news.ycombinator.com/item?id=26555617 https://news.ycombinator.com/item?id=26555617
- detaro 6y ago
  What difference is the "production app" distinction supposed to make? Its not clear from neither the article nor the linked comment. If it's an attempt to suggest that Heroku isn't suitable for production use, that's going to need a lot of argument backing it up.
  - sytse 6y ago
    A production app has stateful services that retain data between deployments. The ambition of the 5 minute production app is to make this faster than doing it on Heroku. The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.
    - jrochkind1 6y ago
      Typical heroku apps have services like postgres and redis that maintain state between deployments. This is very typical, and trivial to provision. Still not sure what you mean. Are you sure you are at all familiar with heroku?
k__ 6y ago
User experience is often laughed at or even overlooked, but this is why Firebase and Heroku are used! I had a mainframes course in university and people from IBM would tout how everything we do today was already invented by them decades ago. But yeah, when you tried to use their stuff you had to jump through so many hoops, that you lost your motivation half the way.
- alecbz 6y ago
  I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are. My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting something working quickly and easily.
  - jack_riminton 6y ago
    It must be something to do with forgetting how hard things are for novices Reminds me of the famous old HN comment about Dropbox
    - ulisesrmzroche 6y ago
      That one never gets old.
    - colesantiago 6y ago
      https://en.wikipedia.org/wiki/Curse_of_knowledge https://en.wikipedia.org/wiki/Curse_of_knowledge
  - j4yav 6y ago
    It’s from getting caught out when they’ve hidden the setting that is causing your site to be down in the name of making things easier. I’m not saying it’s right or wrong, but that’s where it comes from.
jelling 6y ago
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)
stickfigure 6y ago
People use Heroku (and Google App Engine) because - if your app fits the model, and most do - you can completely skip ops/devops. Your whole team can go to sleep without a pager. You spend your life building features that customers care about instead of mucking with config files.
- SoreGums 6y ago
  Yes!! Being part of a large org, nobody cares about the ops bit, leadership/product/dev mgrs just want features deployed!!! It's very obvious that the sooner we can abstract all the ops away the leaner we'll be.
throwaway894345 6y ago
> You don't need a bunch of silly yml configs The "silly yml configs" are the things I care about the most. I don't want to have to remember how to reproduce my environment in order to stamp out a new one or recover an existing one. I'm all for removing the seldom-needed complexity, but "reproducibility" is the concern around which I build my whole tech stack--I largely avoid VM-based stacks precisely because the reproducibility story is so much flakier than the reproducibility story for containers. I imagine you can use something like Terraform for Heroku, but pretending that you can ignore reproducibility altogether is... really something. Maybe the parent means that "yaml is silly" and Heroku has a better reproducibility story in some other format (maybe graphical?)?
- lumost 6y ago
  There is a gap here in apps that (typical) developers need. There is absolutely a market for footguns that work 95% of the time as long as the developer pays some attention to it. If you did all of the things required of launching a cloud level service for every signup page... few things would get done. There are some web apps which only need to exist for a few weeks or less before they can be tossed in a fire. If I'm a startup with limited customer expectations of reliability and I just want to see if my friends would use my product demo... a point and click solution sounds pretty great.
  - throwaway894345 6y ago
    Absolutely, I didn't mean to imply that there was no room for MVPs (as well as signup pages, demos, etc), but I didn't understand that the thread was limited in scope to MVPs. Is it?
- detaro 6y ago
  they have them if you want. But you don't need them, which is the getting started quickly bonus.
tyingq 6y ago
They did update just under the title... "Update: This post does not live up to its original title We are building a better Heroku. It shows my own personal experience and reflects poorly on competitors. I am sorry about that."
- ralph84 6y ago
  No, it reflects poorly on GitLab. The competitor comes out looking just fine.

gwbas1c 6y ago

On top of that: It's very easy to create an open-source project and put a "Deploy on Heroku" button right on the Github page.

sytse 6y ago

I agree Heroku has the perfect dev environment, not much to improve there. We’re trying to make the perfect production environment. Most people end up hosting at a hyper cloud (edit: like AWS). We’re trying to make the app on a hyper cloud in production as easy as Heroku is in development. We’re still building that, it is t done by any means. And the article doesn’t do a good job of showing what we are trying to make easier. Setting up managed services on AWS is time consuming and that is what we want to solve. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template https://gitlab.com/gitlab-org/5-minute-production-app/deploy... The contents of the blog post doesn’t warrant the title. We regret it.

capableweb 6y ago
What does "hyper cloud" mean in this context? Searching only shows a headset with the name "HyperX Cloud" but I'm sure that's not what you are referring to.
- boleary-gl 6y ago
  In this context "Hyper Cloud" means one of the major cloud vendors - AWS, GCP, Azure.
- parasubvert 6y ago
  Hyperscaler = Google, Amazon, Microsoft, Alicloud
- sytse 6y ago
  In the West it means AWS, Azure, or GCP. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template#hypercloud https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
fnomnom 6y ago
but isnt that what AWS does with elastic beanstalk? elastic beanstalk always seemed to me as a "heroku with more dials"
- boleary-gl 6y ago
  I think that lots of the clouds will have their own offering, but having an open source based offering across clouds is what we're going for. Also it's very early stages - but the goal would to be better than Beanstalk
  - rad_gruchalski 6y ago
    As long as it is faster than gitlab itself, sure. Every time I go to the hosted gitlab, I cringe. I like the product but the whole thing is sooo slow. First, 5 seconds wasted to "check if my browser supports gitlab", then the lag on every click. Hopefully your heroku will have a better experience than your gitlab.
    - brodock 6y ago
      Isn't that "5 seconds" a cloudflare thing?
      - rad_gruchalski 6y ago
        Why should I care? I click sign in button, which takes me to https://gitlab.com/users/sign_in https://gitlab.com/users/sign_in and I see the message. Who cares where it comes from.
- runako 6y ago
  Oh my goodness, no. Beanstalk is a very poor clone of Heroku. Context: I have used Elastic Beanstalk in real production apps for years. For my Rails side project, figured I would use Beanstalk instead of Heroku so that I'm using the same platform (although I have also used Heroku in prod settings). Quick summary is the AWS tutorial for launching their Rails sample app in Elastic Beanstalk doesn't work at all. I though maybe my Rails install was borked somehow, so I tried launching a sample app at Heroku. Worked on the first try. Heroku really spends time making sure everything works out of the box, and that's what you're paying for.
Trasmatta 6y ago
It would be helpful if the post was a bit clearer on that. FWIW, I've used Heroku as a production environment at multiple jobs. It works great there as well. The primary issue in my experience is cost. If you need to serve a lot of traffic, Heroku gets very expensive very fast. But it's still easy to use. That cost can be offset by the fact that you may not need to hire a dedicated devops engineer right away, and your other developers spend much less time dealing with server setup and debugging.
- sytse 6y ago
  I agree the blog post isn’t clear on that. I agree a simple production app can be great on Heroku. However besides being costly it is also hard when you want a managed service that isn’t on the platform. There are other reasons, https://gitlab.com/gitlab-org/5-minute-production-app/deploy-template#hypercloud https://gitlab.com/gitlab-org/5-minute-production-app/deploy... lists 9 in total. While a production app on Heroku isn’t hard it isn’t trivial either. We’re trying to make the 5 minute production app faster to set up than Heroku for production apps by automatically configuring a bunch of services. We’re not there yet but that is the goal.
  - edoceo 6y ago
    We hear you. But it looks like you're losing focus.
  - llbeansandrice 6y ago
    > Hypercloud Why list all of these reasons and then make no use of them in the infrastructure code? The code doesn't scale, has huge downtime, you recommend granting Admin access to the CI jobs, the free tier is only for the first year the account exists. The purpose and focus of this repo isn't clear to me at all.
gjhr 6y ago
I am not a Heroku user so cannot assess how this compares to their offering but as someone who spends ~4 hours a day looking at Terraform and the AWS console this does not look "production" quality at all. * The web app is deployed to a single AWS EC2 instance which cannot be scaled horizontally. * The web server is deployed from an AMI filter, when a new AMI matches this filter there will be downtime to redeploy the instance entirely. * There does not seem to be any considerations for patching the web server. * Everything shares a single security group. Although this is probably fine because you are using managed services for redis and postgres its still weird to allow port 443/22 from anywhere on your database. I'd be happy to be proven wrong on these points. There also seems to be quite a bit of assumed knowledge about AWS and Terraform. You mention the free tier a lot, but that only applies for the first year since your AWS sign up. After the free tier is up this infra is going to cost $40+ per month.
llbeansandrice 6y ago
> See https://gitlab.com/gitlab-org/5-minute-production-app/deploy https://gitlab.com/gitlab-org/5-minute-production-app/deploy... This code is awful. > Terraform which has the following advanatges: > 1. Terraform is the most popular What an awful reason to pick a technology. I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? None of the others are particularly compelling for a "5-minute" setup either. > 5. You avoid the cost and complexity of Kubernetes But k8s is popular so why not use that? >If you are not sure what correct permissions are then use AdministratorAccess as a temporay solution. Aside from all of the spelling errors in the README I hate this advice. You have the infrastructure code, you know what's going to be provisioned. Create an IAM policy and add it to the code or README. Telling people to give their little app Admin access is a terrible idea. In addition to all of the issues another commenter mentioned. This is hardly "production" quality code or infrastructure. Production should be able to scale, that's the entire point of using HyperCloud providers.
- throwaway823882 6y ago
  > I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? They don't really mean "because it's popular", they mean because it's the industry incumbent and de-facto standard. You can't use anything else, because nothing else makes sense. You need to standardize on one tool, especially if your infrastructure / teams grow. If you want to deploy something on AWS using an API with a minimal graph of dependencies, there's just Terraform. Pulumi isn't totally free, you have to write more code, there aren't nearly as many providers, not as many people know it, etc. There's basically nothing else. As a result, it's "popular".
jrochkind1 6y ago
What are you saying is lacking in heroku's production environment? "Setting up managed services on AWS is time consuming and that's what we want to solve." Right, that's exactly what heroku has solved. Are you saying you don't think heroku has solved it as well as you have or you can? > The contents of the blog post doesn’t warrant the title. We regret it. OK, what SHOULD the title be, what's it actually about? Trying to build a heroku competitor?

ksajadi 6y ago

Totally agree. The ease was the reason for us as well (although now running Cloud 66). This post seems a bit disingenuous. Gitlap + Terraform + AWS != Heroku.

jack_riminton 6y ago

"there is no CLI involved" Well that's annoying, seeing as I've just done everything else on the CLI

Trasmatta 6y ago
You can do the majority of Heroku interactions on the CLI if you prefer.
- jack_riminton 6y ago
  I know, and I do The quote was from the blog. Making it seem like doing things off the CLI was a plus point Right now I have a git alias that does everything, including pushing to my heroku master, in one command. Why would I want to go off the CLI?
  - deleted 6y ago
    [deleted]

emdowling 6y ago

Agree with all of this. It is just such an easy environment to work in. Pipelines, team management, etc are a breeze. When it gets too expensive, Cloud66 is a great migration path and offers the best of both worlds. It's a fairly simply transition too.

rgharris 6y ago
Heroku CI, Pipelines, and Review Apps made for an awesome continuous deployment setup for me in the past. Easy promotion of builds to staging/production after your tests pass and apps created automatically per pull request for testing in an environment just like all of your other environments.

rcarmo 6y ago

Yep. Heroku's workflow is why I created Piku (https://github.com/piku/piku https://github.com/piku/piku). I wanted something dead easy for deployments and updates when iterating.

ctas 6y ago
Interesting. On Dokku installing postgres and redis takes just two commands. How would the equivalent look on piku?
- rcarmo 6y ago
  There isn't one. Piku does not concern itself with back-end stores, only apps (it was designed to run on ARM hardware, without containers and with minimal packages).

sytse 6y ago

I fully agree, this should have been about it production app, not a development app which is already great on Heroku. Also see this post by the author https://news.ycombinator.com/item?id=26555617 https://news.ycombinator.com/item?id=26555617

detaro 6y ago
What difference is the "production app" distinction supposed to make? Its not clear from neither the article nor the linked comment. If it's an attempt to suggest that Heroku isn't suitable for production use, that's going to need a lot of argument backing it up.
- sytse 6y ago
  A production app has stateful services that retain data between deployments. The ambition of the 5 minute production app is to make this faster than doing it on Heroku. The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.
  - jrochkind1 6y ago
    Typical heroku apps have services like postgres and redis that maintain state between deployments. This is very typical, and trivial to provision. Still not sure what you mean. Are you sure you are at all familiar with heroku?

k__ 6y ago

User experience is often laughed at or even overlooked, but this is why Firebase and Heroku are used! I had a mainframes course in university and people from IBM would tout how everything we do today was already invented by them decades ago. But yeah, when you tried to use their stuff you had to jump through so many hoops, that you lost your motivation half the way.

alecbz 6y ago
I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are. My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting something working quickly and easily.
- jack_riminton 6y ago
  It must be something to do with forgetting how hard things are for novices Reminds me of the famous old HN comment about Dropbox
  - ulisesrmzroche 6y ago
    That one never gets old.
  - colesantiago 6y ago
    https://en.wikipedia.org/wiki/Curse_of_knowledge https://en.wikipedia.org/wiki/Curse_of_knowledge
- j4yav 6y ago
  It’s from getting caught out when they’ve hidden the setting that is causing your site to be down in the name of making things easier. I’m not saying it’s right or wrong, but that’s where it comes from.

jelling 6y ago

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)

stickfigure 6y ago

People use Heroku (and Google App Engine) because - if your app fits the model, and most do - you can completely skip ops/devops. Your whole team can go to sleep without a pager. You spend your life building features that customers care about instead of mucking with config files.

SoreGums 6y ago
Yes!! Being part of a large org, nobody cares about the ops bit, leadership/product/dev mgrs just want features deployed!!! It's very obvious that the sooner we can abstract all the ops away the leaner we'll be.

throwaway894345 6y ago

> You don't need a bunch of silly yml configs The "silly yml configs" are the things I care about the most. I don't want to have to remember how to reproduce my environment in order to stamp out a new one or recover an existing one. I'm all for removing the seldom-needed complexity, but "reproducibility" is the concern around which I build my whole tech stack--I largely avoid VM-based stacks precisely because the reproducibility story is so much flakier than the reproducibility story for containers. I imagine you can use something like Terraform for Heroku, but pretending that you can ignore reproducibility altogether is... really something. Maybe the parent means that "yaml is silly" and Heroku has a better reproducibility story in some other format (maybe graphical?)?

lumost 6y ago
There is a gap here in apps that (typical) developers need. There is absolutely a market for footguns that work 95% of the time as long as the developer pays some attention to it. If you did all of the things required of launching a cloud level service for every signup page... few things would get done. There are some web apps which only need to exist for a few weeks or less before they can be tossed in a fire. If I'm a startup with limited customer expectations of reliability and I just want to see if my friends would use my product demo... a point and click solution sounds pretty great.
- throwaway894345 6y ago
  Absolutely, I didn't mean to imply that there was no room for MVPs (as well as signup pages, demos, etc), but I didn't understand that the thread was limited in scope to MVPs. Is it?
detaro 6y ago
they have them if you want. But you don't need them, which is the getting started quickly bonus.

tyingq 6y ago

They did update just under the title... "Update: This post does not live up to its original title We are building a better Heroku. It shows my own personal experience and reflects poorly on competitors. I am sorry about that."

ralph84 6y ago
No, it reflects poorly on GitLab. The competitor comes out looking just fine.