How Microsoft IT Architected and Redeployed a Published: August 2011 The following content may no longer reflect Microsoft s current position or infrastructure. This content should be viewed as reference documentation only, to inform it business decisions within your own company or organization Microsoft IT identified a business-critical internal application, Business Case Web (BCWeb), for migration to the new Windows Azure platform to establish best practices and create reusable processes for future migrations. BCWeb had reliability and performance issues in its previous environment and met the criteria set for the pilot project. By using the Windows Azure platform, Microsoft IT migrated BCWeb to a more reliable, more scalable solution. Additionally, they also determined a number of best practices and reusable components to apply to future enterprise application migrations. Target Audience IT Decision Maker, IT Implementer Situation Microsoft IT identified a complex, distributed application to migrate to the Windows Azure platform as a showcase project and to develop best practices for future migrations. The selected application, BCWeb, was an internal web-based suite of applications that was experiencing performance and reliability issues. Additionally, Microsoft IT wanted to migrate an enterprise level application, and BCWeb fulfilled that need. Solution BCWeb was migrated to the Windows Azure platform, which resulted in increased performance and reliability. The application's integrity was improved, and secure and reliable integration with on-premises components was built into the new solution on Windows Azure. The migration project also resulted in key best practices and reusable components that Microsoft IT could leverage in future migrations. Benefits Increased application performance and reliability. No hardware maintenance is required on the Windows Azure platform. Much of the original application reused, with some refactoring. Reusable development components that can be leveraged in future migrations Best practices derived from migration challenges and solutions. Introduction BCWeb is an internal, web-based application that Microsoft employees use to create business cases for exemptions to product pricing. BCWeb has three distinct application components, with the core component providing an interface and underlying functionality that enables users to generate business cases for pricing exceptions. The Workflow Routing and Approval system (WRAP) is the second component, and it routes pricing-exception requests for approval within the Microsoft corporate infrastructure. Rapport, the third component, provides a user interface for the WRAP approval process. BCWeb has a user base of 2,500 internal Microsoft employees, and in 2010, employees used it to process approximately 27,000 pricing-exception requests. Situation Microsoft IT was searching for an application to showcase both the ease of migrating applications to the new Windows Azure platform, as well as the platform's extensive capabilities. Additionally, Microsoft IT planned to use the migration to develop best practices and reusable components that it could leverage in future migrations. BCWeb Legacy Status BCWeb was originally deployed in late 2007 as a primarily Microsoft Office Sharepoint Server 2007 centric solution. Microsoft developed separate user interfaces for the production of business-case documents and for the management of the workflow and approval process. Transactional data for pricing exceptions was stored as individual documents within the SharePoint database as individual SharePoint documents. Since its inception in 2007, BCWeb had undergone several important architectural changes, including the implementation of network load balancing (NLB) in 2009. Additionally, in 2009, Microsoft IT initiated a re-architecture project to increase application reliability, and then in
2010, migrated the storage component from SharePoint storage to a solution based on Microsoft SQL Server. Due to the nature of the information that employees access and use in BCWeb, the application was integrated with several on-premises components hosted on the Microsoft corporate network (corpnet). These components primarily provide access to external data that BCWeb functionality requires. Microsoft considers the information that BCWeb accesses and contains to be important business data, so Microsoft IT had to ensure that it was secured accordingly. Performance and Reliability Issues Figure 1. Legacy Architecture of BCWeb In 2008, Microsoft IT introduced a new pricing-exception type in BCWeb that caused an eight-fold increase in BCWeb traffic. This rapid traffic increase resulted in significant performance and reliability issues for BCWeb, because the existing application infrastructure could not handle the workload. The application was unstable, and even offline at times, during peak usage at month-end, quarter-end and year-end periods. Despite attempts to alleviate these issues through load balancing, architectural changes, and data-storage changes, the performance and reliability of BCWeb were not adequate. Choosing the Windows Azure Platform The Windows Azure platform provides a hosted, location-independent environment for hosting applications and their supporting data and infrastructure. Microsoft administers hardware-implementation and maintenance in its data centers, through Microsoft cloud services, which enables customers to focus on their application development and deployment. Microsoft operates the Windows Azure platform at high availability and reliability, and benefits from the related economies of scale (cost savings from high volume operations) that it then passes to customers and partners. How Microsoft IT Architected and Redeployed a Page 2
In the case of BCWeb, many aspects of the application environment led the Microsoft IT team to choose Windows Azure as the target platform, including the ability to reuse significant amount of application code, increased application portability and the ability to automate considerable portions of the application migration. The following attributes made BCWeb a good candidate to migrate to Windows Azure: Developed using the.net Framework Hosted on Internet Information Services (IIS) servers Uses SQL Server databases Additionally, the team recognized that the Windows Azure platform includes several built-in scalability and high-availability qualities that would enable BCWeb to be both flexible and efficient in handling variable workloads and peak usage times. Solution Once Microsoft IT chose the Windows Azure platform, the team designed a solution that would ensure that the new BCWeb deployment would be useful as a migration showcase. The design also enabled BCWeb to take advantage of the benefits that the Windows Azure platform provides. Design Goals Microsoft IT identified several key design goals that the migration project should fulfill: BCWeb, Rapport, and WRAP should be maintained as physically and logically separate applications to ensure the most flexible environment for future application development. All network traffic should be encrypted end-to-end by using trusted certificates. All Windows Communication Foundation (WCF) endpoints should be internal to the application, unless external exposure was absolutely necessary. The new application infrastructure should remove any SharePoint dependencies. Integration with, and dependency on on-premises components should be as efficient and replaceable as possible. The application's architecture, once migrated to Windows Azure, should be scalable to handle usage peaks, without affecting application performance. The application's architecture, once migrated to Windows Azure, should eliminate single points of failure that existed in the legacy application's architecture. Design Collaboration The Microsoft IT Volume Licensing group collaborated with Accenture, a global management consulting, technology services and outsourcing company, to design and implement the migration of BCWeb to Windows Azure. Accenture supports many internal Microsoft IT applications, including BCWeb, so they used assets and accelerators from their Azure practice group to increase the speed of the assessment and migration process. Remapping the BCWeb Architecture to Windows Azure Maintaining the design goal of separating the BCWeb component applications, Microsoft IT mapped each application, and its core components, to separate Windows Azure services and roles. How Microsoft IT Architected and Redeployed a Page 3
BCWeb Architecture BCWeb was comprised of three core components: the web-based UI, background services, and data storage. The web-based UI was mapped directly to the Windows Azure Web role. The BCWeb services and background processes were split into two groups, and Microsoft IT mapped each to a Windows Azure. The WCF services were assigned to one, while the background processes and notification mechanisms were assigned to another. Finally, Microsoft IT mapped the SQL Server database components to Microsoft SQL Azure. Table 1. Mapping BCWeb Components to Windows Azure Roles BCWeb Component BCWeb UI WCF services Background processes SQL Server databases On-premises components Windows Azure Component Web role SQL Azure AppFabric ServiceBus WRAP Architecture Similar to BCWeb, WRAP's s also were split. One hosted the WCF services, such as the WRAP service and the workflow process, while the other contained notification and provisioning components. As with BCWeb, WRAP's SQL Server database components were mapped to SQL Azure. Table 2. Mapping WRAP Components to Windows Azure Roles WRAP Component WCF services Background processes SQL Server databases On-premises components Windows Azure Component SQL Azure AppFabric ServiceBus Rapport Architecture Microsoft IT continued with the separation of the three main application components by establishing an additional Windows Service for Rapport. Rapport consisted of two roles, a Web role to host the UI and a to host the business logic and service components. Table 3. Mapping Rapport Components to Windows Azure Roles Rapport Component Rapport UI Background processes Windows Azure Component Web role How Microsoft IT Architected and Redeployed a Page 4
Using Service Bus to Integrate On-Premises Components BCWeb also relied on on-premises components to provide access to information hosted outside of the BCWeb application infrastructure. To adequately integrate these components with the Windows Azure infrastructure, Microsoft IT employed the Windows Azure AppFabric Service Bus, which enables developers to build distributed applications on the Windows Azure platform. The Service Bus provides secure messaging and connectivity capabilities. This enables developers to use various communication and messaging protocols and patterns in their cloud-based applications, to communicate with on-premises resources without having to worry about delivery assurance, reliable messaging, and distribution scale. The Service Bus also solves issues that relate to on-premises resources and distributed applications, by: Connecting applications based on Windows Azure with on-premises applications and databases. Exposing applications and services through firewalls, network address translation (NAT) gateways, and other problematic network boundaries. Exposing communication endpoints easily, and supporting multiple connection options. Using Service Bus for BCWeb In the BCWeb architecture, Service Bus integrates with two key on-premises resources: SAP for business data. (For more SAP information, see "Upgrading a 6.5-Terabyte SAP ERP SQL Server Database to Support Microsoft Worldwide Operations" at: http://technet.microsoft.com/en-us/library/dd794468.aspx) Microsoft IT's corporate Active Directory, for organizational data Architecting the Windows Azure Platform for Resiliency A key aspect of the project's design goals was to provide an application that was scalable in performance and resilient in the case of single or multiple component failure. Fortunately for Microsoft IT, the Windows Azure platform natively supports architecture components that can fulfill both of these requirements. For the critical aspects of the two applications, like the UI and the core WCF components, the team implemented multiple instances of the associated Windows Azure roles. This enables the respective roles to use multiple instances of a role that are running concurrently to maintain performance by providing more application resources, or to provide continued services should a component of the application within any instance fail. The team also planned to build a component hosted within Windows Azure that would monitor process health and ensure instances were recycled if the component encountered issues. This approach removed several single points of failure that existed in the previous version of BCWeb. Key Implementation Tasks During the migration, Microsoft IT encountered challenges that required alteration of the project's design approach or the migration implementation. How Microsoft IT Architected and Redeployed a Page 5
Refactoring Application Code Several parts of BCWeb's application code needed to be refactored for Windows Azure. Most of the refactoring was specific to Windows Azure architecture, but a significant refactoring task was based on refactoring for Microsoft.NET Framework requirements. The majority of the original BCWeb application was developed primarily by using the Microsoft.NET Framework 2.0. To take full advantage of the Windows Azure platform, the development team refactored that code and upgraded the application to the Microsoft.NET Framework 4.0. Ensuring End-to-End Data Protection BCWeb contains important business information that Microsoft IT wanted to protect. Therefore, to host the application fully on Windows Azure, Microsoft IT had to secure the endpoints for accessing the application. However, the distributed architecture of BCWeb provided a slightly different challenge. Microsoft IT had to protect the data moving in and out of the application from the end user's web browser to database storage to integrated onpremises components. The migration team implemented WCF message encryption in all possible places within the architecture, as well as Secure Sockets Layer (SSL) encryption from the web browser to the application components, and from the Windows Azure components to the SQL Azure databases. Migrating Application Data For the initial data-migration process, Microsoft IT had to move a large amount of data to the Windows Azure platform. The development team moved approximately 20 gigabytes (GB) of data to the Windows Azure platform in less than six hours by using a combination of SQL Server Integration Services (SSIS) packages and Bulk Copy Program (BCP), which is a utility for moving large amounts of database information in and out of SQL Server. One key aspect of migration procedure that Microsoft implemented was retry logic in its code. Connections to SQL Azure opened by long-running tasks are closed after one minute, which means that a process could not depend on an open connection when it began. Ongoing Movement of Application Data The Windows Azure platform hosts the primary Online Transaction Processing (OLTP) functionality of BCWeb databases. However, the data-warehouse databases are hosted onpremises so they can be accessed correctly by external applications and processes. As a result, Microsoft IT had to ensure that the transactional data was exported to the on-premises data-warehouse database regularly. To accomplish this, Microsoft IT implemented SSIS to extract, transform, and load the data based on SQL Azure to the on-premises databases. Synchronizing SQL Azure Data In the legacy version of BCWeb, BCWeb and WRAP worked together to provide data from SQL Server databases for search and reporting services. Additionally, the legacy database structure contained several elements that were used for reporting purposes and integration with outside data sources. In SQL Azure, the previously used data-movement processes were refactored into SQL Azure Data Sync, which enables creating and scheduling regular synchronizations between SQL Azure and SQL Server or other SQL Azure databases. SQL Azure Data Sync can be used with Microsoft SQL Server 2005 SP2 or newer versions. How Microsoft IT Architected and Redeployed a Page 6
Ensuring Reliable Integration with On-Premises Components Rather than build integration mechanisms into each individual on-premises component, the development team chose to implement an on-premises active/passive Windows Server 2008 R2 failover server cluster. This cluster would act as a gateway between on-premises components and components on Windows Azure, and host those objects that were required to interact with on-premises components. Furthermore, the majority of communication between the on-premises components and BCWeb on Windows Azure would be routed through the Windows Azure AppFabric Service Bus to the gateway cluster. This approach consolidated communications and ensured the use of the fewest endpoints possible within the application architecture. One of the most important components involved was Microsoft's business information contained in SAP. BCWeb needed a reliable way to maintain synchronization with SAP data and also to be made aware of changes within SAP that would affect BCWeb functionality. Therefore, the development team created a lightweight service on the gateway server that would provide notification to the components on Windows Azure if any changes were made to the SAP data. Final Solution Architecture Figure 2. Architecture for BCWeb on Windows Azure Benefits There were several benefits that resulted from the successful migration of BCWeb to the Windows Azure platform, both from an application perspective and in best practices that Microsoft IT determined during the migration. How Microsoft IT Architected and Redeployed a Page 7
Application Benefits Increased performance and stability. The development team leveraged built-in Windows Azure components to increase performance and reliability. Multiple role instances in Windows Azure enabled BCWeb to scale according to performance demands, while providing redundancy to protect against single points of failure within the application architecture. Cost savings. BCWeb hosted on Windows Azure can now utilize the Windows Azure distributed cloud architecture. This means that no hardware must be purchased or maintained, as the BCWeb application is stored at a Windows Azure data center. Code refactoring savings. Much of the original application code from the previous version of BCWeb was reused or slightly refactored for use in the Windows Azure version. Reusable components. The development team created several different components to enable BCWeb to function properly on the Windows Azure platform. Many of these components can now be reused with minimal refactoring in other Windows Azure migrations. Best Practices Microsoft IT gained several best practices when migrating BCWeb to Windows Azure, and these can be used for future distributed application migrations to Windows Azure. The new best practices include: Prepare for refactoring for on-premises integration. When migrating a distributed application to Windows Azure, developers should be prepared to refactor their code or create new code to enable communication between Windows Azure and on-premises components. Plan for multiple communication and encryption methods. When migrating business data to Windows Azure, multiple communication and encryption methods may be required, depending on the on-premises components. Remember to build retry logic into code for endpoints and SQL Azure access to ensure success of process-based tasks. Use built-in Windows Azure component redundancy for performance and reliability. Windows Azure multi-instance roles enable developers to implement a more robust application platform. Create components for monitoring, if centralized monitoring is required. When working with a distributed application, developers will need to develop monitoring components to accurately monitor and maintain system health in an automated and centralized manner. Conclusion Working with a distributed application brought many challenges to the migration process, but the flexibility of the Windows Azure development platform allowed Microsoft IT to migrate the application while maintaining design goals. Migrating BCWeb to Windows Azure provided the application with the stability and flexibility that it lacked in its legacy architecture. Microsoft IT gained numerous best practices for distributed migration that will be used in future implementations. How Microsoft IT Architected and Redeployed a Page 8
Products & Technologies Windows Azure Web role Windows Azure Windows Azure AppFabric SQL Azure SQL Azure Data Sync Microsoft SQL Server 2008 R2 Microsoft Visual Studio 2010 Windows Azure SDK 1.4 For More Information For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to: http://www.microsoft.com http://www.microsoft.com/technet/itshowcase 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. How Microsoft IT Architected and Redeployed a Page 9