GAE is a mistake. By that I mean that it's got a big design flaw that's bound to cost Google money, which means it'll always be expensive than alternatives. Consider shared PHP hosting: a request comes in, apache finds which PHP file is responsible for it, then directs the request to the PHP interpreter. The PHP interpreter will parse the file (or more likely load the parsed bytecode from a cache) and return a response, which apache will then forward to the user agent. Notice that aside from the cache the PHP interpreter is stateless. As soon as it is done serving a request from site foo.com it can immediately jump on a request from bar.com and the context switch doesn't cost anything (once again disregarding finite cache size issues).
Contrast this with running a stand-alone application server for each site, which is what GAE does. Here, even if your code is not serving any requests it's still waiting to get them. Now, GAE has powerful magic in it to retire request handlers which aren't frequently used. This way if site foo.com is getting 1 request/minute, it only really needs one process/thread/hander abstraction at a time. However, it is expensive to start/stop these "processes", so instead GAE is forced to keep this "process" around for a while after a request has been served hoping that the cost of keeping it alive would be justified by a second request. Thus these stateful, slow-to-start processes are always taking up resources that could be used to serve other requests.
Disclaimer: all my knowledge of GAE has been from reading their docs/blog, not from deploying projects to it.
Disclaimer 2: I am not saying that PHP is better/worse than GAE in any way. However, I am saying that the model that GAE uses is more costly for a typical application. This can be easily seen by comparing the cost of running a basic site on GAE vs $2/month shared hosting.
Heroku uses the same model. They're doing quite well.
GAE has problems, but I think the root is just how unique everything is. That manifests itself in people using a datastore that they don't understand, with Google expecting them to know how many writes an action will take and whether that feels like the right number of writes or two orders of magnitude more than if they made a different decision about how to store their data and solve their problems.
It also manifests itself in the lockin that Heroku mostly avoids (which is a huge problem if some subset of users get to a point where they realize "whoops, this would be much easier if I could do things Google won't let me do, time to leave").
I think a good counterexample is Engine Yard and GitHub. Engine Yard had a somewhat limited offering (especially for what GitHub was willing to pay) that didn't really fit with GitHub's heavy direct disk I/O. (Most Rails apps almost entirely read and write from the db, but GitHub does a lot of direct operations on the git repositories.) But GitHub was still just a Rails app, not an app for some specially-designed Engine Yard framework. So it was fairly painless for them to decide to solve the problem in a way that didn't fit with what Engine Yard would offer them and migrate to their own hardware. It wasn't easy, especially since they weren't solving an easy problem, but at least they didn't have to replace their database.
The GitHub example is the reason why I never wrote any code against GAE. The lock-in into their data store is a hard pill to swallow and was an early warning sign.
I am not familiar with the internals of Heroku and don't know how they solve the problems I outlined. Maybe someone else can elaborate.
Heroku runs a process for each application (or multiple). The first one for an application is free. But just like with GAE, they'll spin it down if it's idle long enough. So I know that if I go to a site of mine that no one has visited in months, where I'm not paying for extra instances, it'll take a few seconds to load. But having to run those free instances doesn't kill them because all but the first one for an application is paid for at 5 cents/hour, which presumable is enough margin to cover the free instances, and then some.
But they run normal applications. It started out being any Rack (Ruby web standard--Rails, Sinatra, etc) app; they've expanded into other languages now, but it's always some open framework that they're running for you, not something they own and keep proprietary. They give you a normal Postgres database. There are a few restrictions that you might not have on your own hosting (like a read-only filesystem). But you could basically take an app running on Heroku, install a webserver and Rails, install Postgres, make sure any config you had was the same, and run it.
Another huge advantage Heroku has is the ability to give other people access to their datacenters, since they're just running on EC2. So there's lots of Addon services that can add various pieces of functionality, like hosting a different database, many of which are only tractable because they're also hosted on EC2 and thus have very good latency to Heroku servers.
This means that you're not stuck with Postgres. If you think a part of your data, or all of your data, would be better stored in Mongo or Couch or Redis or flat files on S3, there are hosted services for that, and you can even deploy your own solution on EC2 if you'd rather. This leads to nice halfway solutions where you use Heroku to have super-scalable application servers, and maybe to manage your main relational db, but then you can tack on other things where that doesn't fit with your problem. Now, if you're running some of your own EC2 instances, you're losing some of the "never have to worry about hosting again" value of Heroku, but at least it's possible. It could be a temporary solution that keeps you above water while you migrate off of Heroku, or maybe you decide it really is the best long-term solution.
It's interesting, since GAE charges $0.08/hour per front end instance, with 28 front end hour instances free per day. However, I once helped someone debug an application that on average gets one hit a minute, and yet manages to max the 28 free hours and then some. Closer examination showed that GAE was having these instances hang around for much longer than seemed necessary after they fulfilled the initial request.
So either Heroku has more magical magic than GAE, or there is some other kind of efficiency that they are tapping into. One thing I can think of is that possibly Heroku is more conservative with spinning up extra processes, preferring longer response times.
I may be misunderstanding what you mean but heroku does not spin up or down any processes, the amount of workers you have is controlled entirely by the end user and you will be billed by the worker regardless of how much traffic you're getting. I'd venture that 95% of heroku apps have a single process, and that 95% of the time those workers are in some sort of suspended state.
If you have 1 dyno, heroku spins that dyno down after 20-30 minutes of inactivity.
Also, there are services out there that will monitor your queue depth and increase your dyno count for you. Or, you could use the heroku gem to do that yourself.
Depending on how long it takes a call to be dealt with it might be worth telling GAE to never spin up more than one instance. Sure, the occasional user will have to wait a couple of extra seconds to be dealt with, but you won't have to worry about cost.
Speaking for myself, I down-voted because of the absurd false dichotomy of comparing Google App Engine to $2/month shared PHP hosting! It's like complaining that an oil tanker costs more than a rowboat.
The value proposition of App Engine is that with no systems administration expertise you can rent an extremely reliable, massively scalable web platform that is managed around the clock by a world class devops teams. Unsurprisingly this costs money. If you don't need the reliability or scalability of App Engine, no one is forcing you to pay for it. But it's absurd to suggest that you can get anything remotely comparable in PHP for $2/month.
Thanks for the explanation. The reason for the comparison is two-fold. First, there seems to be a section of GAE users who use it solely to host a blog, a need satisfied by a much cheaper service elsewhere.
Second, while I understand the value of high availability and not having to worry about Ops, I am talking about cost per HTTP request. Here, the $2 PHP host is a clear winner. As I said, that does not mean it is better. Your analogy with the oil tanker and a row boat is applicable: one is more appropriate if you just want to cross the pond. The other is better for going from Alaska to California, with the caveat that GAE exists in the world where there are vanishingly few cost-effective ways to use it.
This comparison is still absurd (and incredibly naive). If you have a few hundred requests per day, sure a PHP server is far more efficient use of your box. For that matter, if you have zero requests per day, it's more efficient to just power it off.
At any kind of scale, PHP's model of "start the interpreter, load the code, start executing" is abysmal. To make efficient use of CPU resources you need compiled code - JIT or otherwise. You often need to make use of instance RAM and pooled database connections. Long-running processes are vastly more efficient when running flat-out.
If you have the interpreter live and the code loaded, you're circumventing the parent's "point" that GAE is inefficient because it keeps your application running in a process vis-a-vis the standard way appservers work in java, python, ruby, node, etc.
But if you need the reliability and scalability that App Engine provides, I still think it's cost effective compared to attempting to build the same functionality yourself. You get the benefit of directly using the work of Google's top flight App Engine programmers (e.g., Guido van Rossum).
By way of comparison, I've done quite a bit of work w/ the AWS components (e.g. EC2, S3, SQS) that in theory allow you to build a highly reliable, highly scalable site but in practice there's still a lot of assembly required, whereas w/ App Engine that's provided out of the box.
I think you misunderstand him. He was using PHP to illustrate the efficiency of request handling and the lack of in AppEng. Whether he got it right or wrong technically doesn't deserve a downvote.
Contrast this with running a stand-alone application server for each site, which is what GAE does. Here, even if your code is not serving any requests it's still waiting to get them. Now, GAE has powerful magic in it to retire request handlers which aren't frequently used. This way if site foo.com is getting 1 request/minute, it only really needs one process/thread/hander abstraction at a time. However, it is expensive to start/stop these "processes", so instead GAE is forced to keep this "process" around for a while after a request has been served hoping that the cost of keeping it alive would be justified by a second request. Thus these stateful, slow-to-start processes are always taking up resources that could be used to serve other requests.
Disclaimer: all my knowledge of GAE has been from reading their docs/blog, not from deploying projects to it.
Disclaimer 2: I am not saying that PHP is better/worse than GAE in any way. However, I am saying that the model that GAE uses is more costly for a typical application. This can be easily seen by comparing the cost of running a basic site on GAE vs $2/month shared hosting.