Show HN: Dynosaur, An autoscaler for Heroku using Google Analytics Live • Hacker News Board

Re: Show HN: Dynosaur, An autoscaler for Heroku using Google Analytics Live

#21

Post by werkshy » Wed, Jan 22, 2014, 10:08 PM UTC

oceanplexian wrote: post #17

I'm curious why people put so much effort into scaling Heroku when you could outperform the maximum number of Dynos with only a handful of AWS instances for a fraction the price. It doesn't make sense. We're literally working around a problem that shouldn't exist.

We certainly don't use Heroku for the price. I've got a fair amount of experience running distributed apps on AWS and I have found that Heroku do provide a lot of value-added services on top (from deployment to database provisioning). For us, the best reason to use Heroku is that when AWS has a problem, Heroku can actually do something about it. Try calling AWS support when a whole availability zone just went down!

Of course, we are a Rails shop who have been on Heroku since we launched, so Heroku is really tailor made for us. If you're happy on raw AWS, good for you. Every hour I'm not thinking about AWS is an hour I can be writing a feature for our 10-month-old startup. The extra cost of Heroku is negligible when viewed in that light.

Re: Show HN: Dynosaur, An autoscaler for Heroku using Google Analytics Live

#22

Post by hayksaakian » Thu, Jan 23, 2014, 1:53 AM UTC

sergiotapia wrote: post #10

So I'm curious, how many users per dyno are needed for a typical CRUD rails app?

You can get a lot out of 1 dyno.

On two dynos you can have 1 do background jobs and 1 server content

obviously it varies, but you don't inherently need many.

Re: Show HN: Dynosaur, An autoscaler for Heroku using Google Analytics Live

#23

Post by zer0defex » Thu, Jan 23, 2014, 6:12 AM UTC

werkshy wrote: post #16

spydertennis wrote: post #13

Doesn't it make more sense to scale based on New Relic response times? Why are you guys using # of users? Depending on the page they are requesting and how the requests are clustered that could produce vastly inferior results.

We find that neither New Relic nor Analytics gives the full picture: some of our pages are heavily cached, others (e.g checkout processing) are computationally expensive, database heavy and communicate with other systems (e.g payment processors) that can be a big bottleneck. Both New Relic and GA tend to just average those together (although with GA you can create new views that focus on specific pages). You are righ…

Nice work, looks pretty solid. If you want to offload the responsibility of determining which GA metric events signify a potential spike, you could abstract it out and instead make the plugin use GA intelligence event alerts setup by your analytics team. This would help keep the respective subject-matter experts in their realms of expertise ideally allowing for a more on-going tailored approach to what, where, and how can trigger scaling fluctuations and the dev team isn't responsible for on-going management of the scaling trigger rules (well, to a certain extent).

Just a thought. I know you abstracted it out the way you did so as not to tie it to just GA, but if GA is your analytics platform of record, it could be worth pursuing. Cheers!

Re: Show HN: Dynosaur, An autoscaler for Heroku using Google Analytics Live

#24

Post by geemus » Thu, Jan 23, 2014, 3:49 PM UTC

willcodeforfoo wrote: post #12

It's kind of surprising that Heroku hasn't cracked this nut on their own. Perhaps it isn't in their best interest to scale down? Scalability certainly is often touted as one of the benefits of "the cloud".

Unfortunately auto-scaling is incredibly application specific. It would be a great feature, but it seems likely to be quite difficult to make a particular solution that is useful to more than a small subset of users. You can get some sense of this from the other comments above (ie how analytics wouldn't be a good scaling metric for them).