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?
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.
> you can do the same thing by having .... and a bunch of scripts with which you can start new instances in seconds.
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.
At Heroku, free applications get idled out when no request comes in for a while. As a result, when the first request comes in after some time, it can take a few seconds to find a piece of iron to run the process on, run it, and hook up all the tubes.
The advantage is you get to run arbitrary code rather than, say, serve static pages, though.
I'm sure someone will correct me if I'm wrong, but I'm pretty sure that's only true if you're on the free level (i.e. only running 1 dyno). Otherwise, your process is always active.
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?