Google App Engine Logo. Most Cartoonish Ever.

Google releases a App Engine. I am more than happy to cover in brief the details. Reading documentations is something that I love to do once and only once.

In summary, Google App Engine allows developers to host fully scalable web services based on the technologies that drives other official Google Services. For a start, developers are given 500MB of web space and enough server resources to serve 200M megacycles of CPU per day, and 10GB bandwidth per day. Most applications will be able to serve around 5 million pageviews per month. That is a lot of computing power there.

First of all, the important links:

Google App Engine runs with the following:

  • Dynamic webserving, with full support of common web technologies
  • Persistent storage (powered by Bigtable and GFS with queries, sorting, and transactions)
  • Automatic scaling and load balancing
  • Google APIs for authenticating users and sending email
  • Fully featured local development environment

I have no experience in Bigtable and GFS for that matter. And according to the SDK, the current supported language is Python for server side code. Those well verse in PHP are out of luck, including me. But heck, it is one hell of good reason to pick up another coding language.

From what I understand, Google App Engine aims to take away the trouble in administering a web service away from the developer. This greatly allow independant developers to access massive computation resources without the cost and effort in procuring server, bandwidth and administrative talent. Very good news for developers.

The following sums up the intention of Google App Engine:

What is App Engine?

There are three key facets to the App Engine system that are important to understand.

First, Google App Engine provides an infrastructure for running web apps. By that, I mean that we’re focused, specifically on web applications: making them easy to run, easy to deploy, and easy to scale. App Engine is different than a lot of other things out there: App Engine is not a grid computing solution– we don’t run arbitrary compute jobs. We also don’t give you a raw virtual machine. Instead, we provide a way for you to package up your code, specify how you want it to run in response to requests, and then we run and serve it for you. You don’t reserve resources, or machines, or RAM or a number of CPUs, or anything like that. It’s a fluid system, that runs your code in response to load and demand.

What you define are the URLs you use, what code they map to, and upload an application. We do everything else.

This leads me to my next point: Another big part of App Engine is that we provide for the entire life cycle of a web app. By that, I mean that App Engine is a complete system. We provide ways to run your code, serve your static content, a database, request and application logs, methods to push new releases of your code, and more. Ultimately, we are trying to provide an simpler alternative to the traditional LAMP stack. This is a big leap for you to take, and this is a big challenge for us. We’ve got a lot of tools that we need to provide good alternatives for. What we’re trying to do, though, is to integrate all of these tools together into one system. We do this because we want to make the whole task of writing serious web applications easier.

Finally, the other key part of App Engine is that we’re providing you access to Google’s infrastructure. The APIs and systems we are providing to you are built off of the same distributed, scalable infrastructure we use to power Google’s other applications, like Google Accounts, GFS, and Bigtable. We’re giving you access to those powerful building blocks, and giving you the ability to write real code and real apps that make use of them.

Read more here.

And going into details, there are apis which will also comes with Google App Engine.

Datastore is to access the BigTable and GFS. Much like SQL servers, or MySQL for most developers on a LAMP stack. But according to Google:

The App Engine datastore is not a relational database. While the datastore interface has many of the same features of traditional databases, the datastore’s unique characteristics imply a different way of designing and managing data to take advantage of the ability to scale automatically.

Guess to the end developer, the result set is what as expected from a SQL server. And that should be sufficient for most app to function.

The User API is there becasue only users with a Google account can access and use a Google App Engine App. Hence the need for a User API to authenticate users using Google Accounts. Only the nickname and email address is accessible.

The URL Fetch API and Mail API are interesting. First the URL API. It allows HTTP request to be made, outwards to external servers to access data, or pages. This gives a lot of flexibility to the developers to access and integrate current non-Google services with Google App Engine. Want to grab a RSS feed to process? URL Fetch API is your hammer.

The Mail API does a simple task and that is to send a email from your app. That is all.

Guess that is a short summary of what is to be expected. I am on the waiting list for the developer key. Hard luck. Meanwhile the documentation should keep me entertained for some time.

Also, guess it will be good times ahead for those who know Python and especially the any Python Frameworks.

Also, more news of can be found at the following friendly places: