5 Comments

Summary:

Earlier this month, Google launched their App Engine cloud computing platform. The initial beta slots filled up very quickly, but over the weekend my number finally came up and I was able to start working with the product. (Even if you’re not in the beta, you […]

ScreenshotEarlier this month, Google launched their App Engine cloud computing platform. The initial beta slots filled up very quickly, but over the weekend my number finally came up and I was able to start working with the product. (Even if you’re not in the beta, you can download the SDK and work with it on your own computer). After some hands-on time, it seems to me that App Engine will indeed be useful to many web developers – though I continue to think it’s not really a direct competitor for Amazon’s more flexible AWS platform.

The process of developing an application for App Engine is quite straightforward. You write your code on your own computer using Python (the only choice currently; there’s a decent tutorial on the main Python web site if you need it). To test the application, you run a local development web server that emulates the App Engine API for you. When you’re satisfied, another Python script prompts for your Google login information and then uploads to the server for you. You can pick your own URL, using a subdomain of appspot.com or your own Google Apps domain.After your application is uploaded, it’s available at your URL with, as far as I can tell, no delay at all. App Engine’s dashboard lets you manage versions of the application, review log files, and track the use of the metered resources that are allocated to you.

You don’t have unrestricted access to the host where your application is running; rather, it’s sandboxed to keep you from doing bad things. The sandbox restrictions are not terribly onerous; you can’t use the file system or the network, or spawn a sub-process. On the other hand, you do get access to several App Engine-specific APIs:

  • The Datastore API provides an object-oriented database with its own pseudo-SQL language.
  • The Users API gives you trivially simple integration with Google Accounts.
  • The URL Fetch API lets you grab data from other hosts, using port 80 or port 443.
  • The Mail API lets you send email from your application.

And, of course, you have access to frameworks already built in Python – notably Django, a version of which is included in the SDK. This will give current Python web developers a leg up in building things with Google App Engine (Google has promised support for additional languages, but there’s no timeframe on that).

Even if you’re not currently a Django hacker, though, there are opportunities here. The URL Fetch API makes it easy to create mashups using data from other services that provide a RESTful API, which is increasingly common in this Web 2.0 era. And it’s super easy – a matter of 3 lines in a configuration file – to serve static files from an App Engine application. That means that, depending on where they draw the line for free versus paid use after launch, you can use App Engine as an asset server for other web applications. Apart from the free storage, this gets you caching across Google’s worldwide infrastructure.

The cost you pay for this functionality is good old-fashioned vendor lock-in. Although they’re written in Python, it’s unlikely that any non-trivial application built for App Engine will run anywhere besides the Google servers for quite some time to come. Provided you’re willing to put your eggs in the Google basket, though, App Engine provides an easy way to get scalability with near-zero effort.

You’re subscribed! If you like, you can update your settings

  1. Mike, do you think its possible to abstract the appengine depedency points to make porting elsewhere more possible?

  2. Mike Gunderloy Monday, April 21, 2008

    I think the big issue with porting would be the data handling. Google’s Datastore API uses its own custom query language and way of organizing the data. Eventually someone may write an abstraction layer to cover that and other, more widespread storage engines – but I don’t think that will be an especially easy task.

  3. Pete Johnson Monday, April 21, 2008

    I think the point of it is that you’d never have to run it anywhere else because Google will give you all the bandwidth you’ll ever need. It certainly requires you to drink some of the Google Kool-aid, but it would theoretically remove the “find a host” part of the decision making process. Then again, maybe you don’t want to lose that decision point.

    I don’t think this is for everybody, I especially can’t see large enterprises wanting to hand over that much data to Google, but if you are a smaller company the time to market gains would seem significant.

    I played around with trying to build a Twitter client with it and got quickly frustrated with the XML parsing not quite working right in the dev environment and it has no native JSON libraries. That’ll get fixed at some point, but it was fun to play with for a couple of days.

    It’ll be interesting to see where this goes.

    Pete Johnson
    HP.com Chief Architect
    Personal blog: http://nerdguru.net

  4. Marcin Grodzicki Monday, April 21, 2008

    Mike, the data handling is a problem, but one to be solved. If you didn’t see it already: http://preview.tinyurl.com/6yh35x – Chris Anderson managed to port AppEngine to EC2 quite easily – but with text files as database. No scalability here, but it’s a matter of time I suppose.

  5. Dean Landolt Monday, April 21, 2008

    I can only imagine Mike Bayer will have a compatibility shim in SQLAlchemy in no time.

    Chris Anderson said it would be trivial, so no problem. And I heard Mike counted to infinity…twice…

Comments have been disabled for this post