Autoscaling Heroku workers is definitely a problem that people would like solved, but I see a few issues with trying to offer the solution as a SaaS. One, you're targeting developers. There are several github repos that do this kind of thing for free, and developers would know how to find and implement those. Two, those github repo's are going to do a better job of scaling because they can turn dynos/workers on and off instantly (e.g. as soon as a delayed job is done); much more cost effective than waiting up to 5 minutes to turn dynos/workers on/off. Three, you're targeting people that are trying to save money and _don't_ want to spend money.
As an aside, perhaps I (a cheap developer) am not in your target demographic, and you're really targeting folks with lots of Heroku apps and lots of money to spend. In which case you should be charging bundles more than $20/month.
Yep, I tried all the open source autoscaling heroku tools on Github. They were not easy to use, and had major problems (try them, you'll see!)
I think Heroku users value their time above all else. There's much cheaper ways to host your Rails apps. This tool allows Heroku users to save money while not having to spend days getting their autoscaling stuff working and tested.
>>I think Heroku users value their time above all else. There's much cheaper ways to host your Rails apps. This tool allows Heroku users to save money while not having to spend days getting their autoscaling stuff working and tested.
Then charge more!!!
I mean, you just said it yourself, your target market values time over money. Don't try to compete on price then. right? :)
I think this is a great idea however it would seem that this is more of a feature than a business. What happens when Heroku implements this feature themselves?
Hah, yep. I've been waiting for this feature from Heroku for over a year. Finally decided to just implement it ourselves. We then realized it might be nice to make it easy for other people.
We'd welcome Heroku implementing it! We actually think there's many other things we can add on top of Heroku that would be valuable so we're not too worried :-)
the landing page design really grabbed me, but I'm also really impressed with how simple and functional the actual dashboard is when you login. I had signed up with another beta autoscaling service, but I never heard back from them again. Best of luck with the service! I'll be rooting for ya.
I feel those who point "free" alternatives to Hero Scale have never actually tried to auto-scale their dynos. That gem is not a serious alternative.
David Dollar worked on it for one day and then never committed anything again (except for three months later, one little note: "This gem is a proof of concept and should not be used in production").
In my experience this gem crashes requests frequently (502 errors if I remember well). I don't know what's going on in that code - I wasted some time looking into it with no luck - but something in there is flawed.
Heroku is supposed to be simple. The idea of Heroku is you can focus on the design of your apps. Auto scaling turned out to be a huge pain and waste of time for me. I ran out of patience and moved my Ruby code to the Google App Engine.
This is a great idea. I looked at the auto scaling repositories on GitHub: 1) There wasn't a good solution for Rails 3 yet. 2) The GitHub repos were typically forks of existing repos (like for CollectiveIdea's Delayed Jobs) and therefore would not always be up to date. I wouldn't be too worried about Heroku implementing this (though I hope they do) because there isn't a direct incentive for them to save you money by auto scaling. I'm definitely going to try this out.
For an enterprise: autoscaling is either not a value add ("You can cut $40 a month off our $300 hosting bill? Absence of 'yay'.") or Really Freaking Hard And App Specific. SmugMug, as I recall, did a lot of work to dynamically spin up and shut down instances to minimize their bill (not a Heroku app, obviously), because their usage patterns consistently predicted high load for workers at certain times and low loads at other times.
For a ramen-munching startup: shaving $40 off our bill is very motivating. However, while we have dreams of scaling up, if you actually do it we're going to wig out when we see a four figure hosting bill. By the way, we're pathological customers who understand just enough of this to be a danger to ourselves, and we will blame you on the Internets when your system does exactly what we tell it to do.
I see your point, but why would a startup wig out when they scale? Presumably, revenues would scale with demand, so I would be quite grateful that my provider allowed me to satisfy the demand quickly and reliably...
This looks pretty cool. As a startup, any savings is worth it. Problem is, my app is too matured to try a few things that aren't proven / stable yet. I will wait to see if Heroku official includes this as an add-on. If so, I'm totally down.
I could implement it myself, but if it's coming and implemented by a team who's dedicated a lot more time than I can, then it's worth it.
Yes and no. Right now, if you're running at one dyno then you're pulled from the heroku "mesh" if you run idle. However, this is a free account so it's not really saving you any money.
Heroku doesn't auto manage your dyno and workers based on usage. You set dynos at 10, you're running 10 throughout the month. Likewise with workers.
Heroscale ramps your dynos and workers up/down based on necessity.
Since the site doesn't describe this in any detail: can you define 'necessity'? In other words, can you tell us anything about how and when your service decides to scale up or down, for dynos and for workers? And what have you done to avoid porpoising (to borrow an aviation term for lack of a better option coming to mind at the moment.)
Also, can your service scale workers all the way down to zero and then spark up the first worker upon the next job submission? Or can it only scale workers as low as one?
Good feedback, will put together a "wtf is it doing" page.
I'm familiar with the "pilot induced oscillations" from a first hand basis, scared the crap out of me. The desired scaling quality is quick ramp ups and then gradual, minute based ramp downs. This is to handle a sudden influx of traffic to the site. We don't just peg your dynos anytime something comes in. And the free accounts are set at 3 max, so don't worry about it blowing up your bill.
Dynos are ramped up fast as a response to incoming traffic and average wait times per request. I'm still refining this algorithm so feedback during beta would be awesome.
The algorithms for workers are slightly different than dynos since they feed of different info. The answer to your question is yes, it will scale down to zero if you have nothing in the queue. You can override this by setting server min and max thresholds for workers.
Drop us a line at contact AT heroscale DOT com and happy to talk more.
Thanks for the details. I will have a think about what other questions I might like to ask you and will try to fire them over to your contact email in the next day or so.
It would be if that error meant that the app couldn't handle the traffic. "App crashed" just means that their code is doing something weird and the thin process crashed.
As an aside, perhaps I (a cheap developer) am not in your target demographic, and you're really targeting folks with lots of Heroku apps and lots of money to spend. In which case you should be charging bundles more than $20/month.