Live data from Hacker News

Dear Heroku: Quit blaming all of us when you fail. Do this instead…

blog.pardner.com

41–50 of 139 posts

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#41
post #28

Earlier quoted context omitted.

Actually I do not disagree.... I make the platform choices, so i live with the results. However, IMO an error message that distinguishes between an "hosting" issue and an "app" issue is not only fair, it is in fact, meaningful data to (at least some) customers.

The people who care that it's a Heroku issue not app issue (hint: not many) have probably already heard about the Heroku outage. Everyone else will be confused about what the hell this "Heroku" thing is. That said, if they don't use appropriate error codes (maybe 502 or 504 for Heroku issues and 503 for app issues?) they should. But I don't think error messages should mention "Heroku" by name.

I think that's true with Heroku, but gets less true as providers get bigger. If you tell a user that your service is temporarily down "because Google is down", even a lot of regular people will know what that means, and not really blame you for it.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#42
post #24

As someone who was inconvenienced by the outage, and with no mitigation strategy in place, I DON'T blame Heroku. The weight is placed squarely on me (lone tech in our company) for not having researched how to distribute services alongside Heroku, or fall back to something else, or whatever the proper term is. I've been googling like mad since this morning, finding a few mostly-unanswered StackOverflow questions and a…

Even vendors that promise that, e.g. Amazon, aren't infallible.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#43
Quite off topic, but I'm always sad to see really poor scalability:

To my surprise, this blog post hit the top spot on HN at least briefly. My blog started throwing some app errors.

I've had a couple of hit HN stories on my blog without a problem, and it was hosted from my apartment on an old server with 256MB of RAM. Now, it is static pages served through nginx, but I'm pretty sure that a few thousand hits shouldn't require 10 Heroku dynos to not fall over.

Kids these days. (the mindset, not the age)

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#44
post #28

Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.

Actually I do not disagree.... I make the platform choices, so i live with the results. However, IMO an error message that distinguishes between an "hosting" issue and an "app" issue is not only fair, it is in fact, meaningful data to (at least some) customers.

Your customer wants to know whether it's you or Heroku because...? (There may be a legitimate business case for the distinction. Perhaps you can clarify.)

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#45

Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.

Continue in that vein, then if there is a natural disaster then it is their fault as well.

The information is useful. Heroku should provide it. We're done here.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#46
post #28

Earlier quoted context omitted.

Actually I do not disagree.... I make the platform choices, so i live with the results. However, IMO an error message that distinguishes between an "hosting" issue and an "app" issue is not only fair, it is in fact, meaningful data to (at least some) customers.

Why, do your users care?

You might be providing a service to people who would like to know what part of the chain broke. If hosting company A fails all the time, and that's visible to me as a technical user of service A, I would avoid hosting company A for anything that I happen to host. I'm not the average end user, but that information is still valuable to me, and I would think less of hosting company A, instead of service A.

By Heroku not listing when its their downtime, they are insulating their reputation as a hosting company from end users, at the expense of the customers already using them. It's a little shady.

I agree that the average end user would probably not care, but most not caring does not mean it's not valuable information to some people. So I see where the original poster is coming from.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#47
post #43

Quite off topic, but I'm always sad to see really poor scalability: To my surprise, this blog post hit the top spot on HN at least briefly. My blog started throwing some app errors. I've had a couple of hit HN stories on my blog without a problem, and it was hosted from my apartment on an old server with 256MB of RAM. Now, it is static pages served through nginx, but I'm pretty sure that a few thousand hits shouldn't…

I doubt it requires anywhere near 10 dynos, normally I just run 1, and I suspect 2 or 3 dynos would work fine today... but since 10 dynos only costs 45 cents per hour, and it's presumably just for an hour or two, I simply threw two handfuls at the problem and went back to my actual work. Handling a one-time spike didn't seem like something worth optimizing when I could throw the price of a cup of coffee at the problem.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#49
post #42
post #24

As someone who was inconvenienced by the outage, and with no mitigation strategy in place, I DON'T blame Heroku. The weight is placed squarely on me (lone tech in our company) for not having researched how to distribute services alongside Heroku, or fall back to something else, or whatever the proper term is. I've been googling like mad since this morning, finding a few mostly-unanswered StackOverflow questions and a…

Even vendors that promise that, e.g. Amazon, aren't infallible.

The gist that I'm getting from a few places seems to be: Have separate hosts/service providers, and do the load balancing yourself, or make switch yourself, when one fails. I've yet to find many detailed examples, though, as most similar articles deal with load balancing with in your own locally-managed network, or co-located set of machines.

The more generalized "Cloud plus Dedicated" fallback/load balancing seems fairly involved, and raises a lot of other questions, but at least I've got a path to follow now. Also would be more expensive, as a backup server might just be hanging around doing nothing at times.

Then again, it would pay for itself in satisfied customers after just a single event.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#50
If Heroku is down, and I discover that site X that I want to visit was hosted on Heroku, I'm more likely to hear that Heroku is back up or that site X is back up, than just that site X is back up. I also can skip checking any other sites I know to be using Heroku during the outage. It is therefore mildly useful data to a user.
Post reply on HN