Paul Kinlan’s Development Blog

Having just got on to the Beta of Google App Engine I have been investigating its features and I can’t help but think that if Google pull this off, traditional hosting providers really have something to worry about.

If you look at the quota page (http://code.google.com/appengine/articles/quotas.html), look at what you get for free at the moment.

Quota                              Limit
Emails per Day                  2,000
Bandwidth In per Day         10,000 MB
Bandwidth Out per Day       10,000 MB
CPU Megacycles per Day     200,000,000
HTTP Requests per Day       650,000
Datastore API Calls per Day  2,500,000
URLFetch API Calls per Day  160,000

Admittedly, you only get 500MB of storage, if it wasn’t for that My Topicala site (http://www.topicala.com/) could easily run on this system!

Niall Kennedy has some great coverage of it on his blog (http://www.niallkennedy.com/blog/2008/04/google-app-engine.html), some of the missing features he has found are as follows:

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. You can rely on Google services (and branding) for 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.

 

Still, even with these missing features, the package is formidable, you get the back up of Google’s infrastructure.  One thing I could add, is that it appears that the application you are creating is hosted by Google, so you wonder if the applications developed on this will suffer the GeoCities effect where nobody trusts them because of a bad experience with one or two sites.

I have been thinking about this and I think that even this early on in the public versions of this development it is a winner.  For instance:

• Most people use RDBMS because they think they have to, when in actual fact quite a lot of data access can be done either against a single table or in a Persistent Hash Table, simplifying the data access may help developers create sites very quickly.
• Most applications don’t have anywhere near the daily bandwidth requirements that Google offer, and if they do in the future I am sure Google will allow you to scale for a fee.
• Most sites and applications need to manage users including registration and maintenance, using Google’s User Infrastructure from a developer’s perspective we shouldn’t have the hassle of creating this infrastructure and from a users perspective we have one less password and account information to maintain.  Maybe in the future they could use an OpenId infrastructure, or a developer might create an application on this platform that opens Google’s User accounts up to allow Open Id sites to take advantage of your Google account.

So what services to Hosting providers give that Google doesn’t?  Multiple languages - Google only allows applications to be developed using Python.  Sometime constraints make for better programming and better innovation, and you wonder if you need all the services that hosting providers offer.

Anyway, I am trying to work out how this affects Amazons EC2 (I suspect not much - they are two different things) and what applications I can create.