Last week Google released Google App Engine. With this new service you can develop web applications and deploy them in the Google infrastructure. The benefits are: scalability (automatic load balancing, replication), fault tolerance, high availability, easy deploy, easy administration and… it’s free to get started!
Every Google App Engine application can use up to 500MB of persistent storage and enough bandwidth and CPU for 5 million monthly page views.
By the moment this service is a preview release. But is easy to figure out that this service will be fundamental for several future startups.
The runtime
The SDK is less than 10Mb in weight once installed and is very simple to use. You start the server and everything is reloaded when you make changes. So you don’t have to restart the server in any case. With one command you can deploy the application to the Google servers and with other command you can switch to a previous version if you, for example, inserted a critical error in the latest version.
By the moment you can only develop in Python 2.5. They are planning to support more languages. The community wants Java, Ruby or PHP to be supported. But in my honest opinion I think Java would be difficult to be supported.
If in a future Google adds support for the Java programming language I think it won’t be JavaEE standard. As with Android that isn’t JavaME standard and even it does not compile to standard Java bytecodes. I think it will be something much more easier to deploy than JavaEE. And you won’t develop servlets but something similar. But this is just my opinion.
The datastore API
The persistence API of Google App Engine has the following features.
- Scalable. You don’t have to worry about replication, fragmentation,… Even you don’t have to worry about indexes. When you are developing the SDK determines the indexes based on which fields are most used in queries.
- Easy to use. The data modeling API is very simple. You don’t have to create tables or synchronize them with your domain model. You just create a class that extends from db.Model (or db.Expando) and then automatically your class is persistent. It has methods for inserting, updating and deleting (put() and delete()). To query the database you use a simple query language called GQL similar to SQL. However you have the following restrictions (or features
).
- Your classes have one and only one primary key. This key is auto-generated.
- There are no JOINs. In a distributed and scalable environment is pretty difficult to implement an efficient mechanism to support JOINs Google has said.
- You have a set of available data types.
- No tools for getting data on and off Google App Engine. But Google is working on it.
Other APIs
The runtime comes with other interesting APIs
- Users API. An authentication API based on the Google accounts. Isn’t it more or less similar to Microsoft Passport? I would love Google supporting OpenID. Google joined recently the Dataportability Working Group (that defines the OpenID standard and others). Also several developers want support for OpenID in Google App Engine. So, in my opinion, OpenID support is a MUST.
- URL fetch API and Mail API. Some Python standard APIs such as threads, sockets and some functionality related to the file system are disabled for security and scalability reasons. So Google provides these specific APIs to let your applications consume web services or send mails.
What about Amazon
Amazon has well known web services that compete directly with Google App Engine: SimpleDB and EC2. But I think Google App Engine is better for some reasons:
- Free to get started.
- SimpleDB has huge limitations. However Amazon is planning new features.
- Google App Engine is absolutely easy to use. You don’t have to care about how many servers you need. How much band width. You don’t have to care about elastic IPs or things like that. And deploying is soooo easy in Google App Engine.
Nevertheless with Amazon you get much more flexibility. You don’t have the restrictions of the Google App Engine runtime (language, APIs,…) and your application won’t be Google-specific.
By the moment Google doesn’t compite with Amazon in file storage. Google App Engine free accounts provide you with only 500Mb. However you don’t need more: you can’t write in the file system. Maybe 500Mb are sufficient if you need to store images uploaded by the users (for example). In that case you can insert them into the datastore as Blob objects. In other case you can purchase more disk capacity or you can use Amazon S3.
Conclusions
Google wants developers to build great web applications that interoperate with their systems.
- You develop with Google-specific APIs.
- You have an API that authenticates users with Google accounts.
- All your data in the datastore can be converted to GData (just .to_xml() in your domain classes).
A great service with great features. But, too much Google-centric? Yes, but it is by far the best service I’ve seen since Amazon S3.
Nice pot there.
Don’t forget about the BigTable that Googs has which allows scalability at the cost of lock in whic is far too scary and too ‘Google-centric’. And though, it takes a lot of work to deploy to the Amazons EC2, it still is pretty open and neutral at this point.
You may want check out morpheXchange.com, which is built on top of Amazon and currently available for Rails only. It makes apps deployment a cinch.
Best.
alain
Comment by friarminor — April 17, 2008 @ 6:53 am