However, I never understood why people like Heroku ... it's like renting instances on EC2, only 10 times more expensive.
Of course, people then start enumerating a whole bunch of stuff that they don't have to worry about when using Heroku. However, when starting out, configuring a server is just like configuring your localhost development environment. You just have to start with something that works, then gradually keep learning.
Heroku doesn't provide anything to me other than an unreasonable free quota that's basically useless for serving anything other than static content (poorly) ... even GitHub does a better job with their static pages option, since GitHub's servers don't go sleeping when unused.
False. I'd suggest you take a look at their architecture overview. It's not like renting instances on EC2 at all because dynos != virtual machines. http://www.heroku.com/how
"Of course, people then start enumerating a whole bunch of stuff that they don't have to worry about when using Heroku. However, when starting out, configuring a server is just like configuring your localhost development environment. You just have to start with something that works, then gradually keep learning."
This may be fine for some, but for those that _don't_ want to worry about sysadmin work and want to focus on rapid iteration, Heroku makes more sense. Besides, it's not the initial configuration that is the most painful, it's the maintenance and cost associated with managing your own virtual instances, and infrastructure pieces such as reverse proxies, caches, etc.
"since GitHub's servers don't go sleeping when unused."
I'm not even sure what this means. Can you elaborate?
dynos != virtual machines
Well, yeah, a small instance on EC2 is the equivalent of 20 dynos, maybe more.What you do get with dynos is scaling out when you need it, however you can do the same thing by having a prepared AMI, a load-balancer and a bunch of scripts with which you can start new instances in seconds.
focus on rapid iteration
I really do think that sysadmin work and rapid iteration are orthogonal. When you're starting out, administrating you servers is something that hardly takes up any time ... but the flexibility is priceless. ... infrastructure pieces such as reverse
proxies, caches, etc.
Well, Cedar doesn't have Varnish anymore -- and IMHO, setting up Varnish is just a day's work, which includes configuring it for your own needs.Yes, Heroku takes that away by (1) giving you a useless Varnish configuration OR (2) eliminating Varnish altogether, as they couldn't figure out a common denominator.
Also, I know that "reverse proxies" and "caches" sound bad ass, but it's really a solved problem.
Of course, infrastructure can get very hairy further down the road, but that's what I've been saying -- when starting out, you just need Passenger or mod_wsgi, as in one "sudo aptitude install" or "gem install" away. It took me a day's work to configure an EC2 instance, including a deployment workflow with Capistrano (for the first time ever). That server is still running just fine, with no further maintenance.
And if small deployments is not Heroku's strength, than what is? If you've got a successful app that needs special infrastructure care and you can't afford a good developer/sysadmin to take care of it, then you're doing it wrong.
Right, so if you already have everything you need, you don't need to buy it. This argument is similar to "I don't need water when I'm not thirsty". Hardly compelling.
> administrating you servers is something that hardly takes up any time
Sure if your servers never get any traffic, or you never scale.
> It took me a day's work to configure an EC2 instance, including a deployment workflow with Capistrano (for the first time ever). That server is still running just fine, with no further maintenance.
Right, it took me less than a minute to do that with heroku, and with less dependencies (on capistrano). When I decide my app needs an extension written in node, that is another minute on deployment for me, and another day for you. I'd gladly compete on those terms :)
> And if small deployments is not Heroku's strength, than what is? If you've got a successful app that needs special infrastructure care and you can't afford a good developer/sysadmin to take care of it, then you're doing it wrong.
This is just your highly opinionated view of things. Who ever said anything about 'special infrastructure'... Heroku deal in commodity infrastructure (that's the point). You also never successfully made the point that small deployments are not their strength.
The advantage is you get to run arbitrary code rather than, say, serve static pages, though.
But I'm with you that I find it a bit too costly as I know (and actually like) configuring my stuff.