It can be illuminating to compare the strategies of the major cloud platform vendors. Instead of matching currently exposed features, let’s imagine what each major player could do to tack away from competitor strengths and toward their own. For example, Google.
Unlike Amazon Web Services or Microsoft’s forthcoming Azure cloud, Google’s overall application architecture is firewalled off from direct developer access. Yes, AppEngine can be addressed directly, as can the Google APIs. But to date there is no easy way to engage with Gmail Labs unless you are a Google engineer with 20% of your time on your hands. If you’re a Salesforce, you can invest in API connectors and leverage your own cloud. Or you can add gadgets from your iGoogle toolchest.
But harness the viral power of the social media wave and its central driver — the realtime experience? Google shuts you out as a power user developer, and in the process cedes the ball to smaller players. Take the central console experience as embodied by the Gmail/GReader/GApps container. IM feeds and services from FriendFeed, Twitter, TwitterSpy, Identi.ca, the open sourced Jaiku, and Leo Laporte’s XMPP engine (to name just the most visible) overwhelm the screen real estate. Yet there are limited tools to orchestrate these streams before they hit the IM stream.
Then there’s the lack of intelligence in managing these multiple windows. Each reboot of FireFox mandates popping out the same set of windows and then dragging and resizing them into position. FireFox 3 added auto-recovery of tabs and their contents, but a FriendFeed realtime Gtalk IM pop-out when recovered has to be closed and reopened. No smarts, no access to user configuration, no continued disruption.
Combining access to screen coordinates and routing of information to IM windows would likely result in an explosion of third party developers and aggregator tools. But what would happen to Google Reader in that scenario. Already we’re seeing growth in FriendFeed rooms as a workaround for GReader’s relatively locked down UI. Reports of the official release of the API notwithstanding, even then we still wouldn’t have access to the larger Gmail container to integrate the Google services under user control.
By contrast, Live Mesh and eventually Azure may well offer console control on a device by device basis. It’s not that Google has a less expansive architecture, it’s that Google doesn’t appear interested in opening the platform up at the user level. Part of the reason may be the complexity of integrating the various teams across the company, but more likely the company hasn’t seen a compelling reason for opening up more granular access to its crown jewels, namely its advertising services.
Think about it. If we could interactively configure our screens to reflect our interests, publish them out via a social graph to our natural affinity and peer groups, and then test content and information flow against advertising models until we find the best mix…. The growth would be explosive, the stickiness fly-paper strength, the incentive for third parties to build and market to power users an offer they couldn’t refuse.
Console real estate is the coin of the realm in the realtime wars. We see the early battles being played out at the rich client interface level, with Twhirl and TweetDeck the most obvious examples. A level down at the routing layer, FriendFeed is way ahead of the social media pack, with a similar business model clash holding back Facebook and Twitter from leveraging their market clout.
In retrospect the real estate crash was easily predicted, but not acted on until too late. Google has been somewhat responsive to critiques of its realtime strategy, most recently offering promises of improving Feedburner latency when pressed. It remains to be seen if the company will be more transparent about its application framework. At its simplest, the question is: will Google open up its console? Final answer?