An alternate perspective: Google App Engine is still a fine platform even with the new price increases. (Which they told us were coming by the way)
And by the time the pricing takes effect the updated python runtime should bring costs down even more.
The instance costs are comperable to Heroku AND you get a high availability data store AND the ability to store really huge amounts of data in the blobstore AND a CDN for serving images from said blobstore. Not to mention background processes, task queue, XMPP, memcache, Multitenancy and multiple versions of apps so you can easily roll things back or test out updates painlessly.
Try and replicate that setup on Heroku or AWS for anywhere near the costs and time that you can get there with app engine.
While you're fighting with AWS and playing sysadmin or trying to think of ways to bring down the costs of Heroku's database services by using RDS instead or being nickel and dimed by add-on fees I'll be shipping code. Code that actually takes advantage of the platforms strengths.
The blobstore is basically S3, and the CDN for the blobstore is basically CloudFront. Both S3 and CF seem to me to have really simple APIs, plugins to Rails and other common frameworks, and are almost certainly battle tested by an order of magnitude more companies than the blobstore. What am I missing?
As far as I can tell, of your list, Heroku has all of the things you describe, with the possible exception of XMPP. Task queues (workers, SimpleWorker), many flavors of high availability data stores, memcache (or even better, Redis as a service), multitenancy, multiple versions of apps (git, releases).
Is there something bad about RDS that I don't know about? I had always assumed you just spun it up and could optionally replicate a MySQL instance a few times in different zones.
More broadly, it sounds like you had a really bad experience with Heroku. If so, what was it? I'm a bit curious because we are rather dependent on it.
All I'm saying is with Heroku you have to clobber these features together and the real cost of that is higher than people may be admitting in these comparisons.
I've worked with both platforms and I'm not saying heroku is horrible. In fact it might be the easiest to get started with of all the PAAS providers but it's expensive (they all are) and does not provide the same level of features out of the box that GAE does. Saying that because I can eventually get all the features I need by clobbering together a bunch of random gems and bringig AWS into the mix is quite different than having a unified api out of the box.
The point I'm making is that there is an additional real cost this kind of integration work (just like there are real costs learning googles API and accepting a certain amount of lock in.) and I don't think these costs are being fairly represent in the current discussion.
It seems as though you are actually contrasting two competing philosophies.
BareBoneswithAdd-ons : Heroku handles deployment (via git, releases), app servers (thin), reverse proxies (varnish), and caches (varnish). (That's "bamboo" rather than "cedar" for what it's worth.) Heroku provides optional data storage via Postgres and background jobs via worker queues. For everything else, a combination of add-on providers (MongoHQ, RedisToGo, SimpleWorker, ...) and your own custom EC2/S3 code is used.
Integrated : GAE handles deployment, app servers, reverse proxies and caches. It also has channels, XMPP, workers, a data store, and a blob store built in. All of the documentation is in one place and from one provider. All of the billing is unified.
Personally, I have always assumed that the integrated approach is by necessity. GAE can't rely on other providers to provide functionality like a blob store because they don't want other providers running in their data centers. By contrast, since Heroku is in US-East, basically any SaaS can pop up to offer functionality with low latency to Heroku apps. If there's no SaaS, in the worst case, the web app author can write their own backend services within US-East to meet their own needs.
I think you're right that the inconsistency of pricing, documentation, and quality of many providers can be a problem for the bare bones approach. However, I've found in general that almost everything I want is (a) S3, which has a simple API and a well known gem, (b) Redis, which has a simple API, a well known gem, and basically one (somewhat overpriced) provider, and (c) very rarely EC2 instances if I need to run some really weird, open source Java or backend code. I'm also much more comfortable knowing that there are basically no problems that cannot be solved, at some difficulty, by the EC2 backend solution.
I could see the appeal of the integrated solution. For example, if I had a class of students, I could just point them to one documentation source with GAE, or monitor one billing page with GAE.
Do you think that web developers generally prefer (a) integrated solutions with shared documentation and the possibility that some functionality may be impossible or (b) piecemeal solutions where they may get varying quality from a set of services they select, but where basically all functionality is possible?
"An alternate perspective: Google App Engine is still a fine platform even with the new price increases."
This depends a lot on what you're doing. GAE is now pretty terrible if you're using it for high-bandwidth applications (say, a data proxy or similar). Especially when you compare it to other providers for whom bandwidth prices have been dropping (AWS, Linode, etc now offer incoming bandwidth totally free and the rates on outgoing are very low as well). If you're using it as a number-crunching backend with relatively small in/out datasets, the new prices aren't too bad at all.
c1.xlarge on EC2 is $1.16/hour. How many of the $0.08 GAE units does it take to match one of those? How many of those GAE units can run optimized SSE4/AVX? (Answer: none of them). I've run 250 c1.xlarge units at a time. GAE wasn't even possible, let alone affordable.
I agree that picking the right tool for the job is important but I just wanted to list the reasons I prefer GAE. There is quite a lot of outrage (raising prices does that) without really considering what the real costs of the alternative platforms are.
And by the time the pricing takes effect the updated python runtime should bring costs down even more.
The instance costs are comperable to Heroku AND you get a high availability data store AND the ability to store really huge amounts of data in the blobstore AND a CDN for serving images from said blobstore. Not to mention background processes, task queue, XMPP, memcache, Multitenancy and multiple versions of apps so you can easily roll things back or test out updates painlessly.
Try and replicate that setup on Heroku or AWS for anywhere near the costs and time that you can get there with app engine.
While you're fighting with AWS and playing sysadmin or trying to think of ways to bring down the costs of Heroku's database services by using RDS instead or being nickel and dimed by add-on fees I'll be shipping code. Code that actually takes advantage of the platforms strengths.