1. SQL Server Deployment Options in Azure and When to Use Them
Pio Balistoy
SQL Server Deployment Options in Azure and When to Use Them

2. GOLD
Silver
Bronze

3. Pio Balistoy
Lead Microsoft Data Platform Consultant, The Pythian Group
Co-Founder, Excent One Inc.
Administrator, Philippines SQL Server User Group
Core Organizer, SQL Pass Singapore Chapter |
/pio.balistoy
@pioisms
So before we begin, I would like to introduce myself. I’m Pio Balistoy. I’m a Lead Data Platform Consultant for Pythian. It’s a remote managed services provider based in North America. I’m a Microsoft Certified Solutions Expert for Data Management & Analytics. I used to work for Accenture and I co-founded with my ex-colleagues a little company in the Philippines, called Excent One. It’s a Sharepoint Integrator and custom .Net Business Applications solutions provider based in the Philippines and Singapore. I also help administer and organize the SQL Server User groups in Philippines and Singapore. Those are my contact details. If you have any questions about SQL you can reach out to me.

4. Agenda Deployment Options Available for SQL in Azure
Major Similarities and Differences between them
Choosing the Right Deployment Option for you
This sessions’ Agenda is to discuss the various deployment options we currently have for SQL Server. Talk about the similarities and differences between them. Then discuss different factors that can help you decide and choose the right SQL option for you. Just quick show of hands, who’s already using Azure SQL Database in their environment? How about Managed Instance? Ok that’s a good mix. So the session is both for those who haven’t used it and wants an overview on what’s out there. Also for those who have been using it already and wants a quick refresher on what’s new and out there.

5. Microsoft Azure Data Services
SQL Server in a VM
SQL Database
DocumentDB
Tables
Blobs
fully featured RDBMS
transactional processing
rich query
managed as a service
elastic scale
schema-free data model
Internet accessible http/rest
arbitrary data formats

6. Azure SQL Data Warehouse
Responsibility Zones
On-Premise
IAAS
PAAS/DBAAS
Azure VM
Managed Instance
Azure SQL Database
Azure SQL Data Warehouse
Database
Instance
Server-level features
Middle ware
Operating System
Servers
Physical Network
Physical Data Center
Here’s another way of looking at it. So Your on-prem data center, you are responsible for everything. From the security and upkeep of the physical location – cabling, setting up your Data center to the racking of servers. Administering your OS to the management of your database. All the responsibility falls on you. These requires a lot of Upfront costs or Capital Expeditures. Both for the physical resources and the time/skill resource for administering and managing it. Moving into the cloud you start to lower your responsibility by transferring it to your provider. So for IAAS, you are only responsible for managing everything from the OS and up. Everything from servers below, you already outsource that to the Cloud provider. Once you move to PAAS, you are only concerned about either the instance for Managed Instance or just the database itself for Azure SQL Database.

7. SQL Deployment Options in Azure
Azure SQL Database
SQL Server in
Azure VM
Single
Elastic Pool
Managed Instance
Serverless
Hyperscale
IAAS Model
Full SQL Server Instances running inside a Fully-managed Azure VM
So lets focus on what’s on Azure. There’s essentially two ways – Infrastructure as a service or Platform as a service. For IAAS, you can deploy a full SQL Server product in an Azure VM. This is exactly the same implementation you likely currently have on prem, just hosted on a VM in Azure. Honestly, most of the deployments or migration that you currently encounter in the field right now are like this. Simply because it’s the easiest path for migration. We call it “Lift & Shift” wherein you just lift whatever you have on prem and move it to the cloud. This is best for existing legacy applications that you cannot make a lot of changes to. Then we have on the left the Platform as a service options – Azure SQL Database and Azure SQL Data Warehouse. For Azure SQL Database there’s three deployment options, as a singleton database, or you can put multiple Azure SQL databases into an Elastic Pool, or if you require an Instance – Managed Instance. We’ll go into detail with them later on. These options are more for new applications and for certain existing applications that we can go into detail later on. And the latest addition to our option -Azure SQL Data Warehouse. We won’t go into detail on this one later since it is fairly obvious when you should be using it – its for Data Warehouse. If you have a huge data warehouse that requires massively parallel processing this will be your option. One thing to note about this, Azure SQL Data warehouse uses multiple nodes for processing, these nodes are different servers with their own CPU and memory so they can partition the query and process it in parallel to return huge query results faster. So it is only recommended for huge analytical loads. If your database is more than TB size and requires fast processing, this is for you. But if your Data warehouse is just under 1 TB, it may not be the way to go,
Best for existing and legacy apps
That requires fast migration with minimal or no changes.

8. Azure SQL Database
The Developer’s intelligent cloud database service

9. Azure SQL Database Protects and secures Learn and adapt with your app!
The Developer’s intelligent cloud database service
Learn and adapt with your app!
Scales on the fly without app downtime!
Build multitenant apps with customer isolation and efficiency!
Work within your environment
so you can focus on building great apps!
A relational database as a service, fully managed by Microsoft
For cloud-designed apps when near-zero administration and enterprise-grade capabilities are key
Perfect for cloud architects and developers looking for programmatic, DBA-like functionality
Elastic scale and performance
Predictable performance levels
Programmatic scale-out
Dashboard views of database metrics
Business continuity and data protection
Protects and secures
your app data!

10. Highlights Limitations Fully-managed Single Isolated Database
Always at the latest SQL Version
Elastic Scale & Performance
Built in backup and High Availability
Performance Monitoring and Tuning
Limitations
Let’s focus on the first one, Azure SQL Database is a fully managed Single Isolated database. Fully managed, your backups are manged by Azure, your high availability is built in. From the time you deploy your database, the SLA is already 99.99% availability. It will always have the latest features for SQL Server. Right now development for SQL Server is cloud first. This means any new development or features for security, performance, everything, it goes first to Azure SQL Database before it is even added to the next release of SQL Server product. All the new features right now for SQL Server, Always encrypted, Row-level security, and others, they were on Azure SQL Database first. So you are always assured that the latest features are available for you. Dynamic Scalability, you can scale up or scale down the resources for your database online. And these changes are seamless for your side. If you are hosting this on-prem, you’ll need to procure the additional resources ahead of time then you’ll need a downtime every time you need to add CPU or ram. For Azure SQL database it is just a few clicks. There is also a tool for automatic performance monitoring and tuning as well as threat detection.
The downside, since this is only a database – you don’t have access to any server/instance level objects or features. That means you don’t have SQL Server Jobs, linked servers, alerts, database mail, CLRs. All those server objects. You don’t have any access to it. Also right now, you can’t change the collation and the timezone. Also, since this is an isolated database, you cannot do cross database query even if the databases are in the same server. Any transaction is contained on the database you connected to. So if you require any of those, it may not be the right deployment option for you.
No access to Server/Instance level objects features
Cannot restore from on-prem backup

11. Elastic Pool A group of Azure SQL Databases
For sharing resources among Azure SQL DB
For grouping Azure SQL DB with different performance spike periods
Elastic jobs and Elastic Queries
Another deployment option for Azure SQL Database is putting it in an Elastic Pool. Now these is often misused/misunderstood. Elastic Pool is not a logical grouping of your database. Elastic Pool is primarily for sharing resources. What you do is you take databases that have different performance peak period. Group them together into one elastic pool so you can efficiently use the resources you are paying for. Say you have an oltp database that uses 100 DTUs during business hours but more or less idle during the night. And you have a BI or an Analytics database that does its heavy lifting during the night. You can group these two databases together in one elastic pool so they can share the resources you are already paying for instead of paying for two 100 DTU. An added benefit to elastic pool is you can have elastic jobs and elastic queries. These are jobs/queries that you want to run on databases inside your pool, say like an index maintenance job.
In has the same limitations as with the Azure SQL Database since it is still Azure SQL DB. It is more for sharing your resources to better use what your paying for.

12. Managed Instance Combining the best of SQL Server with the benefits
of a fully-managed, intelligent service

13. Like I said earlier. People has been moving their SQL Server to the cloud using lift & shift instead of going to Azure SQL Database. So Azure came out with Managed Instance. It has the closest compatibility with your on-prem sql server. You have a full instance so you have all those server level objects. You have your SQL Server agent, so you can migrate your jobs. You have linked servers, clr, Service broker. All those while still benefiting on the features available for Azure SQL DB – the High availability, fully managed backups, and all the latest SQL Server features.

14. Highlights Vnet Isolation or Public Endpoint
Access to Server/Instance Level features
Collation can be changed
Time zone can be changed
Azure Active Directory Login
SQL Server Agent
Allows cross-database queries (3 part name queries)
Restore backup from SQL Server
Allows SQL Backup (Copy Only)
Read Scale Replicas
For Managed Instance you have VNET Isolation. You know how your traditional deployment on prem. You usually put your database servers on a separate subnet isolated from your application and the internet. You can do that with Managed instance. ON the flipside, this was just released last month, you also have a public endpoint if you want it to be accessible for specific Azure services or through the internet. Like I mentioned earlier you have access to server level features – SQL jobs, DB Mails, Linked servers, CLR, service brokers. Collation and timezone can be changed unlike with Azure SQL Database, this one was also just added last month. You can use Azure AD logins. You can do cross-database queries. This one is big, especially for migrating your on prem to Managed instance – You can restore native sql backups from on-prem to Managed Instance. It also allows you to do copy only backups for your databases in managed instance. You can also create multipole read scale replicas. Similar to your AG read replicas for your read-only loads.

15. Limitations Physical path related commands are not available
SQL Agent is available but only TSQL jobs
Linked Servers to SQL Server and Azure SQL Databases only
No buffer pool extension
So for the limitation. Since you only have access to the SQL Server Instance and not the underlying server hosting it, any physical path related commands are not available. You can restore a database but you cannot use the with move option. Later with the demo I’ll show you why. You can use CLR but it needs to be in assembly format not a file. SQL Server agent jobs is available, but only for tsql jobs. You can use comandexec or powershell. Linked server is available but only for sql server and azure sql database targets, since you don’t have access to odbc or can install drivers. And no buffer pool extension, since you are only allow to use the memory you configured it for.

16. Portal Experience

17. SQL Database Serverless
The Best Price for Performance tier for your unpredictable workloads

18. Best for unpredictable and intermittent workloads on single databases
What is SQL Database Serverless?
Best for unpredictable and intermittent workloads on single databases

19. Optimize Price to Performance with per-second Billing
Serverless Compute Tier
Provisioned Compute Tier

20. Serverless Vs Provisioned
Capability
Serverless Compute
Provisioned Compute
Database Usage Patterns
Intermittent, unpredictable usage with lower average compute utilization over time.
More regular usage patterns with higher average compute utilization over time, or multiple databases using elastic pools
Performance Management Effort
Lower
Higher
Compute Scaling
Automatic
Manual
Compute Responsiveness
Lower after inactive periods
Immediate
Billing Granularity
Per second
Per hour

21. Serverless Vs Elastic Pool
Single Database
Intermittent& Unpredictable Workload
Can tolerate warm-up after idle period
Multiple Databases
Known fix peak periods
Cannot afford a delay in resources

22. SQL Database Hyperscale
Limitless Scale for Very Large Databases

23. What is Azure SQL Database Hyperscale?
8/3/2019 2:58 PM
What is Azure SQL Database Hyperscale?
SQL
Storage
Cloud native
Seamless compatibility
Scalable new storage architecture
Architected for cloud
Fully compatible with Azure SQL Database
Performance
No limits
Large database
VLDB operations without VLDB headaches
Scale compute and storage
Support for 100TB+
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

24. 1 2 3 n Compute Storage P S S S P S Log Service 128GB 128GB 128GB

25. Demo: Copying a 50TB database using point-in-time restore
8/3/2019 2:58 PM
Demo: Copying a 50TB database using point-in-time restore
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

27. Which one to use, IAAS or PAAS?

28. Azure SQL Managed Instance
Choosing the Right One
SQL Server in Azure VM
Azure SQL Managed Instance
Azure SQL Database
SQL Server Feature Parity
Fully Compatible
Partially Compatible – Any features that requires Access to OS/File System is not available
No Instance-level objects/features
Database Compatibility
Supported (Use DB Compatibility level)
Security
SQL Server Login and Azure AD
High Availability and Disaster Recovery
Configure and Manage your own
Built-in, SLA is by default 99.99% HA
Geo-Replication is also available
Built-in, SLA is by default 99.99% HA Geo-Replication is also available
Other SQL Server Services (SSAS, SSRS or SSIS)
No, use PAAS equivalent instead
No, No, use PAAS equivalent instead
Requires OS customisations/Admin rights No
Migration
Lift & Shift, Refactor, Rearchitect, or Rebuild
Lift & Shift, Refactor, Rearchitect, Rebuild, or Replace
Refactor, Rearchitect, Rebuild, or Replace
Size
Up to 64 TB - as many DB as needed
Up to 8 TB
Up to 100 DB per Managed Instance
Up to 4 TB
Up to 5000 DB per Server
Best For
Existing/Legacy Applications
New/existing applications
New cloud native applications
Complete list of feature comparison: Azure SQL Database versus SQL Server

29. Migrating your SQL Server stack
Azure SQL Database/MI
SQL Server
SSIS in Azure Data Factory (ADF)
SSIS
SSAS
SSRS
Power BI (PBI)
Azure Analysis Services (AAS)
Full compatibility lift & shift
Tabular
Replac e/uplo ad reports
Cloud
On-premises
…ADF connectors (80+)…
Extend
Modernize
SSISDB
AAS components
SSAS components
Power Query (PQ) Source
…More ISVs…

30. Azure SQL Database (Singleton/Elastic Pool)
Migration Strategies
SQL Server in Azure VM
Managed Instance
Azure SQL Database (Singleton/Elastic Pool)
Backup & Restore
Yes No
Dettach/Attach
Mirroring/Availability Groups
Log Shipping
Replication
DMA/DMS
Bulk Load

31. SQL Deployment Options in Azure
Azure SQL Database
SQL Server in
Azure VM
Single
Database-scoped
deployment option
with predictable
workload performance
Best for apps that require
resource guarantee
at database level
Elastic Pool
Shared resource model
optimized for greater
efficiency of multi-tenant
Applications
Best for SaaS apps
with multiple databases
that can share resources
at database level,
achieving better
cost efficiency
Serverless
Database-scoped deployment option with best the price for performance for unpredictable workload performance
Best for Development, Test, and for applications with unpredictable workloads and not sensitive to performance
Managed Instance
Instance-scoped
deployment option
with high compatibility
with SQL Server
and full PaaS benefits
Best for modernization
at scale with
low friction and effort
Hyperscale
Database-scoped
deployment option
With unlimited storage and performance scales.
Best for Very large databases more than 4 TB range.
IAAS Model
Full SQL Server Instances running inside a Fully-managed Azure VM
So lets focus on what’s on Azure. There’s essentially two ways – Infrastructure as a service or Platform as a service. For IAAS, you can deploy a full SQL Server product in an Azure VM. This is exactly the same implementation you likely currently have on prem, just hosted on a VM in Azure. Honestly, most of the deployments or migration that you currently encounter in the field right now are like this. Simply because it’s the easiest path for migration. We call it “Lift & Shift” wherein you just lift whatever you have on prem and move it to the cloud. This is best for existing legacy applications that you cannot make a lot of changes to. Then we have on the left the Platform as a service options – Azure SQL Database and Azure SQL Data Warehouse. For Azure SQL Database there’s three deployment options, as a singleton database, or you can put multiple Azure SQL databases into an Elastic Pool, or if you require an Instance – Managed Instance. We’ll go into detail with them later on. These options are more for new applications and for certain existing applications that we can go into detail later on. And the latest addition to our option -Azure SQL Data Warehouse. We won’t go into detail on this one later since it is fairly obvious when you should be using it – its for Data Warehouse. If you have a huge data warehouse that requires massively parallel processing this will be your option. One thing to note about this, Azure SQL Data warehouse uses multiple nodes for processing, these nodes are different servers with their own CPU and memory so they can partition the query and process it in parallel to return huge query results faster. So it is only recommended for huge analytical loads. If your database is more than TB size and requires fast processing, this is for you. But if your Data warehouse is just under 1 TB, it may not be the way to go,
Best for existing and legacy apps
That requires fast migration with minimal or no changes.

32. Questions? Thank you for attending SQLSaturday Sydney 2019!|
/in/piobalistoy/
/pio.balistoy
@pioisms
/groups/phissug
/groups/sqlugsg

33. Resources Document When to use it
Choosing the right SQL Server option in Azure
Microsoft Document Guide for choosing between available SQL Server Deployment Options
Azure SQL Database pricing page
Business model and pricing details
Azure Hybrid Use Benefit (AHUB)
Discount details for customers with SQL Server licenses
Feature comparison: Azure SQL Database versus SQL Server
High level feature availability matrix and need comparison with SQL Server and rest of SQL Database
Azure SQL Database Managed Instance T-SQL differences from SQL Server
Detailed functional behavior of SQL MI
Create Managed Instance - Tutorial
How to create SQL MI and connect to it (quick getting started guide)
How To: Configure a VNet for Azure SQL Database Managed Instance 
How to makes sure that VNet is compliant with SQL MI requirements
How To: Configure a Custom DNS for Azure SQL Database Managed Instance
Networking misconfiguration is currently the most frequent reason that prevents customers from deploying SQL MI successfully
Connect your application to Azure SQL Database
High level of detail how to connect app to MI (supported scenarios, high level steps, links on detailed how-to)
SQL Server instance migration to Azure SQL Database Managed Instance
Various options to migrate application to SQL MI
Subscription-level quotas and official process to obtain larger quota
Azure Support plans
Explore the range of Azure support options and choose the plan that best fits, whether you're a developer just starting your cloud journey or a large org. deploying business-critical, strategic applications
How to create Azure support request
Step by step instructions to open support ticket