Application patterns and development strategies for SQL Server on Azure Virtual Machines

Applies to: SQL Server on Azure VM

Overview

Determining which application pattern or patterns to use for your SQL Server-based applications in an Azure environment is an important design decision and it requires a solid understanding of how SQL Server and each infrastructure component of Azure work together. With SQL Server in Azure Infrastructure Services, you can easily migrate, maintain, and monitor your existing SQL Server applications built on Windows Server to virtual machines (VMs) in 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 Azure as well as developing new applications in 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 Azure-specific development strategies so that you can design your applications correctly. Due to the many possible application patterns, it's recommended that architects and developers should choose the most appropriate pattern for their applications and users.

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

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:

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 on Azure Virtual Machines and Azure.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.

Choose SQL Server on Azure Virtual Machines, when:

• You need control on SQL Server and Windows. For example, this might include the SQL Server version, special hotfixes, performance configuration, etc.

• You need a full compatibility with SQL Server and want to move existing applications to Azure as-is.

• You want to leverage the capabilities of the Azure environment but Azure SQL Database does not support all the features that your application requires. This could include the following areas:

  • Database size: At the time this article was updated, SQL Database supports a database of up to 1 TB of data. If your application requires more than 1 TB 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 Database, DTU-Based Purchasing Model, and vCore-Based Purchasing Model(preview).
  • HIPAA compliance: Healthcare customers and Independent Software Vendors (ISVs) might choose SQL Server on Azure Virtual Machines instead of Azure SQL Database because SQL Server on Azure Virtual Machines is covered by HIPAA Business Associate Agreement (BAA). For information on compliance, see Microsoft Azure Trust Center: Compliance.
  • Instance-level features: At this time, SQL Database doesn't support features that live outside of the database (such as Linked Servers, Agent jobs, FileStream, Service Broker, etc.). For more information, see Azure SQL Database Guidelines and Limitations.

1-tier (simple): Single virtual machine

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 article on migration useful for moving your data to your SQL Server VM: Migration guide: SQL Server to SQL Server on Azure Virtual Machines.

3-tier (simple): Multiple virtual machines

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 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. When following this application pattern, manage the network security group rules to control access. For more information, see Allow external access to your VM using the Azure portal.

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

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

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.

Best practices for 2-tier, 3-tier, or n-tier patterns that have multiple VMs 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 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 Azure enables you to place the high availability nodes into separate fault domains and upgrade domains.

To leverage multiple VM instances of a tier, you need to configure 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 ensures that they 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 more information on how to allow access to the presentation layer, see Allow external access to your VM using the Azure portal.

Note that the Load Balancer in Azure works similar to load balancers in an on-premises environment. For more information, see Load balancing for Azure infrastructure services.

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

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

In this application pattern, you deploy a 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.

2-tier and 3-tier with presentation and business tiers scale-out and HADR

In this application pattern, you deploy a 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 (HADR) 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 tracks 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 for Azure infrastructure services. Having multiple instances of web and application servers behind a load balancer ensures the high availability of the presentation and business tiers.

Best practices for application patterns requiring SQL HADR

When you set up SQL Server high availability and disaster recovery solutions in Azure Virtual Machines, setting up a virtual network for your virtual machines using 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 Azure and creates a trusted security boundary. For example, if your application has corporate domain restrictions (such as, Windows authentication, Active Directory), setting up Azure Virtual Network is necessary.

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

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

2-tier and 3-tier using Azure Virtual Machines and Cloud Services

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 the section in this topic on Comparing development strategies in Azure.

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 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.

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 requiring SQL HADR.

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.

Pattern with Azure Virtual Machines, Azure SQL Database, and Azure App Service (Web Apps)

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 App Service.

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 Apps, 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 Comparing web development strategies in Azure 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 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.

In Azure, you can use Microsoft Entra ID (formerly Azure Active Directory) for identity and access management, or you can integrate an existing on-premises Active Directory with Microsoft Entra ID. As seen in the diagram, the business tier components can authenticate to multiple data sources, including: SQL Server on Azure VMs via a private internal IP address, on-premises SQL Server via Azure Virtual Network, or Azure SQL Database using the .NET Framework data provider technologies. In this diagram, Azure 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.

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 your network security group rules to control public traffic to the VM. For more information, see Allow external access to your VM using the Azure portal.

   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 Connect to a SQL Server virtual machine on Azure.

4. Set up scheduled jobs and alerts that back up on-premises data in a virtual machine disk in Azure. For more information, see SQL Server Backup and Restore with Azure Blob Storage and Backup and Restore for SQL Server on 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 Always On Availability Groups at High Availability and Disaster Recovery for SQL Server on Azure Virtual Machines.

Comparing web development strategies in Azure

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 on Azure Virtual Machines.
• Implement and deploy a cloud service to Azure. Then, make sure that this cloud service can access databases in SQL Server on 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 Apps with respect to SQL Server on Azure Virtual Machines. The table includes Azure Web Apps as it is possible to use SQL Server in an Azure VM as a data source for Azure Web Apps via its public virtual IP address or DNS name.

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

Next step

For more information on running SQL Server on Azure Virtual Machines, see SQL Server on Azure Virtual Machines Overview.