Personally - I prefer Linode to Heroku, sure there is more of my time consumed with sys admin, but I like having full control over my platform & setup, rather than having it virtually dictated to me. I'm always open to change but this strategy has served me very well for almost 3 years now.
Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
11–20 of 437 posts
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#12So the issue here is two-fold:
- It's very hard to do 'intelligent routing' at scale.
- Random routing plays poorly with request times with a really bad tail (median is 50ms, 99th is 3 seconds)
The solution here is to figure out why your 99th is 3 seconds. Once you solve that, randomized routing won't hurt you anymore. You hit this exact same problem in a non-preemptive multi-tasking system (like gevent or golang).
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#13Randomized routing isn't all bad. In fact, if Heroku were to switch from purely random routing to minimum-of-two random routing, they'd perform asymptotically better [1].
[1]: http://www.eecs.harvard.edu/~michaelm/postscripts/mythesis.p...
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#14Shame that this seems to have been flagged off the homepage before a reasonable discussion can ensue
Hmm seems to be back on the homepage again, not seen that before
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#15Given that ElasticBeanstalk has support for rails now, does Heroku still have any advantage over AWS for a new startup?
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#16This explains why some of my benchmarking tools gave very different and sometimes weird results when figuring out how many dynos our application needed.
As this blogpost also states Heroku really need to keep their documentation up to date. I sometimes stumble across something old referring to an old stack, or something contradicting.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#17rails server -p $PORT
rake jobs:work
Webrick and DJ
No procfile? No Unicorn or Puma? No worker process or threads defined
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#18Rap Genius is employing a classic rap-mogul strategy: start a beef
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#19I 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 :)
It has to deal with the number of open connections to postgresql, not disk IO. You don't want to have 4,000 connections open at once (unless you were using a connection balancer, but that would only work in transaction mode).
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#20Wow. I suspect Rap Genius has the dollars now where it's totally feasible for them to go beyond Heroku, but it still might not be the best use of their time. But if they have to do it, they have to do it.
OTOH, having a customer have a serious problem like this AND still say "we love your product! We want to remain on your platform", just asking you to fix something, is a pretty ringing endorsement. If you had a marginal product with a problem this severe, people would just silently leave.