4 ms·

Interesting... I wonder if this makes Google App Engine more appropriate for internal apps for Google Apps customers? For quick/easy personal hacking/developm

by jedc 15y ago

Interesting... I wonder if this makes Google App Engine more appropriate for internal apps for Google Apps customers? For quick/easy personal hacking/development having a Python stack on Heroku seems pretty attractive now.

bad_user 15y ago
Personally I don't like Google App Engine, but I can understand its value -- it has reasonable free quotas (even now, after the pricing scheme changed), and your app ends up running on Google's infrastructure which is rock solid. 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.
- aashay 15y ago
  "it's like renting instances on EC2" 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 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?
  - fdr 15y ago
    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.
    - kyleslattery 15y ago
      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.
      - bad_user 15y ago
        If you read the message in which I said that, I was specifically referring to their free quota.
  - bad_user 15y ago
    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.
- mark_l_watson 15y ago
  I don't think that any of Heroku's paid plans swap out Dynos. Sure, for the free plans they do - seems fair to me.
phzbOx 15y ago
Also, to get something up quick and dirty with a vps or shared host, is fairly easy, I'll agree with you. However, as you need to get more power, it becomes more problematic. With Heroku, the "quick and dirty" way is actually quite robust and can scale well. But I'm with you that I find it a bit too costly as I know (and actually like) configuring my stuff.

by jedc 15y ago

bad_user 15y ago

Personally I don't like Google App Engine, but I can understand its value -- it has reasonable free quotas (even now, after the pricing scheme changed), and your app ends up running on Google's infrastructure which is rock solid. 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.

aashay 15y ago
"it's like renting instances on EC2" 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 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?
- fdr 15y ago
  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.
  - kyleslattery 15y ago
    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.
    - bad_user 15y ago
      If you read the message in which I said that, I was specifically referring to their free quota.
- bad_user 15y ago
  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.
mark_l_watson 15y ago
I don't think that any of Heroku's paid plans swap out Dynos. Sure, for the free plans they do - seems fair to me.

phzbOx 15y ago

Also, to get something up quick and dirty with a vps or shared host, is fairly easy, I'll agree with you. However, as you need to get more power, it becomes more problematic. With Heroku, the "quick and dirty" way is actually quite robust and can scale well. But I'm with you that I find it a bit too costly as I know (and actually like) configuring my stuff.