Live data from Hacker News

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

blog.pardner.com

131–139 of 139 posts

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

#131

It’s your fault for not having a fault tolerant site that runs on another service provider. This is what happens when you put your eggs in one basket and that basket bursts into flames. If reliability is so important, make it a priority instead of just expecting stuff to work or for a more politically correct error message — which leads me to my next point: who cares about the ERROR message? The damage has been done…

Question: given that Heroku involves a certain amount of platform lock-in, how do you write a Heroku app that runs on another service provider?

It hardly makes sense if Heroku says "well, it's your fault for trusting us."

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

#132
post #71

Earlier quoted context omitted.

This is a poor response: Abusive, insulting and makes only a token effort to advance the discussion. Does the fact that it sits at the top of the page mean that it's the most highly rated? And in practical terms, it seems totally theoretical. In my experience, more information is always valuable. It's not a matter of shifting responsibility, it's a matter of understanding what the problem is and efficiently getting i…

woooosh OP was playing the role of the user. Paying customers don't care about the implementation details of the products they pay for. They only care about whether or not they work.

Leave it to paying customers to decide what they care about, and leave it to Heroku's paying customers to decide whether they care about the content of the error page.

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

#133
post #68

Earlier quoted context omitted.

When you go to a restaurant to get lunch, and they are closed due to a power failure, do you blame them?

I agree with the other commenter that the analogies are getting stretched but I'll bite: 1. You haven't paid them for anything yet. 2. Wrong question!!! It's an opportunity . If I showed up for lunch and despite power being out (probably on the entire block or neighborhood) the proprietors were set up outside making cold sandwiches next to a sign that said "Sorry, power's out so only egg salad" I'd be thrilled. Here…

Purely as a customer, I do not give a crap whether you make egg salad in an attempt to show your hustle and dedication. I am not thrilled because I do not go out for egg salad to begin with. If you are an awesome hustling entrepreneur, it does not make your egg salad taste any better to me. If the power is out, there is nothing you can do and I understand that and do not penalize you for it, if you normally provide me with good service.

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

#134
post #72
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…

How do you not blame Heroku? You are paying them a good chunk of money to handle not only hosting, but failover strategies, multiple locations, etc. If you have to worry about any of those things they aren't doing their job. That's like if you chose MySQL as the database, and then when an update had a huge bug that broke your site, you say "totally my fault that I don't have a version of the site that uses PostgreSQL…

To clarify part of this, Heroku doesn't have the same position as (say) a router manufacturer because they are offering an all-in-one 'platform'. And unlike MySQL, they are charging you a decent rate for using it.

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

#135
post #86

Earlier quoted context omitted.

Customers usually don't care about the reason for outage. They gave you money. If the service is running, good. If it's not, you screwed up. No matter what actually happened, you should've been prepared. Sad but true.

"No matter what actually happened, you should've been prepared." This is just plain false. Being prepared comes at a cost. If you over-prepare, then your customers have to pay more for no good reason, and they don't necessarily want to. You have to draw a line and make a judgement call. There are such things as natural (or political) disasters so serious that it would be extremely stupid to plan for them. And there a…

It is false. Most of the time, at least. But then again I wasn't expressing my opinion but a probable opinion of Your Regular Customer.

Yes, Heroku should put up a different error notification when the problem is on their side, but I doubt it would make that much of a difference in the eyes of the user.

That's all.

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

#137
post #121

Earlier quoted context omitted.

This is BS. Your users DO care. When our service is down for some reason, the ONLY question we get (like this one we got today) is - "Has the service been down recently? If so, no worries - it happens, just wanted to report and see if this is temporary or if it is just me." Having a "holy shit our entire service is down" message means your users dont' have to ask "is it just me?". That's a big difference. It has noth…

Showing enough information for your users to sensibly understand what they should do is important, but thats not what the article was about[1], it was about the application developer wanting to pass-the-buck when there application failed because of a Heroku error. This is really lame because, you chose to host on Heroku not your customers, so it is your fault. You can play pass-the-buck but as far as your customers a…

You say "pass the buck" I say "tell the truth." Heroku's current message says it's an "application error" even when it is not an application error. It is incorrect. And I suggested one simple way to correct it. They could word the message as they see fit, but platform_problem != application_error. What percent of customer grok/care about the difference is irrelevant... an incorrect error message should be corrected.

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

#138
post #110
post #20

Earlier quoted context omitted.

Frankly, I believe it certainly can matter. It may not make any difference to all clients, but some will draw a distinction between avoidable / unavoidable downtime. Rational clients understand they are not hiring demigods or living in some uptime utopia. However, they expect their service providers to adhere to best practices and make logical decisions. In this case it's Heroku, in another setting it might be a NetA…

Heroku going down isn't unavoidable downtime. It's clownshoes downtime.

That's a strong statement. Can you please elaborate?

Heroku is generally regarded as a reliable hosting solution. If it was a bargain basement alternative that was expected to fail randomly, then this would in fact be "clownshoes" downtime.

Building in full redundancy behind Heroku is possible, but non-trivial. They are after all being paid to provide a reasonably fault tolerant solution.

Therefore, while not literally unavoidable, it may not make good business sense for a venture to incur the additional expenses associated with implementing full redundancy. Most of their clients probably understand that downtime happens and will be perfectly content as long as every reasonable effort was made to keep the system online.

edited to add : Communication is key. Business relationships typically don't crumble due to aberrations like this (power outage, hosting provider going down, etc.). However, they do crumble if communication either doesn't occur, or the wrong information is conveyed. That is the crux of this discussion.

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

#139
I've seen so much blame in IT/systems/coding in the last 15 years that I can't recount it all. Anytime a vendor or service provider or consultant is involved, get ready for finger pointing when things go wrong (from both sides). I think many managers like being able to blame them and see this as a benefit of the relationship. Outside providers should just expect to be blamed for things they did not do and charge for that accordingly.
Post reply on HN