Hade du nytta av den här sidan?
Din feedback om det här innehållet är viktig. Berätta vad du tycker.
Ytterligare feedback?
1500 tecken kvar
MSDN Library
Det här innehållet finns inte tillgängligt på ditt språk men här finns den engelska versionen,

Development Considerations for Azure Cloud Services

Updated: June 25, 2014

Authors: Selcin Turkarslan

Reviewers: Tim Wieman, Valery Mizonov, Avilay Parekh, Paolo Salvatori, Steve Howard

Before migrating your applications to Microsoft Azure Cloud Services, we recommend that you first review the details of the service. The article, "Introducing Azure" provides information on:

  • Azure components.

  • Execution models.

  • Data management.

  • Networking.

  • Supported programming software development kits (SDKs), etc.

This article aims to provide introductory information about implementing a Microsoft Azure application using Microsoft Azure Cloud Services. There are almost an infinite number of migration scenarios. Therefore, we recommend that developers choose the most appropriate techniques and solutions for their applications and users.

Migrating an existing application to Azure includes:

  • Deciding on the compute execution model that best suits your application (e.g., Cloud Services, Web Sites, Virtual Machines (VM), etc.). Read "Introducing Azure: Execution Models".

  • Adding Azure-specific configuration and custom code.

  • Storing and managing your data in Azure.

  • Repackaging your existing application as an Azure application.

  • Deploying your application to Azure.

An application deployed to Microsoft Azure Cloud Services includes your application code, data management, and its configuration settings. When you develop an application for the cloud, the general architectural patterns are still applicable. For example, developers must architect their applications to handle availability, scalability, reliability, and security in a distributed environment. In addition, developers need to consider:

  • Service Level Agreements (SLA).

  • Capacity planning.

  • Customer billing.

  • Auditing.

  • Application monitoring.

  • Traffic analysis.

  • Cost management.

  • Scaling - when and how to scale up, scale down, scale out, and scale in their cloud applications.

In a traditional, private data center environment, you are responsible for purchasing, setting up, and maintaining hardware to run your services. With Azure, you can design and build applications that can scale on-demand by allocating virtualized resources. Some on-premises applications can run in Azure with very minimal or no changes. However, most applications can really benefit from designing and architecting for the cloud. To take full advantage of Azure, we recommend that you modify your application to use multiple roles before migrating to Azure.

For example, web services and applications hosted in legacy data centers often combine multiple functions in a single application. Sometimes this does not scale well. Many web applications also store persistent application state on a local disk drive, which does not work in the Azure Cloud Services environment. When migrating from an existing web application to Azure, to fully take advantage of cloud computing scalability and elasticity, you have two options:

Azure Cloud Services implements every application as one or more roles. Each role contains the code and configuration information required to carry out some part of your application's function. Front-end services and code that interacts directly with web browsers or other HTTP clients are Web roles. Web roles run on Internet Information Services (IIS), Microsoft's web server. A Worker role performs background processing and support tasks. Middle-tier services are typically Worker roles.

Each role can have multiple instances. Each instance runs the same code that has been written for the role. However, each role instance resides in a separate virtual machine in the Azure data center. For each role, you can indicate the desired VM size that instances of that role should use. For more information, read “Configure Sizes for Cloud Services”.

In addition to the functional differences between the roles, each role serves as a scaling unit for your application. For example, you can have 20 instances of your Web role to serve more traffic. Then you can have only 5 instances of your Worker role to process requests from the Web role asynchronously. If you want to create a simple ASP.NET, PHP, or Node.js application or web service, you might only use a Web role. We recommend that you perform detailed functional and performance tests on your cloud service. These tests will help you determine the optimal number of role instances and VM sizes before you deploy your application to production. For more information on cloud service concepts, browse the Azure Developer Center and the Azure Documentation Center.

Consider taking advantage of the available storage options that Azure provides. Doing so helps to simplify your application logic and improves your cloud service’s performance. It is very important that you understand the limitations of each data storage option while planning the application migration. You must also know how to identify the appropriate data storage option for your cloud service. For more information on available storage options in Azure, read “Overview of Data Management Services in Azure”.

You may also want to use the Azure Caching service to provide memory-based, high-speed storage for Azure applications. Caching increases performance by temporarily storing information from back end sources. Caching can reduce the costs associated with database storage access transactions in the cloud. For best performance results, deploy your application to data centers that fulfill these two criteria:

  • Closest to the majority of your clients.

  • Closest to the data center that hosts your storage account or Azure SQL Database instances.

However, you may have some jurisdictional or legal concerns about your data and where it resides. In that case, choose a data center closer to your company or closer to your data. For more information, read “Performance Considerations with Azure SQL Database”.

Before you start implementing your Azure Cloud Service, you must first purchase a Microsoft Azure subscription. For more information, browse the Microsoft Azure site. Then you must prepare your development environment. Microsoft provides language-specific SDKs for .NET, Java, PHP, Node.js, Python, and Ruby. For the most current information on the supported programming languages and platforms, browse the Microsoft Azure Documentation Center. Additionally, you can use the Azure SDK and Tools Download Center to access all the Azure client libraries, SDKs, and command-line tools.

Microsoft Azure also provides the Azure Web Sites service for hosting websites and web applications. Azure Web Sites is a fully managed Platform-as-a-Service (PaaS) offering that allows you to deploy and scale web apps in seconds. For more information, browse Azure Web Sites.

To allow client applications that run on different platforms to connect to relational data sources, Microsoft chose ODBC. It is the standard client connectivity API for native client applications that connect to Azure SQL Database (SQL Database). The SQL Server Native Client OLE DB Provider will ship for the last time in SQL Server 2012. The SQL Database will not support it.

When writing applications on Windows or Azure, use the .NET Data Provider for SQL Server. Alternatively, you can use the SQL Server Native Client ODBC driver that comes with SQL Server 2008 R2 or later. We recommended that you adopt ODBC in the development of new and future versions of your application. For existing applications that use OLE DB, we recommend that you migrate those applications to ODBC in the future. For more information on how to convert an OLE DB application to an ODBC application, read "Converting SQL Server Applications from OLE DB to ODBC". For information from the ADO.NET team on the OLE DB deprecation read the “Microsoft SQL Server OLEDB Provider Deprecation Announcement”.

As with any other application, you must architect your application to handle availability, disaster recovery, and security in a multi-tenant, distributed, cloud environment. For more information, read “High Availability and Disaster Recovery Considerations with Azure SQL Database” and the Azure Security Guidance. We recommend that you address the security requirements at the beginning of the software development lifecycle before onboarding an application to Azure.

For more information on application development in Azure, read “Developing Azure Applications” and “Failsafe: Guidance for Resilient Cloud Architectures”.

Azure is a multi-tenant, dynamic, scalable platform in the cloud. Therefore, you must consider cloud-specific monitoring and diagnostic techniques when you design your application. We recommend that you consider monitoring and diagnostics at the beginning of your software development lifecycle. Evaluate your existing monitoring and diagnostic techniques to determine if they will provide an adequate service after you deploy the application to the cloud. For example, an application generating large log files may require tuning in its diagnostic and logging settings. The tuning will allow it to produce smaller log files that can be quickly inspected or downloaded to the on-premises environment for further analysis.

The following list provides some available troubleshooting tools and techniques for Azure:

  • Azure Diagnostics (WAD): It collects operations and diagnostic data from your Azure service. Azure Diagnostics logs diagnostic data from various data sources such as:

      • IIS logs.

      • Windows Diagnostics infrastructure logs.

      • Windows Event logs.

      • Performance counters.

      • Crash dumps.

      • Custom error logs.

      You can configure the logging intervals for Azure Diagnostics. The collected information persists to Azure Table and Blob storage for analysis. For more information, read “Collect Logging Data by Using Azure Diagnostics”.

  • System Center Azure Management Pack (MP): The Azure Monitoring Management Pack allows you to monitor the availability and performance of applications that are running on Azure. For more information, read the “Guide for Monitoring Pack for Azure Applications”. We recommend that you use Azure Diagnostics and the System Center Azure Management Pack. For additional information, watch the video on the System Center 2012: Manage Applications Across Private and Public Clouds webpage.

  • Azure Storage Analytics: It performs logging and provides metrics data for an Azure storage account. You can use this data to trace requests, analyze usage trends, and diagnose issues with your storage account. For more information, read “Storage Analytics”.

  • SQL Database Connection Management: It handles error codes by implementing retry logic in your application. For more information, read “Azure SQL Database Resource Management”.

  • Azure PowerShell Cmdlets: They allow you to browse, configure, and manage Azure cloud and data management services directly from PowerShell. These tools can be helpful when developing and testing applications that use Azure Services. For more information, read “Azure Cmdlet Reference”.

  • Cloud Service Fundamentals reference solution: This application demonstrates how to build database-backed Azure services. This demonstration is based on lessons that the Microsoft Azure Customer Advisory Team (CAT) has learned while working with real-world customers. Learn the fundamental building blocks for scale-out Azure applications, including gathering and using telemetry data in your application. The reference solution is on the Cloud Service Fundamentals in Microsoft Azure webpage. The guidance includes a TechNet Wiki (Cloud Service Fundamentals Wiki) with detailed articles.

As with any other application, your Azure Cloud Service also needs detailed testing before uploading to production. You should test for functionality, end-to-end execution, performance, scalability, security, and so on.

For a detailed prescriptive guidance, read “Troubleshooting Best Practices for Developing Azure Applications”. For supplementary information, read “Collect Logging Data by Using Azure Diagnostics and “Testing, Managing, Monitoring and Optimizing Azure Applications”.

Azure offers a range of networking capabilities to help you integrate existing applications with the cloud and manage your network traffic. The primary networking and connectivity components in Azure are:

  • Azure Storage Queues: Azure Storage Queues can be used to store messages that clients may access and can provide reliable messaging between role instances. For more information, read “How to use Queue Storage from .NET” and “Storage”.

  • Azure Service Bus: We recommend that you use Azure Service Bus for any service-to-service communication within Azure. Additionally, use Azure Service Bus to keep integration between on-premises servers and Azure. Service Bus provides secure messaging and relay capabilities in the application layer. Azure Service Bus offers a cloud-based communication infrastructure that supports a common, secure messaging service on a public network. It provides a simple, unified namespace like https://myhostname.servicebus.windows.net. The Service Bus supports the following programming models: .NET API, REST API, and WCF. For more information, read the Service Bus Documentation webpage and “Azure Queues and Service Bus Queues - Compared and Contrasted”.

  • Azure Active Directory: We recommend that you use Azure Active Directory (AD) to provide scaled-out, claims-based access control for cloud-hosted web services and end-user applications. Azure Active Directory is a comprehensive identity and access management cloud solution. It combines core directory services, advanced identity governance, security, and application access management. Azure AD also offers developers an identity management platform to deliver access control to their applications based on a centralized policy and rules. The service also provides integration with Windows Identity Foundation (WIF). For more information, read “How to Authenticate Web Users with Azure Active Directory Access Control” and the Azure Active Directory Documentation webpage.

  • Azure Traffic Manager: Traffic Manager allows you to load balance incoming traffic across multiple, hosted Azure services. You can load balance traffic for services running in the same datacenter or across different datacenters around the world. By effectively managing traffic, you can ensure high performance, availability, and resiliency for your applications. For more information, read the Traffic Manager Documentation webpage.

  • Azure Content Delivery Network: The Azure Content Delivery Network (CDN) offers developers a global solution for caching content. You can cache content at locations closest to your customers to provide the best experience for your application. The CDN caches Azure blobs and the static content output of compute instances at strategically placed locations. By doing so, the CDN provides maximum bandwidth for delivering content to users. You can activate CDN delivery for your content providers using the Azure Platform Management Portal. For more information, read the Azure CDN Documentation webpage.

  • Azure Virtual Network: Azure Virtual Network allows you to create a logically isolated section in Azure. Then you can securely connect it to your on-premises datacenter or a single client machine using an IPsec connection. Virtual Network makes it easy for you to take advantage of Azure’s scalable, on-demand infrastructure. It also provides connectivity to on-premises data and applications, which includes systems running on Windows Server, mainframes, and UNIX. For more information, read the Virtual Network Documentation webpage.

  • Azure ExpressRoute: Azure ExpressRoute allows you to create private connections between Azure datacenters and infrastructure on your premises or in a co-location environment. ExpressRoute connections do not traverse the public Internet. They offer more reliability, faster speeds, lower latencies, and higher security than typical connections over the Internet. With ExpressRoute, you can establish connections to Azure at an ExpressRoute location (Exchange Provider facility). Alternatively, you can connect directly to Azure from your existing WAN network (such as a MPLS VPN). For more information, read the ExpressRoute Overview and ExpressRoute Documentation webpages.

For more information, read the Network Services webpage

After you complete the development of your cloud service or application, you are ready to package, upload, and deploy it to Azure. There are four different deployment scenarios:

  • New Deployment

  • Configuration Change

  • Incremental Code Upgrade

  • Major Upgrade

For more information, read “How to Manage Cloud Services”, “Manage Deployments in Azure”, and “Managing Your Services”.

You can configure multiple deployments using one Azure subscription to support development, testing, QA, staging, etc. Azure also allows you to configure one Azure account to access multiple subscriptions. You can, therefore, create separate development and testing environments, with their own subscriptions, for your Azure application. In this case, consider deploying your service to a test subscription first and then to a production subscription. When you are ready for your service to go live, you can move it to the production environment. After you deploy your cloud service to a production subscription, you can use the staging environment for continuous testing.

Azure allows you to configure your application to automatically scale up or down to match the current demands and minimize costs. To activate this feature, use the “auto scale” rules and schedules. For more information, read “How to Scale an Application”.

See Also

© 2015 Microsoft