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

Introduction

1-tier application pattern: single virtual machine

3-tier simple application pattern: multiple virtual machines

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

2-tier and 3-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

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

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

N-tier hybrid application pattern

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

Additional Resources

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 Azure. For information, see SQL Server Books Online, SQL Server in 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 Azure, such as Azure Storage, Azure SQL Database, and SQL Server in an 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 Azure.

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

• You require a full compatibility with SQL Server on-premises and want to move existing applications to Azure as-is.
  
  
• You want to leverage the capabilities of Azure environment but 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 an 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 Azure. On the other hand, Azure SQL Database provides built-in resiliency to node-level failure in 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: At the time this article was updated, SQL Database supports a database of up to 500 GB of data. If your application requires more than 500 GB of data and you don’t want to implement custom sharding solutions, it’s recommended that you use SQL Server in an Azure Virtual Machine. For the latest information, see Scaling Out Azure SQL Databases and Azure SQL Database Service Tiers and Performance Levels.
    
    
  • HIPAA compliance: Healthcare customers and Independent Software Vendors (ISVs) might choose SQL Server in Azure Virtual Machines instead of Azure SQL Database because SQL Server in an Azure Virtual Machine is covered by HIPAA Business Associate Agreement (BAA). For information on compliance, see Azure Trust Center.
    
    
  • Functionality gaps: Some customers might choose SQL Server in Azure Virtual Machines instead of Azure SQL Database because of the functionality gaps in Azure SQL Database, such as data compression and flexibility in backup and restore. For more information, see Guidelines and Limitations (Azure SQL Database).
    
    

In this application pattern, you deploy your SQL Server application and database to a standalone virtual machine in 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 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 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 Azure.

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 Azure Virtual Machines: Getting Ready to Migrate to SQL Server in Azure Virtual Machines and Migrating to SQL Server in an Azure Virtual Machine. In addition, you can Use the 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 Azure Storage. Microsoft uploads the data in disk to 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.

In this application pattern, you deploy a 3-tier application in 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 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 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 Azure by placing each application tier in a different virtual machine.

In this application pattern, there is only one virtual machine (VM) in each tier. If you have multiple VMs in Azure, we recommend that you set up a virtual network. 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 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.

In this application pattern, you deploy 2-tier or 3-tier database application to 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 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 Azure by scaling out the presentation tier due to increased volume of incoming client requests. As seen in the diagram, 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.

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

In this application pattern, you deploy 2-tier or 3-tier database application to 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 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 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 Azure by scaling out the business tier, which contains the business logic tier and data access components. As seen in the diagram, 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.

In this application pattern, you deploy 2-tier or 3-tier database application to 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 Azure virtual machines.

This application pattern is useful when:

• You want to move enterprise applications from virtualized platforms on-premises to 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 Azure. In addition, you implement high availability and disaster recovery (HADR) techniques for SQL Server databases in 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, 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.

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

In this application pattern, you deploy 2-tier or 3-tier application to Azure by using both Azure Cloud Services (web and worker roles - Platform as a Service (PaaS)) and Azure Virtual Machines (Infrastructure as a Service (IaaS)). Using Azure Cloud Services for the presentation tier/business tier and SQL Server in Azure Virtual Machines for the data tier is beneficial for most applications running on 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, 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 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 Azure Cloud Services. If Azure SQL Database does not support all the features you are looking for, use SQL Server in an Azure Virtual Machine for the data tier. Running an application on Azure Cloud Services and storing data in Azure Virtual Machines combines the benefits of both services. For a detailed comparison, see Development Strategies in Azure: Comparison of Traditional Web Development vs. Azure Cloud Services and Azure Web Sites.

In this application pattern, the presentation tier includes a web role, which is a Cloud Services component running in the 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 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 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 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.
  
  
• 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 Azure. Running multiple copies of the presentation tier in different web roles ensures to load balance requests across them. When you combine Azure Cloud Services with Azure Virtual Machines, we recommend that you set up up Azure Virtual Network as well. With 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 Azure web/worker roles in the same Azure Virtual Network provides low latency and more secure connectivity. For more information, see What is a cloud service, Azure Execution Models and Azure Virtual Network.

As seen in the diagram, 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.

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 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: Azure Caching, Azure Table Storage or Azure SQL Database.

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

In this application pattern, you deploy a database application to Azure by placing the presentation and business tiers in the same virtual machine and accessing a database in 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 Azure Web Sites.

This application pattern is useful when:

• You already have an existing SQL Database server configured in Azure and you want to test your application quickly.
  
  
• You want to test the capabilities of 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 Azure and access data in Azure SQL Database.

If you choose to implement a combined web and application tier by using 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 Azure: Comparison of Traditional Web Development vs. Azure Cloud Services and Azure Web Sites section at the end of this article to learn more about programming techniques.

In n-tier hybrid application pattern, you implement your application in multiple tiers distributed between on-premises and 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 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 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 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 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 Azure.

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

In 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 Azure Active Directory. As seen in the diagram, the business tier components can access to multiple data sources, such as to SQL Server in 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, 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 Azure platform, such as storage accounts and virtual machines. For a detailed migration plan, see Getting Ready to Migrate to SQL Server in Azure Virtual Machines.
   
   
3. Set up network connectivity between the corporate network on-premises and Azure Virtual Network. To set up the connection between the corporate network on-premises and a virtual machine in Azure, use one of the following two methods:
   
   
   1. Establish a connection between on-premises and Azure via public end points on a virtual machine in 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 Azure via Azure Virtual Private network (VPN) tunnel. This method allows you to extend domain policies to a virtual machine in Azure. In addition, you can set up firewall rules and use Windows authentication in your virtual machine. Currently, 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 Azure. It is recommended for connecting your on-premises data center environment to Azure.
        
        
      • With secure point-to-site connection, you can establish network connectivity between your virtual network in 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 Azure, see Connectivity Considerations for SQL Server in Azure Virtual Machines.
      
      
4. Set up scheduled jobs and alerts that would backup on-premises data in a virtual machine disk in Azure. For more information, see SQL Server Backup and Restore with Azure Blob Storage Service and Backup and Restore for SQL Server in 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 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 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 Azure. This setting allows the on-premises web servers or reporting applications to access the database replicas in 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 Azure, see AlwaysOn Availability Groups at High Availability and Disaster Recovery for SQL Server in Azure Virtual Machines.
      
      

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

• Set up a traditional web server (IIS - Internet Information Services) in Azure and access databases in SQL Server in Azure Virtual Machines.
  
  
• Implement and deploy a cloud service to Azure. Then, make sure that this cloud service can access databases in SQL Server in Azure Virtual machines. A cloud service can include multiple web and worker roles.
  
  

The following table provides a comparison of traditional web development with Azure Cloud Services and Azure Web Sites with respect to SQL Server in Azure Virtual Machines. The table includes Azure Web Sites as it is possible to use SQL Server in Azure VM as a data source for Azure Web Sites via its public virtual IP address or DNS name.

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

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

Overview of Azure Virtual Machines

Azure SQL Database and SQL Server -- Performance and Scalability Compared and Contrasted

Cloud Design Patterns (for PAAS)

What’s an Enterprise Application

Enterprise Architecture

Service Level Agreements

Concepts