Google announced a game-changing hosted platform for application development last night. Our initial enthusiasm at Union Square Ventures about this platform is captured by Albert over on our blog. I’m trying to tease out initial limitations in order to wrap my brain around the implications of this offering. Any insights would be much appreciated.

To get the ball rolling, the top comment on Hacker News is quite insightful. I haven’t verified all these limitations with my own research, but here’s a repost of “nickb’s” comment:

Lots of limitations:

- Python-only for now but the complete architecture is language neutral and they will add other language support (will rely on feedback on which language support to add next). Before they add a language, they need to ‘harden’ it (i.e. remove some features from it).

- Django is the only API that’s currently supported, can upload other framework(s) but you’re on your own (which will be an issue since there will be some issues with other frameworks due to other limitations)

- you cannot write to the filesystem - due to distributed nature of the system, you have no idea where the file will end up.

- you cannot open sockets! you can only use the limited API that they provide (URL & mail sending API). Forget about Twisted :(

- no threads (Google says they provide scalability in other ways)

- limits on how long an app request can run – forget about uploading large files for now.

- admin console contains version source deployment client (svn or git?) which means Google will have easy access to your source code. If you’re competing with Google, beware… Google potentially has access to your source code (and data of course) so you will have to trust them and their legal agreement! Definitely some conflict of interest is possible.

Update: Here’s the relevant info from the TOS:

By submitting, posting or displaying the Content on or through the Service you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.

Seems to me that there’s a lot of magic happening behind the scenes but you get simplicity for that.

Some of these limitations seem crippling, particularly the ToS.

Also, how do you create server logs if you can’t write to the filesystem (FS)? Or, how do you store any flat files at all (such as users’ uploaded content like images, audio, and video)? The limitation about “not being able to write to the filesystem” must be exaggerated… I’m guessing that users can write to some kind of file handling interface that places and retrieves flat files across Google’s distributed FS architecture… In other words, the FS is abstracted, but it’s still accessible. I’d love to get confirmation on this speculation.

What about the fundamental decision to create an insular platform that cannot be used a la carte, which is different from Amazon’s decision to provide a services architecture that can be used a la carte with other technology from other environments? It seems like Google favors reliability and scalability over flexibility, but is this choice necessary? If all a user wants is a scalable and reliable FS, and the user is willing to take on the liabilities of managing his own database, why is Google unwilling to address his needs?

How about SLAs? Without SLAs is anyone willing to build a business on top of Google’s platform? What incentive does Google have to provide SLAs that have some teeth? Amazon’s SLAs turned out to be pretty wimpy because they had no reason to create significant liabilities.

Other open questions?

While the tone of this piece may come off as bearish, that’s not my attitude at all. I’m interested in limitations because I want to figure out open opportunities and likely points of future expansion. I’m eagerly awaiting my invite, and I look forward to hosting my code on Google’s infrastructure.