Yes, It's Time To Destroy Your E-Mail Servers. What App Is Next?
If running your car on corn oil were possible, the car got 100 miles per gallon on corn oil, and corn oil was 25 cents per gallon, plentiful, and the use of corn oil meant you never had to take the engine in for a tune-up, what sort of rationale would you use to fool yourself that you still needed a fossil fuel-powered car? It's the same rationale that many businesses are using today to justify....
If running your car on corn oil were possible, the car got 100 miles per gallon on corn oil, and corn oil was 25 cents per gallon, plentiful, and the use of corn oil meant you never had to take the engine in for a tune-up, what sort of rationale would you use to fool yourself that you still needed a fossil fuel-powered car? It's the same rationale that many businesses are using today to justify.......insourcing their e-mail.
What most people don't know is that if you send or receive e-mail to/from me using any one of my six e-mail addresses (including email@example.com), the e-mail server doing the majority of the heavy lifting in the background is Gmail (specifically, Google's enterprise version of it which comes as a part of the Google Apps bundle).
After more than a decade of engineering, re-engineering, dot-level releases, and major upgrades, Microsoft Exchange and Lotus notes are incredibly mature, robust, and [technologically speaking] marvelous e-mail and group calendaring solutions so long as you've fooled yourself into believing that you need to in-source your e-mail servers. While at Interop in Las Vegas, I learned about how the most recent version of Microsoft's Exchange server had gone through a lot of retooling for modern storage use-cases. I think it's great that software makers like Microsoft and IBM Lotus continue to make their products better.
But compared with Google Apps (and similar cloud-based offerings from outfits like Zoho), could insourcing e-mail be like staying with fossil fuel in a corn-oil world?
The post, which dates back to October 2006, talks about a new feature of Exchange Server called Continuous Replication that makes it possible for Exchange Server clients to fail-over to a secondary Exchange Server within minutes of the primary one failing. In terms of the end-game (keeping clients up and running with their e-mail), it's good to see that Exchange Server finally caught up to a feature that Lotus Notes has had for more than a decade.
Five years ago, comparing Lotus Notes and Exchange Server was a favorite pastime of labs, reviewers, analysts, and especially of Microsoft and IBM Lotus. Imagine. All that engineering. All those comparisons. The hard-fought e-mail turf wars. All those e-mail servers you have to run and upgrade over the years. The extra ones for the fail-over. The storage subsystems and the care and feeding they needed. The networks themselves. The upgrades. The back-up procedures. The people. The cost.
Five years ago, the cost was quite justified given the needs of enterprises. Today, as e-mail and calendaring servers go, Gmail is far from being a perfect substitute for enterprise e-mail servers. In fact, the logo still says "beta" -- a term that has long been emblematic of solutions that, according to their manufacturers, still require work before they're ready for production deployment. I've been a Google Apps administrator for more than two years now. I've hitched the GMail piece of Google Apps to pretty much every e-mail client that matters (desktop and mobile). Emulating the foldering and integrated calendaring functionality that most Exchange and Notes users take for granted isn't easy. That is, if you don't want to use the Web-based client. It requires add-ons and an antiquated folder replication standard called IMAP that barely gets the job done.
So why, after two years, if I could have mostly better functionality in Lotus Notes, Microsoft Exchange or one of a half dozen other in-sourced solutions (Gordano, Scalix, etc.), don't I take it? First, headaches. Second Cost.
Sure, I've had my share of headaches given Gmail's so-called "beta" state. But compared with the headaches ... OK, let's be civil and call them responsibilities....that I might normally have if I had to babysit a server (or two, for fault tolerance), manage upgrades, backups, the spam management, etc., etc., etc. (the list of etceteras is really long), the list of shortcomings associated with a cloud-based service like Gmail is short. Really short.
And then there are the benefits. Since starting with Google Apps two years ago, I've deleted thousands of e-mails. But I've never emptied my trash folder. Try doing that on your insourced corporate e-mail server and you're likely to get an e-mail from some highly paid e-mail administrator requesting that you groom your mail file (that is, of course, if your e-mail doesn't start to disable itself, which is what CNET's corporate e-mail servers used to do to me when I worked there). According to the statistic box at the bottom of my Gmail Web-based interface, I'm using 831 MBytes of storage, which amounts to 12% of the 6.7 GB of storage that are availalble to me.
Perhaps more interesting is that no matter how many e-mails (many with large attachments) I seem to get, the percentage never seems to change. It has hovered at 11% or 12% for as long as I can remember. Even MORE interesting (to me) is how, not only have I needed to find some of those old e-mails, finding them, thanks to Google's search capability, takes less than a second. I know how e-mail administrators like to run a super-tight ship. But, as a user, where does having virtually unlimited storage and lightning-fast search of all your e-mail dating back to what feels like the beginning of time rank on your list? It has been invaluable to me.
How much has all this cost me and the other users on my Google Apps domain? Nothing. Zero. I don't even pay the $50 per user per year fee that Google wants you to pay if you want or need things like 24/7 telephone support or 25 GB of storage per user. Bear in mind that I'm one administrator with a handful of users. If I were to insource my e-mail domain, the investment of time and money would be nothing compared with the investment required of companies with thousands of users. One question I have for those companies is why invest so much to scale solutions (one of the most expensive aspects of insourcing e-mail) that are tough to scale when, out of the box, Gmail scales so well.
Today, perhaps Gmail (beta) has its faults. But I'd argue that most of them are worth the trouble for a great many organizations given the savings in money, time, and effort. For example, you'll never have to apply a security patch or an upgrade to your Gmail server. When there's a bug, it's often magically corrected (behind the scenes, Google's engineers keep vigil over many of Google's applications watching for faults and subsequently correcting the code in a way that all of Gmail's users inherit the fix the next time they press refresh on their browsers).
OK, so you think this is a story about why you should be moving off Microsoft Exchange or Lotus Notes to Gmail. It's not. It's a story about why you should be eying the cloud for your entire enterprise. It's only a matter of time before the remaining rub on Gmail is history and your CFO starts asking questions about that long-running cost center associated with your e-mail and calendaring systems. In the bigger picture, you shouldn't be asking if you should be moving from insourced servers to Gmail (or an equivalent for e-mail). Within the next five years, that will no longer be an "if." The bigger question you should be asking is what application comes after e-mail and calendaring and, as time goes by, how will you manage your company's undeniable attraction to the cloud?
Now, for the more fun question: How will you bid your servers adieu? Watch the video below.
Server Market SplitsvilleJust because the server market's in the doldrums doesn't mean innovation has ceased. Far from it -- server technology is enjoying the biggest renaissance since the dawn of x86 systems. But the primary driver is now service providers, not enterprises.