I recently saw the movie "Up in the Air." In it, George Clooney's character runs away from many of his problems by choosing a life that keeps him on airplanes — no place to call home, no entanglements, and where things we all take for granted are notably missing.
I had been working on a presentation about cloud computing, and it struck me that in a number of ways what Clooney's character did was to outsource his lifestyle to the cloud — literally! Like Clooney, many users think they can escape certain challenges by moving to cloud computing. And, like Clooney, most companies find that, sooner or later, they need to come back down to earth and deal with them.
Email-wise, there are several functions that certainly can be moved to the cloud — at least for some customers. Most commonly, enterprises outsource inbound message delivery to a company that removes spam and email-borne viruses. You might successfully outsource POP/IMAP services to a service like Google Apps or Oracle on Demand, or outsource the hosting of Exchange functions to a company that specifically handles this type of request.
But, to ensure success when moving functions to the cloud, you must be prepared to do your homework. Security concerns must be guaranteed by the hosting provider and have to be matched with requirements from your security and legal teams. Those security concerns may not have been explored before, when the company firewall was protecting your data and when mail was not being sent where it could be viewed by others.
In addition, you need an inventory of ALL the functions provided by the systems you plan to move out to the cloud. We've heard from customers who were asked by their CIO to "move everything to the cloud", who haven't thought about what is actually meant by everything.
This is where the idea of "putting things out in the cloud" comes down to land. Just like Clooney, you can't put everything into the cloud — unless you're willing to give up things that you currently take for granted.
To put this into perspective, think of the consequences involved in telling your current stakeholders, "We are planning to move email to the cloud. Pretend nothing you depend upon will be there, unless you explicitly request it. What are the functional requirements from your group?"
You've just created a hard task for them — but if you're the technical project lead for the move, this is a good way to uncover requirements early in the process.
Here are just a few examples of technical requirements that are challenges with cloud service offerings. For each requirement try asking, "Does this apply to us today or in the future?" and then, "Does the cloud provider we are looking at accommodate that?"
- Does your current internal server environment have applications that need to send messages, internally or to the internet? These might be apps that send millions of billing statements a day, monitoring alerts sent by critical servers in the data center, and anything in between. If this describes your environment, it is generally far more cost effective and flexible to keep an internal mail routing environment than it would be to reconfigure all the applications.
- Do you require the full ability to track and monitor end-to-end email delivery, and/or keep historical log information specific to your message flow? Some companies might be okay with losing this, but other federally regulated industries are required to provide full auditing and tracking. Again check with your legal department to explore their requirements and then talk to the hosting provider to see if they can implement what you need.
- Is your enterprise a bank, EDU, or other entity that needs to be able to archive — or redirect — messages to, or from, selected individuals? Often this must be done covertly and quickly, without involving the hosting provider.
The list of possible requirements is large. For you, it might include guaranteed HIPAA (Health Insurance Portability and Accountability Act) enforcement on outbound, tie-ins to internal databases to prevent personally identifiable information (PII) leakage, or outbound policy enforcement to prevent the leak of sensitive information.
It might be that you need the ability to quickly adapt mail routing and message headers during mergers-and-acquisitions activities, or you have complex internal message routing to support.
If you are in health care, you may require the ability to exchange messages securely using automated gateway-to-gateway encryption with partners and the Food and Drug Administration.
My favorite requirement is finding that your security team needs to be able to perform deep analysis of inbound, internal, and outbound messages for various types of policy violations — without visibility of their actions by the email team.
If you're being asked to move things to the cloud, have you run into these questions yet? Can you think of other cases that aren't listed here?
In most cases, after doing the research, our customers have either decided to stay in-house or they have gone with a hybrid model. With a hybrid model, some functions, like spam handling, are moved to the cloud, but everything is configured, so all (non-spam) inbound mail and all outbound mail still passes through a set of full-featured, privately managed, messaging servers in the customer's DMZ. This way, your company maintains control and visibility of your mail flow.
Take the airplane if it makes your trip shorter, but, please, keep your feet on the ground.