Google App Engine for developers

App Engine over quota error

On Monday Google launched Google App Engine, a hosted dynamic runtime environment for Python web applications inside Google’s geo-distributed architecture. Google App Engine is the latest in a series of Google-hosted application environments and the first publicly-available dynamic runtime and storage environment based on large-scale propriety computing systems.

Google App Engine lets any Python developer execute CGI-driven Web applications, store its results, and serve static content from a fault-tolerant geo-distributed computing grid built exclusively for modern Web applications. I met with the App Engine’s team leads on Monday morning for an in-depth overview of the product, its features, and its limitations. Google has been working on the Google App Engine since at least March 2006 and has only just begun revealing some of its features. In this post I will summarize Google App Engine from a developer’s point of view, outline its major features, and examine pitfalls for developers and startups interested in deploying web applications on Google’s servers.

What is Google App Engine?

Google App Engine is a proprietary virtualized computing suite covering the major common components of a modern web application: dynamic runtime, persistent storage, static file serving, user management, external web requests, e-mail communication, service monitoring, and log analysis. The Google App Engine product offers a single hosted production web server stack hosted on Google’s custom-designed computers and datacenters distributed around the world.

Google App Engine is a managed hosting environment with a tightly managed stack running in a machine-independent environment. It simplifies the deployment and management of your web application software stack while constraining you to a specific stack. When I start a new web development project today I have to first setup a tiered system to effectively handle site growth:

Web application configuration
  1. Purchase dedicated servers or virtualized slices. Estimate necessary CPU, memory, disk space, etc. at each tier.
  2. Configure a web server for dynamic content. Install Python and its eggs, Apache HTTPd and extra modules such as modwsgi. Configure and tweak each. Open appropriate ports. Listen.
  3. Setup a MySQL database server and choose the appropriate storage engine. Configure MySQL, add users, add permissions. Tweak and optimize.
  4. Add an in-memory caching layer for frequently accessed dynamic content.
  5. Monitor your uptime and resource utilization with Ganglia and/or other tools on each machine.
  6. Serve static files such as JavaScript, CSS, and images from a specialized serving environment such as Amazon’s Simple Storage Service.
  7. Turn your static server into an origin server for a CDN with points of presence close to your website’s users.
  8. Connect each piece of the stack, keep its software updated to avoid security vulnerabilities, and hopefully respond to all website requests in less than a second.
  9. Dedicate work hours and expertise to all the above. Hire outside assistance if needed.
  10. Don’t go broke trying.

Your tiers will expand as your new web application gains popularity. Your single-server tiers become load-balanced services, message bus broadcasts and listeners, and distributed cache arrays at scale. You’ll probably spend time rearchitecting your application at each stage of growth to incorporate for these new resource demands if you can afford the time, expertise, and effort.

Google App Engine is a new and interesting solution for Python developers interested in adding features, not servers. Google spends hundreds of millions of dollars developing its custom infrastructure with 12-volt power supplies tapped into a hydro-electric dam next door and fat fiber pipes owned by local governments carrying requests and responses to their proper home. Google’s physical infrastructure is vast array of highly optimized web machines, and we’ll now be able to see how such infrastructure performs across more generic applications on App Engine.

Freemium hosting model

Google App Engine is a “freemium” business model offering basic features for free with paid upsells available for application developers exceeding approximately 5 million pageviews a month. This resource quota approximately matches the Google Analytics 5 million pageview limit. Google Analytics customers may currently exceed this limit if they maintain an active AdWords account with a daily advertising budget of $1 or more. The Google App Engine team plans to introduce pricing and service level agreements for additional resources, priced in a pay-as-you-go marginal resource structure, once the product leaves its limited 10,000-person preview period later this year.

Quota TypeLimit / day
HTTP requests650,000
Bandwidth In9.77 GB
Bandwidth Out9.77 GB
CPU megacycles200 million
E-mails2,000
Datastore calls2.5 million
External URL requests160,000

Google publishes these quotas and provides administrative monitoring tools. The quotas are just a guideline as Google may cut off access to your application if you receive a traffic spike of an unspecified duration. The Google App Engine quota page specifies:

If your application sustains very heavy traffic for too long, it is possible to see quota denials even though your 24-hour limit has not yet been reached.

App Engine over quota error

Google App Engine already failed the Techcrunch effect and appears the platform is currently unable to handle referral traffic loads from a popular blog or news site typically associated with a product launch. The traffic spike cutoffs make me think twice about hosting anything of value on App Engine.

The team

The Google team behind App Engine has a long history in developer services. Team members include some of the top Python experts in the world, financial transaction specialists, and developer tool builders.

  • Python creator Guido van Rossum wrote the App Engine SDK and ported the Python runtime and Django framework for the new environment. Google App Engine is Guido’s first full-time project at Google after his Noogler project Mondrian.
  • Technical lead Kevin Gibbs previously worked on the the SashXB Linux development toolset and multiple RPC projects at IBM before he created Google Suggest in 2004.
  • Developer Ryan Barrett wrote the BigTable datastore implementation and related APIs. Previously Ryan was tech lead on Moneta, Google’s transaction processing platform and customer data store.
  • Product lead Paul McDonald has worked on Google Checkout, AdWords, and a Web-based IDE named Mashup Editor (all strong candidates for App Engine inclusion).
  • Product manager Peter Koomen has previously authored papers on natural language search and semantic analysis.

The list above is just a sampling of the full-team behind App Engine.

Feature limitations

Google App Engine is not without its faults. Applications cannot currently expand beyond the quota’s ceiling. It’s still unclear how an application will dynamically scale on App Engine once it leaves the farm leagues, and at what cost.

A few major issues include:

  1. Static files are limited to 1 MB. App Engine does not support partial content requests (Accept-Ranges).
  2. Cron jobs and other long-life processes are not permitted.
  3. Applications are not uniquely identifiable by IP address, leading to a lack of identification for external communications. Applications may suffer from bad neighbor penalties from API providers upset at another app on the service.
  4. No SSL support. No IP address complicates signing, but port 443 is open for requests. You can rely on Google services (and branding) for trusted login and possibly future payments.
  5. No image processing. Python Imaging Library relies on C, and is therefore not a possible App Engine module.
  6. Google user accounts. Site visitors are very aware of your choice in web hosts each time they attempt to logon to your application. I feel like this flow makes your application seem less professional, but may be a reasonable trade-off. Google will store your user data and potentially mine its data for better ad targeting.

Summary

Overall I am quite impressed with Google App Engine and its potential to remove operations management and systems administration from my task list. I am not confident in Google App Engine as a hosting solution for any real business while the host is in preview stage but those concerns may be alleviated once the product is ready for real customers and real service-level agreements.

Python developers have just been granted a few superpowers for future projects. As an existing Python and Django developer I know how difficult it can be to find a managed hosting provider with modern Python support. Many hosts are years behind, running Python 2.3. I am excited App Engine already features the programming tools I use every day, with a few modifications for their proprietary systems. App Engine should introduce more developers to Python and the Django framework and hopefully cause other web hosts to provide better Python support as well.

14 comments

Commentary on "Google App Engine for developers":

  1. the daniel on wrote:

    “Google App Engine already failed the Techcrunch effect
    and appears the platform is currently unable to handle referral traffic
    loads from a popular blog or news site typically associated with a
    product launch. The traffic spike cutoffs make me think twice about
    hosting anything of value on App Engine.”

    The product is clearly in a beta, the hard caps are part of that. No one in their right mind would host anything of value on it until the private beta is over. Something tells me that Google will be able to handle the techcrunch effect (lol) just fine, and happily charge you painful overages for it.

    • Niall Kennedy on wrote:

      Daniel,
      Technically App Engine is a “preview release” and may in the future be available without an invitation, outside of beta, and with many different features. My article comments on reality as we know it today. Traffic spikes such as a product launch are currently unspecified ceilings in the Google App Engine quota system. Your quota assumes equal resource consumption over 24 hours, but spikes will expire your resources beyond their standard metering schedule. It could be a double penalty, triple penalty, or higher but we don’t currently know for sure.

  2. Gábor Farkas on wrote:

    Google user accounts. Site visitors are very aware of your choice in
    web hosts each time they attempt to logon to your application. I feel
    like this flow makes your application seem less professional, but may be a reasonable trade-off.

    as far as i understand, you do not have to use google-accounts for user management. you can implement your own user/session management if you want to.

  3. Skott Klebe on wrote:

    Thanks for your balanced perspective, Niall.

  4. Patrick Chanezon on wrote:

    Thanks for the detailed in depth article Niall: your coverage of developer products is always a good read.
    I knew you would like App Engine :-)

    P@

  5. John on wrote:

    I like the direction that the major web titans are going. They may not be there just yet, but with google and amazon opening up there platforms for all to build web apps that will easily scale, I’m looking forward to these products in the future as the primary hosts of all new web apps. I hope they (google, amazon, etc) can pull it off though. And get it to a level of stability that your web app can run with out too many major hiccups.

  6. Roger Jennings on wrote:

    Niall,Re: “4. No SSL Support”The documentation’s “Sandbox Security Controls” topic states, “Other computers can only connect to the application by making HTTP (or HTTPS) requests on the standard ports.” So I believe the apps support SSL.Also, SSL is supported for external URL requests with any certificate (including self-signed certificates) by the URL Fetch API but the proxy does not authenticate the host.–rj

  7. Paul on wrote:

    App Engine sounds nice.  Thanks for reporting on it.
    What “version” is the Python runtime engine? 2.5? 2.6? Proprietary?
    What is the “lock in” factor? If I should decide to go to the trouble of managing my own infrastructure, what will it take to migrate the application to it? Must I license the Google App Engine? Is it possible?

    • Niall Kennedy on wrote:

      Paul,
      App Engine runs the latest public release of Python: 2.5.2. Some modules, such as marshal, are disabled due to local disk access or C dependencies.
      Lock-in is a bit more complex to explain and deserves an entirely separate post. If you use an ORM to manage data interactions you now have a new engine: BigTable. You may want to attach wrappers around requests typically handled by httplib, urllib, and urllib2 to better match Google’s urlfetch behavior.

  8. Paul on wrote:

    Thanks for your quick reply. Once App Engine gets going, I would like to see Google and friends create some custom ASIC or processor that runs Python compiled code directly in order to speed things up. I hear that interpreted languages present difficulties to hardware designers, but I am confident that some creative thinking can overcome this.
    Perhaps it would be good to have the global lock issue to a point where threaded and/or MPP platforms can operate well.

  9. jack on wrote:

    Has anyone heard when this will be opened up to the public. I wasn’t one of the lucky 10,000 but am itching to give Google App Engine a try.

    • cesoid on wrote:

      jack: I don’t know when it opens to the public, but after not making it in as one of the first 10,000, google has followed up and let me in. So I wouldn’t be surprised if you can get in soon.

  10. Massimo on wrote:

    You can also run code developed with a high level framework like web2py on the Google App Engine.

  11. Kiran on wrote:

    This article needs revision! Limitations have changed, you can now do a lot more than what you could initially! I love Cron support!