While
migrating on-premise SQL Server to Azure SQL platform we have 3 options to
choose from Azure SQL family.
·
Azure
SQL Database.
·
Azure
SQL Managed Instance.
·
SQL
Server on Azure VMs.
Depending
on the requirement, each of these is best suited for different scenarios.
Azure SQL Database:
Azure
SQL Database option gives us a single database in the Azure cloud, which is similar
to a SQL Server database. It supports all the features of the SQL Server
database. With the Azure SQL Database option, we are responsible only to manage
and optimize the database, the server and instance are managed by MS. We will
get the latest stable version of SQL Server as Azure SQL Database. We can
process both relational and non-relational data with this database. It falls
under Platform as a Service (PaaS).
As we
can see this option is best suited when we don’t want the overhead of
maintaining and managing underlying instance and OS. Also at the same time,
this option is best suited when we want to use only database scoped features.
This option does not suit if we want to use instance level features like SQL
Server Agent and so on. We need to use alternatives like Elastic jobs in-place
of SQL Server jobs if we want to schedule any activities when we opt for Azure SQL Database.
Elastic
Pools:
Elastic
Pools is a collection of several Azure SQL Databases. This option is suited
when we have applications relying on multiple databases with unpredictable
usage demands. In short, when we have several databases with fluctuating loads instead of allocating resources to each single database and managing them we
can add all those databases under a single pool and allocate resources to the
entire pool. This helps hugely while managing the resources of all the
databases in the pool. All the databases within the pool will share the
resources of the pool and will use the resources whenever required. If we
notice there is a resource crunch on the overall pool itself, we can allocate
more resources to the pool as per the demand.
This
option mainly helps in avoiding over and under allocation of resources than
required along with providing all the Azure SQL Database advantages which in turn saves costs included.
Azure
SQL Managed Instance:
Azure
SQL Managed instance option is suited when we want to migrate our entire SQL
Server instance to the Azure cloud. As we know with Azure SQL Database we can
use all the database related features, with this managed instance option we can
use instance level features along with database-level features. This option
helps in doing a lift and shift migration to the cloud with minimal to no
changes to the applications. With this option, we will not have the
responsibility of managing and maintaining the underlying OS.
SQL
Server on Azure VMs:
This
option is suited when we want complete control of the environment like OS, SQL
instance, and the databases. We will have to manage and maintain the entire
infrastructure. We will be responsible for installing and configure SQL
instances and creating / managing required databases, SQL jobs, HA features,
and so on. With this option, we can lift and shift the applications and
databases with minimal to no changes to the existing on-premise environment.
These
features will give us flexibility in selecting and managing only the required features,
like if we don’t want to use SQL Server Agent jobs then we can choose Azure SQL
Database or if we don’t need to use linked server then we can use Azure SQL Database
or Elastic pools or if we don’t want to manage the underlying OS but want to
use SQL Server instance level features then we can choose SQL Manage instance
or if we want to complete control of SQL Server instance and the underlying OS
then we can choose SQL Server on Azure VMs and so on.
Depending on the requirements and budget, we can choose only required features which in turn helps in saving costs and will save the time of the support groups.
Below table outlines the comparison of all these options as of today:
Azure SQL Database vs Azure SQL Managed Instance vs SQL Server on Azure VMs
No comments:
Post a Comment