Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

rapgenius.com

Post reply on HN
Print view View original

431–437 of 437 posts

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#431

Post by donavanm »

jeremyjh wrote: post #430
donavanm wrote: post #418

Earlier quoted context omitted.

No, lbs don't inspect established streams. The lb will periodically send requests to a known uri as a health heck instead. The problem is when the health check uri isn't indicative of availabilty. (Hint: it never is) Nope, don't do this either. Unless you like getting pages because things are working?

You can configure a LB to inspect layer 7 - in HAProxy this is done with an observe directive. Error 500s would then take the member out of a pool. You are right that the health check of a static file may put it right back into the pool, but you can give it a slow rise value so that it waits a few minutes to do that. I'm not saying this is easy to get right but it is definitely possible to at least reduce the frequen…

Yes, all things are possible. You'll also have to keep state and track rates. Otherwise a very low error rate could down all of your backend hosts.

But you're now running a stateful l7 application proxy. That's waaaaaay more expensive than a tcp proxy with asynchronous checks.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#433

Post by lectrick »

vicks711 wrote: post #287
nsrivast wrote: post #262

OP is a friend of mine, and when I first heard of his problem I wondered if there might be an analytical solution to quantify the difference between intelligent vs naive routing. I took this problem as an opportunity to teach myself a bit of Queueing Theory[1], which is a fascinating topic! I'm still very much a beginner, so bear with me and I'd love to get any feedback or suggestions for further study. For this exam…

I cant stop myself from saying this. You wrote all this instead of doing what?

Maybe he's off work? Maybe he's "decompressing" from a hard problem at his job? Maybe you should STFU and enjoy the free information you are getting?

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#434

Post by SnootyMonkey »

themgt wrote: post #269
nsrivast wrote: post #262

OP is a friend of mine, and when I first heard of his problem I wondered if there might be an analytical solution to quantify the difference between intelligent vs naive routing. I took this problem as an opportunity to teach myself a bit of Queueing Theory[1], which is a fascinating topic! I'm still very much a beginner, so bear with me and I'd love to get any feedback or suggestions for further study. For this exam…

As someone building a Heroku Cedar-esque PaaS[1], here's the problem with your analogy: back in Aspen/Bamboo days (and what a lot of people still think of as "PaaS"), Heroku was like this (i.e your app was the one-a-time cashier, and Heroku's "routing mesh" setup checkout lanes and routed customers to your cashiers intelligently). Now however, Heroku lets you build your own checkout lane, so you can run apps with sin…

This whole we can't optimize for Rails anymore seems like a red herring. Dumb (random) routing is dumb routing. It doesn't matter if you have single threaded Rails or Django stack or highly concurrent Node.js or Erlang serving requests, if you distribute the requests randomly you're not going to efficiently use your resources and the Heroku "promise" of spinning up a 2nd dyno and getting 100% more concurrency is just not true.

All it changes is the details of the analysis, not the core finding. It makes the problem not as worse, but it's still pretty bad, and it's worse the more uneven your traffic is (in terms of how long each request takes to service).

All apps, even Unicorn, JRuby, Node.js, Erlang, etc. would benefit from something better than random routing.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#435

Post by vicks711 »

lectrick wrote: post #433
vicks711 wrote: post #287

Earlier quoted context omitted.

I cant stop myself from saying this. You wrote all this instead of doing what?

Maybe he's off work? Maybe he's "decompressing" from a hard problem at his job? Maybe you should STFU and enjoy the free information you are getting?

Maybe he is like so unemployed. Maybe he got his ass fued at work. Maybe you should shove a menorah up your back side and enjoy the free sensation.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#436

Post by Uchikoma »

Terretta wrote: post #347
Uchikoma wrote: post #345

~$20,000 sounds like a lot of money, they would need at least $100M a year in revenue to justify this number. This will be a major challenge if they want to grow profitable after the $15M VC money runs out. I'd assume they'd get the same for $5000 in rented servers which would free up enough money - outside of the valley - to have an DevOps and another developer.

Not following. Why do you say they need $100 million a year in revenue to justify $240K (00.25% of revenue) in hosting expenses? For an online biz, 10% - 50% isn't uncommon for profitable businesses. Many "virtual" companies (online only) do fine at 80%.

Otherwise you do not have enough traffic to justify $240k.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#437

Post by mcguire »

bambax wrote: post #412
mcguire wrote: post #407

Earlier quoted context omitted.

Note: I think we have different referents for "OP" here; bombax's is, I think, the whining customer; while shabble's is the pompous CEO. Me, I'm the swarthy pirate. Arrrh.

Upvoted, although it's bambax, not bombax ;-)

I'm having trouble reading around the eye patch.
Post reply on HN