13 ms·

Heroku down for production and staging apps

29 points by julioademar 13y ago

julioademar 13y ago
I still dream of the day they'll let us set up different availability zones. Not that I'm sure this wouldn't occur, mind you.
- sync 13y ago
  Dynos already run in different availability zones: https://devcenter.heroku.com/articles/production-check https://devcenter.heroku.com/articles/production-check You can take that a step further by running dynos in the European (eu-west-1) region: https://devcenter.heroku.com/articles/regions https://devcenter.heroku.com/articles/regions
  - julioademar 13y ago
    That's still in Beta though.
    - kxu 13y ago
      I'm running a production webapp since May on the Heroku EU region, not a scratch since then. It's a Beta suited for production apps since February: "Beta Testers, Heroku Europe is ready to begin running your production apps! Create an app in the region: $ heroku create --region eu Then add add-ons, deploy, and scale as usual. Please note we're still adding capacity in this area, so contact us if you expect to run more than 30 dynos or do more than 500 reqs/second on any app in Europe. As always, private betas should be considered confidential. Please don’t tweet, blog, or talk about this feature publicly until we announce it ourselves. Documentation: https://devcenter.heroku.com/articles/regions https://devcenter.heroku.com/articles/regions Questions & feedback: eu-beta@heroku.com Best, The Heroku Team"
      - richardwhiuk 13y ago
        "Please don’t tweet, blog, or talk about this feature publicly until we announce it ourselves." - but commenting on Hacker News is fine :p
        bjeanes 13y ago
        It's no longer a private beta... https://blog.heroku.com/archives/2013/4/24/europe-region https://blog.heroku.com/archives/2013/4/24/europe-region
  - 1qaz2wsx3edc 13y ago
    > Multiple dynos are also more likely to run on different physical infrastructure (for example, separate AWS Availability Zones), further increasing redundancy. It's not guaranteed. As I understand it, it's random. And as for regions. They only help you locate content to a closer region. You cannot use them for balancing/redundancy. As any data or third party add-on you use, will manage it's data in it's own specific zone. Thus creating latency issues.
- gabrtv 13y ago
  If you need deeper control of your application platform infrastructure, you should check out something like http://deis.io/ http://deis.io/. You can run a private Heroku in any EC2 region, zones, etc. Running your own PaaS is not for the faint of heart -- and Heroku certainly saves you time and headache -- but it's nice to have a private PaaS option that is Heroku compatible.
crashoverdrive 13y ago
I'd be curious to see the numbers of how often Heroku pushes code to production, and also how often those pushes break the build.
- julioademar 13y ago
  Well, it may not be their fault: http://status.aws.amazon.com/ http://status.aws.amazon.com/
  - crashoverdrive 13y ago
    Sorry, what I meant was that I wasn't suggesting it was their fault, I was merely reminded of my own curiosity of wanting to build a better product but not wanting to break what a ton of customers are using and paying a lot of money for
- oliverdavenport 13y ago
  Is this issue not to do with the AWS problems?
  - justinsb 13y ago
    For some reason, that story seems to have fallen off the front page, so people may not know that the root cause is not Heroku: https://news.ycombinator.com/item?id=6380772 https://news.ycombinator.com/item?id=6380772
webbruce 13y ago
Yeah, seems to be Amazon, not Heroku this time.
- chubot 13y ago
  Note from last time: https://status.heroku.com/incidents/151 https://status.heroku.com/incidents/151 "This post will reference the AWS services that we use behind the scenes so that we can be very specific. Note that although we will be discussing various AWS service failures, we don't blame them for what our customers experienced in any way. Heroku takes 100% of the responsibility for the downtime affecting our customers last week." In other words, they shouldn't be exposing AWS outages to users (although as as long as they use a single cloud provider that's impossible to avoid in general.)

29 points by julioademar 13y ago

I still dream of the day they'll let us set up different availability zones. Not that I'm sure this wouldn't occur, mind you.

sync 13y ago
Dynos already run in different availability zones: https://devcenter.heroku.com/articles/production-check https://devcenter.heroku.com/articles/production-check You can take that a step further by running dynos in the European (eu-west-1) region: https://devcenter.heroku.com/articles/regions https://devcenter.heroku.com/articles/regions
- julioademar 13y ago
  That's still in Beta though.
  - kxu 13y ago
    I'm running a production webapp since May on the Heroku EU region, not a scratch since then. It's a Beta suited for production apps since February: "Beta Testers, Heroku Europe is ready to begin running your production apps! Create an app in the region: $ heroku create --region eu Then add add-ons, deploy, and scale as usual. Please note we're still adding capacity in this area, so contact us if you expect to run more than 30 dynos or do more than 500 reqs/second on any app in Europe. As always, private betas should be considered confidential. Please don’t tweet, blog, or talk about this feature publicly until we announce it ourselves. Documentation: https://devcenter.heroku.com/articles/regions https://devcenter.heroku.com/articles/regions Questions & feedback: eu-beta@heroku.com Best, The Heroku Team"
    - richardwhiuk 13y ago
      "Please don’t tweet, blog, or talk about this feature publicly until we announce it ourselves." - but commenting on Hacker News is fine :p
      - bjeanes 13y ago
        It's no longer a private beta... https://blog.heroku.com/archives/2013/4/24/europe-region https://blog.heroku.com/archives/2013/4/24/europe-region
- 1qaz2wsx3edc 13y ago
  > Multiple dynos are also more likely to run on different physical infrastructure (for example, separate AWS Availability Zones), further increasing redundancy. It's not guaranteed. As I understand it, it's random. And as for regions. They only help you locate content to a closer region. You cannot use them for balancing/redundancy. As any data or third party add-on you use, will manage it's data in it's own specific zone. Thus creating latency issues.
gabrtv 13y ago
If you need deeper control of your application platform infrastructure, you should check out something like http://deis.io/ http://deis.io/. You can run a private Heroku in any EC2 region, zones, etc. Running your own PaaS is not for the faint of heart -- and Heroku certainly saves you time and headache -- but it's nice to have a private PaaS option that is Heroku compatible.

crashoverdrive 13y ago

I'd be curious to see the numbers of how often Heroku pushes code to production, and also how often those pushes break the build.

julioademar 13y ago
Well, it may not be their fault: http://status.aws.amazon.com/ http://status.aws.amazon.com/
- crashoverdrive 13y ago
  Sorry, what I meant was that I wasn't suggesting it was their fault, I was merely reminded of my own curiosity of wanting to build a better product but not wanting to break what a ton of customers are using and paying a lot of money for
oliverdavenport 13y ago
Is this issue not to do with the AWS problems?
- justinsb 13y ago
  For some reason, that story seems to have fallen off the front page, so people may not know that the root cause is not Heroku: https://news.ycombinator.com/item?id=6380772 https://news.ycombinator.com/item?id=6380772

webbruce 13y ago

Yeah, seems to be Amazon, not Heroku this time.

chubot 13y ago
Note from last time: https://status.heroku.com/incidents/151 https://status.heroku.com/incidents/151 "This post will reference the AWS services that we use behind the scenes so that we can be very specific. Note that although we will be discussing various AWS service failures, we don't blame them for what our customers experienced in any way. Heroku takes 100% of the responsibility for the downtime affecting our customers last week." In other words, they shouldn't be exposing AWS outages to users (although as as long as they use a single cloud provider that's impossible to avoid in general.)