Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
1–10 of 437 posts
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#2I am only going to suggest a small edit -> s/Postgres can’t/Heroku's Postgres can't/
PG can scale up pretty well on a single box, but scaling PG on AWS can be problematic due to the disk io issue, so I suspect they just don't do it. I'd love to be corrected :)
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#3Shame that this seems to have been flagged off the homepage before a reasonable discussion can ensue
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#4Someone from Heroku really needs to weigh in on this.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#5This should be more prominent. I want to love Heroku, and am sure that I could.
But really, throwing in the towel at intelligent routing and replacing it with "random routing" is horrific, if true.
It's arguable that the routing mesh and scaling dynamics of Heroku are a large part, if not -the- defining reason for someone to choose Heroku over AWS directly.
Is it a "hard" problem? I'm absolutely sure it is. That's one reason customers are throwing money at you to solve it, Heroku.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#6Shame that this seems to have been flagged off the homepage before a reasonable discussion can ensue
[deleted]
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#7This is something that I have been struggling with the past long while. Very troublesome when a dyno cycles itself (like they always will at least every 24 hours), as the routing layer continues to send it requests, resulting in router level "Request Timeouts" if it takes too long to restart.
Especially difficult to diagnose when the queue and wait time in your logs are 0. What is the point of these in the logs if it never waits or queues?
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#8We ran into this exact same problem at Impact Dialing. When we hit scale, we optimized the crap out of our app; our New Relic stats looked insanely fast, but Twilio logs told us that we were taking over 15 seconds to respond to many of their callbacks. After spending a few weeks working with Heroku support (and paying for a dedicated support engineer), we moved to raw AWS and our performance problems disappeared. I want to love Heroku, but it doesn't scale for Rails apps.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#9i don't think some details of the argument hold. it alleges that you need more dynos to get the same throughput. but that's not true once you have sufficient demand to keep a queue of about sqrt(n) (i think - someone who knows more theory than me can correct me) in size on the dyno (where you have n dynos). because at that point all dynos will be running continuously, and the throughput will be the same with either routing.
the average latency will be higher, though (and the spread in latency larger).
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#10Shame that this seems to have been flagged off the homepage before a reasonable discussion can ensue
People invested too much time/money/energy into Heroku and get defensive when a problem needs discussion? Just guessing.