1. Understanding development priorities
It’s tough to drive innovation into a product that has been
around for so long, and it’s tough to satisfy all the different
constituencies that use Exchange, from the small business that deploys
one or two servers to the world’s largest enterprises that support
hundreds of thousands of mailboxes. Each time Microsoft releases a new
version of Exchange, it has to include enough new stuff in the product
to create a compelling case for an upgrade.
All development
projects have priorities. Microsoft reveals its goals for each version
of Exchange when it meets with customers or makes presentations at
major industry conferences, such as the return of the Microsoft
Exchange Conference (MEC) in September 2012. These goals include:
Supporting a multigenerational workforce. The
first generation of workers that experienced email was in the 1980s.
Each generation since has added its own expectations of how email
should work in the mix. The current multigenerational workforce is more
diverse and demanding and expects information to be integrated and
available through more devices than ever. Microsoft points to the way
Exchange 2013 combines information from multiple sources (including
LinkedIn and Facebook) to present a unified view of personal contacts
(“People”) and the way Smart Search works from the way users
collaborate to improve search results as evidence of how it is
providing better access to information.
Providing an engaging experience. The
evidence here often includes the reworked user interfaces in Outlook
2013 and Outlook Web App, including support for touch devices. Although
some will enjoy features in the new client applications (such as the
way Outlook and Outlook Web App permit inline editing of replies to
messages), many users will continue to use earlier versions of Outlook
because of the difficulty and expense involved in deploying new
software to desktops.
Improving integration with Microsoft SharePoint and Lync. Exchange
2010 can store Lync conversations for individual users but has no real
integration with SharePoint. Lync contacts can now be stored in
Exchange 2013, and Lync archiving is subject to Exchange compliance
features such as in-place hold. For SharePoint, Exchange 2013
introduces site mailboxes to bridge the gap between how people
collaborate through email and document authoring. Search capabilities
are also enhanced by using Search Foundation as a common platform
across Exchange, SharePoint, and Lync so that information can be
located in all repositories. These features depend on SharePoint 2013,
Lync 2013, and Outlook 2013 to provide the necessary points of
integration and user interface.
Meeting evolving compliance needs. Microsoft
made a huge investment to provide a broad range of compliance features
such as archive mailboxes and retention policies in Exchange 2010.
Real-life experience has helped Microsoft refine these features. Search
is improved as previously described, and retention holds are expanded
to allow multiple query-based holds to be placed on user mailboxes when
essential information must be retained. In addition, the new data loss
prevention (DLP) feature helps users exert better control over
important forms of data that often travel in email, such as credit card
information.
Providing a resilient solution. There’s
no doubt that the introduction of native high-availability features
embodied in the Database Availability Group (DAG) was the major success
story of Exchange 2010. Unlike other features, high availability is
based on the heart of Exchange, the Store databases. Experience
revealed how automation of the resolution of failure conditions could
be improved, and new capabilities were introduced to make it easier to
introduce and manage truly resilient mailbox servers. Making the CAS a
more stateless server also helps because these servers can now be moved
into and out of operational environments more easily. In addition,
because a version dependency no longer exists between front-end (CAS)
and back-end (Mailbox) servers, it should be possible to update servers
of one type to a new version of Exchange without updating the others at
the same time.
Because Exchange 2013 builds on
the architecture and priorities established for Exchange 2010, it is
valuable to review the priorities for that release in the context of
Exchange 2013. Because you know how Exchange 2010 has been used in the
intervening period, you can assess how the development priorities
turned out in reality and how the different investments in technology
made several years ago have developed in Exchange 2013. When it was
developing Exchange 2010, Microsoft concentrated on three major areas:
Increasing
operational flexibility through easier deployment, higher availability,
and simpler administration. Simplicity comes about in many areas,
including the reduction in server roles to just two: the Mailbox server
and the CAS. Administration is simplified in that you now have a single
management console: the browser-based Exchange Administration Center
(EAC). Microsoft Windows PowerShell continues to provide the basis for
automation. After a slow start, the Exchange community has truly
embraced Windows PowerShell, and the number of useful scripts that are
shared on the Internet is growing at a rapid rate.
Streamlining
communications by supporting larger, better-organized mailboxes;
investing further in unified communications; and allowing users to work
more easily together no matter which device or client they use.
Exchange 2010 focused on 10-GB mailboxes with up to 100,000 items in a
folder; Exchange 2013 considers a world in which a 100-GB mailbox and
1,000,000 items in a folder might be common.
Delivering
greater visibility and control with protected communications, in-built
compliance and archiving functionality, and better reporting and
management alerts. A large range of compliance features, including
archive mailboxes and retention policies, was introduced in Exchange
2010 to assist companies in complying with various legal and regulatory
directives. As explained earlier, features such as discovery searches
are refined further in Exchange 2013 and enhanced in new ways such as
the provision of site mailboxes, which also create a closer connection
between SharePoint and Exchange. The DLP feature comes from experience
gained with transport rules and MailTips to enable organizations to
define and implement policies to control the transmission of sensitive
information through email.
This is not an
exhaustive list of the improvements in Exchange 2013. For example, the
advent of modern public folders is welcome because it addresses a
nagging problem that has existed in Exchange for at least a decade.
In
scanning the development priorities for Exchange 2013, it’s interesting
that many of the same points could have been made about Exchange 2010.
Perhaps it’s good that development priorities have remained reasonably
consistent, or maybe the same influences that guided Microsoft to make
these the priority areas for Exchange 2010 have not abated.
These
areas of investment have to work as well for hosted environments as
they do when deployed onsite. Security and privacy are big challenges
for hosted environments because all communications have to be routed
from a customer’s own network across the Internet to a data center
Microsoft or another provider hosts. It’s not just a matter of
transporting messages anymore; directory synchronization and
administrative commands have to flow as easily as messages, and
everything has to work in dedicated environments and in the multitenant
shared environments that are becoming more common because of their cost
efficiencies. The debate that erupted following the PRISM controversy
in mid-2013 is an example of the sensitivities that exist around
security and privacy.
Many
of the changes in Exchange 2013 are highly influenced by recent
developments in hardware. For example, managed availability imposes a
certain overhead on a server because it consumes resources to verify
that components are functioning correctly. The overhead might have been
a problem for older servers but should not be an issue for the kind of
multicore servers available now. Exchange trades memory for disk I/O in
a number of versions, based on the principle that memory is becoming
cheaper, and it’s better to cache data than to go to disk. Exchange
2013 uses larger caches than Exchange 2010, and this, along with the
other changes made to reduce or manage I/O better, make it feasible to
deploy mailbox databases on low-cost, high-capacity drives. Hardware
will continue to evolve, and the Exchange developers keep a keen eye on
the possibilities enabled by new capabilities. They also know that how
Exchange uses hardware resources has to be as efficient as possible to
make it an economic platform for cloud deployments, whose major selling
point is often a low monthly cost per mailbox.
At the
time of writing, Exchange has been under development for nearly 20
years, and its source code encompasses some tens of millions of lines
of code. At one time, the code base amounted to 21 million lines, but a
rewrite of the Exchange Information Store into managed code for
Exchange 2013 eliminated a large amount of redundant code that handled
conditions that are no longer valid. No engineering group stays
constant over such an extended period. Different engineering
leadership, internal Microsoft politics, and competitive pressure have
all contributed to elevating different priorities for the product over
the years. Working in a world of cloud services is just the latest
influence on Exchange.
2. The influence of The Service
Since Exchange 2010, Microsoft has had to walk a thin line to
develop software that can run as well in a traditional on-premises
deployment as in its Office 365 cloud service. Companies have offered
hosted Exchange services for years, and many continue to compete
successfully against Office 365 with products based on Exchange 2013.
The big difference is that Microsoft now runs a massively scalable
cloud service that exerts a huge influence over the engineering
roadmap. Microsoft is more likely to create new functionality if it is
important to Exchange Online, the email component of the Microsoft
Office 365 cloud platform, than if it is important to a few on-premises
customers. This is the downside of the cloud for on-premises customers;
the upside is that Microsoft gains enormously from the experience of
operating Exchange Online.
The
Service is the name the Exchange development group uses for Exchange
Online. The name gives insight into how the developers and testers
think about Exchange Online; it provides a cloud-based email service to
end users.
The early history of Microsoft with cloud-based email was inconsistent. Hotmail (now Outlook.com)
was acquired in 1997 and has been a great success as a consumer email
service. “Consumer” means that Hotmail offers all the functions and
features required by home users but lacks the features, such as
compliance, that have become increasingly important for businesses.
Although Hotmail gained tens of millions of users, its underpinnings
were not suitable to provide a foundation for a business-oriented
service. For example, although you can connect Outlook to Hotmail, most
of the advanced features in Outlook do not work, among them
calendaring. For this and other reasons, Microsoft had to evolve
Exchange to become cloud-capable.
The first Microsoft attempt at
delivering a business-oriented, hosted email service was based on
Exchange 2007, launching as Microsoft Business Productivity Online
Services (BPOS) in late 2008. Microsoft was operating other online
email services at that time, including the Live@EDU service that
focused on the U.S. education market, but BPOS was the first email
service targeted at the enterprise market.
The fundamental
problem with Exchange 2007 is that it was not designed to run at the
kind of massive scale demanded by cloud services. Exchange 2007 was
well suited to on-premises deployment, but it had problems that were
revealed at scale. CAS was new, the Microsoft front-end proxy
technology available at the time (ISA Server) was fragile and limited
by its 32-bit platform, and Exchange management tools had only begun
the process of automation enabled by the adoption of Windows
PowerShell. Hard work and many endless nights that Microsoft support
personnel worked closed more of the gaps in functionality.
Nevertheless, deficient as BPOS was in many respects, it was a superb
learning experience for the architects, developers, and operations
personnel who ran the online email service.
Many of the benefits
were realized in Exchange 2010, the first version of Exchange that can
be regarded as cloud-capable. The improvements and extra stability
gained in Exchange 2010 enabled Microsoft to launch Exchange Online as
part of Office 365 in July 2011, preceded by a long beta period during
which Microsoft gained additional operational experience. However, soon
after the formal launch, Office 365 revealed some of the immaturity in
processes and procedures surrounding the service. Major outages in
August and September 2011 were publicly embarrassing but highly
informative. The problems seemed to spur Microsoft to additional
effort. No further significant outage was encountered in the next 18
months, an achievement that matched Google’s record and exceeded the
service level that most companies are capable of delivering in terms of
IT service availability.
Exchange Online and Exchange development
The
Exchange development group manages Exchange Online. Developers and
testers are held accountable for problems that occur in Exchange
Online. It is therefore in the developers’ and testers’ interest to
make sure that no code is released for production use in Exchange
Online that is not as robust, secure, and scalable as is humanly
possible to create. Everyone in the development group knows that if a
problem is found, the responsible developer will be called to duty with
an automated call from a vice president, commanding him to fix a bug.
In this instance, accountability truly drives results.
This
approach is invisible to many customers, and those who are responsible
for running on-premises Exchange servers might wonder whether there is
any evidence that this approach delivers value to them. Indeed, given
the investment Microsoft has made in its cloud platforms, on-premises
customers might well conclude that they gain no advantage from all this
work and are unlikely to see new features appearing in future
on-premises versions of Exchange. However, a positive feedback loop
exists to ensure that good ideas implemented for the cloud platform
find their way back into the on-premises code base. The best example in
Exchange 2013 is the managed availability subsystem, by which a series
of probes deployed across the product analyze how the service is
functioning and take automated action to address problems as soon as
possible after they are detected. Automation is the key to successful
scaling and operation of cloud-based systems. You cannot afford manual
intervention when you manage thousands of servers supporting millions
of users, so having code that detects and fixes problems without
administrator intervention is clearly a very good idea.
Another
example is the evolution of the CAS to become a stateless server, so
much so that you can’t deploy an Exchange 2013 CAS server in an
organization without having at least one Exchange 2013 mailbox server
as a companion because the CAS proxies all connections to a suitable
mailbox server, including Windows PowerShell commands. If a mailbox
server isn’t available, CAS can’t function.
CAS has been the
source of many problems since it first appeared in Exchange 2007. Its
scalability was weak, and load balancing and affinity have always
presented challenges. These issues are increasingly important, given
the growing number of devices that connect to Exchange. Users once had
a single device (the PC) that ran a client connected to Exchange to
access mailboxes, but they now cope with a profusion of smart phones,
pads, tablets, ultra-notebooks, laptops, and other devices that can run
email clients. Moreover, if a device supports ActiveSync, IMAP4, or
POP3 (listed in order of feature availability), it can connect to
Exchange. All these connections have to go through a CAS before they
can be redirected (through a proxy) to the correct mailbox server that
currently holds the active database containing the user’s mailbox.
Exchange 2013 moves away from the previous requirement to use layer 7
load balancing to support layer 4 (Transmission Control Protocol, or
TCP), a change that makes the load balancing of incoming connections
across a pool of available CAS servers much easier.
At
the same time, all client connections now use HTTPS, even those from
internal Outlook clients that traditionally have used remote procedure
call (RPC) over TCP to connect to mailboxes. Internal Outlook clients
connect to Exchange 2013 using RPC over HTTPS, just as external Outlook
clients do. (The internal connections use HTTP.) No client makes a
direct connection to an Exchange 2013 mailbox server because all
connections are forced through a CAS. This change does not mean that
Exchange has eliminated its use of Messaging Application Programming
Interface (MAPI) RPCs. Instead, these calls are encapsulated inside
HTTP packets.
Collectively, these changes make CAS deployment and
management easier while also making it possible for individual CAS
servers (which can still be deployed in arrays) to be removed from
service without causing an impact on clients. Giving the CAS a
simplified set of tasks also means that the functionality of mailbox
servers can be upgraded without imposing the need to upgrade the CAS,
so future product upgrades should be much simpler because you’ll be
able to run Exchange Server 2013 CAS alongside Exchange 2013+1 mailbox
servers. At least, that’s the plan.
Microsoft gains many
operational advantages through these changes because Exchange Online is
the largest deployment of CAS servers in the world. However, so do
on-premises customers who have complained about the fragility of the
CAS for years.
Many other examples exist to testify to the
transfer of improvements made to streamline and strengthen the cloud
platform to on-premises servers. The continuing refinement and
capability of the Mailbox Replication Service (MRS) is one instance
because mailbox moves are performed continually to rebalance load
across available servers in Microsoft datacenters; the growing maturity
in the high availability of Exchange Server is another. You could not
run mailbox databases on low-cost disks if Microsoft didn’t need this
capability to achieve the necessary operational cost level required to
make money when charging $6 a month per mailbox. Features such as
single-page patching and autoseed of failed databases are other
examples of the kind of functionality that becomes hypercritical when
operating at scale while also being extremely useful inside a classic
on-premises deployment.
However, the pace of change that occurs
in the cloud version of Exchange and its subsequent push-through effect
of features that appear in updates for on-premises customers can be
difficult to manage. Over the years, on-premises administrators have
become accustomed to a relatively predictable and steady pace for
feature updates, which usually only appeared in service packs. Over the
lifetime of Exchange 2010, as development accelerated for Exchange
Online, Microsoft began to ship updated functionality in slipstream or
roll-up updates. This took some customers by surprise, but it was
really only a pointer to the situation that now exists with Exchange
2013 and Exchange Online, where updates proven in the datacenter are
subsequently released to on-premises customers. Microsoft will not
retreat from providing new features as quickly as it can put them into
user hands. Microsoft and Google are locked in an ultracompetitive
battle in which Google has declared that its “goal is to get to the 90
percent of users who don’t need the most advanced features of Office.”[]
Given the presence of a very large competitor who wants to grab most of
a very valuable franchise, every reason exists for Microsoft to
continue to press forward with new features while making the service as
economically attractive for customers as possible.
Transition into the cloud
The Service is not going away. Writing about the introduction of Exchange 2013 in December 2012, Gartner[]
said that, although we are in the early days of movement to cloud-based
email systems, by 2020, these systems would have 50 percent of the
market. Office 365 will not take all of this share, but given the size
of the Microsoft installed base, it is fair to expect that Office 365
will support hundreds of millions of active mailboxes at that time.
Another
way of looking at the situation is to debate just how deeply cloud
services will penetrate across the sectors representing small, medium,
and large companies. It is obviously easier for a small-to-medium
company to move to a cloud service, especially now that the migration
and interoperability tools have been refined. It is harder for a large
and complex company to move, but overall, cloud email systems will
occupy an increasing portion of the market as time goes by. In the
immediate future, companies that meet some or all of the following
criteria are most likely to move to Office 365:
Run Exchange 2003 or Exchange 2007 servers
Have fewer than 5,000 mailboxes (or fewer than 1,000 in some smaller markets)
Have no real reason to develop expertise in email
Struggle
to keep email systems updated and functioning properly in such a way
that they attain a service level agreement (SLA) of 99 percent or more
In
addition, no startup company should ever deploy an on-premises email
server unless it has a very clear and unarguable need to do so.
An
increasing percentage of the overall Exchange installed base will be
hosted by the service in the coming years simply because it is easier
and cheaper for many companies to host their mailboxes on the service
than to grapple with the complexities of an on-premises deployment.
They now have a choice. Even better, the experience Microsoft has
gained from Office 365 is demonstrably flowing back into the
on-premises product.
