Gmail had its biggest failure yesterday. Both Google Apps and regular Gmail users were affected. For many people at work here at Arc90 – there was no way to get to your email. The outage affected tens of millions of users.
Email is not about sending and receiving messages anymore. It is about storage. It is about your professional and/or personal archive that you dip into many times a day. With a solution like Gmail, we’ve chosen to centralize everything: the user interface, our history of information (both messages and attachments) as well as the all-important task of sending and receiving mail. And here lies the flaw around such over-zealous centralization: when it goes down, it all goes down. Let’s just be thankful that our data returned this time around. The worst-case scenario is the permanent annihilation of our email history.
There is no reason why our email history should be soley centrally stored and tapped as needed by a web browser or mobile device. For all time, email lived in numerous places, especially in enterprise environments. Outlook may tap Exchange server for messages, but it mirrored your content locally. If your Exchange server went down, you had your data. Now everyone is talking about how we all need Google Sync for Gmail so we can recreate the benefit of mirroring local and cloud storage. A common, widely-available feature in enterprise email is now highly sought after again in an unduly complex, roundabout way. Syncing is a pain in the ass.
Imagine your IMAP or Exchange server going down and the outcome isn’t just no email but no email client. If the mail server goes down, Outlook or Apple Mail won’t load at all. Again, we drank the centralized browser-centric Kool Aid and failed to see how we actually took some steps back. I don’t need a server to send down buttons and levers around my information each time I access email. Marc
Which Direction Are We Coming From And Which Way Do We Go?
So which way do we build out? Do we work our way back and out of the browser with tools like syncing and such or should we web enable existing client apps? Microsoft’s Dare Obasanjo touched on this very point:
When it first shipped I was looking forward to a platform like Google Gears but after I thought about the problem for a while, I realized that such a platform would be just as useful for "online enabling" desktop applications as it would be for "offline enabling" Web applications. Additionally, I came to the conclusion that the former is a lot more enabling to users than the latter.
The culture of web applications, with its focus on "shipping software" and "access anyware," has gleaned over key features that while not sexy or enticing, really show their value when the s%#t hits the fan.
Yesterday was a low probability/high impact event. They are going to happen. What we can do is tweak the chain of dependencies so the failure isn’t so centralized and far-reaching. Oddly, it may require that the "revolutionary" culture of Web software take a good look at taking a backseat to desktops for once.