Development Considerations for Windows Azure Cloud Services
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
When you consider migrating your applications to Windows Azure Cloud Services, we recommend you first understand and learn Windows Azure Cloud Services. The Introducing Windows Azure article provides information on the components of Windows Azure, data management, and the supported programming software development kits (SDKs).
This topic aims to provide introductory information on implementing a Windows Azure application. Due to all infinite different migration scenarios, it’s recommended that developers choose the most appropriate techniques and solutions for their applications and users.
Migrating an existing application to Windows Azure includes:
Adding Windows Azure specific configuration and some custom code
Repackaging your existing application as a Windows Azure application
Deploying your application as a cloud service running on Windows Azure virtual machine.
A Windows Azure cloud service includes both your application code and its configurations settings on Windows Azure. When you develop an application for the cloud, the general architectural patterns are still applicable, such as 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, capacity planning, customer billing, auditing, application monitoring, traffic analysis, and managing costs as well as when to scale up or down.
Authors: Selcin Turkarslan
Reviewers: Valery Mizonov, Avilay Parekh, Paolo Salvatori, Steve Howard
Creating a cloud service in Windows Azure
In a traditional private data center environment, you are responsible for purchasing, setting up, and maintaining hardware to run your services. With Windows Azure, you can design and build applications that can scale on-demand by allocating virtualized resources. While some on-premises applications can run in Windows Azure with very minimal or no changes, most applications can really benefit from designing and architecting for the cloud. In order to take the full advantage of Windows Azure, we recommend that you modify your application by using multiple roles before migrating to Windows Azure.
For example, web services hosted in legacy data centers often combine multiple functions into a single application, which does not scale well. They also store application state on a local disk drive, which does not work in Windows Azure Cloud Services environment. When migrating from an existing web application to Windows Azure, we recommend that you convert your legacy application code to Windows Azure web or worker roles.
In Windows Azure Cloud Services, every application is implemented as one or more roles. Each role contains the code and configuration information required to carry out some part of your application's function. A web role is intended to be used by front-end services and code that interacts directly with web browsers or other HTTP clients—it runs on IIS, Microsoft's web server. A worker role is typically used to perform background processing and support tasks, and is most suited for middle-tier services. Each role can have multiple instances. Each instance runs the same code that has been written for the role but each role instance resides in a separate virtual machine in the Windows Azure data center. For each role, you can indicate the desired VM size that instances of that role should use. For more information, see How to Configure Virtual Machine Sizes in the MSDN library. In addition to the functional differences between the roles, each role serves as a scaling unit for your application. In other words, you can have 20 instances of your web role to serve more traffic and only 5 instances of your worker role to process requests from the web role asynchronously. If you just want to create a simple ASP.NET, PHP, Node.js application or WCF service, for example, you might use only a web role. We recommend that you perform detailed functional and performance tests on your cloud service to determine the optimal number of role instances and VM sizes before uploading your application to production. For more information on cloud service concepts, see Windows Azure Developer Center.
We recommend that you consider taking advantage of the available storage options that are provided by Windows Azure. This helps to simplify your application logic and improves your cloud service’s performance. That’s why, it is very important to understand the limitations of each data storage option while planning the application migration and have a solid knowledge of when to use which data storage option for your cloud service. For more information on available storage options in Windows Azure, see Overview of Data Management Services in Windows Azure in Windows Azure. In addition, you may want to use the Windows Azure Caching service to provide memory-based high-speed storage for Windows Azure applications. Caching increases performance by temporarily storing information from other backend sources, and can reduce the costs associated with database storage access transactions in the cloud. If you plan to migrate an application that has strong dependencies on the underlying file-system, see Migrating Data to Windows Azure Drives topic for a detailed guidance. Using Windows Azure Cloud Drive allows you to migrate an application that must continue maintaining its state in the traditional NTFS file system. For best performance results, deploy your application to data centers that are closest to your majority of clients and to the data center that is hosting your storage account or Windows Azure SQL Database instances. However, you might choose a data center closer to your company or closer to your data if you have some jurisdictional or legal concerns about your data and where it resides. For more information, see Performance Considerations with Windows Azure SQL Database.
Application Development in Windows Azure
Before you start implementing your Windows Azure cloud service, you must first get a Windows Azure subscription. For more information, see WindowsAzure.com site. Then, you must prepare your development environment. Microsoft currently provides language-specific SDKs for .NET, Java, PHP, Node.js, and Python. For the most-up-to date information on the supported programming languages and platforms, see WindowsAzure.com site. In addition, you can use the Windows Azure Download Center to access to all the Windows Azure client libraries, SDKs, and command-line tools.
To enable client applications running on various different platforms to connect to the cloud, Microsoft chose ODBC as the standard client connectivity API for native client applications connecting to Windows Azure SQL Database (SQL Database). The SQL Server Native Client OLE DB Provider will ship for the last time in SQL Server 2012 and is not supported in SQL Database. When writing applications on Windows or on Windows Azure, you should use the SQL Server Native Client ODBC driver that comes with SQL Server 2008 R2 or later. It's recommended that you adopt ODBC in the development of your new and future versions of your application. For existing applications that use OLE DB, we recommend that you consider migrating those applications to ODBC as a part of your future roadmap. For more information on how to convert an OLE DB application to an ODBC application, see Guidance of OLE DB to ODBC Conversion white paper. Starting with the Windows Azure Preview release, Windows Azure provides a new service to the service providers: Windows Azure Web Sites. This new service enables developers to quickly create and deploy a web site to Windows Azure. With this new service, you can develop and publish your web sites directly at the Windows Azure Portal. For more information, see Windows Azure Web Sites at WindowsAzure.com site.
As with any other application development, you must architect your application to handle availability, disaster recovery, and security in a multi-tenant, distributed, cloud environment. For more information, see High Availability and Disaster Recovery Considerations with Windows Azure SQL Database in Windows Azure and Security Resources for Windows Azure. We recommend that you address the security requirements at the beginning of the software development life before onboarding an application onto Windows Azure. For more information on application development in Windows Azure, see Developing Windows Azure Applications.
Logging, Testing, Diagnosing, and Debugging Windows Azure Applications
Since Windows Azure is a multi-tenant dynamic scalable platform on the cloud, you need to consider cloud-specific monitoring and diagnostics techniques when you design your application. We recommend that you consider monitoring and diagnostics at the beginning of your software development life cycle. We recommend that you evaluate if your existing monitoring and diagnostics techniques would provide an adequate service after the application is deployed on the cloud. For example, an application generating large log files may require tuning in its diagnostic and logging settings. Therefore, it produces a small number of 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 Windows Azure:
Windows Azure Diagnostics (WAD): It collects operations and diagnostic data from your Windows Azure service. Windows Azure Diagnostics logs diagnostic data from various data sources, such as, IIS 7.0 logs, Windows Diagnostics infrastructure logs, , Windows Event logs, performance counters, crash dumps, and Custom error logs, at a regular configurable interval and persists the collected information into the Windows Azure Table and Blob storage for analysis. For more information, see Overview of Windows Azure Diagnostics.
System Center Windows Azure Management Pack (MP): The Windows Azure Monitoring Management Pack enables you to monitor the availability and performance of applications that are running on Windows Azure. For more information, see Guide for Monitoring Pack for Windows Azure Applications. We recommend that you use both Windows Azure Diagnostics and the System Center Windows Azure Management Pack to effectively monitor the availability and performance of your Windows Azure applications. For an additional video, see System Center 2012: Manage Applications Across Private and Public Clouds.
Windows Azure Storage Analytics: Performs logging and provides metrics data for a storage account. You can use this data to trace requests, analyze usage trends, and diagnose issues with your storage account. For more information, see Storage Analytics in the MSDN library.
SQL Database Connection Management: Handle error codes by implementing re-try logic in your application. For more information, see Connection Management in SQL Database at TechNet wiki.
Windows Azure PowerShell Cmdlets: The Windows Azure PowerShell Cmdlets enable you to browse, configure, and manage Windows Azure cloud and data management services directly from PowerShell. These tools can be helpful when developing and testing applications that use Windows Azure Services. For more information, see Windows Azure PowerShell Cmdlets.
As with any other application, your Windows Azure cloud service also needs detailed testing before uploading to production, such as functionality, end-to-end execution, performance, scalability, security, and so on.
For a detailed prescriptive guidance, see Troubleshooting Best Practices for Developing Windows Azure Applications. For supplementary information, see Monitoring Hosted Services and Logging Data in Windows Azure and Testing, Managing, Monitoring and Optimizing Windows Azure Applications in the MSDN library.
Cloud-based networking and connectivity options in Windows Azure
Windows 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 Windows Azure are below:
Windows Azure Service Bus: We recommend that you use Windows Azure Service Bus for any service-to-service communication within Windows Azure and also to keep integration between on-premise servers and the Windows Azure. The Service Bus provides secure messaging and relay capabilities in the application layer. The Windows Azure Service Bus offers a cloud-based communication infrastructure that supports a common secure messaging service on a public network with a simple unified namespace like https://myhostname.servicebus.windows.net. The Service Bus supports the following programming models: .NET API, REST API, and WCF.
Windows Azure Access Control Service: We recommend that you use Windows Azure Access Control to provide a federated, claims-based access control for cloud-hosted WCF and REST web services and end-user applications. Access Control is a Windows Azure service that provides an easy way of authenticating users who need to access your web applications and services without having to factor complex authentication logic into your code. The service also provides an integration with Windows Identity Foundation (WIF). For more information on ACS, see How to Authenticate Web Users with Windows Azure Access Control Service.
Windows Azure Connect: We recommend that you use Windows Azure Connect to enable a secure connection between on-premise servers and Windows Azure. This provides a migration path to Windows Azure for existing applications by enabling direct IP-based network connectivity with existing on-premises services and infrastructure. In addition, Windows Azure Connect simplifies direct connectivity to cloud-hosted virtual machines, enabling remote administration and troubleshooting via the same tools used for on-premises applications. For more information, see Connecting Local Computers to Windows Azure Roles.
Windows Azure Traffic Manager: Traffic Manager allows you to load balance incoming traffic across multiple hosted Windows Azure services whether they’re running in the same datacenter or across different datacenters around the world. By effectively managing traffic, you can ensure high performance, availability and resiliency of your applications. Windows Azure Traffic Manager is currently in Community Technology Preview (CTP) and available at no charge.
Windows Azure Content Delivery Network: The Windows Azure Content Delivery Network (CDN) offers developers a global solution for caching content at locations closest to your customers or users to provide the best experience for your application. The CDN caches Windows Azure blobs and the static content output of compute instances at strategically placed locations to provide maximum bandwidth for delivering content to users. You can enable CDN delivery for your content providers using the Windows Azure Platform Management Portal. For more information, see Overview of the Windows Azure CDN.
Windows Azure Virtual Network: Starting with Windows Azure Preview release, Windows Azure supports this new service to provide a secure site-to-site network connectivity between on-premises and cloud. For more information, see Overview of Windows Azure Virtual Machines in the MSDN library.
Windows Azure SQL Data Sync (SQL Data Sync): The service currently has two main capabilities. It allows you to synchronize data between on-premises SQL Server databases and the databases in Windows Azure SQL Database, allowing on-premises and cloud-based applications to utilize the same data. In addition, you can synchronize data between two or more SQL Database instances; the databases can be in the same data center, different data centers or different regions. SQL Data Sync is often used with Windows Azure Traffic Manager. 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.
For more information, see Networking and Caching in Windows Azure.
Application Deployment and Management in Windows Azure
After you complete developing your cloud service or application, compile and upload it to Windows Azure. There are four different deployment scenarios:
Incremental Code Upgrade
Windows Azure allows you to configure multiple subscriptions under one Windows Azure account. This enables you to create separate development and testing environments for your service. In this case, consider deploying your service to a test subscription first, and then to a production subscription. After you deploy your cloud service to a production subscription, you can use the staging environment for continuous testing. When you are ready for your service to go live, you can move it to the production environment.