Impressions from the development of the applications under Google App Engine

Impressions from the development of the applications under Google App Engine are quite positive.
It is finally java. The development on familiar j2ee platform is pleasant. It also gives the sense of freedom to move to other platform if needed.
The good part: very easy to kick off the development. Eclipse plugin does everything and smiles to you. No more headache integrating debugger with tomcat or other container. Most of the debugging is done locally, which is very convenient.  Deployment to GAE is performed by one button click.
Briefly, the limitations are following: 30 seconds per request, no threads and the mandatory use of datastore to persist data.  First two are more or less easy to understand. The third one is a game changer: no more SQL. We are given the distributed hash map wrapped with JDO.  Its capabilities are impressive - especially the ability to query by non key properties. Here comes interesting feature of mandatory indexing. You must have index on all properties used in WHERE clause. The nice part is that the development server builds them automatically by analyzing queries during the debugging phase. The main limitation, widely discussed over the net is maximum of 1000 objects per result set. It sounds weird and it is a first time I see such an intrusion into my programming freedom.   But instead of complaining I would like to analyze why such limitation is enforced.
I think Google is trying to ensure proper practice on building scalable applications in the cloud. They ask us to do pure OLTP system. Do small things at a time. Use async requests for other services when you need more work done per request (here I refer to URL fetching service). Spawn small async tasks whenever possible (good for multicore architecture). All this sounds perfectly reasonable to me. However I already hear questions – what about the batch processing? How to do analytics? How to make mailings to many users? How to perform heavy upgrade process? And these complaints are perfectly valid. You can not build a system without those long, CPU intensive tasks. But I do not think that the OLTP optimized framework and runtime can be suitable for this type of processing. I assume that Google will introduce some other framework for the batch processes. We can speculate that it might be a kind of MapReduce, which is perfect for performing massive processing, while does not provide any kind of real time response.
To summarize things: It seems that by now Google has realized that building both short and long processing procedures in the same framework is not a good practice and tries to prevent us from using this practice by brute force.
And we are yet to see the second part of the GAE - slow and powerful. One could imagine that it will look rather like a bulldozer, not a jet plane.