The current email service provided to EMC employees, as of 2011, is deployed on an evolving platform that is moving towards a true cloud definition. In this sense the deployment doesn't meet most definitions of cloud (as described by NIST, for example). However, framing a conversation about EMC's internal road to IT-as-a-Service can be effectively done in three steps:
- describe a (pre-virtualization) physical deployment of an IT solution
- frame the historical config against present-day cloud requirements (e.g. NIST definition)
- describe the steps that have been/will be taken on the road to ITaaS
EMC Distinguished Engineer Wissam Halabi has been implementing IT configs at EMC for over a decade. He's also currently implementing the internal transition to ITaaS. With that said, Wissam provided me with an interesting picture of EMC's Exchange deployment from many years ago.
At the time the two datacenters were hosting 45,000+ mailboxes in over 300 offices (80+ countries around the world). The DMX systems stored tier-1 email (mission-critical users with aggressive RTO/RPO requirements), while the CX700 stored email for tier-2 users. Mailbox clusters were made up up physical servers (one passive), and each of these servers were mapped to underlying LUNs for Exchange support (logs, databases, SMTP). Clustering software on the servers had access to additional LUNs (e.g. quorum, recovery). Some servers in this configuration were dedicated to other critical services (e.g. public folders and web access).
This configuration was designed to scale to 48,000+ mailboxes.
Where does this configuration fall short when compared to a cloud definition? Let's frame the discussion using the five essential characteristics of cloud as defined by NIST.
On-demand Self-Service
A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider (NIST)
Provisioning more mailboxes was not something that the "consumer" could accomplish without human interaction (e.g. involvement from IT). It required the manual steps of LUN creation, LUN export, switch zoning, O/S recognition of LUNs, etc. When certain mailbox thresholds were crossed, additional servers had to be added for things like public folders and web access. The process was far removed from self-service and on-demand.
Broad Network Access
Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).(NIST)
Other than the traditional corporate access to email, the system above allowed for web access as well. Mobile devices were far less pervasive.
Resource Pooling
The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.(NIST)
The configuration above certainly contained pools of physical and virtual resources. However, it lacked the dynamic assignment and reassignment in response to demand.
In addition, the entire system was dedicated to running Outlook. There was no other tenant (such as an ERP application), and therefore there was no give and take between tenants occupying the same hardware.
Rapid Elasticity
Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in.(NIST)
Should the processing load reach capacity on any of the physical servers in this config, there was no way to rapidly expand to take advantage of more resources, nor was there a method for shrinking or scale-in. Once again, the physical configuration mandated a set of manual steps that required rigid, repeatable provisioning that typically occurred after the fact.
Measured Service
Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service (NIST).
This configuration could be measured, at the time, by using a reporting tool such as StorageScope. However, the capabilities of StorageScope did not contain the breadth of metering suggested above by NIST. And while the IT administrator may have had access to this type of data, the consumer typically would not (which falls short of the transparency defined by NIST).
Starting the March to ITaaS
The picture above contains zero percent server virtualization, and the entire configuration is dedicated to one application (Exchange). The picture below graphically describes this starting point, and highlights that increasing the percentage of virtualization is a key metric for enabling Exchange-as-a-Service.
Virtualization, of course, is not the only action that IT must take to deliver ITaaS. I'll describe the evolution of EMC's email services, along with the other steps that have been taken, in future posts.
Steve
Twitter: @SteveTodd
