Eksportuj (0) Drukuj
Rozwiń wszystko
EN
Ta zawartość nie jest dostępna w wymaganym języku. Wersja w języku angielskim znajduje się tutaj.

Planning a Migration to Azure

Updated: April 17, 2014

When you begin planning your migration, you need to consider several key factors, such as, cost, business and technical requirements, timeline, and any testing that will be required in the migration process. This section provides a walk through on several concerns and steps you should consider as you plan migrating to Azure:

Authors: Steve Howard
Reviewers: James Podgorski, Paolo Salvatori, Selcin Turkarslan, Stuart Ozer

Plan for cost

Cost is one of the biggest questions that needs be answered. We recommend that you address it early in the decision making and planning process when considering the migration of an on-premises application to Azure. Pricing an application for Azure depends on a number of factors such as the network traffic load, input/output characteristics of the application, and volume of data processed by the application. Calculating price is outside the scope of this topic. We recommend that you use the Azure pricing calculator to help estimate cost as you begin planning your migration. You can find the Azure pricing calculator here.

When calculating the cost to your organization, remember to include direct Azure costs during development and testing. In an on-premises development project, you pay for development and testing servers. Similarly, in the Azure environment, you need to pay for the resources you use during development and testing. Additionally, you should calculate training and learning costs, and costs associated with porting the application to the Azure. We recommend that you conduct performance testing and capacity planning to assess how much capacity you will need for your application in advance.

Identify key business and technical requirements that Azure can help resolve

Azure can address some business and technical requirements very well. While this list is not all inclusive, applications with these characteristics are good candidates for migration to Azure:

  • Distributed user base: Azure data centers are located across several continents. Interconnection between the data centers allows for high performance data distribution where necessary. Azure features such as Content Distribution Network (CDN) and Data Synchronization services allow you to keep relevant or high-use data distributed across data centers that are near end users. Having users hit the data centers close to their geographical location minimizes the length of a round trip, thus optimizing the user experience.

  • Variable load: You need to purchase hardware for on-premises applications to handle peak load. For example, a retail outlet typically buys servers to be able to handle the load for holiday shopping seasons. Similarly, an accounting department may plan additional infrastructure to be able to handle peak loads at end of month or end of year closing cycles. The rest of the time, servers intended to handle such peak loads are underutilized. On the other hand, applications architected for elastic-scale can take advantage of Azure to bring new instances of applications online during peak times, and return to lower levels of processing power and capacity during periods of lower need. In this way, Azure allows you, with properly architected and managed applications, to pay only for what you need.

  • Multi-tenancy: For service providers, Azure allows several ways to provide your application services to any number of customers on the same infrastructure, thus minimizing your operational costs.

  • Need to focus on applications: Service providers in particular want to focus their resources on development of applications and features more than on maintaining infrastructure. Azure frees you from much of the administrative overhead required by the infrastructure hosting on-premises or traditional hosted-server applications. It allows you to focus your resources on developing applications and features.

  • Minimizing infrastructure resource requirements: When you architect your applications to take advantage of the elastic scale that Azure provides, instances of roles and resources can be allocated as they are needed as well. There is no up-front hardware investment and no need to maintain servers capable of handling peak load during times of low utilization.

In addition to the traditional platform as a service oriented advantages; Azure can host virtual machines. These virtual machines can run any Azure supported operating system, and can run applications in the same way they would run on-premises. For a list of supported operating systems, see Overview of Azure Virtual Machines. These virtual machines can also be part of a larger application architecture which may include instances of web or worker roles, and other Azure components. Virtual machines are a way to port some services or application parts that may not otherwise be easily portable to Azure. For more information, see Migrating with Azure Virtual Machines.

Perform analysis and design

In the analysis and design phase, you should identify the applications that would benefit you the mose by moving to Azure. Then, begin designing the Azure implementation and the plan of implementation. During this phase, you should plan the outline of the architecture design and timeline.

Some of the key elements of the planning are:

  • Identify current challenges: The following list shows some examples of challenges that should be identified in planning for any re-architecture need:

    • Application components that are not performing up to standard at current loads on the current architecture: For example, if a SQL query is not performing satisfactorily, you should tune it prior to migration or further design. You should also re-design and scale-out any application-tier components.

    • Determine Elastic Scale Requirements: You should identify how your application can be decomposed into functional, independently scalable units which can run independently of each other.

    • Uneven load patterns: You should identify the uneven load patterns and design the application for scale-out to handle the peak periods. You should make plans on how to manage the level of scale out from peak periods to low demand periods.

    • Growth projections: Often, growth projections are what first alert an IT department that a change of paradigm may be necessary. Decide where scale out may be a solution to address growth projections. The growth projections may also be the indicator that you need to consider paradigm shifts such as switching to a paradigm of big-data analytics in certain data warehouse-centric applications. At the planning stage, you should discuss these options. Keep in mind that you may not be able to know the solution for sure until later in the design and implementation process. You should list such contingencies and determining factors so you can evaluate them at the proper time, such as during the initial migration or at a later date.

  • Identify technical requirements: Learn what the requirements of each component of your application are at both peak and off-peak times. Then, plan for scale for each component. Each component might have a different ability and mechanism to scale. Technical requirements can be more than just performance. For example, high availability and disaster recovery requirements, or requirements for maximum network latency should be determined and compared with Azure capabilities when planning a migration. The following list shows some examples of technical requirements:

    • Use of relational storage: Examine the data stored in the relational databases. Data that is truly transactional and relational in nature, or data that requires truly transactional processing should stay in relational storage. You may use an Azure SQL Database (SQL Database) or SQL Server running in Virtual Machines to store this type of data. You can store other type of data in Azure Tables, Azure Blob storage, or Azure drives efficiently. We recommend that you identify the type of storage that is needed for each part of your data.

    • Choosing your relational data storage: The choice of SQL Database or SQL Server running in Azure Virtual Machines depends on several factors. If you want to avoid the administrative overhead of high-availability, load balancing and transparent failover, SQL Database is the best choice. However; for an intermediate state while migrating an application, or for special cases where features are not yet available in SQL Database, SQL Server running in Azure Virtual Machines might be the best solution. The answers to these questions depend on the situation and the solution. The following list shows some considerations on this:

      • Database size: Azure SQL Databases are currently limited to 5 GB of data for the Web Edition Database and to 150 GB of data for the Business Edition Database. To expand the capacity of the database, use a scale out method. To learn about Azure scale out methods, read "Scaling Out Windows Azure SQL Databases". For the most up-to-date information on available database editions and sizes, see Accounts and Billing in SQL Database.

      • Number of databases: By default, SQL Database supports up to 6 servers per subscription and 150 databases in each SQL Database server, including the master database. An extension of this limit is available. For more information, contact a customer support representative at the Microsoft Online Services Customer Portal.

      • Cross-database queries: SQL Database currently does not support cross database joins or other cross database queries. If you have unions or joins that require data from more than one database in SQL Database, you must perform that logic in the application-tier of your application.

      • Common Language Runtime (CLR) objects: SQL Database does not currently support CLR stored procedures, aggregations, triggers, or functions. You should port stored procedures, triggers, or functions in Transact-SQL to run on SQL Database. Complex logic or operations, such as aggregations, that cannot be performed in Transact-SQL at the database-tier should be moved to the application tier. You may use a worker role to perform such work.

      • Data types: SQL Database does not provide support for some of SQL Server's system data types. For the most up-to-date information, see Data Types (SQL Database) in the SQL MSDN library.

      • Replication: Replication types such as transactional replication or merge replication are not available in SQL Database. You can set up and run them in SQL Server running in Azure Virtual Machines. You can use SQL Data Sync to synchronize data between SQL Database instances. But the SQL Data Sync service may not be satisfactory where transactional consistency or complex conflict resolutions are required. Warning: SQL Data Sync is currently available only as a Preview and is meant only for product feedback for future releases and should not be used in production environments.

      • Full Text Search: Azure SQL Database does not currently support Full-text Search. If your application runs full-text queries against character data in SQL Server tables, you may want to consider migrating your database to a SQL Server in an Azure Virtual Machine. For more information on SQL Server in Azure VM, see Migrating to SQL Server in an Azure Virtual Machine topic.

      • Licensing: SQL Database charges per month for the database size chosen. SQL Server requires a license when running in an Azure Virtual Machine.

      • Login and security: Windows Authentication (integrated security) is not supported in SQL Database but is available for SQL Server running in Azure Virtual Machines. For more security guidelines and limitations of SQL Database, see Security Guidelines and Limitations (SQL Database).

      • Feature parity: For more information on similarities and differences between SQL Server and SQL Database, see SQL Database Overview.

  • Login and User Security: With new network enhancements to Azure, an active directory domain from the on-premises network can be extended to Azure. For more information, see Migrating with Azure Virtual Machines. For detailed information on SQL Database Security Administration, see Managing Databases and Logins in SQL Database.

  • Functional decomposition of the application: Identify where the application can be broken down into functional units so that it can run in separate Azure roles or virtual machines. You can do this to produce elastic scale and also to allow for hybrid applications if some applications are not good fits for cloud computing.

  • Payment Card Industry (PCI) and other regulatory requirements: Prior to moving an application or component to Azure, check the current status of required certifications or requirements. In cases such as PCI compliance requirements, you may want to remove some parts of the application and database from what is migrated to Azure, and run a hybrid application. This allows for the benefits of Azure and cloud computing on most components while still allowing for tight institutional control and compliance for the parts of the data and application for which it is required.

  • Key components that cannot be hosted in Azure Platform: You may not be able to host some components or some types of data in the public cloud due to some other concerns. Identify these components and consider a hybrid application. With hybrid architecture, you can host some components in Azure to realize the full benefit of Azure and cloud computing. At the same time you can still achieve tight institutional control and compliance for the parts of the data and application for which it is required.

Plan the timeline

Once you define the scope of the migration, the amount of work for each step in the migration plan becomes clear as well. Look at each application and data component and estimate the time and resources required for development, testing and migration. When functionally decomposing your application, develop those decomposed components in parallel to produce the elastically scalable components.

Set project milestones such as functional and performance testing, and release dates in your migration plan. Your migration may proceed in a series of steps and iterations as different components become ready for Azure, or as components are ready to be moved to Azure web roles and worker roles.

Make a plan for the interim

When the timeline for development and migration is set, plan for growth in that time period and decide what must be done to the existing application and infrastructure. This kind of planning allows you to operate your existing system until your migration is complete. When forming this interim plan, identify current pain points and identify what must be done to allow continued operations, and at what scale operations can continue on the interim infrastructure. In addition, identify steps that you may need to allow the continued operations. Often these steps may be as simple as tuning a SQL query or adding a web server depending on your particular application’s characteristics. Identify contingency plans in case of faster than expected growth or unexpected surges. When making contingency plans, consider whether surges or growth can be handled by scaling out to Azure Virtual Machines as this may allow you to handle these situations without additional hardware investment.

Make a plan for testing

Any migration plan should include plans for comprehensive functionality testing and load testing. A description of testing methodologies is beyond the scope of this article. The following list shows some critical points to remember when testing:

  • Automate test scripts

  • Test all tiers and components of your application

  • Test on ratios of activities that represent the real ratios on your systems

  • Test to a level of your highest expected utilization or beyond

We recommend that you include time for building and running tests as well as fixing problems found by testing.

Identify the resources needed

When you define the business and technical requirements, identify the resources needed to execute the migration successfully. You may need to bring these in for the migration. There are three primary areas to look at when identifying resources:

  • Personnel: You may need to bring in additional employees with additional skill sets in order to successfully migrate your application. In addition, after the migration, roles of technical staff may change and skills may need updating. For example, consider the roles of Account Administrator and service administrators to manage logins, access and service and scale levels.

  • Tools: Identify the tools you need to develop, test, and deploy your Azure application. For more information, see Azure Tools for Microsoft Visual Studio and Tools and Utilities Support (SQL Database).

  • Consulting: You may need specific expertise for migrating your application. A migration specialist may save considerable time and money by helping you avoid common pitfalls.

Plan the application management in Azure

For small applications, the Azure Management portal may be sufficient for management of Azure deployments. The Azure Management portal allows you to log in and manage the deployments and applications including changing the number of instance roles, and managing SQL Database instances. However, for complex applications and applications that provide a service to customers, the Azure Management portal may not be sufficient.

Azure exposes the REST API to allow you to programmatically manage applications and VMs hosted in Azure as well provisioning and using Azure storage. You can write a management interface to handle scaling and monitoring of your Azure environment. Your migration plan should include a plan for managing the application after migration, especially if this management is to include a custom interface or automation.

For more information on the REST API for managing your Azure deployments see API References for Azure.

See Also

Zawartość społeczności

Dodaj
Pokaż:
© 2014 Microsoft