[Karunamon]

>It really disgusts me how quick people are to bite the hand that feeds them.

Really? Because it really disgusts me when a company:

    * Misrepresents their product (saying it's A when it's actually B)
    * Privately acknowledges this misrepresentation under the radar
    * Makes large and ridiculous amounts of bank on this misrepresentation (since you have to throw more dynos at the app to mitigate the lag caused by the misrouting.. and Heroku may be many things, but economical it isn't)
    * And on that note, provides very expensive monitoring and performance analysis tools that further perpetuate the misrepresentation!
    * And then force you to resort to litigation to get some portion of this huge mis-spent investment refunded. (Looking at the suit, this is all that's being asked for)

This wasn't a mistake on Heroku's part, this was calculated. And even if you accept that it was a mistake, the fact of the matter is that their negligence in this matter made them a hell of a lot of money.

This is definitely grounds for a suit.

[res0nat0r]

By misrepresents you mean that the end users didn't exactly understand how underlying architecture worked, didn't like the performance, but kept using the service anyway. If every customer I dealt with while working on the EC2 platform could sue because they didn't understand how every technical detail of AWS worked and they couldn't optimize for it...well there would be more lawyers employed by Jeff Bezos than engineers.

This lawsuit will go nowhere and it is sad that such a supposedly tech savvy crowd wants to bring out the pitchforks so fast. But I guess since Heroku has a lot of cash they are now the enemy since they've made it and they should be taken down.

[jacques_chester]

The problem is that Heroku made claims about their architecture and subsequent performance characteristics that were flatly untrue.

The further problem it looks as if they knew the claims were untrue.

These are not matters of internal consideration. They cut directly to the heart of the Heroku marketing material: "Write for our platform, our expensive secret sauce will make your stuff linearly scalable."

In which case people expect that it will be linearly scalable. Not exponentially anti-scalable.

[res0nat0r]

The same can be said for EC2. "Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change."

If my instances don't launch "quickly" or I've designed my app in such a way that it isn't 100% linery scalable I can now sue Amazon? You can't sue heroku for their marketing speak.

[Karunamon]

>You can't sue heroku for their marketing speak.

You can sue anyone for anything, success is not assured.

That bit of pedantry aside, Heroku led people on to believe that their queueing backend was intelligently distributing requests to nodes. Rather than randomly.

You are not allowed to argue this, as Heroku themselves acknowledged it!

Furthermore, they blatantly lied about it. From the rap genius article:

Heroku claims that though they received reports of unexplained latency over the past couple of years, they weren’t able to figure out the request queuing issue until they read the Rap Genius article. But there is evidence that Heroku knew about the problem for more than 2 years.

And the conclusion, also from the same article:

Based on Heroku's response so far, it appears their approach to fixing the problem is, “We promised you intelligent routing, we delivered random routing (which is worse than intelligent routing), so we're going to change our documentation to make it clear that we're only promising you random routing.”

This works for future customers, since once Heroku makes these documentation changes, everyone who signs up will understand exactly how routing works. But it does nothing to address the time and money that existing customers have spent over the past few years. What does Heroku owe them?

[res0nat0r]

Who's to say random routing doesn't qualify as "intelligent"? What if random routing is the most efficient routing schema for 99% of their users? Trying to sue because "intelligent" doesn't mean what you think it means isn't going to be very successful.

[Karunamon]

>Who's to say random routing doesn't qualify as "intelligent"?

Heroku themselves!

Again, they changed their documentation.

[Karunamon]

>By misrepresents you mean that the end users didn't exactly understand how underlying architecture worked

Uh.. no.

Heroku claimed to use intelligent routing, they used random routing. And then covered it up with their monitoring tools.

How in the name of crap can you blame this on the user?! Did you even read the Rap Genius writeup on this problem? If I were in their position, I would be utterly livid.

[res0nat0r]

I read the article. I wouldn't call it "covering up". It didn't explain everything going on, just like all kinds of things that go on behind the scenes everyday at AWS that users don't understand.

Define "intelligent routing". Maybe it is intelligent to route 85% of your requests to /dev/null. Can you sue because your performance sucks in your application use case? Most normal people eval their provider, try to get answers from support (which rapgenius have done here), and if the answers aren't up to snuff or the performance isn't whay they think it should be for what they are paying they move to another provider. They don't sue their provider for being "slow".

[joesb]

> Define "intelligent routing".

At least Heroku themselves define "intelligent routing" such that the request will only be given to the free Dynos. Their random routing does not do that.