Why GMail is Disruptive

Blogged by: Karen Hobert

Yesterday I was asked to comment on a series of blog posts my colleague Guy Creese recently made regarding Google Apps for the enterprise and how I felt about his commentary. For background here are links to the posts in Guy's blog, Pattern Finder:

1. Google Should Announce Google Exchange (April 8, 2008)
2. Stark Reminder: Gmail Is Still in Beta (April 17, 2008)
3. A SaaS Lesson for Microsoft: Simplify the Licensing (April 18, 2008)

The person who asked my opinion was concerned that Guy was being too biased towards Google in his posts and what I thought about his commentary, especially regarding the challenges he's posited to Microsoft. I think this is a great discussion and thought that I'd share it with you as well.

I actually agree with Guy’s observations on the situation. First, in my opinion, I don’t feel that Guy has ever sung the praises of Google or Gmail as an enterprise solution. I've always found his commentary to be thoughtful and he hasn't been afraid to point out the warts. Read the Guy's recently updated report "Google Apps in the Enterprise: A Promotion-Enhancing or Career-Limiting Move for Enterprise Architects?" if you want proof. However Guy has highlighted some very important dynamics that are making Google disruptive for enterprise e-mail vendors including Microsoft, IBM, and Novell.

• Organizations are fed up with e-mail costs: costs for licenses and resources are skyrocketing and IT managers are looking for a cheaper more cost manageable solutions. Google Apps is extremely attractive to companies that are frustrated with the cost of maintaining e-mail. This is a very emotional issue and the reality of running an enterprise on Gmail becomes a secondary priority when facing a huge IT savings (and CIO cap feathers) in these economically strained times. Licensing and system management complexities are a big complaint with respect to Exchange. Even hosted Exchange services are more costly than other hosted e-mail options. For example, the average per user, per month cost of hosted Exchange is ~$15, contrasted with hosted Zimbra or other e-mail which is around $5 per user per month. That’s a $120 per user per year difference. So Guy’s point about Google’s simplicity model is very valid and its turning heads of IT decision makers who are looking for ways to solve e-mail cost problems.
• Decoupling e-mail services from clients is a good thing for customers: Guy’s point about using Gmail as a messaging engine but letting end users work within Outlook is very compelling to organizations. IT is finding it difficult to meet the demands of users who are familiar with Outlook and the demands of the business to manage costs. As Guy mentions, Google is very close to having a solution for customers in this position. This is a dynamic that could be very disruptive to Microsoft and other enterprise e-mail vendors. E-mail vendors such as Novell, PostPath, and Zimbra have created Outlook connectors for their mail systems so users can keep working in familiar tools. After all it doesn’t matter to users if the e-mail back end is Exchange, Gmail or something else, just as long as the e-mail is being delivered and received. Removing the need to convince end users to use a new e-mail client means that you only need to convince IT that a platform move is a good idea. Big win.
• You get what you pay for: I don’t think Guy’s post on Gmail still being beta is a retraction of his earlier post – after all his earlier post made the point that he felt Google was on “it’s way” and is not “there” yet. The post is a valuable warning that “you get what you pay for” in these circumstances. That any organization needs to enter into this e-mail business with open eyes (OK, I’ll stop with the aphorisms). The real question is what are the trade offs for moving to Google? Since this decision is placed in IT's hands it’s hard to argue against the substantial cost savings that Google represents. IT should do its homework to know what is lost for that savings and then turn the decision around to the business. Is the business willing to loose certain assurances that the current system provides in order to save the money, such as a Gmail outage?

Some customers that we’ve spoken with have said that Google Apps is 10% the cost of their current e-mail system (Exchange or other). A 20% savings might not be worth the effort and disruption of changing the e-mail system and the organization can likely manage to squeeze out a 20% savings from within their current environment. However, an enterprise would be negligent if it did not investigate something that might mean a 90% savings. That is what is making Google so disruptive. It isn’t a foregone conclusion that the customer will switch to Google but they at least should do their homework and find out what they are getting for their money. This investigation will likely include looking at other hosted options, including hosted Exchange. The problem Microsoft is facing is a market perception that Microsoft is more expensive. Right now Microsoft is offering entitlements for customers for its hosted services; however that doesn’t address how it will make Exchange less expensive over time. If hosted Exchange could beat Google’s price (say $40 per user, per year) then Microsoft would likely find itself inundated with phone calls for the service.

I also agree with Guy’s reaction to the numbers provided in the Cemaphore Systems' MailShadow Press Release (March 26, 2008). They indicate that something is going on and that people are looking for answers. I agree with his assertion that Google Apps is grounded in the SMB market and that most enterprises are probably looking at Google Apps from a “kick the tires” perspective. Like Guy, I expect that Google Apps will fall short of enterprise requirements. That said, enterprises may find that certain segments of the workforce, those non-information workers who don’t generally use Office, might be fine using Google Apps (or maybe just Gmail). I expect that large enterprises are looking to Google or other hosted options to provide e-mail services to those users while maintaining more robust e-mail services, such as Exchange, for users who need more than basic e-mail. Being able to integrate the two platforms (e.g., common directories, centralized management) will be paramount to these types of customers.

Comments

[Nicholas Fiekowsky]

Karen - you & Guy are getting closer, but you haven't touched on infrastructure - the wind beneath the cloud. Google has a 10x - 100x capacity / dollar advantage. Plus scalability, massive multi-threading, distributed operation...

Start with traditional IS design assumptions:

- Any specific application or middleware runs on a small number of servers and dedicated storage systems.

- Hardware efficiency is relatively unimportant since capacity / dollar constantly improves, and is relatively small compared to total project cost or business value.

- Therefore the servers and storage should be bulletproof. Redundancy provides reliability - dual data paths, dual power supplies, parity checked memory, RAID for disk, clustered processors, DR site with replicated configuration...

- Since the component count per application is relatively low, management cost per component is relatively unimportant. Also, specific component failures will be rare. They should not stop the application but are likely to introduce a potential single point of failure. They therefore require prompt human intervention to address the problem - replace the failed drive in the RAID array, failed processor in the cluster, broken SAN or network component...

- Since applications run on a small number of servers, parallelism/threading is relatively unimportant. Transaction-level parallelism with record-level locking is adequate.

Microsoft SharePoint is a poster-child for this design heritage. ALL data is in MS SQL Server. MS SQL Server needs lots of disk acreage per megabyte of data, and it's gotta be high-performance disk to support a database. Oh - did you remember to set up a duplicate configuration featuring those acres of high-performance storage to provide high availability / disaster recovery?

An online Microsoft hosting vendor (with appealing Exchange prices) lists $70 / month ($840 / year) to host 5 GBytes of SharePoint data. Compare that with Google with 25 GBytes for $50 per year. Is SharePoint 17 times better before factoring in the difference between 5 & 25 GBytes?

Google's technology is shaped by a different set of assumptions:

- Servers are hard to get if you're a grad student at Stanford so the infrastructure should extract maximum value from each one.

- Servers are fallible (grad students getting by on scrounged hardware; later scaling out with thousands of servers) so the infrastructure should insulate service delivery from any specific component failure.

- There are tens or hundreds of thousands of servers, so the infrastructure should require zero human involvement to bring a new machine into full production, or to cope with failure.

- Hardware is a large percentage of operating cost, so the infrastructure should automatically maintain the proper degree of redundancy, while extracting maximum business value from that redundancy - see commercial success driver.

- Since an individual server failure is unimportant, servers should be designed to provide maximum output from the least expensive hardware and lowest possible power consumption. This means no redundancy except probably dual NICs to separate network switches, and commodity class components.

- Commercial success depends on rapidly processing huge volumes of complex search queries. The infrastructure should natively farm each work item across the optimum number of servers to provide eye-blink response time.

- Plus Google grabbed oodles of fiber at fire-sale prices after the telecom meltdown earlier this century.

How can the incumbents develop this kind of sustaining design & scale as they move into the cloud?