Google App Engine Pricing Model | Hacker News Reader

Google App Engine Pricing Model

googleappengine.blogspot.com

34 pointstortilla17 comments

Those are actually some pretty innovative new features. Unfortunately, I don't think there has been enough of a shift away from what a lot of people saw as core issues ( python only, etc.) to flock to app engine en masse. When I check out who is using app engine right now, i'm a bit underwhelmed. http://code.google.com/appengine/casestudies.html

Really? I think people have hesitated to launch major App Engine sites primarily because: (1) it isn't supposed to be production-ready yet, and (2) no one has hitherto had any idea how much it costs. It wouldn't be pleasant to spend time to write an app, become popular (and everyone hopes to become popular), and then have Google turn around and say, "Sorry, you blew out of your free quotas, and we aren't ready to bill you to extend them." Just as bad: "Your free app is popular, congratulations! You owe us $10K for the bandwidth and storage you used last month."

"... It wouldn't be pleasant to spend time to write an app, become popular (and everyone hopes to become popular), and then have Google turn around and say, 'Sorry, you blew out of your free quotas, and we aren't ready to bill you to extend them.' Just as bad: 'Your free app is popular, congratulations! You owe us $10K for the bandwidth and storage you used last month.' ..."

At the same time the entry level cost for exploring an idea in code has been reduced yet again. Explore an idea, create something and see what happens. If it works then inject some funds. If it fails, the outlay is time and effort only.

Except there is no way to inject funds to the idea. There's no way to pay Google for more cpu/bandwidth/storage. The system is also very propriety and there is no (easy) way move an appengine app to a new server.

I'd much rather get some cheap hosting somewhere else than develop for free on appengine. Its an interesting platform but there are still too many limitations for me to consider it for serious use.

"... There's no way to pay Google for more cpu/bandwidth/storage. ..."

Agreed, this will change in time. But I'd use this point to refine the idea as you suggest on cheap hosting.

"... The system is also very propriety and there is no (easy) way move an appengine app to a new server. ..."

Not convinced of that. The biggest problem is not the porting of an idea but replicating the scaling.

One thing I enjoy about Heroku is the option to export code and run a local Rails + Postgres instance if the need comes to fruition. The "escape hatch" is good for any system in which you intend to invest resources, even if you never need to escape. I think AppEngine is a little bit more proprietary, although with some work you could probably move to Python, Django, CouchDB or something similar in an emergency.

Really, python only isn't the issue. Sure, it takes a while to learn a new language, but a good programmer shouldn't have that much trouble.

The real problems are the other limitations. Background tasks, full text search, MapReduce, support for uploading files larger than 1MB, not having short bursts cause the application to exceed limits, limitations in the datastore like only returning 1,000 records.

Those are real limits to what the system allows you to do. Python doesn't stop you from producing something, those limitations might. Learning a new language isn't that hard if you're a programmer.

It seems that for many programmers, Python-only is just another limitation in that list. Sure you can learn Python, just like there are ways to work around a lot of the other issues, but I would think that all of these limitations add up to discourage programmers from building small apps as an experiment. Learning Python just to use GAE seems dumb when you can just use EC2.

EC2 is nothing like App Engine, the only thing that relates them is that their logos are placed in cloud clipart together on powerpoint slides.

App Engine is an abstract distributed REST machine. EC2 is just x86 VMs (albeit with nice provisioning APIs).

That's only true if your program (a) isn't written yet, and (b) wouldn't benefit from doing things which are difficult in Python (e.g., from being even higher-level). It's not learning time -- I already know Python quite well.

I know Python-only is fine for many people, but for others it is a showstopper. I've got a bunch of Lisp code I wouldn't mind hosting on Google's servers but there's zero chance I'll ever take the time to greenspun myself macros, multimethods, parts of the MOP, various Lisp-only libraries, and so on that it uses, and then re-optimize my program for their unique architecture.

Which lisp dialect/implementation do you use? And which libraries? Do you have a blog, maybe? Thanks!

Short answers: (a) Common Lisp, typically SBCL. (b) Nothing terribly exotic about the selection, but since Lisp libs tend to be Lisp-all-the-way-down (compared to wrapper-on-a-C-lib, common in the Python world) you can use them in creative ways the authors never imagined, which would elsewhere require, say, rebuilding C code with custom hooks. (c) Not yet, but my CTO keeps bugging me to start one, so maybe next week when I have more time...

GAE is not suitable for porting existing programs to it regardless of the language: the architecture is too different.

This is good to hear! I just started a project that happens to fit well within GAE's free requirements, so it's good to know Google will support me as it grows.

Scroll down to read the paper

404 =/

It seems that App Engine will remain just a fun toy until more of its limitations are removed.

Reply on news.ycombinator.com