Live data from Hacker News

Heroku Class Action

herokuclassaction.com

31–40 of 78 posts

Re: Heroku Class Action

#31
post #27
post #25

My startup is heavily invested in and tied to Heroku. We don't have the resources right now to get off of the platform quickly, but plan to as soon as possible. Like Rapleaf, we have spent an enormous amount of effort optimizing and searching for the causes of latency, and overpay for dynos to reduce but not eliminate the chance of latency issues. Heroku has always told us it's our fault. While I have no interest in…

[deleted]

EDIT: I don't necessarily support a class action lawsuit against Heroku, but in the interest of conversation...

Scalability is not a magic knob you can twist as far as you want…

Isn't that the problem? That's Heroku's selling point is that scaling is basically a magic knob. Here are some of the things on their homepage right now:

    deploy and scale powerful apps

    Focus 100% on your code, and never think about servers,
    instances, or VMs again.

    Run any web or background process with any web framework
    or worker type.

    Scale distributed processes effortlessly with a single
    command. Easily scale to millions of users.
Your comment seems to be defending Heroku, by saying Heroku is lying.

Re: Heroku Class Action

#32
post #27

Earlier quoted context omitted.

[deleted]

EDIT: I don't necessarily support a class action lawsuit against Heroku, but in the interest of conversation... Scalability is not a magic knob you can twist as far as you want… Isn't that the problem? That's Heroku's selling point is that scaling is basically a magic knob. Here are some of the things on their homepage right now: deploy and scale powerful apps Focus 100% on your code, and never think about servers, i…

[deleted]

Re: Heroku Class Action

#33
post #27
post #25

My startup is heavily invested in and tied to Heroku. We don't have the resources right now to get off of the platform quickly, but plan to as soon as possible. Like Rapleaf, we have spent an enormous amount of effort optimizing and searching for the causes of latency, and overpay for dynos to reduce but not eliminate the chance of latency issues. Heroku has always told us it's our fault. While I have no interest in…

[deleted]

"Scalable way" as defined by the platform Heroku was built and marketed for is single threaded.

I won't argue that the lack of concurrency support in rails and ruby is not also a stupid horrible unacceptable choice - and I never understood why the rails community defended it.

Regardless, Heroku was originally built for and continues to market itself as a platform that can scale Rails by using intelligent routing, but it's quite clear that they can not.

Maybe you understand the above, though it seems you are just trolling rails for being single-threaded. This is not the place.

Re: Heroku Class Action

#34
This isn't some grassroots action lead by startup CTOs across the valley. This is just a lawyer searching for a lead plantiff. I find the site rather misleading, and ultimately trashy. (Disclaimer: I am personally opposed to class action lawsuits.)

Re: Heroku Class Action

#35

This is interesting, because I don't remember any similar class action lawsuits/attempts like this in the tech/SAAS sector, though I've often heard of threats. Have there been any similar attempts?

Right now there are a lot more lawyers in the US than there is honest work for them.

Not hard to see what's coming.

Re: Heroku Class Action

#36
post #25

My startup is heavily invested in and tied to Heroku. We don't have the resources right now to get off of the platform quickly, but plan to as soon as possible. Like Rapleaf, we have spent an enormous amount of effort optimizing and searching for the causes of latency, and overpay for dynos to reduce but not eliminate the chance of latency issues. Heroku has always told us it's our fault. While I have no interest in…

> We don't have the resources right now to get off of the platform quickly,

I hear people say this a lot but I believe it comes more from the emotion of fear than a rational consideration of the possibilities. For example, Amazon Elastic Beanstalk now supports Rails deployments that are just as easy as Heroku, and you retain 100% control over the underlying EC2/ELB/etc resources while having a nice management layer to help you out.

Re: Heroku Class Action

#37

Ok this is going too far. Did Heroku make a mistake? Yes. Did they mislead and lie to their customers? Yes. But is it worth pursuing a class action lawsuit that could ultimately ruin them - if not financially, but force their mgmt team to focus on this damn suit rather than fixing the damn problems? Hells no. I hope RapGenius is not the lead plaintiff in this, otherwise I will be very disappointed. I applaud them for…

They blatantly lied about how a core part of their service worked for years. It was raised to them previously and they didn't change the docs nor the way their system worked.

This negatively affected a lot of their customers in many ways (overspending on heroku, time wasted, lost customers and revenue).

When Heroku's customers have incurred significant costs and/or losses because of Heroku's false claims, I don't see why this is so inappropriate. We need to make companies accountable for their claims.

For context, I am a Heroku customer and have been significantly affected by all of this. I won't participate in the lawsuit but I can understand why others would.

Re: Heroku Class Action

#38
post #32

Earlier quoted context omitted.

EDIT: I don't necessarily support a class action lawsuit against Heroku, but in the interest of conversation... Scalability is not a magic knob you can twist as far as you want… Isn't that the problem? That's Heroku's selling point is that scaling is basically a magic knob. Here are some of the things on their homepage right now: deploy and scale powerful apps Focus 100% on your code, and never think about servers, i…

[deleted]

If you build your app in the correct way

That's interesting terminology to use, "the correct way". Heroku's own devcenter article on deploying Rails apps to Heroku [1] still recommends the thin webserver, which isn't concurrent, and therefore causes all the issues being discussed for any rails app. In other words, if you're using thin, it doesn't matter how you architected your app, it's not going to run in concurrent processes on one dyno. So I'll assume by "the correct way", you're referring to both building your app for concurrency and using unicorn as your webserver. Doing only one of those things will not work, both are necessary.

But their article only mentions unicorn only as an alternative, and up until recently their documentation actually said "We recommend thin" [2] over unicorn and that unicorn was possible but wasn't officially supported (EDIT: actually the most recent version of the article in wayback machine doesn't even mention unicorn on the page).

I wouldn't call using thin "naive", given that it's what Heroku's docs have recommended for a long time. I don't think it's fair to call customers of Heroku naive for not knowing that when Heroku says "easily scale" and "use thin", they are talking about two mutually exclusive possibilites.

[1] https://devcenter.heroku.com/articles/rails3

[2] http://web.archive.org/web/20120801214821/https://devcenter....

EDIT: Added quotes with references.

Re: Heroku Class Action

#39
post #36
post #25

My startup is heavily invested in and tied to Heroku. We don't have the resources right now to get off of the platform quickly, but plan to as soon as possible. Like Rapleaf, we have spent an enormous amount of effort optimizing and searching for the causes of latency, and overpay for dynos to reduce but not eliminate the chance of latency issues. Heroku has always told us it's our fault. While I have no interest in…

> We don't have the resources right now to get off of the platform quickly, I hear people say this a lot but I believe it comes more from the emotion of fear than a rational consideration of the possibilities. For example, Amazon Elastic Beanstalk now supports Rails deployments that are just as easy as Heroku, and you retain 100% control over the underlying EC2/ELB/etc resources while having a nice management layer t…

Honestly I have not looked into it so far and hope you're right. We also use a number of addons, though I don't think any would be too difficult to replicate.

Regardless, it's a significant amount of work for a startup with just a few engineers, perhaps a week of two of distraction. I expect a bunch of "how to migrate off of heroku" blog posts will be out there shortly.

Re: Heroku Class Action

#40
post #26
post #22

Earlier quoted context omitted.

The old bamboo stack has the same old intelligent routing, but the intelligence is only within each router. When the number of routers increased, the intelligence stopped mattering because concurrent requests were highly likely to not be handled by the same router, making the routing effectively random instead of intelligent. So what you suggest would be great, but unfortunately not possible.

I'll just repeat my previous comment: For $60,000 per month they can't create a mode where all your dynos are behind a single HAProxy with "intelligent" least-connections load balancing?

In other terms: "Damn, the hallways in this building are getting too crowded, lets add some more hallways and shit and lets add new rooms... Later: damn, this is getting complicated. Peopke are piling up in doorways, theyre losing patience and leaving (or being forced to leave to ease the congestion)... Wish there was something we could do!"

Wmf: "Build another building, geeez!"

Post reply on HN