Don’t believe everything that you read on the Internet. This is good advice that more people should really follow considering the amount of sheer dross that one comes across in an average day. A good example is a recent publication of a blog review that purports to compare Zimbra Collaboration Server (ZCS), the open-source based email server now owned by VMware, and Exchange 2010. The core theory advanced by the author, a fellow named Christopher Wells who rejoices in the splendid handle “'vSamurai" (probably due to his experience in Japan coupled with his focus on VMware), is that ZCS can be simply dropped in to replace Exchange “in enterprise deployments of all sizes”.
The ideas advanced in the article have been comprehensively addressed by a rebuttal written by Dave Stork and Michel de Rooij, so I won’t bother to repeat those points here. Instead, I’d like to consider some of the myths about Exchange that the article perpetuates.
First, it’s important to say that ZCS is a fine product that includes components such as a MAPI connector that allows Outlook clients to connect to the server. Zimbra Desktop is the native client alongside a web client and support for a SOAP application programming interface. Free versions of the server and clients are available while the full-fledged ZCS is available as paid-for online download (in some countries) or through VMware sales and partner channels.
So good so far – now let’s consider some of the myths and FUD that are advanced.
· The Extensible Storage Engine (ESE) is over 20 years old: This point is true, but I don’t see why twenty years of sustained development to continually tune and improve the performance of a database engine is a bad thing. After all, the work done to reduce I/O requirements in both Exchange 2007 and Exchange 2010 proves that ESE continues to deliver high performance and reliability. The author gets bent out of shape because ESE databases are “non-modular” and don’t “separate message and metadata, so is not conducive to tuning”. Well, I worked on ALL-IN-1 for some 12 years and enjoyed the challenges advanced by its separation of message storage in individual files and the metadata in the “SDAF”. This was a long time ago and I think that it makes more sense to keep everything together in one place, especially now that ESE boasts features such as single page patching to keep databases healthy.
· Microsoft is considering moving the storage engine to SQL: Ah, the hoary old chestnut appears in all its glory. Although it’s true that Microsoft initiated the “Kodiak” project to move Exchange from ESE to SQL and that some engineering work continues to monitor SQL from an Exchange perspective, I can say that there’s no prospect of such a changeover in the near future, even if commentators like Brien Posey have it on their wish list for the next major release. Replacing ESE with SQL is attractive from the perspective of engineering efficiencies and it’s technically possible for SQL to act as a database engine for Exchange, but this ignores the twenty years of development that ESE has had as a database that deals very well with the somewhat unpredictable nature of email together with its proven ability to scale and handle the demands of even the largest deployment (Exchange Online in ).
· Exchange doesn’t support the use of tiered storage, so adding more users is more costly: Hmmm… I guess it all depends on your definition of tiered storage, but the work done in Exchange 2010 to support JBOD-style storage laid the foundation for Microsoft’s ability to support millions of Exchange Online users at reasonable cost ($6/month for a 25GB mailbox seems pretty good to me, especially when it comes with SharePoint and Lync also). I guess the same must be true of all the other third-party hosted providers that have built their business around Exchange. They couldn’t all be so silly as to ignore the cost equation?
· DAG doesn’t protect the entire infrastructure: Yes. Absolutely. That’s the reason why the transport dumpster and message shadow redundancy features are integrated into Exchange – to ensure that messages en route can be recovered if they don’t make it to a database before the DAG replication can protect them. It’s also worth noting that messages sent by a DAG member server are automatically submitted to a different hub transport server to ensure that shadow redundancy is effective and that Exchange 2010 SP1 increased the protection that shadow redundancy affords to include messages coming in from foreign email systems, such as ZCS.
· DAG has a learning curve and only applies to Exchange: Hmmm… you could advance a case that the DAG builds on the SCR/CCR implementation in Exchange 2007. You could also say that DAG implementations have been in production since 2009 and that three years of solid experience is instantiated in tools such as the Mailbox Server Storage Calculator that help novice administrators take advantage of community knowledge. As to applying only to Exchange, I should point out that a third-party replication API is available to allow other companies to plug in their solutions to a DAG. And while most customers go with the native-mode replication available in a DAG, EMC Replication Enabler for Exchange is an example of how this API has been used.
· Microsoft is a closed platform: I can certainly see how this theory was far easier to argue in the past when Microsoft a) held fast to MAPI as the only totally functional method to integrate with Exchange and b) introduced and discarded different APIs such as CDO Routing Objects that proved to be not fit for purpose. But lately the introduction and power of Exchange Web Services (EWS) and the availability of code samples in public repositories such as Codeplex (EWSEditor is a good example) means that the charge is less valid. Microsoft will never be as open as an open-source product so what’s the point in hammering them with this charge when the available evidence proves that they are providing suitable APIs to allow third-parties to interface with Microsoft technology? After all, without interfaces like MAPI, would Zimbra have been able to develop their connector for Outlook?
· Limited browser support for Outlook Web App: I fear that the author was really losing their grasp of reality at this stage (they also said that only a single theme is available for OWA; I count 28). OWA runs on almost every available browser. I say almost because there’s probably something obscure that doesn’t support the OWA light interface (then again, Exchange 2010 SP2 reintroduces Outlook Mobile Access). Certainly, I have had no problems running OWA with Safari, Chrome, Firefox, and IE – including Firefox on Linux (which addresses the need for Linux support). The premium version of OWA - supported by all major browsers - is now a highly functional and usable email client.
I could go on and on to pick more holes with the content. It’s actually sad when a technologist lets themselves down by publishing commentary about something with which they obviously lack the necessary experience and knowledge to be able to make sense. I’m sure that vSamurai intended to do the right thing by sharing his views. The sad thing is that he is so wrong that it undermines anything else that he’s written about technology such as NetApp storage or VMware, which seem to be his specialities.
The lesson is clear. If you publish something on the Internet please make sure that you do the research to understand your material. If not, you simply become another testament to the truth that you shouldn’t believe everything on the Internet. I must remember this advice myself.
Follow Tony’s ramblings via Twitter.