Enterprise Integration Patterns
Gregor's Ramblings

Google I/O

June 5, 2009

Gregor HohpeHi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also an Enterprise Strategist at AWS.
ALL RAMBLINGS  Architecture (12)  Cloud (10)  Conversations (8)  Design (26)  Events (27)  Gregor (4)  Integration (19)  Messaging (12)  Modeling (5)  Patterns (8)  Visualization (3)  WebServices (5)  Writing (12) 

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home: ArchitectElevator.com.

I guess I am the last person to blog about Google I/O. I am sure everyone already read about Wave and the free Android phone (with 30 day SIM!). I am just now getting to write this up on my flight back to Japan, so I’ll give you my personal impressions and viewpoints, if you are still interested.

Eric Schmidt Opening Keynote

Google I/O KeynoteGoogle I/O was a huge success, running smoothly with some 4000 attendees (and Android phones given out). Eric is hands down one of Google’s most accomplished speaker. His speeches tend to be inspiring and thoughtful, even though we tend to wonder afterwards what exactly he told us. He chose “It’s time” as his key theme. It’s time that bandwidth, available compute power, and simple programming models come together to make Internet programming available to a everyone. He spoke on the importance of embracing the Internet Programming Model, which is of course close to my heart.

Eric also reminded us that innovation is always elsewhere. And he did not bring this across as a “your job will go to Usbekishangalore” kind of way, but to remind us of the importance of platforms that support this type of innovation by giving global and easy access to internet computing platforms.

People are tired of complexity. Eric feels that we are just at the beginning of getting this (as in the Internet Programming Model) right. You no longer have to pick up a book on operating systems and programming interfaces (well, we do have 35-some API’s on code.google.com). Instead, you pick and choose, mashing up what you need. You do this in the cloud, which takes care of deployment, scaling, and management. I think Eric was spot on to remind us how powerful easy access to an amazing set of capability out in the cloud really is. People build cool mashups every day, such as telling the user the history of a building as you walk down the street.

Day 1 Keynote

It’s a tough act to follow Eric. Luckily, Eric and Vic Gotundra have quite different personalities, making a diect comparison unlikely. Clearly, Eric gave us the grand vision while Vic shows us all the cool products Google has been building. I actually wish we had a few sessions explaining how Google views the space (of cloud and Internet computing), as well as the role it intends to play in it. As expected, most sessions were product focused. But hey, a free phone lets us forgive a lot.

It took Vic only 30 seconds to make the first snipe at Microsoft: “We underestimated the Web” That’s certainly true, but the MS bashing reminds me of JavaOne a few years back, where instead of showing innovation in his own backyard, Scott McNealy would just ridicule Microsoft. I don’t really come to company A’s event to hear how dumb company B is. Maybe I am overly sensitive, but I guess honest feedback counts. And we saw where it got Sun.

The keynote focused on two areas this year:

Vic introduced the increased power of the browser with another Microsoft snipe: Back at Microsoft, they could not get adoption for XmlHttpRequest. Then Google Maps came along and presented the killer app. I wonder whose job it was to drive adoption back then :-) Actually, I think the killer feature of Maps was the panning of pre-rendered map tiles, which I don’t think use XmlHttpRequest, but modify the DOM and have the browser load the tiles. But I may be wrong. The most interesting comment in this context came from Erik Meijer from Meijcrosoft. He revealed that XmlHttpRequest was actually snuck into IE as a hack to make Outlook Web Access more responsive. Basically, like Gmail! At its day, Outlook Web Access was actually pretty neat. I feel a bit weird saying this, but it’s true – Outlook Web Access looked strikingly similar to the desktop app. However, Microsoft marketed this only to the Outlook enterprise crowd instead of exploiting the feature for broader applications. Maybe they were ashamed of the “hack”. So if there is a lesson to be learned: don’t be afraid to exploit hacks to the fullest extend if it gives you a killer feature.

Google I/O KeynoteBespin got a quick mention as one of the killer HTML 5 apps – a full-blown, responsive IDE in a browser (well, at least Firefox). I attended Dion’s session on Bespin later. Sign-ups for Google App Engine for Jave (GAE/J) are now wide open – no more wait lists. We actually saw some live coding for the App Engine demo. In my opinion, live coding in a keynote takes some guts, and makes for a great dynamic. Interestingly, in a conversation with Martin Fowler, Martin expressed that to him the value of a live demo is pretty small. I think he said that before the Wave demo :-) Maybe it’s the switch from PowerPoint (or Presently), which makes live coding appealing to me. I also like seeing something built from scratch to appreciate what it really takes, as opposed to having pre-made demos that may obscure the core of what the product does behind a lot of CSS and other machinery. Martin’s valid counter point is that it’s quite possible to explain cause (as in developer effort) and effect (as in product feature) without a live demo.

Back to the keynote, the next announcement belonged to Google WebElements. These elements allow you to easily embed Google gadgets, such as calendars, discussions, or presentations into any web page. Kind of like iGoogle without the “i”. Copy-Paste development for the Internet. We did notice, though, that despite the apparent copying and pasting, the presenter was taking some shortcuts in the “live” demo. I can’t blame him too much – if you are given a 3 minute slot in a keynote, maybe you do not want to wait for your app to deploy with every change.

The demos went very smoothly and were well rehearsed, but it felt a bit like JavaOne in 2000 – “look, we can have things move inside the browser.” In a funny coincidence, during the JavaOne keynote the Sun folks re-ran one of the original “rotating molecules” Applet demos. I think we are all happy that this is now possible using HTML 5 instead of Java applets.

Google Wave

The second day keynote was all about Google Wave, Google’s amazing new collaboration / document platform. This project was kept secret inside Google for some year-and-a-half (ticking off many people), so it’s cool to see the audience’s reaction. After an hour and a half of live demo, Lars and his team received a standing ovation. Wave is equally innovative and ambitious. As already described my many, it’s a combination of communication, collaboration, and document management. It’s a very interesting concept to see a conversation embedded in a document. You can play back this conversation over time later. The playback even applies to gadgets like a chess game. I am guessing that the internal model is that of an event-sourced application, which can recover the state at any point in time by replaying the sequence of events.

I believe making time a first class citizen has a number of powerful applications. For example, we have seen how being able to dynamically rewind time on a source code repository gives you valuable insights into the code evolution. One of the most difficult things in software is to unearth the intention and motivation. From the code we can easily see what was done, but it’s much harder to ascertain why it was done. That’s why comments such as “Loops over all values and adds them up” are so meaningless.

Lars admitted that the near real-time concurrent editing was the hardest feature. It’s certainly great for meeting notes. The spell checker was impressive. It’s context aware, so it can turn “icland is an icland” into “Iceland is an island.” Wave is an open platform, with a published waveprotocol.org. Alas, according to Lars the external API’s are almost same as the internal ones. Kinda like Microsoft Windows <cough/>.

One of the many neat features of Wave is that you can create robots, who can participate in a wave much like humans do. These robots can be built using Google App Engine, by virtue of an AbstractRobotServlet class. The honors for the first third-party robot must go to uebersmart ThoughtWorks developer Ola Bini, who demo’d his iokebot in an afternoon session, only a few hours after Wave was announced. My plan was to demo App engine at JavaOne by writing a JavaLawyer robot, which replaces every occurrence of “Java” with “Java(TM)-based Technology” Unfortunately (or luckily for my relationship with Sun), I was not able to get a Wave account in time.

AppEngine From Sparkplug to Drivetrain

Google engineer Alon Levi shared some of the internal App Engine architecture in his talk, AppEngine From Sparkplug to Drivetrain. A good portion is what you’d expect from high-performance Web app: separate database servers and app servers. Then scale out to multiple app servers and load balance across them. DNS round-robin as a load balancing mechanism is slow, so use a reverse proxy. Serve static content separately because it’s stateless and does not require an app server

On the database end, master-slave replication is a common technique. This scales reads, but not writes. As a next step, you can partition, or “shard” the data by spreading it across multiple database instances. But this requires a good amount of management on the side of the application. If data spans multiple partitions, the application has to deal with being able to perform joins, manage transactions, etc. across shardss. The next step is to move to a non-relational, but highly scalable and distributed storage infrastructure, aka Bigtable. On the front-end, external traffic hits the nearest Google data center and is then routed on the internal Google network. Google App Engine currently handles some 140M pageviews per day on this configuration, and I am sure it can go a lot higher.

Martin Fowler and Rebecca Parsons on App Engine

Martin Fowler was one of the invited third-party speakers. I am expecting that as Google I/O and Google’s developer community grow, we’ll see more third party talks at Google events. Martin gave a balanced view of the pros and cons of App Engine. Of course, deploying Java servlet apps into the cloud with the push of a button is unbelievably powerful. But there are also some limitations: the App Engine JVM is not 100% complete and has some holes, for example you cannot start new threads. Martin agrees that this is the right decision, but in the near term it means that you can’t use libraries that use threads unless they are open source and you (or someone else) rewrites them. Actually, at JavaOne someone commented that the Spring framework does not run on App Engine, but when I pinged Rod Johnson, he thought otherwise (and he would know). Spring is a fairly substantial framework, so it may be that some portions don’t run on App Engine. The good news is that as App Engine becomes increasingly popular, we can expect most Java-based open source projects to be modified to run on it.

Martin also highlighted that the local App Engine server, which is part of the SDK, is not an exact clone of server-side framework. For example, it’s missing the implementation of Google services, such as mail. Lastly, Martin is suspicious about the mapping of the non-relational Bigtable data store to an object model via JDO / JPA. This is no surprise given the many different object-relational mapping frameworks, each of which has its own quirks and limitations. In Martin’s opinion, the underlying model tends to leak, especially if your application is performance sensitive. I guess the presence of explicit index tables in the App Engine config file is an example of such leakage. But I think that such mappings can make your life much easier, as long as you understand the limitations and assumptions baked into the mapping layer.


Ex-Googler and now Mozilla tools hacker Dion Almaer and Ben Galbraith showed off Bespin, a browser based code editor that pushes the envelope of what’s possible in today's (or tomorrow's) browsers. These guys hit a home run by exploiting my weakness for live coding on stage. They set out to build a minimal text editor using JavaScript and an HTML 5 canvas element. From scratch. They feel that the Ajax libraries, e.g. Dojo etc, are donem so it’s time to move on to the next sexy thing, HTML5. They are not shy about exploiting the fact that Web developers tend to use a smaller set of browsers, so they don’t need to support Internet Explorer. Apparently, it is possible to get HTML 5 Canvas behavior into IE with a bridge or ActiveX. Yahoo Pipes apparently uses this for its smooth UI. In the same vein of making time a first class citizen, Bespin also allows you (or will allow you) to play back changes made to the code base over time. This way you can replay how other developers work. It could be quite exciting to see how rockstar developers create their open source code.

Sadly, I was too sick to attend many sessions on Day 2. But it's fair to say that this was the biggest and most successful Google I/O so far. Judging from the mood at JavaOne this year, Google I/O may indeed become a more relevant conference than JavaOne. I think the key points will be to branch out beyond Google speakers and to attract enterprise developers in addition to the Internet wiz kids. And it'll be tough to satisfy the crowd next year after giving out a free phone to every attendee this year.


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is an Enterprise Strategist with Amazon Web Services (AWS). He is a frequent speaker on asynchronous messaging, IT strategy, and cloud. He (co-)authored several books on architecture and architects.