[DeBraid]

The drama with Google has to be mentioned as major part of their company history.

They also had a famous fight with heroku

https://genius.com/James-somers-herokus-ugly-secret-annotate...

[nomilk]

Genius's investigation and analysis of Heroku's load balancing claims vs their actual practices was anything but "dickish", and it wasn't a "fight".

They produced an intelligent, thorough, and fair exposè of poor engineering practices by Heroku which were otherwise not documented (or worse, misleadingly documented), and which also benefited Heroku financially, since users would have to purchase many more dynos to get the expected performance - up to 50 times more if I recall correctly.

Genius didn't have to share any of their analysis. They could have simply shown it to Heroku and probably received a bunch of "hush" benefits to forget about the whole thing. The fact they bothered to polish it and open source it allowed others to benefit from their work and meant that even 8 years' later, someone like me can better plan hosting requirements and avoid falling into the trap they did.

Yes, Heroku's load balancing works the same way to this day, resulting in much higher costs to medium-large apps as well as huge degradations to end user experience as some users will randomly be routed to dynos with long queues despite others being completely idle! This is a huge waste of energy and bad for the environment too.

As a heavy Heroku user, I'm incredibly grateful for Genius's work on this issue!

[glenngillen]

That’s one interpretation of the events, motivations, and hypothetical alternative situations.

Or it’s simply that Heroku didn’t provide customers great visibility into a the issue at hand, that the best-in-class at the time 3rd party add-on that gave that visibility was misleading, and that architectural changes required to support a broader set of languages in a more distributed fashion introduced a change in behaviour that was not documented. The engineering best practice continues to be the same, which is why it is unchanged 8 years later: push long-running requests into an async flow. It’s both more scalable and more durable.

[jayzalowitz]

If you are capable of making this post, you are capable of self hosting rails on something closer to the metal.