I hope this is a start of supporting and keeping up to date many versions of Django, the Python runtime and common libs so that the 1000 file limits can be used solely for applications running not all the libraries needed.

UPDATE: on the issue for adding Django 1.0 Guido chimed in on 1.1 support when it is out of beta and a nice switch that allows you to choose the django version, hooray! Maybe a python version selector and other libraries soon…

use_library('django', '1.0')

It's indeed fixed, though not yet documented.

To use:

1. Install Django 1.0 into the Python version you're using with the SDK (usually the
system Python).

2. In your app:
from google.appengine.dist import use_library
use_library('django', '1.0')

You no longer need to copy Django 1.0 into your app, nor do you need to mess with
sys.modules, sys.path and zipfiles.  (Though those instructions still apply if you
want to use Django 1.1 -- we'll start supporting that once it's out of beta.)

Note, Django 0.96 is still the default, and can also explicitly be requested by using
use_library('django', '0.96') -- in API v2, we'll probably change things so you
*have* to specify a Django version before you can use it.

We're contemplating the support of other open source packages as well (as long as
they don't contain C code).

It is still in beta but select developers are being added and developers allowed in will be expanded, I got in as I made the request so it looks like it is still filling up.

Both Java and C# were top requests on AppEngine desired languages/platforms.  They have low level support for specific Google features and infrastructure and wrappers around these features to mimic common java libraries like JPA, JCache and java.net around google urlfetch.  So it is still a bit locked to the platform or changes will need to be made to run on Google AppEngine and other environments.  

Many of the changes made to apps really are due to the scalable nature of the cloud architecture without such things as joins and limits on bulk processing, but in the end these points are really better for scalability from the start.  As for being locked to a platform we are already seeing copies such as AppScale that is an open source implementation of Google AppEngine.  So software architecture, data architecture and how we prepare for the terabytes upon terabytes of shared data in the future might be changing. 

Some unsupported features of major Java libraries…

java.net Features Not Supported

• The URL Fetch service does not support persistent HTTP connections. When the app accesses response data using the URLConnection object, App Engine calls the URL Fetch service to complete the request. After the response data has been accessed, the request data cannot be modified.
• The app cannot set explicit connection timeouts for the request.

Unsupported Features of JPA

The following features of the JPA interface are not supported by the App Engine implementation:

• Owned many-to-many relationships, and unowned relationships. You can implement unowned relationships using explicit Key values, though type checking is not enforced in the API.
• “Join” queries. You cannot use a field of a child entity in a filter when performing a query on the parent kind. Note that you can test the parent’s relationship field directly in query using a key.
• Aggregation queries (group by, having, sum, avg, max, min)
• Polymorphic queries. You cannot perform a query of a class to get instances of a subclass. Each class is represented by a separate entity kind in the datastore.

JCache Features Not Supported

• The JCache listener API is partially supported for listeners that can execute during the processing of a app’s API call, such as for onPut and onRemove listeners. Listeners that require background processing, like onEvict, are not supported.
• An app can test whether the cache contains a given key, but it cannot test whether the cache contains a given value (containsValue() is not supported).
• An app cannot dump the contents of the cache’s keys or values.
• An app cannot manually reset cache statistics.
• Asynchronous cache loading is not supported.
• The put() method does not return the previous known value for a key. It always returns null.

High Level Cloud Provider or Low Level Cloud Provider?

With other cloud providers like Amazon EC2, Mosso, SliceHost and others you can choose your platform.  But Google has an amaxing infrasturcture and taking advantage of BigTable and automatic scaling is nice expecially with a 300MB transfer free quota per app.  There are probably times when each type of provider might be beneficial, lower level like Amazon or higher level like Google AppEngine.

View the announcement here at Google AppEngine Blog which has other great news with the launch:

• Access to firewalled data: grant policy-controlled access to your data behind the firewall.
• Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
• Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

The slides from the video

Google AppEngine SDK has been updated

I really hope Google AppEngine can go 1.0 soon.  After the official launch of Amazon EC2 and other services out of beta, mosso, joyent etc it is getting hard to convince people to build on it until it goes out of beta.

Hoping for two things, 1.0 of Google AppEngine and support of Django 1.0 on that release officially. It is possible to run Django 1.0.x on the engine but it is painful using all that disk space (django has lots of files and google has a 1,000 file limit).

http://code.google.com/p/googleappengine/issues/detail?id=61

Microsoft also has been playing with entering the cloud with Mesh and now with “Strata”.  This would be a cloud for .NET developers.

There are already cloud providers for .NET mainly in Mosso’s offerings of any language being cloud enabled. But one from Microsoft will probably draw all the .NET developers to it like most Microsoft offerings.

Also, Amazon EC2 recently announced support for MS SQL Server and Windows servers.  So really any platform can also be used in Amazon EC2 in Amazon Machine Images. This took longer to happen due to the licensing per processor and server that most Microsoft software has.

This won’t be changing things much for me in the near term but having more platforms available in the cloud and on cloud systems is the natural progression.  At some point a platform might have advantages in cheaper processing but for now Python with AppEngine is still the best bet.

Next question is, when are they going to launch this out of beta?  I want to start using it for business.

We’re happy to announce we’ve released some small updates to Google App Engine. Among the more significant changes:

• More apps: Want to create more than 3 applications with your App Engine account? Now you can now create up to 10!
• Time windows for Dashboard graphs: Zoom in on the data in your dashboard to get a more accurate picture of whats going on. You can zoom in to see graphs for the last 24, 12, and 6 hour periods.
• Logs export: You can now use appcfg.py to download your application’s logs in plaintext format. Use appcfg.py –help for more information on how to download your logs.
• Send email as logged in user: If you’re using the users API, you can now send email from the email address of the currently-logged-in user.

Be sure to update your SDK and check the release notes for a full list of changes. Have more changes you’d like to see with App Engine? Let us know in our Google Group!

If you are a developer and not excited about the ability to make applications with no worry of scale or support in infrastructure, I am just not sure if you are a developer or more worried about change. I always have these ideas that end up being based on the fast that I would need at least 3-5 servers to pull off. Unfortunately when you are smaller or just trying out an idea you dont’ want to buy infrastructure for the most extreme case (large traffic spike) and then have servers sitting at 1% utilization the rest of the time. With cloud computing and service storage, this whole problem is abstracted away. Many times this is at a much reduced cost, you are only paying for minimal usage, not what your maximum usage would be.

One big element to the cloud computing rage is also that dynamic languages will win out. If you will note in all the new cloud technologies there is a recurring theme of BigTable/MapReduce datastores (eliminiating much of relational database ways), dynamic languages (removing static typing and adding flexibility for rapid deployment and development) and the developer has alot of freedom and power to innovate.

Consider cloud computing the point at which dynamic languages such as Python (maybe Jython, IronPython, etc), Ruby, and higher order parallel languages like Erlang won out. Google App Engine uses Python, SimpleDB from Amazon is built with Erlang, etc. These languages like Python and Ruby which are slower (Ruby is much much slower than Python, Python can hang with static compiled languages) but the scalability, ActiveRecord like BigTable architecture, and rapid prototyping ORMs which were previously seen as too performance intensive or slow could become moot with the power of Amazon or Google’s infrastructure.

It is just a real interesting time in technology, it a major leap, it should be recognized. If you are a developer or infrastructure specialist, you should be diving in.

To create a model:

class Person(db.Model):
  first_name = db.StringProperty()
  last_name = db.StringProperty()
  hobbies = db.StringListProperty()
 
p = Person(first_name="Albert", last_name="Johnson")
p.hobbies = ["chess", "travel"]
 
p.put() # creates/updates model and inserts data

To create an Expando model
Expando models are fun because they are dynamic. You can add properties to the classes on the fly and it expands automatically.

class Person(db.Expando):
  first_name = db.StringProperty()
  last_name = db.StringProperty()
  hobbies = db.StringListProperty()
 
p = Person(first_name="Albert", last_name="Johnson")
p.hobbies = ["chess", "travel"]
 
p.chess_elo_rating = 1350
 
p.travel_countries_visited = ["Spain", "Italy", "USA", "Brazil"]
p.travel_trip_count = 13
 
p.put() # creates/updates model and inserts data

Prototyping is extremely fast with Google App Engine. Python of course is always extremely fun to do. The winds are a changin’.

[ google app engine entities docs for the DatastoreAPI ]

What is the Google App Engine?

It is actually a bit different than I expected. I expected these services to directly compete with S3, EC2, SimpleDB and they do but as of right now you can only run Google App Engine apps on their servers. Amazon Web Services you can run on any server which makes for a much more flexible usage into existing apps. Not everything yet can be hosted in the cloud and having the access to store locally or in the cloud is key, right now Amazon has that right model for it. Amazon isn’t trying to be your authentication service or push you into other services, it is simply an extension of your domain. However Google’s offerings are very compelling here and threaten lots more markets than just amazon and salesforce but also hosting companies.

Google is looking like they are trying to take over the domain which might work but I am more for the parallel development. For instance, if you wanted to run storage on Google but computing on EC2 could you do that with Google’s setup, no. With Amazon you can swap out S3, EC2, SimpleDB for other things if you want. I like the componentized model much much better. Hopefully Google moves in the component model as well as their hosted solutions, this is very nice for upstart and getting things moving quickly though. Google does want to become the base.

On the other side, SalesForce is probably freaking out because if you use Google Apps for your business, this just adds in the element of business apps that can be run for entire small business infrastructure with Google Apps and any custom apps needed with Google App Engine. But they probably will adapt to use this within their systems, if it was more componentized and available outside Google App Engine.

I will post more on this when it has been through the wringer. As of right now Google’s service is extremely beta, limited on their servers and only available for small traffic. When they release pricing and more information we will see where the market falls for cloud based storage and computing.

A few things I really like about the new Google offerings is simplicity. They are using Python which arguably has some of the best toolkits out there for cloud development right now (boto being one of them for Amazon). They are pretty much using Pure Python and you can push up whatever libraries you want. They have Django and I will see if other templating engines like pyTenjin work up there. But also their configuration is in a simple format. Simple user formats I am fond of are Markdown and YAML. This is how you configure an app for Google App Engine, in YAML (Yet Another Markup Language):

application: myapp
version: 1
runtime: python
api_version: 1
 
handlers:
- url: /
script: home.py
 
- url: /index.html
script: home.py
 
- url: /stylesheets
static_dir: stylesheets
 
- url: /(.*\.(gif|png|jpg))
static_files: static/\1
upload: static/(.*\.(gif|png|jpg))
 
- url: /admin/.*
script: admin.py
login: admin
 
- url: /.*
script: not_found.py

However I see Amazon still being the champ here when comparing the current publicly known offerings. Hopefully Google is just testing their engines and infrastructure in a limited capacity and will open it up to componentization to run from anywhere, much like OpenSocial or other services like RESTful, XML-RPC, JSON-RPC etc. As of right now Google App Engine is too closely coupled for integration into many systems residing on servers not on Google’s environment.

I think Google’s App Engine service more closely matches the SalesForce.com type hosted SaaS rather than true cloud technologies just yet. It is a bit of a mix of both.

It sure is an interesting time seeing and participating in another game changing announcement and new pardigm and bend in the software market from local to cloud computing and storage.

• App Gallery
• Google App Engine Docs
• Google App Engine

Google has some nice setup though with these great Python libraries running for your disposal:

In addition to the Python standard library and the App Engine libraries, the runtime environment includes the following third-party libraries:

• Django 0.96.1
• WebOb 0.9
• PyYAML 3.05

They are using django templates, these are pretty nice I have taken a liking to Mako and pyTenjin but django framework is quite nice.

Here is a video walk through of the application run through. Basic Python templating app essentially in django.

Google App Engine Walkthrough

Click here to view the embedded video.

Guido Speaks

Click here to view the embedded video.