During the last year, Azure SQLDB team made a great job in porting an amazing number of new features into the platform, thus reducing the surface area gap with box product version of SQL Server. Today, deciding between IaaS and PaaS for SQL Server solution is pretty easy since fewer aspects need to be considered and Azure SQLDB is constantly evolving toward feature parity. In this blog post I’m trying to summarize the main criteria to consider and related recommendations, based on your requirements and scenarios. To facilitate your reading, I inserted a comparison chart here at the beginning, then you will need to read through the post only if more details will be required.
As always, you can follow me also on Twitter (@igorpag), please let me know if you have some more comparison items you would like to see in this blog post. Regards.
Topic | Azure | SQL |
Features | Less features than box | Full box product features |
Performances | Max 1750 DTU in Premium Tier | Depends on VM SKU/Storage |
DB Size | Max 1TB in Premium Tier (P11) | 64TB on G-SERIES |
Workload | Sizing by average usage | Sizing based on peaks |
High-Availability | Built-in by platform | Manual configuration by AlwaysOn AG |
Fault-Handling | Necessary fault-handling & | Recommended fault-handling & |
Locality | No co-location with application | Co-located by VMs and VNETs |
Segregation | Internet exposed endpoint | Internal private endpoint |
Versioning | No control on upgrades | Full control over DB upgrade |
TCO | Very low, almost self-managed | High (as on-premise) |
Administration | No full-time DBA required | Full staffed DBA required |
Management | Easy to manage many DBs | Complex to manage many DBs/VMs |
Scale-Out | Tools & Frameworks available | No easy scale-out |
Configuration | No setup customization | Full access to OS and SQL |
Authentication | Only SQL standard authentication | SQL standard and integrated |
Security | No Fixed IP available | Fixed IP possible at VM level |
Backup | Backup files not accessible | Full control of backup files |
FEATURES: Is Azure SQLDB able to provide all the features you need?
Most but not all SQL Server 2014 Transact-SQL statements are fully supported in Microsoft Azure SQL Database. Additionally, not all the features and tools that exist today for SQL Server box product are fully (or partially supported. For example, if your application requires MSDTC or SQL Agent or SSIS, then SQL Server in Azure VM is the only possible choice. For a comprehensive list of supported TSQL statements, features and tools, see the links below:
https://azure.microsoft.com/en-us/documentation/articles/sql-database-general-limitations
https://azure.microsoft.com/en-us/documentation/articles/sql-database-transact-sql-information
PERFORMANCE: Which is the transaction throughput required by your application?
Moving a database to the Cloud, does not matter if using PaaS or IaaS, requires careful planning and workload characteristics knowledge to avoid problems. Azure SQLDB provides several levels of Service Level Objectives (SLO), each one with its own assigned resources:
SQL Database options and performance: Understand what's available in each service tier
https://azure.microsoft.com/en-us/documentation/articles/sql-database-service-tiers
If the highest Premium Edition will not be able to satisfy application throughput requirements, SQL Server in Azure VM should be evaluated. Azure provides different sizes and hardware resources for Virtual Machines, then also in this case upper limits should be evaluated to ensure resource requirements will be satisfied:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs
Currently, the maximum database size that you can have in Azure SQLDB is 1TB (Premium P11 SKU). If you require more than that, SQL Server in Azure VM should be evaluated: on G-SERIES SKU you can allocate up to 64TB total disk space (Standard_G5). Extreme caution should be used here: allocating a big database, even if possible from a size perspective, may be not feasible from a performance and transaction throughput perspective, then appropriate tests should be done to ensure CPU, memory and disks will be good enough.
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-performance-best-practices
If you chose to install SQL Server in Azure VM, you will need probably to size it for peak workload: if your application workload presents frequent peaks and steady usage at different time, you may be forced to overcommit resource allocation in term of number of cores (then memory) and storage. VM SKU and size changes in Azure Virtual Machines are possible, but there are some limitations and it is essentially an offline operation. Vice-versa, Azure SQLDB provides a very efficient built-in mechanism to dynamically change SKU, then allocated resources, very quickly and completely on-line with no application downtime. If your workload is dynamic and un-predictable by nature, Azure SQLDB is the best solution.
Changing Database Service Tiers and Performance Levels
https://msdn.microsoft.com/en-us/library/azure/dn369872.aspx
If the highest Premium Edition will not be able to satisfy application throughput requirements, SQL Server in Azure VM should be evaluated. Azure provides different sizes and hardware resources for Virtual Machines, then also in this case upper limits should be evaluated to ensure resource requirements will be satisfied:
Sizes for Virtual Machines
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-size-specs
Azure SQLDB, in its V12 versions, is able to provide 99,99% high-availability SLA. Using SQL Server in Azure VM will require provisioning of at least two virtual machines in the same availability set and additional configuration of AlwaysOn Availability Group feature: this configuration will be able to provide only 99,95% HA SLA.
General Availability: Azure SQL Database Basic, Standard, and Premium service tiers
http://azure.microsoft.com/en-us/updates/general-availability-sql-database-basic-standard-and-premium-service-tiers
Including proper retry logic and transient fault handling remediation in the code should be a universal best practice, both on-premised and in the cloud, either IaaS or PaaS. If this characteristic is missing, application problems may raise on both Azure SQLDB and SQL Server in Azure VM, but in this scenario the latter is recommended over the former.
The Transient Fault Handling Application Block
https://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx
If network latency between application and database is critical for the performance, SQL Server in Azure VM should be used: deploying both components in the same Virtual Network and same datacenter will guarantee minimum latency. Additionally, in some extreme situations, it is also possible to install the application on the same SQL Server VM. Azure SQLDB may require additional network hops and proximity is not guaranteed.
Azure Network Latency & SQL Server Optimization
http://blogs.msdn.com/b/igorpag/archive/2013/12/15/azure-network-latency-test-and-sql-server-optimization.aspx
Azure SQL Database Firewall
https://msdn.microsoft.com/en-us/library/azure/ee621782.aspx
http://blogs.msdn.com/b/igorpag/archive/2014/12/22/sql-2014-high-availability-and-multi-datacenter-disaster-recovery-with-multiple-azure-ilbs.aspx
Azure SQLDB is Microsoft PaaS offering for SQL Server technology, this means that Microsoft takes care of updating and patching of underlying database infrastructure. Azure SQLDB is always and constantly evolving, but you don’t have to schedule service maintenance activities. While Microsoft puts any reasonable commercial effort to guarantee that no breaking changes will be introduced, certification and management requirements may prohibit adoption to a small percentage of customers: if this is the case, and you need full control over SQL Server versioning and updating, you need to use SQL Server in Azure VM approach. Even if you don’t have control over Azure SQLDB versions, you can change the compatibility level of your database and be sure Azure SQLDB will adhere to that specifications:
ALTER DATABASE Compatibility Level (Transact-SQL)
https://msdn.microsoft.com/en-us/library/bb510680.aspx
https://azure.microsoft.com/it-it/updates/compatibility-level-130-for-azure-sql-database-v12
If one of these options will satisfy all your requirements, which one you should use? Determining precise cost of Azure SQLDB and SQL Server in Azure VM is not difficult, proper pricing tooling and web pages exist, obviously you will chose the least expensive. What is more difficult is how to make an equal cost comparison between PaaS and IaaS offering, that’s why you should read the article below before making any maths on cost comparison:
Azure SQLDB and SQL Server VM - How to make an equal cost comparison
http://blogs.msdn.com/b/igorpag/archive/2015/03/20/azure-sqldb-and-sql-server-vm-how-to-make-an-equal-cost-comparison.aspx
SQL Database offers the scale and functionality of an enterprise data center without the administrative overhead that is associated with on-premise or Virtual Machine instances of SQL Server. This self-managing capability will greatly reduce DBA requirements removing the overhead on managing, monitoring and maintaining database infrastructure. SQL Database also manages load balancing and, in case of a server failure, transparent fail-over to a healthy machine hosting one of the backup copies of your database with no human intervention. If you don’t have a DBA, Azure SQLDB should be the preferred choice.
If your application architecture and requirements ask for a non-trivial number of databases to manage, you should definitely look at Azure SQLDB PaaS option. SQL Server declined in its IaaS form, will still require DBA, additionally if you have many databases to manage, even with support of tooling and automation, this will require more IT resources. Additionally, Azure SQLDB recently introduced new technologies and capabilities to manage a large number of database at scale:
https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-jobs-overview
SQL Server in Azure VM provide limited scale-up capabilities, essentially dictated by Azure VM SKU and sizes available. Additionally, if your application adopts a tenancy model based on database-level tenant isolation, you may need to create a large number of databases. In addition to administrative problems, application architectural changes must be also considered. If you want to dynamically scale out your database set and at the same time provide minimal impact on your code, you should evaluate Azure SQLDB option and some recent new features introduced "Elastic Database Client library", "Elastic Database Jobs" and "Split-Merge tool".
Elastic Database features overview
https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-introduction
http://social.technet.microsoft.com/wiki/contents/articles/2693.windows-azure-sql-database-sql-authentication.aspx
https://azure.microsoft.com/en-us/documentation/articles/sql-database-aad-authentication
http://azure.microsoft.com/blog/2014/05/14/reserved-ip-addresses
https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity