Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Application Patterns and Development Strategies for SQL Server in Windows Azure Virtual Machines

Technical Article for SQL Server and Windows Azure

Summary: Determining which application pattern or patterns to use for your SQL Server based applications in Windows Azure environment is an important design decision and it requires a solid understanding of how SQL Server and each infrastructure component of Windows Azure work together. With SQL Server in Windows Azure Infrastructure Services, you can easily migrate, maintain, and monitor your existing SQL Server applications built-on Windows Server to virtual machines in Windows Azure.

The goal of this article is to provide solution architects and developers a foundation for good application architecture and design, which they can follow when migrating existing applications to Windows Azure as well as developing new applications in Windows Azure.

For each application pattern, you will find an on-premises scenario, its respective cloud-enabled solution, and the related technical recommendations. In addition, the article discusses Windows Azure specific development strategies so that you can design your applications correctly. Due to all infinite different application patterns, it’s recommended that architects and developers should choose the most appropriate pattern for their applications and users.

Author: Selcin Turkarslan

Technical Contributors: Luis Carlos Vargas Herring, Madhan Arumugam Ramakrishnan

Technical Reviewers: Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkowski, Sanjay Mishra, Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman, Xin Jin

Contents

Introduction

You can develop many types of n-tier applications by separating the components of the different application layers on different machines as well as in separate components. For example, you can place the client application and business rules components in one machine, front-end web tier and data access tier components in another machine, and a back-end database tier in another machine. This kind of structuring helps isolate each tier from each other. If you change where data comes from, you don’t need to change the client or web application but only the data access tier components.

A typical n-tier application includes the presentation tier, the business tier, and the data tier:

  • The presentation tier (web tier, front-end tier) is the layer in which users interact with an application.

  • The business tier (middle tier) is the layer that the presentation tier and the data tier use to communicate with each other and includes the core functionality of the system.

  • The data tier is basically the server that stores an application's data (for example, a server running SQL Server).

Application layers describe the logical groupings of the functionality and components in an application; whereas tiers describe the physical distribution of the functionality and components on separate physical servers, computers, networks, or remote locations. The layers of an application may reside on the same physical computer (the same tier) or may be distributed over separate computers (n-tier), and the components in each layer communicate with components in other layers through well-defined interfaces. You can think of the term tier as referring to physical distribution patterns such as two-tier, three-tier, and n-tier. A 2-tier application pattern contains two application tiers: application server and database server. The direct communication happens between the application server and the database server. The application server contains both web-tier and business-tier components. In 3-tier application pattern, there are three application tiers: web server, application server, which contains the business logic tier and/or business tier data access components, and the database server. The communication between the web server and the database server happens over the application server. For detailed information on application layers and tiers, see Microsoft Application Architecture Guide.

Before you start reading this article, you should have knowledge on the fundamental concepts of SQL Server and Windows Azure. For information, see SQL Server Books Online, SQL Server in Windows Azure Virtual Machines and WindowsAzure.com.

This article describes several application patterns that can be suitable for your simple applications as well as the highly complex enterprise applications. Before detailing each pattern, we recommend that you should familiarize yourself with the available data storage services in Windows Azure, such as Windows Azure Storage, Windows Azure SQL Database, and SQL Server in a Windows Azure Virtual Machine. To make the best design decisions for your applications, understand when to use which data storage service clearly. The Data Management: Choosing the Right Technology article provides a detailed comparison of each data storage service in Windows Azure.

In summary, choose SQL Server in a Windows Azure Virtual Machine, when:

  • You require a full compatibility with SQL Server on-premises and want to move existing applications to Windows Azure as-is.

  • You want to leverage the capabilities of Windows Azure environment but Windows Azure SQL Database (SQL Database) does not support all the features that your application or database needs, such as:

    • High availability and disaster recovery: You want to have the traditional availability and disaster recovery features of SQL Server, such as AlwaysOn Availability Groups or database mirroring. With SQL Server in a Windows Azure Virtual Machine, you have full control on setting up and executing the SQL Server based high availability and disaster recovery solutions for your applications. This ability prevents your databases from any downtime due to software or hardware failures or operating system upgrades in Windows Azure. On the other hand, Windows Azure SQL Database provides built-in resiliency to node-level failure in Windows Azure. In the case of node failure the database automatically fails over to one of the secondary replicas. Since you don’t have any control on how a failover can happen, you need to handle the connection interruptions for client applications running against SQL Database.

    • Database size: Currently, SQL Database supports a database of up to 150 GB of data. If your application requires more than 150 GB of data and you don’t want to implement custom sharding solutions, it’s recommended that you use SQL Server in a Windows Azure Virtual Machine.

    • HIPAA compliance: Healthcare customers and Independent Software Vendors (ISVs) might choose SQL Server in Windows Azure Virtual Machines instead of Windows Azure SQL Database because SQL Server in a Windows Azure Virtual Machine is covered by HIPAA Business Associate Agreement (BAA). For information on compliance, see Windows Azure Trust Center.

    • Functionality gaps: Some customers might choose SQL Server in Windows Azure Virtual Machines instead of Windows Azure SQL Database because of the functionality gaps in Windows Azure SQL Database, such as data compression and flexibility in backup and restore. For more information, see Guidelines and Limitations (Windows Azure SQL Database).

1-tier application pattern: single virtual machine

In this application pattern, you deploy your SQL Server application and database to a standalone virtual machine in Windows Azure. The same virtual machine contains your client/web application, business components, data access layer, and the database server. The presentation, business, and data access code are logically separated but are physically located in a single server machine. Most customers start with this application pattern and then, they scale out by adding more web roles or virtual machines to their system.

This application pattern is useful when:

  • You want to perform a simple migration to Windows Azure platform to evaluate whether the platform answers your application’s requirements or not.

  • You want to keep all the application tiers hosted in the same virtual machine in the same Windows Azure data center to reduce the latency between tiers.

  • You want to quickly provision development and test environments for short periods of time.

  • You want to perform stress testing for varying workload levels but at the same time you do not want to own and maintain many physical machines all the time.

The following diagram demonstrates a simple on-premises scenario and how you can deploy its cloud enabled solution in a single virtual machine in Windows Azure.

1-tier application pattern

Deploying the business layer (business logic and data access components) on the same physical tier as the presentation layer can maximize application performance, unless you must use a separate tier due to scalability or security concerns.

Since this is a very common pattern to start with, you might find the following links useful for migrating on-premises data and application files to Windows Azure Virtual Machines: Getting Ready to Migrate to SQL Server in Windows Azure Virtual Machines and Migrating to SQL Server in a Windows Azure Virtual Machine. In addition, you can Use the Windows Azure Import/Export Service to Transfer Data to Blob Storage. Using the Import/Export Service, you create an import job to move data files to Windows Azure Storage. Microsoft uploads the data in disk to Windows Azure Storage. Once Microsoft finishes uploading the data files to BLOB storage in the same data center as your virtual machine, you can do remote desktop to the virtual machine and download the data files from BLOB storage. You can also access the files in in Bob Storage, using the Blob storage SDKs.

3-tier simple application pattern: multiple virtual machines

In this application pattern, you deploy a 3-tier application in Windows Azure by placing each application tier in a different virtual machine. This provides a flexible environment for an easy scale-up and scale-out scenarios. When one virtual machine contains your client/web application, the other one hosts your business components, and the other one hosts the database server.

This application pattern is useful when:

  • You want to perform a migration of complex database applications to Windows Azure Virtual Machines.

  • You want different application tiers to be hosted in different regions. For example, you might have shared databases that are deployed to multiple regions for reporting purposes.

  • You want to move enterprise applications from on-premises virtualized platforms to Windows Azure Virtual Machines. For a detailed discussion on enterprise applications, see What is an Enterprise Application.

  • You want to quickly provision development and test environments for short periods of time.

  • You want to perform stress testing for varying workload levels but at the same time you do not want to own and maintain many physical machines all the time.

The following diagram demonstrates how you can place a simple 3-tier application in Windows Azure by placing each application tier in a different virtual machine.

3-tier application pattern

In this application pattern, there is only one virtual machine (VM) in each tier. If you have multiple VMs in Windows Azure, we recommend that you set up a virtual network. Windows Azure Virtual Network creates a trusted security boundary and also allows VMs to communicate among themselves over the private IP address. In addition, always make sure that all Internet connections only go to the presentation tier. This means that you should open up a public endpoint on the presentation tier but not on the other tiers. When following this application pattern, you also need to set up the network access control list (ACL) on that public port to allow for access certain IP addresses. For more information, see About Network Access Control Lists.

In the diagram, Internet Protocols can be TCP, UDP, HTTP, or HTTPS.

Important: Setting up a virtual network in Windows Azure is free of charge. However, you are charged for the VPN gateway that connects to on-premises. This charge is based on the amount of time that connection is provisioned and available.

2-tier and 3-tier application pattern with presentation tier scale-out

In this application pattern, you deploy 2-tier or 3-tier database application to Windows Azure Virtual Machines by placing each application tier in a different virtual machine. In addition, you scale out the presentation tier due to increased volume of incoming client requests.

This application pattern is useful when:

  • You want to move enterprise applications from on-premises virtualized platforms to Windows Azure Virtual Machines.

  • You want to scale out the presentation tier due to increased volume of incoming client requests.

  • You want to quickly provision development and test environments for short periods of time.

  • You want to perform stress testing for varying workload levels but at the same time you do not want to own and maintain many physical machines all the time.

  • You want to own an infrastructure environment that can scale up and down on demand.

The following diagram demonstrates how you can place the application tiers in multiple virtual machines in Windows Azure by scaling out the presentation tier due to increased volume of incoming client requests. As seen in the diagram, Windows Azure Load Balancer is responsible for distributing traffic across multiple virtual machines and also determining which web server to connect to. Having multiple instances of the web servers behind a load balancer ensures the high availability of the presentation tier. For more information, see Best practices for Best practices for 2-tier, 3-tier, or n-tier application patterns that have multiple virtual machines in one tier.

Application pattern - presentation tier scale out

Best practices for 2-tier, 3-tier, or n-tier application patterns that have multiple virtual machines in one tier

It’s recommended that you place the virtual machines that belong to the same tier in the same cloud service and in the same the availability set. For example, place a set of web servers in CloudService1 and AvailabilitySet1 and a set of database servers in CloudService2 and AvailabilitySet2. An availability set in Windows Azure enables you to place the high availability nodes into separate fault domains and upgrade domains. For more information, see Manage the Availability of Virtual Machines and How to Connect Virtual Machines in a Cloud Service.

To leverage multiple VM instances of a tier, you need to configure Windows Azure Load Balancer between application tiers. To configure Load Balancer in each tier, create a load-balanced endpoint on each tier’s VMs separately. For a specific tier, first create VMs in the same cloud service. This will make sure that they all have the same public Virtual IP address. Next, create an endpoint on one of the virtual machines on that tier. Then, assign the same endpoint to the other virtual machines on that tier for load balancing. By creating a load-balanced set, you distribute traffic across multiple virtual machines and also allow the Load Balancer to determine which node to connect when a backend VM node fails. For example, having multiple instances of the web servers behind a load balancer ensures the high availability of the presentation tier.

As a best practice, always make sure that all internet connections first go to the presentation tier. The presentation layer accesses the business tier, and then the business tier accesses the data tier. For example, open up an endpoint on the presentation tier. Each endpoint has a public port and a private port. The private port is used internally by the virtual machine to listen for traffic on that endpoint. The public port is the entry point for communication from outside of Windows Azure and is used by the Windows Azure Load Balancer. It is recommended to set up the network access control list (ACL) to define rules that help isolate and control the incoming traffic on any public port on any public endpoint on any application tier. For more information, see About Network Access Control Lists.

Note that the Load Balancer in Windows Azure works similar to load balancers in an on-premises environment. For more information, see Load Balancing Virtual Machines.

In addition, we recommend that you set up a private network for your virtual machines by using Windows Azure Virtual Network. This allows them to communicate among themselves over the private IP address. For more information, see Windows Azure Virtual Network.

2-tier and 3-tier application pattern with business tier scale-out

In this application pattern, you deploy 2-tier or 3-tier database application to Windows Azure Virtual Machines by placing each application tier in a different virtual machine. In addition, you might want to distribute the application server components to multiple virtual machines due to the complexity of your application.

This application pattern is useful when:

  • You want to move enterprise applications from on-premises virtualized platforms to Windows Azure Virtual Machines.

  • You want to distribute the application server components to multiple virtual machines due to the complexity of your application.

  • You want to move business logic heavy on-premises LOB (line-of-business) applications to Windows Azure Virtual Machines. LOB applications are a set of critical computer applications that are vital to running an enterprise, such as accounting, human resources (HR), payroll, supply chain management, and resource planning applications.

  • You want to quickly provision development and test environments for short periods of time.

  • You want to perform stress testing for varying workload levels but at the same time you do not want to own and maintain many physical machines all the time.

  • You want to own an infrastructure environment that can scale up and down on demand.

The following diagram demonstrates an on-premises scenario and its cloud enabled solution. In this scenario, you place the application tiers in multiple virtual machines in Windows Azure by scaling out the business tier, which contains the business logic tier and data access components. As seen in the diagram, Windows Azure Load Balancer is responsible for distributing traffic across multiple virtual machines and also determining which web server to connect to. Having multiple instances of the application servers behind a load balancer ensures the high availability of the business tier. For more information, see Best practices for 2-tier, 3-tier, or n-tier application patterns that have multiple virtual machines in one tier.

Application pattern with business tier scale out

2-tier and 3-tier application pattern with presentation and business tiers scale-out and high availability for SQL Server

In this application pattern, you deploy 2-tier or 3-tier database application to Windows Azure Virtual Machines by distributing the presentation tier (web server) and the business tier (application server) components to multiple virtual machines. In addition, you implement high-availability and disaster recovery solutions for your databases in Windows Azure virtual machines.

This application pattern is useful when:

  • You want to move enterprise applications from virtualized platforms on-premises to Windows Azure by implementing SQL Server high availability and disaster recovery capabilities.

  • You want to scale out the presentation tier and the business tier due to increased volume of incoming client requests and the complexity of your application.

  • You want to quickly provision development and test environments for short periods of time.

  • You want to perform stress testing for varying workload levels but at the same time you do not want to own and maintain many physical machines all the time.

  • You want to own an infrastructure environment that can scale up and down on demand.

The following diagram demonstrates an on-premises scenario and its cloud enabled solution. In this scenario, you scale out the presentation tier and the business tier components in multiple virtual machines in Windows Azure. In addition, you implement high availability and disaster recovery (HADR) techniques for SQL Server databases in Windows Azure.

Running multiple copies of an application in different VMs make sure that you are load balancing requests across them. When you have multiple virtual machines, you need to make sure that all your VMs are accessible and running at one point in time. If you configure load balancing, Windows Azure Load Balancer track the health of VMs and directs incoming calls to the healthy functioning VM nodes properly. For information on how to set up load balancing of the virtual machines, see Load Balancing Virtual Machines. Having multiple instances of web and application servers behind a load balancer ensures the high availability of the presentation and business tiers. For more information, see Best practices for application patterns that require SQL Server high availability and disaster recovery solutions.

Scale out and high availability

Best practices for application patterns that require SQL Server high availability and disaster recovery solutions

When you set up SQL Server high availability and disaster recovery solutions in Windows Azure Virtual Machines, setting up a virtual network for your virtual machines using Windows Azure Virtual Network is mandatory. Virtual machines within a Virtual Network will have a stable private IP address even after a service downtime, thus you can avoid the update time required for DNS name resolution. In addition, the virtual network allows you to extend your on-premises network to Windows Azure and creates a trusted security boundary. For example, if your application has corporate domain restrictions (such as, Windows authentication, Active Directory), setting up Windows Azure Virtual Network is necessary.

Most of customers, who are running production code on Windows Azure, are keeping both primary and secondary replicas in Windows Azure.

For comprehensive information and tutorials on high availability and disaster recovery techniques, see High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines.

2-tier and 3-tier application pattern using Windows Azure Virtual Machines and Windows Azure Cloud Services (web and worker roles)

In this application pattern, you deploy 2-tier or 3-tier application to Windows Azure by using both Windows Azure Cloud Services (web and worker roles - Platform as a Service (PaaS)) and Windows Azure Virtual Machines (Infrastructure as a Service (IaaS)). Using Windows Azure Cloud Services for the presentation tier/business tier and SQL Server in Windows Azure Virtual Machines for the data tier is beneficial for most applications running on Windows Azure. The reason is that having a compute instance running on Cloud Services provides an easy management, deployment, monitoring, and scale-out.

With Cloud Services, Windows Azure maintains the infrastructure for you, performs routine maintenance, patches the operating systems, and attempts to recover from service and hardware failures. When your application needs scale-out, automatic, and manual scale out options are available for your cloud service project by increasing or decreasing the number of instances or virtual machines that are used by your application. In addition, you can use on-premises Visual Studio to deploy your application to a cloud service project in Windows Azure.

In summary, if you don’t want to own extensive administrative tasks for the presentation/business tier and your application does not require any complex configuration of software or the operating system, use Windows Azure Cloud Services. If Windows Azure SQL Database does not support all the features you are looking for, use SQL Server in a Windows Azure Virtual Machine for the data tier. Running an application on Windows Azure Cloud Services and storing data in Windows Azure Virtual Machines combines the benefits of both services. For a detailed comparison, see Development Strategies in Windows Azure: Comparison of Traditional Web Development vs. Windows Azure Cloud Services and Web Sites.

In this application pattern, the presentation tier includes a web role, which is a Cloud Services component running in the Windows Azure execution environment and it is customized for web application programming as supported by IIS and ASP.NET. The business or backend tier includes a worker role, which is a Cloud Services component running in the Windows Azure execution environment and it is useful for generalized development, and may perform background processing for a web role. The database tier resides in a SQL Server virtual machine in Windows Azure. The communication between the presentation tier and the database tier happens directly or over the business tier – worker role components.

This application pattern is useful when:

  • You want to move enterprise applications from virtualized platforms on-premises to Windows Azure by implementing SQL Server high availability and disaster recovery capabilities.

  • You want to own an infrastructure environment that can scale up and down on demand.

  • Windows Azure SQL Database does not support all the features that your application or database needs.

  • You want to perform stress testing for varying workload levels but at the same time you do not want to own and maintain many physical machines all the time.

The following diagram demonstrates an on-premises scenario and its cloud enabled solution. In this scenario, you place the presentation tier in web roles, the business tier in worker roles but the data tier in virtual machines in Windows Azure. Running multiple copies of the presentation tier in different web roles ensures to load balance requests across them. When you combine Windows Azure Cloud Services with Windows Azure Virtual Machines, we recommend that you set up up Windows Azure Virtual Network as well. With Windows Azure Virtual Network, you can have stable and persistent private IP addresses within the same cloud service in the cloud. Once you define a virtual network for your virtual machines and cloud services, they can start communicating among themselves over the private IP address. In addition, having virtual machines and Windows Azure web/worker roles in the same Windows Azure Virtual Network provides low latency and more secure connectivity. For more information, see What is a cloud service, Windows Azure Execution Models and Windows Azure Virtual Network.

As seen in the diagram, Windows Azure Load Balancer distributes traffic across multiple virtual machines and also determines which web server or application server to connect to. Having multiple instances of the web and application servers behind a load balancer ensures the high availability of the presentation tier and the business tier. For more information, see Best practices for application patterns that require SQL Server high availability and disaster recovery solutions.

Application patterns with Cloud Services

Another approach to implement this application pattern is to use a consolidated web role that contains both presentation tier and business tier components as shown in the following diagram. This application pattern is useful for applications that require stateful design. Since Windows Azure provides stateless compute nodes on web and worker roles, we recommend that you implement a logic to store session state using one of the following technologies: Windows Azure Caching, Windows Azure Table Storage or Windows Azure SQL Database.

Application patterns with Cloud Services

Mixed application pattern with Windows Azure Virtual Machines, Windows Azure SQL Database, and Windows Azure Web Sites

The primary goal of this application pattern is to show you how to combine Windows Azure infrastructure as a service (IaaS) components with Windows Azure platform-as-a-service components (PaaS) in your solution. This pattern is focused on Windows Azure SQL Database for relational data storage. It does not include SQL Server in a Windows Azure virtual machine, which is part of the Windows Azure infrastructure as a service offering.

In this application pattern, you deploy a database application to Windows Azure by placing the presentation and business tiers in the same virtual machine and accessing a database in Windows Azure SQL Database (SQL Database) servers. You can implement the presentation tier by using traditional IIS-based web solutions. Or, you can implement a combined presentation and business tier by using Windows Azure Web Sites.

This application pattern is useful when:

  • You already have an existing SQL Database server configured in Windows Azure and you want to test your application quickly.

  • You want to test the capabilities of Windows Azure environment.

  • You want to quickly provision development and test environments for short periods of time.

  • Your business logic and data access components can be self-contained within a web application.

The following diagram demonstrates an on-premises scenario and its cloud enabled solution. In this scenario, you place the application tiers in a single virtual machine in Windows Azure and access data in Windows Azure SQL Database.

Mixed application pattern

If you choose to implement a combined web and application tier by using Windows Azure Web Sites, we recommend that you keep the middle-tier or application tier as dynamic-link libraries (DLLs) in the context of a web application.

In addition, review the recommendations given in the Development Strategies in Windows Azure: Comparison of Traditional Web Development vs. Windows Azure Cloud Services and Web Sites section at the end of this article to learn more about programming techniques.

N-tier hybrid application pattern

In n-tier hybrid application pattern, you implement your application in multiple tiers distributed between on-premises and Windows Azure. Therefore, you create a flexible and reusable hybrid system, which you can modify or add a specific tier without changing the other tiers. To extend your corporate network to the cloud, you use Windows Azure Virtual Network service.

This hybrid application pattern is useful when:

  • You want to build applications that run partly in the cloud and partly on-premises.

  • You want to migrate some or all elements of an existing on-premises application to the cloud.

  • You want to move enterprise applications from on-premises virtualized platforms to Windows Azure.

  • You want to own an infrastructure environment that can scale up and down on demand.

  • You want to quickly provision development and test environments for short periods of time.

  • You want a cost effective way to take backups for enterprise database applications.

The following diagram demonstrates an n-tier hybrid application pattern that spans across on-premises and Windows Azure. As shown in the diagram, on-premises infrastructure includes Active Directory Domain Services domain controller to support user authentication and authorization. Note that the diagram demonstrates a scenario, where some parts of the data tier live in an on-premises data center whereas some parts of the data tier live in Windows Azure. Depending on your application’s needs, you can implement several other hybrid scenarios. For example, you might keep the presentation tier and the business tier in an on-premises environment but the data tier in Windows Azure.

Having trouble viewing this topic in the Windows Azure library? Try viewing it in the MSDN library.

N-tier application pattern

In Windows Azure, you can use Active Directory as a standalone cloud directory for your organization, or you can also integrate existing on-premises Active Directory with Windows Azure Active Directory. As seen in the diagram, the business tier components can access to multiple data sources, such as to SQL Server in Windows Azure via a private internal IP address, to on-premises SQL Server via Virtual Network, or to SQL Database using the .NET Framework data provider technologies. In this diagram, Windows Azure SQL Database (SQL Database) is an optional data storage service.

In n-tier hybrid application pattern, you can implement the following workflow in the order specified:

  1. Identify enterprise database applications that need to be moved up to cloud by using the Microsoft Assessment and Planning (MAP) Toolkit. The MAP Toolkit gathers inventory and performance data from computers you are considering for virtualization and provides recommendations on capacity and assessment planning.

  2. Plan the resources and configuration needed in the Windows Azure platform, such as storage accounts and virtual machines. For a detailed migration plan, see Getting Ready to Migrate to SQL Server in Windows Azure Virtual Machines.

  3. Set up network connectivity between the corporate network on-premises and Windows Azure Virtual Network. To set up the connection between the corporate network on-premises and a virtual machine in Windows Azure, use one of the following two methods:

    1. Establish a connection between on-premises and Windows Azure via public end points on a virtual machine in Windows Azure. This method provides an easy setup and enables you to use SQL Server authentication in your virtual machine. In addition, set up the network access control list (ACL) on the public ports to allow for access certain IP addresses. For more information, see About Network Access Control Lists

    2. Establish a connection between on-premises and Windows Azure via Windows Azure Virtual Private network (VPN) tunnel. This method allows you to extend domain policies to a virtual machine in Windows Azure. In addition, you can set up firewall rules and use Windows authentication in your virtual machine. Currently, Windows Azure supports secure site-to-site VPN and point-to-site VPN connections:

      • With secure site-to-site connection, you can establish network connectivity between your on-premises network and your virtual network in Windows Azure. It is recommended for connecting your on-premises data center environment to Windows Azure.

      • With secure point-to-site connection, you can establish network connectivity between your virtual network in Windows Azure and your individual computers running anywhere. It is mostly recommended for development and test purposes.

      For information on how to connect to SQL Server in Windows Azure, see Connectivity Considerations for SQL Server in Windows Azure Virtual Machines.

  4. Set up scheduled jobs and alerts that would backup on-premises data in a virtual machine disk in Windows Azure. For more information, see SQL Server Backup and Restore with Windows Azure Blob Storage Service and Backup and Restore for SQL Server in Windows Azure Virtual Machines.

  5. Depending on your application’s needs, you can implement one of the following three common scenarios:

    1. You can keep your web server, application server, and insensitive data in a database server in Windows Azure whereas you keep the sensitive data on-premises.

    2. You can keep your web server and application server on-premises whereas the database server in a virtual machine in Windows Azure.

    3. You can keep your database server, web server, and application server on-premises whereas you keep the database replicas in virtual machines in Windows Azure. This setting allows the on-premises web servers or reporting applications to access the database replicas in Windows Azure. Therefore, you can achieve to lower the workload in an on-premises database. We recommend that you implement this scenario for heavy read workloads and developmental purposes. For information on creating database replicas in Windows Azure, see AlwaysOn Availability Groups at High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines.

Development Strategies in Windows Azure: Comparison of Traditional Web Development vs. Windows Azure Cloud Services and Web Sites

To implement and deploy a multi-tier SQL Server based application in Windows Azure, you can use one of the following two programming methods:

  • Set up a traditional web server (IIS - Internet Information Services) in Windows Azure and access databases in SQL Server in Windows Azure Virtual Machines.

  • Implement and deploy a cloud service to Windows Azure. Then, make sure that this cloud service can access databases in SQL Server in Windows Azure Virtual machines. A cloud service can include multiple web and worker roles.

The following table provides a comparison of traditional web development with Windows Azure Cloud Services and Windows Azure Web Sites. The table includes Windows Azure Web Sites as this article includes some scenarios that include Windows Azure SQL Database. Currently, Windows Azure Web Sites can work with Windows Azure SQL Database only.

Having trouble viewing this topic in the Windows Azure library? Try viewing it in the MSDN library.

 

Traditional web development in Windows Azure Virtual Machines

Cloud Services in Windows Azure

Web Hosting with Windows Azure Web Sites

Application Migration from on-premises

  • Existing applications as-is.

  • Applications need web and worker roles.

  • Existing applications as-is but suited for self-contained web applications and web services that require quick scalability.

Development and Deployment

  • Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, IIS Manager, PowerShell.

  • Visual Studio, Windows Azure SDK, TFS, PowerShell. Each cloud service has two environments to which you can deploy your service package and configuration: staging and production. You can deploy a cloud service to the staging environment to test it before you promote it to production.

  • Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, Web Deploy, PowerShell.

Administration and Setup

  • You are responsible for administrative tasks on the application, data, firewall rules, virtual network, and operating system.

  • You are responsible for administrative tasks on the application, data, firewall rules, and virtual network.

  • You are responsible for administrative tasks on the application and data only.

High Availability and Disaster Recovery (HADR)

  • We recommend that you place virtual machines in the same availability set and in the same cloud service. Keeping your VMs in the same availability set allows Windows Azure to place the high availability nodes into separate fault domains and upgrade domains. Similarly, keeping your VMs in the same cloud service enables load balancing and VMs can communicate directly with one another over the local network within a Windows Azure data center.

  • You are responsible for implementing a high availability and disaster recovery solution for SQL Server in Windows Azure Virtual Machines to avoid any downtime. You are responsible for backing up your own data and application.

  • Windows Azure can move your virtual machines if the host machine in the data center fails due to hardware issues. In addition, there could be planned downtime of your VM when the host machine is updated for security or software updates. Therefore, we recommend that you maintain at least two VMs in each application tier to ensure the continuous availability. Windows Azure does not provide SLA for a single virtual machine. For more information, see Windows Azure Business Continuity Technical Guidance.

  • High Availability is inherited from Windows Azure worker roles, Windows Azure blob storage, and Windows Azure SQL Database. For example, Windows Azure Storage maintains three replicas of all blob, table, and queue data. At any one time, Windows Azure SQL Database keeps three replicas of data running—one primary replica and two secondary replicas. For more information, see Storage and SQL Database.

Cross-premise Connectivity

  • You can use Windows Azure Virtual Network to connect to on-premises.

  • You can use Windows Azure Virtual Network to connect to on-premises.

  • Windows Azure Virtual Network is not supported.

Scalability

  • Scale-up is available by increasing the virtual machine sizes or adding more disks. For more information about virtual machine sizes, see Virtual Machine and Cloud Service Sizes for Windows Azure.

  • For Database Server: Scale-out is available via database partitioning techniques and SQL Server AlwaysOn Availability groups.

    For heavy read workloads, you can use AlwaysOn Availability Groups on multiple secondary nodes as well as SQL Server Replication.

    For heavy write workloads, you can implement horizontal partitioning data across multiple physical servers to provide application scale-out.

    In addition, you can implement a scale out by using SQL Server with Data Dependent Routing. With Data Dependent Routing (DDR), you need to implement the partitioning mechanism in the client application, typically in the business tier layer, to route the database requests to multiple SQL Server nodes. The business tier contains mappings to how the data is partitioned and which node contains the data.

    You can scale applications that are running virtual machines. For more information, see How to Scale an Application.

  • Scale-up is available by using multiple web and worker roles. For more information about virtual machine sizes for web roles and worker roles, see Configure Sizes for Cloud Services.

  • When using Cloud Services, you can define multiple roles to distribute processing and also achieve flexible scaling of your application. Each cloud service includes one or more web roles and/or worker roles, each with its own application files and configuration. You can scale-up a cloud service by increasing the number of role instances (virtual machines) deployed for a role and scale-down a cloud service by decreasing the number of role instances. For detailed information, see Windows Azure Execution Models.

  • Scale-out is available via built-in Windows Azure high availability support through Cloud Services, Virtual Machines, and Virtual Network Service Level Agreement and Load Balancer.

  • For a multi-tier application, we recommend that you connect web/worker roles application to database server VMs via Windows Azure Virtual Network. In addition, Windows Azure provides load balancing for VMs in the same cloud service, spreading user requests across them. Virtual machines connected in this way can communicate directly with one another over the local network within a Windows Azure data center.

  • You can set up AutoScale on the Management Portal as well as the schedule times. For more information, see How to Scale an Application.

  • Scale up and down: You can increase/decrease the size of the instance (VM) reserved for your web site.

  • Scale out: You can add more reserved instances (VMs) for your web site.

  • You can set up AutoScale on the Management Portal as well as the schedule times. For more information, see How to Scale Web Sites.

For more information on choosing between these programming methods, see Windows Azure Web Sites, Cloud Services, and VMs: When to use which?.

Additional Resources

See Also

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.