The App Engine announcement has sparked quite a flurry of reactions. The biggest arguments seem to revolve around ownership versus convenience. This seems very important, but at the back of mind I wonder why XML documents are not more involved in the announcement.
When I think of Google, I always think back to my college days and the descriptions of how they designed their data store. There was a definite document centric nature about it all that I really appreciated, which alludes to my document centric view of XML. What surprises me about App Engine is that the data store mimics SQL and the RDBMS using something like SQLObject, instead of exposing its document storage and indexing patterns. For me personally, I would have really enjoyed seeing a break from SQL (or GQL in this case) in favor of something more document centered.
The other big surprise is the absence of decent XML tools such as XSLT. Including the Python standard library is a great feature that anyone paying attention to the IronPython and Jython conversations immediately appreciate. But, for those working with XML, the best tools are not included in the standard library. Personally, I’d love to see Amara and the 4Suite libraries included. I’d settle for lxml. I’m assuming ElementTree is included, but in all honesty, it never has felt as natural as Amara and 4Suite. XML and how it interacts on the web has always been of interest to me philosophically, but Amara really made it practical and enjoyable.
Technical nitpicks aside, I’m really excited about App Engine. If nothing else, App Engine lets you deploy relatively pain free. If you’ve ever had to deal with setting up Apache/Lighty/Nginx with Mongrel and Monit to run a Rails application, hopefully you can understand the benefits. The deployment issue is what makes PHP such a great platform. I started programming with PHP simply because it was trivial to get started. Hopefully, as people begin to emulate this pattern, we’ll see the same easy deployment for both Python and Ruby, which is one more step towards having both an expressive language along side practical usage.
I'm not too worried about lock-in. After all the AppEngine itself is entirely open source, so there's nothing to stop you hosting your AppEngine project anywhere you like.
Of course the performance may not be as good as it would be using a genuine BigTable back-end, but since it's open source how long before alternative back-ends and associated services get contributed into the mix? For example modifying the SDK environment to use an RDBMS backend for BigTable storage requests shouldn't be rocket science to implement.
@ Simon
I agree that most of the lock in is probably not to big of a concern. The data lock in could be mitigated by wrapping something like Boto and talking to S3. Also, the actual code, since it runs WSGI, should be pretty easy to move around.
The big migration issues I would see is trying to mimic the deployment and scaling details. I'd imagine once you get used to it, going back to deploying yourself and dealing with the scaling could be difficult.
Of course some people have been arguing that Google will be buying up the apps that do well. It is possible that by the time your application scales to the point where you'd want to take more control, you already got an offer from Google :)
I think if you run your own installation you could take advantage of 4suite, if you're running it on your own server, or any other c python libraries.
However it is interesting that Google isn't giving robust xml support for apps that run on its servers.
Re. XML support:
You can use any XML ttolkit that's writen entirely in Python, but that does unfortunately rule out 4suite and thus Amara as well. Probably the way to get these into AppEngine is to get them included in the Python standard library.
That didn't take long: http://appdrop.com/