Google Gears and Cloud Computing

All timestamps are based on your local time of:

Posted by: stak
Posted on: 2007-05-31 16:09:05

And now, for Google Gears (this post dedicated to gteather :)). First, I find the name "Google Gears" kind of fishy. It seems like a un-intuitive name for something that enables apps to work offline. I suspect it'll be expanded to do more than just that at some point. But that's just random speculation.

Gears seems to finally bring the runaway push-everything-out-to-the-web train back to the station. By using the local machine as a cache for data that resides out in the cloud, Google is fixing the one major flaw with its services - they depend on a reliable Internet connection. By doing this, Google has effectively arrived (in a roundabout but backwards-compatible way) to what I think is the ideal computing state of today.

I'm going to go on a bit of a tangent and describe what I think today's ideal computing state is. Here goes: all user data is stored in a cloud (by "cloud" I don't necessarily mean the Internet - it might also be, for instance, a network file server within some enterprise, or a home file server for a home network). By being stored in a cloud, it can be accessed by any computing device the user chooses to use - whether it's a desktop, laptop, palmtop, tabletop, cellphone, embedded device, kiosk or anything else.

Given that people are already having huge issues syncing their calendar and address books across all of their devices, having a central repository of user data in a cloud is absolutely essential. Also note, by "data" I mean not just calendar entries, but email, documents, media, application preferences - anything that is specific to the user. The data will have to be stored in a standardized format, so that rich clients will also be able to use them. Finally, the cloud has built-in version control. Obviously, this allows the user to retrieve older versions of documents, but also simplifies the process of modifying the data from many devices simultaneously (i.e. collaboration), since file locking and version control is something that we've known how to do well for a long time.

The final advantage to storing data in the cloud - and this is what really makes it worthwhile for the average home user - is transparent backup. By storing data centrally in a cloud managed by professional data-storage people, backups can be made against accidental loss and corruption. No more "Oops, I accidentally deleted my 20 gigs of email!" This is also useful in enterprise situations, where the sysadmins will control the cloud for the enterprise, and can ensure that all system-critical data is properly backed up.

As for applications that the user uses to manipulate the data: one of two things will happen. In the case of cheap-bandwidth devices (desktops, etc.) applications will be cached and run on the devices, but will be originally obtained from master application repositories also stored in the cloud. Updating the application is done by the OS automatically and seamlessly whenever a new version is released. This allows bugfixes and enhancements to propagate trivially. Every time you fire up an app, if you have a connection to the cloud, it will download and install the latest version before running it. If you already have the latest version, or if you don't have a connection to the cloud, it'll just use the version you already have.

The main concern most people have when it comes to self-updating applications is that the new version may be buggy and/or corrupt existing data files. This wouldn't be a problem because of the afore-mentioned version control on data. Even with version control, enterprises may object to self-updating applications because buggy versions may cause loss in productivity. This is also not a problem, because an enterprise would have control over their own cloud and application repository, and can update their application repository only when they are satisfied the new version is solid.

For the case of expensive-bandwidth devices (i.e. cellphones, which may be used on a roaming network in a country with a government monopoly on cell traffic), there will be rich applications that come built-in and need to updated only occasionally. These will cache data more aggressively to minimize bandwidth cost, but still, the data stored in the cloud is the master copy.

Side note: Keep in mind that this ideal state is a function of how people interact with computers. The current trend seems to be tending towards high mobility (people are constantly on the move) and device-independence (people have lots of computing devices), which makes the data-in-a-cloud part of it pretty essential. This wasn't always the case, which is why the ideal state of computing before was very different (personal computing as opposed to cloud computing).

Google has been inching closer to this state for a while. They store data in a cloud. Some of it is already version-controlled. It is backed up and safe from accidental loss (all your data is stored safely on GFS boxes). It can be accessed by anything with a browser, which includes just about any computing device worth using these days. Applications are also stored in the cloud (in the form of huge chunks of Javascript) and are automatically updated (your browser re-fetches any changes every time you access the apps).

There are still a number of things Google needs to do to finish up, and Gears is one of them. One of the implicit requirements in my ideal-state description above is a persistent connection to the cloud. This is where Gears fits in - it allows you to cache both data and applications offline, and transparently handles propagating changes to and from the cloud. This removes the need for a persistent connection to the cloud (which, as much as we want it, is probably not going to be guaranteeable for a while). The fact that Google is going to push the Gears API to become standardized and help browser vendors build it into their browsers also says a lot - they are serious about backing this project.

After looking it all over, Google is most definitely the closest company to the ideal state. There are a handful of things I can think of that they still need to do, almost all of it falls into the "cleanup" category. One of the main things is to allow users to have more control over their own data. Allowing enterprises/businesses to host their own data and application servers would be huge. Currently, Google Apps can be used by enterprises, but all the hardware and software is hosted by Google. This is going to scare away a lot of customers, who would rather have total control over their own data.

This leads directly into the prediction section of this big long post. In my crystal ball, I see...

Once Google has a few more apps (they've already bought Tonic Systems to round out their office suite), they're going to do some polishing and integrating. For instance, they'll provide access to user data in standardized file formats (e.g. making your Google Docs files available in ODF or UOF). Shortly after that's done, I expect them to roll out a site-license option for Google Apps. Enterprises (or other interested parties) will be able to license the Google Apps software suite (complete with email, IM, and office tools) and run their own cloud on their intranet.

In the long term, this, more than anything else, will be what pushes Linux into the mainstream. With no need for Microsoft Office and Outlook/Exchange, a lot of enterprises will be able to ditch Windows altogether and switch to Linux. People who start using Linux at work will then be more open to using it at home. (Dell will probably be in a prime position to take advantage of this, since they've already got a head start on selling pre-built Linux boxes, and will have trained support teams ready to deal with the inevitable deluge of confused users.) Of course, a lot of enterprises will still need Windows for other applications, and they'll probably start using Windows and Office Live, which by then, like most Microsoft products, will be nothing more than a pale shadow of Google Apps.

Oh, and where's Apple in all of this? In your living room. Or rather, your media room. You'll have one, won't you?

Posted by Dave at 2007-06-08 00:27:48
I think the "cloud" could reasonably exist on your home PC. Just having some nicer setup to allow connections to this data anywhere would be the step in the right direction.
[ Reply to this ]
Posted by stak at 2007-06-08 10:51:37
Possibly.. but then access is dependent on your home PC's connection to the internet, which is far less reliable than some data center with a backbone connection. Also, automatic backup wouldn't work so well..
[ Reply to this ]
Posted by GregT at 2007-06-10 21:28:44
Quality post Kats!

I think your vision of the future is exactly where Google is headed.

I must say, as much as the thought of building a typical complex AJAX application terrifies me, adding a technology like Gears to the mix makes it sound even harder, especially for some of the more complex office-suite type applications. I feel like I'm taking the easy way out by being a platform-dev rather than an application-dev these days ;-)

Google certainly has the talent, expertise, and server platform to build next-gen web-applications better and faster than any other company on the planet. I'm not saying it's intentional (this stuff is complicated!) but driving the Gears platform certainly extends that advantage.

I guess while Gears helps the web mature in a capability sense, I'm still waiting for the ease-of-development shoe to drop. While there should always be a bleeding edge for Google, Yahoo, Amazon, and hot-startup-du-jour to push what is possible... What about the other 95% of the world doing software development? I want to see if Google is a platform/service company or purely an application/service company that happens to be pushing at the boundaries of its platform.
Allowed expansions in comments/replies: [i]italic[/i], [u]underline[/u], [b]bold[/b], [code]code[/code], [sub]subscript[/sub], [sup]superscript[/sup], [url=http://some.url]linked text[/url]
Human verification: Sum of ten and fourteen =

[ Add a new comment ]

(c) Kartikaya Gupta, 2004-2024. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!