sorted by: recent | see : popular

Content Tagged with I/O + Google

The first day of Google I/O seemed like a coming out party for Google App Engine, the company’s competitive threat to Amazon AWS. For one, the registrations were thrown open to everyone, and for another, two new APIs were released: the image manipulation API, and (more interesting to web app hosting in general), the memcache API. Now the memcache API was something I expected from Amazon a long time ago, but perhaps they don’t use it themselves as much so it’s not in AWS.

With Yahoo in limbo and Microsoft missing in action on the Internet, Google is making a huge play for developer mindshare. As Microsoft and Sun both demonstrated very effectively, focusing on getting developers excited and making them happy is the key to the success of a platform. Google I/O appears to be Google’s big play for developers. And so far it seems to be working.

Google App Engine (GAE) comes with a webapp framework that’s derived from Django, but you can host your own, including CherryPy, Pylons and web.py, all of which are Python-based. No other language is planned at this time. C++ had AT&T, Java has Sun, and Python now appears to have Google behind it, so expect a lot more Python development activity in the global coding trenches. And a lot more Python books being sold.

The big difference between GAE and Amazon AWS seems to be that GAE commoditizes the application hosting layer while AWS commoditizes the hardware and network hosting layer. With GAE you don’t get to choose the web application stack. You provide the UI and the logic; Google provides the scalable datastore and the application hosting and analytics.

There are a number of characteristics about GAE that serve to give me flashbacks. First is the fact that all apps are hosted as CGI apps. I’m sure Google has a reason for this, but it seems so “early Internet.” Then there’s the fact that Google has created its own query language, GQL (pronounced JeeQuel). Facebook has FQL (how is that pronounced, anyway?), so what’s next, YQL? It’s like we’ve reverted back to the late 80s, when all the database companies mangled the SQL standard just enough so that data was bound to their databases in strategic lock-in. This story doesn’t end well for users.

Finally, the GAE Datastore appears to have a native hierarchical structure with parent-child relationships between entities exposed to the programmer in GQL. This harkens back to the hierarchical databases that preceded SQL and relational databases. The power of SQL was supposed to be that it was declarative, that you didn’t have to know how the data structures were implemented. But hierarchical database application code was viewed as impossible to maintain because your data model leaked into your application. The current iteration of the GAE Datastore seems to require a lot of premeditated syntax design on the part of the developer. It reminds me of how queries performed differently in Oracle depending on the order in which columns appeared in the query. I hope, however, that this is a passing phase and that we soon see a better abstraction in GAE.

In contrast, SimpleDB and CouchDB focus on tuples and dispense with the SQL baggage; they’re surprisingly forward-looking compared to the data models of Facebook and Google. While I’m not questioning whether or not the Google Datastore will scale as promised, some of the choices in how these facilities have been exposed to programmers are curious and have rough edges.

A comment about Ruby: While Steve Yegge’s recent article seemed to suggest that it was hard to promote new languages within Google, I spotted some signs at I/O that Ruby might not be shut out of the picture. OK, just two signs. For one, there is a talk scheduled that mentions Ruby in the title. Second, at one of the talks the speaker mentioned a device called “Radish,” described as a 20-percent time project yielding a device that operates on indoor solar energy and is used to update/monitor the meeting room schedules wirelessly. Apparently the data pushed through this device is managed by a Ruby app — yes, there’s a Ruby app running inside Google. He didn’t say “Rails,” just “Ruby,” so please don’t scream all at once, OK?

Other than that, the conference was Google Gears, HTML5, lots of Javascript/AJAX and of course, Android, Android, Android. There’s even a company selling a 12-hour crash course in Android to prepare developers for the October release. Today, who knows? How Android Google Gears app downloads the Internet and beams it to your desktop via Wi-Fu tubes?