- Understanding Azure SQL Database and SQL Server in Azure VMs
- Azure SQL Database
- SQL Server in Azure Virtual Machines
- New or existing application/service: Migrating existing applications (“lift and shift”) typically requires a higher need to emulate on-premises application behavior than new applications which typically don’t have that need.
- Application/Service requirements: This decision point checks for any compatibility, networking or security requirements which might require SQL Server in a VM. See SQL Server in Windows Azure Virtual Machine vs. SQL Database for more details, and for a full list of feature compatibility differences between SQL DB and SQL/VM refer to the MSDN article Guidelines and Limitations (Windows Azure SQL Database).
- Database size: There are size limits by SQL Database editions, and the current maximum size of a single Azure SQL DB is 150 GB. For SQL/VM, the current maximum VM size is ExtraLarge (8 CPU cores, 14 GB RAM and up to 16 TB of disk space). See the MSDN article How to Configure Virtual Machine Sizes for more details on VM sizes.
- Willingness to (Re)architect/partition for economies of scale: This decision point checks for elasticity and scale-out requirements which can be met using SQL DB scale-out technologies such as Federations in Windows Azure SQL Database. Typically to fully take advantage of the economies of scale and elasticity features offered by SQL DB, a degree of re-architecture is required (see design considerations for scale out in SQL DB here).
Additional considerationsAs you progress beyond these high-level decision points you may have lower-level design criteria and sizing expectations which can impact the choice of database solution, for example a new application might have a specific feature requirement that is not available in SQL DB. The purpose of this decision tree is to provide an easy to use framework to quickly evaluate your application needs. An important consideration is the SLA provided by an IaaS vs. a PaaS database solution. For example in IaaS, Windows Azure has an SLA which covers all VM storage. When Windows Azure VM becomes generally available there will be a Windows Azure VM-level SLA of 99.95% availability for two or more instances in an availability set. In SQL DB there is a database level availability SLA. For more details refer to https://azure.microsoft.com/en-us/support/legal/sla/. Any operations not covered by an SLA become the customer’s responsibility. An application/service does not have to choose exclusively between IaaS or PaaS. Mixed mode application patterns which include both PaaS and IaaS services (for example, SQL DB and SQL/VM in Azure) represent a real and practical possibility for application development and deployment that allows applications to run components in VMs which require compatibility and control such as BI or applications migrated from on-premises, and also use databases in SQL DB to minimize DBA and database costs. Conclusion Both Windows Azure SQL DB and SQL Server running on Windows Azure virtual machines are valid approaches for satisfying distinct database application needs. In summary choose SQL/VM if:
- You require full compatibility with SQL Server on-premises.
- You want to make minimal changes to an existing application.
- You require infrastructure level Isolation.
- Your application/service is designed for “planned database scale” (AKA scale up).
- You are building a net new cloud based application.
- You want to reduce the cost of database management and focus on the application layer.
- You need database level isolation.
- Your app/service is designed for “unplanned & unbounded database scale” (elasticity via scale out).
Gregory Leake’s blog post on SQL Server in Windows Azure Virtual Machine vs. SQL Database: Guidelines and Limitations (Windows Azure SQL Database) SQL Server Virtualization support statement covering virtualized environments beyond Hyper-V: https://support.microsoft.com/kb/956893