Feb 262009
 

The recent outage of Google Gmail, which also affected users of Google Apps (word processing, spreadsheet, etc.) is yet one more reminder of how organizations need to carefully weigh the pros and cons of using on-demand or cloud-based applications and services. As I wrote last August, in response to a larger outage in which Gmail and Apps were down for about 15 hours (and have copied below), I don’t believe that Gmail and Google Apps are really up to supporting large, enterprise end-user organizations at this time. I do think they can be considered useful for consumers and for some small companies, as well as for specific departments, groups, and selective applications. In fact, I use Google Docs and Gmail sometimes when I’m on the road.

Google Apps and Gmail Crash: Cloud Computing’s Limitations Exposed?
Cutter Consortium Enterprise Architecture E-Mail Advisor
August 27, 2008

[…] Just last week, however, we saw Google receiving a lot of criticism because its on-demand Gmail and Google Apps services went out for approximately 15 hours. During this time, end users were either afforded spotty service or were unable to access their Gmail or online applications altogether. Therefore, the big question is: does this incident expose the limitations of cloud computing? In other words, if Google can’t keep its on-demand e-mail and office productivity applications working, should end-user organizations consider using applications that are more comprehensive, such as ERP and CRM?

The answer to the first question is yes: this outage does expose the limitations of cloud computing. How could it not? Many users were unable to access their e-mail and other applications. The answer to the second question depends to a large degree on the amount of risk you are willing to accept and the service-level agreement (SLA) you are able to get from the service provider.

First, let me say that I don’t believe that Gmail and Google Apps are up to supporting large, enterprise end-user organizations. Sure, they can be considered for small companies and for specific departments, groups, and selective applications. However, I still believe that it is risky to think that they can support a larger organization’s overall needs. These are my own gut feelings, and I’m sure the Google folks would argue otherwise and can even point out to me some large, enterprise customers. (But I’d still need to see exactly to what extent these enterprises are actually using Gmail/Google Apps.)

Gmail and Google Apps are available in two forms: a free standard edition and a premier edition, which costs US $50 (user account for one year). According to the Google folks, only the latter offers a guarantee of “99.9%” uptime. Thus, the free service provides something else and these users really don’t have much room to complain. The premier users certainly have a viable argument that Google let them down — depending, of course, on the length of the outage they had to endure. Moreover, that’s something they’re going to have to carefully assess and go over with Google.

I believe that this incident is going to have people rethinking whether they want to use cloud-based or on-demand services to support their organizations. Judging from the some of the comments on the various blogs and newsgroups, this rethinking is already underway. The bottom line, however, remains that cloud computing and on-demand applications are still works in progress. And whether an end-user organization should consider using an on-demand e-mail service or a set of office productivity apps, or a hosted CRM or ERP system, comes down to the degree of risk the organization is willing to take, the service provider’s key practices and performance record, and how comprehensive an SLA you can get. The type of application is important, too. All of these should be carefully reviewed and considered. For example, a project workgroup could probably get by without e-mail for 15 hours. It would certainly be inconvenient. What about your overall company? Could it get by for 15 hours without e-mail or collaboration or word-processing? Obviously, it depends on the company and its line of business. Then substitute this scenario with the nonavailability of an on-demand CRM system or a hosted ERP application or service. Now compare this with how often your own organization’s on-premise e-mail, CRM, ERP, etc., systems are down. See, it doesn’t boil down to a simple black or white or yes or no answer. Finally, when it comes to any SLA, it should be worked out in utmost detail. In other words, as with any business contract, there must be a “meeting of the minds” so that there is no possibility of misunderstanding and nothing is left to chance.

I still believe that it is risky to think that Google can support a larger organization’s overall needs. As I wrote in August, these are my own gut feelings, and I’m sure the Google folks would still argue otherwise and that they can point out to me some large, enterprise customers. Eventually they may become bullet proof enough, but that time is still down the road a ways. I know that some will counter that their own company’s e-mail systems frequently experience outages. And that’s certainly true. But it’s one thing to have e-mail out for a while, and quite another not to be able to access your word processing, spreadsheet, presentation, or other desktop productivity tools.

Discussion

  4 Responses to “Gmail Outage: A Reminder to Weigh Pros and Cons of the Cloud”

  1. A sensible and widely-recommended approach to security and integrity issues is to apply cost-benefit analysis. To do this, you first determine what the risks are of any given problem arising. In exact numerical terms, if possible.

    Unfortunately, the first thing you then notice is that the term “cloud” specifically denotes a system none of whose internal details are visible to you. Such as risks. It’s what carnies used to call “a pig in a poke” – you pays your money (or not), you takes your choice, and you get whatever you happen to get.

    I wouldn’t recommend Gmail for anyone who relies on sending or receiving email. Sure, it has a good record of reliability. But we don’t have any guarantee that record will continue. Until quite recently, “money in the bank” meant “safe as houses”… er… If you see what I’m driving at.

    Free services differ greatly from free software. In the case of free software, you get the code so you are in a position to cope with any problems that arise. In the case of the cloud, all you get is “past performance” and hope. To quote the title of Rick Page’s excellent book, “Hope Is Not A Strategy”. I can think of a few places where that should be etched into the walls in letters a foot high.

  2. avatar

    I agree. The problem with the cloud is that things are abstract: where’s my data? How secure is it? Would I even be notified if it were compromised? SLAs are only somewhat of a guarantee, because there’s a good chance that the cloud provider outsources some of the management tasks as well. The risk is in the unknown. There seems to be this opinion that “clouds are inevitable, so just get over it, that the business is going to end up using cloud-based systems…” and you don’t want to be seen as standing in the way. And this may eventually prove true. However, when all is said and done, it is the end-user organization (your company!) that is going to be held accountable for any breach or privacy violation, etc. Consequently, although it may be seen as not embracing the latest technology or business model, asking the tough questions now about clouds seems the pertinent thing to do.

  3. Architecturally, Technically, there’s no inherent barriers to achieving four or more 9’s (%99.9999+ ) availability for Cloud Based applications.

    Let’s also take the case of Twitter (everyone else has?). I find it fascinating to observe services like Twitter emerge, become rapidly popularized through viral marketing and media buzz, and before the founder and thirty-three employees even understand the implications for monetization and potential application of the service, we see issues with scalability and availablity arise. Should anyone be surprised?

    I think the underlying challenge for all the Google’s, Facebook’s, and Twitter’s of the world, will be to understand “What is the real business case/model for ‘free’ Cloud Based applications?”

    In other words, what is the most effective means to monetize “free services” (is that an oxymoron?), without being intrusive to consumer, and through that monetization, allowing the “just in time” build out of required Cloud architecture to support the service levels of availability (be it one or nine “9’s”), required by the consumer.

    I’m enjoying this discussion thread…

  4. avatar

    This is an interesting topic. Regarding monetizing free services, people point to Twitter. But take the case of Youtube–correct me if I’m wrong, but I believe that Google is still struggling to make money off of this acquisition… Regarding building out the architectures for such free services, youtube seems to be quite reliable. At least I’ve not heard of any availability problems with youtube. But even if it went down for a an extended time, it’s a free consumer service (for the most part). So if someone weren’t able to watch the latest consumer created video, it would hardly present the hardship that would take place if an organization’s on-demand CRM or what have you application went down for an extended length of time (say 10 hrs or more). This is one of the reasons that I’m somewhat apprehensive about Amazon’s “enterprise” cloud offerings. Amazon is obviously good at managing the infrastructure for its webstore (consumer focused), but how experienced is it really for hosting/managing other companies’ enterprise applications?

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)