The Cloud on Your Terms Part 24 of 30: Hybrid for Public Cloud
In part 2 of this 30 part series we introduced the topic of Hybrid Cloud. That is the combining of Public, Private, and or traditional IT into a system that works for you.
One of the great Hybrid examples I like to talk about is internally here at Microsoft. Microsoft is an extremely email centric company. Email is beyond a mission critical app for us. As such we spend a lot on our internal Exchange infrastructure. I have been on a beta test program for many years helping our Exchange team test the next version of Exchange before they are released.
Well we have started moving “Some” of our end users to Office 365. “Some” is 10’s of thousands of users. My account for now stays on Exchange to help test the next versions, but I have several co-workers that their email has been transitioned to Office 365 and they don’t see any difference.
Our MSIT department recently did a webcast and case study about how we are rolling out Office 365 internally. Here is the video: or at least the Link
Another area we need to talk about is Windows Azure in a Hybrid environment.
First check out this site: https://social.technet.microsoft.com/wiki/contents/articles/hybrid-cloud-solutions-with-windows-azure-appfabric-middleware.aspx
This site talks about how to use Windows Azure Appfabric as your middleware in your applications.
Here is the abstract from that article:
Abstract
Technical and commercial forces are causing Enterprise Architects to evaluate moving established on-premises (definition on Wikipedia ) applications into the cloud (definition on Wikipedia
) – the Microsoft Windows Azure Platform.
This blog post will demonstrate that there are established application architectural patterns that can get the best of both worlds: applications that continue to live on-premises while interacting with other applications that live in the cloud – the hybrid approach. In many cases, such hybrid architectures are not just a transition point — but a requirement since certain applications or data is required to remain on-premises largely for security, legal, technical and procedural reasons.
The cloud is new, and the hybrid cloud is even newer. There are many technologies that have just been released or announced so there is no one source for authentic information, especially one that compares, contrasts, and ties it all together. This blog, and a few more that will follow, is an attempt to demystify and make sense of it all. We begin with a brief review of two prevalent deployment paradigms and their influence on architectural patterns: On-premises and Cloud. After that, we discuss developing the hybrid architecture.
This posting takes an architect’s perspective and surveys the major building block components that compose this hybrid architecture. We also match requirements against the capabilities of available and announced Windows Azure and Windows Azure AppFabric
technologies. Our discussions also factor in the usage costs and strategies for keeping these costs in check. We conclude with a survey of interesting and relevant Windows Azure technologies announced at Microsoft PDC 2010 - Professional Developer's Conference
during October 2010.
Back to our part on Office 365 deployment in house. Here is the article on our plan:https://technet.microsoft.com/en-us/library/hh134273.aspx
Introduction
Microsoft Office 365 includes Exchange Online, Lync™ Online, SharePoint® Online, and Microsoft Office Professional Plus. As part of the planning for a “dogfood” deployment of Microsoft Office 365, Microsoft IT (MSIT) is moving to a hybrid deployment of Microsoft Exchange where MSIT hosts some user mailboxes in MSIT’s on-premises service and hosts other mailboxes online in the cloud. For customers planning a move to a hybrid messaging model, it is important to understand application technology dependencies and user experience and support needs. This article discusses how MSIT planned for a hybrid deployment of Microsoft Exchange.
Planning Process
As part of the planning process for a hybrid messaging model, MSIT determined that the following key workstreams were critical to a successful rollout:
Upgrade line-of-business (LOB) applications to Microsoft Exchange Server 2010
Build out Active Directory® Federation Services (ADFS)
Plan for mailbox migration (Microsoft Lync Server 2010 dependencies)
Create a cross-premises support model
Evaluate network readiness
Adjust the service management model
Upgrading LOB Applications to Microsoft Exchange Server 2010
The first step in MSIT’s planning process was to ensure that LOB applications were compatible with Exchange Server 2010. MSIT focused on upgrading mail-enabled applications from Exchange 2007 to Exchange 2010. This enabled MSIT to retire expensive Exchange 2007 clusters worldwide, and reduced incompatibilities between mail-enabled applications and Exchange Online. By doing this work up front, as MSIT moves thousands of mailboxes to the cloud, those mailboxes have seamless interoperability with the many existing mail-enabled applications. This strategy preserves MSIT’s long investment in rich, mail-enabled LOB applications.
Upgrading LOB applications involved a number of different application teams and required coordination across several quarterly release cycles.
Building Out ADFS
MSIT provides federated authentication to applications and external partners through ADFS. Office 365 uses federated authentication to provide single sign-on in hybrid mode, which makes ADFS a critical dependency for Office 365 services. It also increases the volume of ADFS traffic significantly. To meet this new demand, MSIT had to scale up support for the ADFS service, which meant doing additional types of monitoring, providing additional supporting infrastructure, and providing 24x7 mission-critical service. Any company that wants to move to the cloud will need to consider an investment in federation services.
Planning for Mailbox Migration (Microsoft Lync Server 2010 dependencies)
MSIT wants users to have the same great collaboration experience whether mailboxes are located on-premises or in the cloud. Microsoft employees and contingent staff are heavy users of Exchange Unified Messaging (EUM), rich instant messaging, presence, and conferencing features that are provided on-premises by Microsoft Lync Server 2010. Microsoft Lync Server 2010 is a requirement for instant messaging and presence integrated into the Web email client (Outlook® Web App). EUM enablement is also simplified by using Microsoft Lync Server 2010 Enterprise Voice, so MSIT made the Lync Server 2010 rollout the leading edge of the large-scale Exchange Online mailbox migration. Using the same conferencing solution in the cloud enabled MSIT to preserve cross-premises feature parity (all provided by Lync Server 2010). To make a seamless move to a hybrid Exchange environment, administrators will need to consider the instant messaging, presence, and conferencing needs of their cloud users. They will need to consider how they want to deploy UM for their cloud mailboxes.
Creating a Cross-Premises Support Model
Every company does support differently, and there are many teams, technologies, and processes to consider. Transparency of support is a key part of the user experience. There should not be any difference in support whether mailboxes are located on-premises or in the cloud. A simple support model is also key for the IT organization accountable for the service. Microsoft IT analyzed their support model, evaluated their future support and service needs, and determined how to integrate with the Office 365 support.
In order to make the end-user support experience seamless, MSIT introduced new Helpdesk processes for determining where the user’s mailbox is located (on-premises or in the cloud) and processes for troubleshooting the additional dependencies, such as ADFS.
Evaluating Network Readiness
When all mail services are provided on-premises, the corporate network bandwidth is more than sufficient to handle mail usage throughput for all users. As MSIT migrates mailboxes to the cloud, the dependence on edge ingress/egress capacity increases. MSIT evaluated network utilization and capacity and optimized it to address increased traffic between online and on-premises mailboxes.
Adjusting the Service Management Model
Since MSIT is providing mail services to users through two separate providers, service management complexities have increased dramatically, requiring more extensive Exchange user profile/business needs analysis. MSIT created new processes and workflows in the following areas:
· End user communications and readiness workflows
· Migration workflows
· Service validation with a test team
· System Center Configuration Manager strategy to prep and maintain end user computers
Conclusion
MSIT carefully planned its hybrid deployment of Office 365 messaging by upgrading LOB applications to Exchange Server 2010, building out ADFS, planning for mailbox migration with Lync Server 2010, evaluating network readiness, and adjusting the service management model. By doing this planning up front, as MSIT moves mailboxes to the cloud, users have seamless interoperability with Microsoft’s many existing mail-enabled applications. Users have the same rich mail experience whether their mailboxes are located on-premises or in the cloud, and since the hybrid model is not a one-size-fits-all solution, MSIT can choose which users go where based on Microsoft’s short-term and long-term business needs.