Google App Engine Scales and Develops Fast | Hacker News Reader

Google App Engine Scales and Develops Fast

coderoshi.com

22 pointssoundsop16 comments

Ok, I'm the idiot who did the script injection attack. Sorry every one. Actually I figured it wouldn't work because he appears to be escaping the output in the code on the blog page ... but what do I know.

As better outlined in A Berkeley view of Cloud Computing GAE and EC2 serve a different purpose/market. Comparing the two on prototyping time is rather silly. For instance, people are already building GAE alternatives running on EC2.

It seems like GAE is usable for displaying content and building a web interface, but any significant processing has to happen elsewhere. This is due to the limitations on a single request (I just read about the cron functionality, but it appears that the same restrictions are in place for cron jobs). Note that, even in the tutorial, the non trivial part (accepting text messages) is handled by an external service, and the app just stores and displays the data.

So, an architecture that leverages the strengths of GAE might push the processing intensive parts onto servers outside of GAE, interfaced through a services API (most likely something "RESTful"). GAE would then handle the data storage, templating, and UI logic. Note that these web services might already exist, and GAE is a good candidate for building an interface on top of them (this is the case with the text message service in the tutorial).

Does that make sense?

Is there any way to run background processes in the Java version of GAE?

No, there is no threading. A thread starts in response to an HTTP GET or POST, returning the result, then dieing.

Yes. http://code.google.com/appengine/docs/java/config/cron.html

"A URL invoked by cron is subject to the same limits and quotas as a normal HTTP request, including the request time limit."

The request time limit is 30 seconds. Yes, that means that you have to break your background processing in to 30 second chunks.

The GAE team is promising better support for background processing "soon".

I find that despite this limitation, there are clever/elegant ways to work around it. In general, look to increase the frequency of a job while decreasing the amount of "work" done per cycle.

This doesn't actually show anything about the scaling behaviour of an App Engine application.

This is pretty impressive. Can somebody tell me why I should even think about EC2 at the prototyping stage?

EC2 is more platform agnostic.

So I can deploy anything I want?

Exactly, http://aws.amazon.com/ec2/#os has a list of the OS's you can run and within those you can run anything they can run.

I have some servers running java applications, some running php on apache, some running php on fastcgi+lighty, some running ruby, and some that just run memcache.

How does EC2's pricing compare in the early stages? With AppEngine it seems basically free until you reach a certain threshold. Is Amazon comparable, or are you paying a little bit from the get-go?

I'm interested in having more smaller projects, with a higher rate of failure. GAE seems like a good fit, would Amazon's cloud offering work too, and be more flexible?

If you don't need the flexibility in environments than it probably is better for you. I don't develop is Java or Python though and the ways to run other languages aren't really ideal.

A small amazon instance will run you about $70 a month so at that level it might be worth it to go elsewhere unless you think you will need the ability to scale up massively fast.

In that case though it might be worth getting an Amazon instance configuring it exactly how you want then saving the image and turning it off. You'll only be paying for storage of the image than which is a couple bucks a month and in the event you do need to scale up fast you can bring up the instances and swap your original box into a temporary load balancer for your amazon instances.

offline tasks

Reply on news.ycombinator.com