4 ms·

Google App Engine Scales and Develops Fast

22 points by soundsop 17y ago

stanleydrew 17y ago
This is pretty impressive. Can somebody tell me why I should even think about EC2 at the prototyping stage?
- charlesju 17y ago
  EC2 is more platform agnostic.
  - stanleydrew 17y ago
    So I can deploy anything I want?
    - sanswork 17y ago
      Exactly, http://aws.amazon.com/ec2/#os 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.
      - marcusbooster 17y ago
        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?
        sanswork 17y ago
        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.
- ashot 17y ago
  offline tasks
tybris 17y ago
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.
- jimbokun 17y ago
  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?
Confusion 17y ago
This doesn't actually show anything about the scaling behaviour of an App Engine application.
zmimon 17y ago
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.
fiaz 17y ago
Is there any way to run background processes in the Java version of GAE?
- asmithmd1 17y ago
  No, there is no threading. A thread starts in response to an HTTP GET or POST, returning the result, then dieing.
- mshafrir 17y ago
  Yes. http://code.google.com/appengine/docs/java/config/cron.html http://code.google.com/appengine/docs/java/config/cron.html
  - anamax 17y ago
    "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".
    - mshafrir 17y ago
      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.

22 points by soundsop 17y ago

stanleydrew 17y ago

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

charlesju 17y ago
EC2 is more platform agnostic.
- stanleydrew 17y ago
  So I can deploy anything I want?
  - sanswork 17y ago
    Exactly, http://aws.amazon.com/ec2/#os 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.
    - marcusbooster 17y ago
      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?
      - sanswork 17y ago
        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.
ashot 17y ago
offline tasks

tybris 17y ago

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.

jimbokun 17y ago
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?

Confusion 17y ago

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

zmimon 17y ago

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.

fiaz 17y ago

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

asmithmd1 17y ago
No, there is no threading. A thread starts in response to an HTTP GET or POST, returning the result, then dieing.
mshafrir 17y ago
Yes. http://code.google.com/appengine/docs/java/config/cron.html http://code.google.com/appengine/docs/java/config/cron.html
- anamax 17y ago
  "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".
  - mshafrir 17y ago
    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.