Exchange Server 2010 (E2K10) continues to be a baffling phenomenon. We have a raft of features to make E2K10 easier to manage when running at large scale. Integration with the Microsoft ecosystem (ADS, SharePoint, Outlook/Office) is of course excellent. We even hear with the use of the new DAG (replicated mailbox databases) that backups are a thing of the past – don’t need to backup E2K10 apparently.
I have worked with all versions of Exchange, including when it was still MS Mail 3.x. During the years I have been a big fan of this messaging system – mainly due to its integration ability and use of database technology (well JET actually) to provide many features that were novel at the time of introduction. E2K10 is no exception. However, with the rise of the Cloud, and services such as Microsoft’s Business Productivity Online Suite - BPOS or other hosted Exchange service providers, the messaging is becoming increasingly unclear.
What do I mean with that last statement? Well, take a look at the short list of things I hear regularly with clients:
-
Don’t need to backup E2K10 – Microsoft told me so
-
Don’t need fast disks anymore – Microsoft told me so
-
Messaging is not core to my business – will outsource it
-
What added value does the internal IT provide that the Cloud offerings of Exchange cannot provide?
-
Cheaper to host Exchange mailboxes with Microsoft BPOS or another Service Provider
Well having seen in many large organizations what happens when the eMail service is not available, I would argue that messaging services are critical. Indeed, the more integration one has with other upstream applications that utilize eMail, the greater the dependency on a reliable environment. This would indicate that messaging services are core to the business, and indeed may be tightly linked to new service offerings.
The idea of not backing up data, while certainly very attractive, is a little off the mark. There are other reasons for backing up data than simply to cover the “in case” scenario, including compliance, single-item recovery, litigation amongst others that require some idea of preservation of historic point-in-time copies of the messaging environment.
However, the last points regarding cost, and being more effective to host Exchange with Microsoft directly. Well this is really a bit of a sensitive topic for most administrators and indeed organizations. One of the reasons that Exchange is expensive is that it simply could not in an easy fashion cover the needs of the organization in terms of ease of administration, scalability, infrastructure needs, reliability and indeed cost. It does seem to me that Microsoft itself may well be partially responsible for the “high cost” of messaging services.
Why is this Relevant for Virtualization and the Cloud?
Well, many of the cost elements regarding Exchange environments in particular related to the enormous number of dedicated servers that were required to host the various Exchange server roles. The I/O profile of the messaging service was also not very conducive to using anything less than high-end disks in performance oriented RAID groups.
Administration for bulk activities such as moving mailboxes, renaming servers/organizations, backup/restore and virus scanning were not particularly effective to say the least.
Don’t get me wrong, Exchange 2010 is a massive improvement over previous versions. I would put it akin to the change from Exchange 5.5 to Exchange 2000. The new PowerShell enhancements are great, and finally we are getting better I/O utilization allowing us to finally use more cost-effective storage.
Where it starts to all go wrong is when Microsoft starts to lay down support rules or gives out advice that goes against the prevailing wisdom of seasoned administrators:
-
Virtualization on Hyper-V is supported, whilst other hypervisors need to be in their Server Virtualization Validation Program (SVVP)
-
Certain advanced functions such as snapshots, mixing of Exchange server roles in a VM and certain vCPU:pCPU ratios are note supported
-
Low performance disks are fine for messaging functions – what about backup/restore/AV scanning/ indexing etc?
-
Still no flexible licensing options that allow for “pay-as-you-use” or allows cost savings from multi-core processors
Never mind that fact that there are thousands of organizations that have successfully virtualized using VMware their Exchange environments, saving serious amounts of money. Never mind that these organizations are enterprise class, and run their servers at high utilization levels receiving millions of emails daily, whilst running hourly backups and daily virus scans. Never mind that most tier-1 partners of Microsoft offer qualified support for features such as snapshots for rapid backup/recovery.
Why then is Microsoft “scare mongering” organizations to now move to BPOS – to save money no less? The fact is that there are very very few organizations that truly know the cost of their eMail environment. Therefore, how can one say that it is too expensive to do eMail in-house?
The basis of calculating business cases also varies wildly. It is is very difficult to put a price on the cost of operations for messaging environments – even a messaging team is not 100% utilized – and then to spread this across the cost of the total number of mailboxes.
Indeed the cost of a mailbox per month seems to me not to be granular enough. What is the cost of a message? Who pays for inter-system messages? What about the cost of mailbox storage per month? What is the “true” cost per mailbox per month?
The private cloud, and 100% virtualization of Exchange server in particular, is a chance that most large companies should not really pass by so easily. It is the perfect application to verify the cloud assumptions about elasticity, on-demand and metered usage to get the “true” cost of eMail services. As it is so well understood by internal administrators, a company can experience first-hand:
-
massive reduction in server resources needed with virtualization
-
resource metering per user per billiable time period
-
billing systems alignment to cost of eMail services per user per month
-
operational process alignment for the Private Cloud way of doing things
-
eGRC can be applied and enforced with the necessary controls/tools
-
infrastructure business intelligence for zeroing in on further cost consolidation areas
-
provide basis for your internal Private Cloud – complete with self-service portals and end-2-end provisioning
I always say that eMail is in some ways easier to virtualize than high-end database environments such as SAP. Too much time is lost in the difficulties, and the organization gets too little of Cloud benefits as a result. The time-2-value and order-2-cash processes take too long with that approach.
With Exchange virtualization you can literally get started in a week or two once the infrastructure is on the ground – there are plenty of blueprints that can be utilized.
Why is this important for the CIO?
The CIO has the responsibility for setting IT direction in an organization. Simply following the scare-mongering of either vendors or outsourcing service providers will inevitably force you to move what may be a vital function for new product development out of your organization. Aside from this, there are many issues still regarding data confidentiality, compliance, and risk concerns that need to be tackled.
Personally, I would advise large enterprise shops to look at virtualizing their entire Microsoft estate, starting with Exchange Server. This is not only going to make deep savings, but, as experience shows, also provides better service with less downtime than in the past. You choose the type of differentiated service you would like to offer your users. You decide what services to include, with some being mandatory like AV/malware/spam scanning.
Use this as the basis of creating your Private Cloud, and start to gradually migrate entire services to that new platform, whilst decommissioning older servers. Linux is also part of that x86 server estate, and the obvious questions related to replatforming to the x86 server basis away from proprietary RISC architectures.
Innovation is an area where particular emphasis should be applied. Rather than your IT organization putting the brakes on anything that looks unfamiliar, you should be encouraging innovation. The Private Cloud should be freeing up “time” of your administrators.
These same administrators could be working more on IT-Project liaison roles to speed time-2-value initiatives. They can be creating virtual environments for application developers to get the next applications off the ground using incremental innovation with fast development cycles to bring new features online.
Once you are running all virtual, you will have a very good idea of what things really cost, whether to optimize CAPEX/OPEX levels and compare against the wider industry to determine whether you are offering fair value for IT services to your user community.
Let legislation about data jurisdictions and chains of custody also mature. Push vendors for better terms on per processor licensing, allowing “pay-as-you-use” models to come into play. Not on their terms in their Clouds, but on your terms in your own Private Cloud initially. Remember, there are always choices in software. If Exchange+Microsoft won't cut it for you, then use an alternative e.g. VMware+Zimbra
Public Cloud offerings are not fully baked yet, but they represent the next wave of cost consolidation. Recent high-profile outages at Amazon, Google, Microsoft as well as those “un-publicized” failures show seasoned veterans that there is probably another 2 years to go before full trust in Public Clouds is established with the necessary measures to vet Cloud Provider quality. Remember, one size does not fit all!