First published on MSDN on Dec 03, 2018
Some customers already noticed that we are retiring Azure Service Manager REST APIs for Azure SQL Database on December 1, 2019 and may get confused about what this means. In case you haven't seen the notice yet, you can take a look at
https://azure.microsoft.com/en-us/updates/move-to-azure-resource-manager-rest-apis-for-azure-sql...
We have a
documentation page
that states some of the differences regarding Azure Resource Manager vs. classic deployment, it says that:
"The Resource Manager and classic deployment models represent two different ways of deploying and managing your Azure solutions. You work with them through two different API sets, and the deployed resources can contain important differences."
Along the page there isn't much clarity on where Azure SQL DB fits and some information there can induce customers into not so accurate assumptions. The goal of this blog post is to clear those questions.
- By classic deployment we mean Azure Service Manager (ASM).
- The previous portal (manage.windowsazure.com) was based on ASM, the current portal (portal.azure.com) is based on Azure Resource Manager (ARM).
- Both ASM and ARM have their own REST API endpoints and, as an example, we currently have a set PowerShell cmdlets that leverages the ASM REST API and another set for that leverages the ARM REST API.
- Azure SQL Database support both ASM and ARM. The engineering team did a great job, SQL DB customers didn't had to perform any operations to move or make their 'classic resources' (ASM) compatible with ARM. The fact is that both APIs work on top of the same resource.
To provide more clarity we can say that the backend SQL DB resources are in ARM already so there is no need to move the resource from classic to ARM. However, you will need to review all client-based code/APIs used to manage the resource to ensure it is using the ARM-based API. Client applications using SqlClient and other data access libraries that query the database are not impacted.
What should I change? How to check if this impact's me?
You will need to check the way you deploy or manage resources if you are not using the Portal or ARM templates.
You will need to check REST API/PowerShell/CLI scripts you may have on your workloads (like automation accounts, applications, etc.).
REST API
Calls to ASM endpoints like
https://
management.core.windows.net
/{subscriptionId}/services/sqlservers/servers/{serverName}/databases/{databaseName}
will no longer work after December 1, 2019.
Calls should be made through ARM endpoints
https://
management.azure.com
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/servers/{serverName}/databases/{databaseName}
Azure SQL Database REST API documentation can be found
here
.
PowerShell
To provide some clarity:
- ASM cmdlets are named like *-
Azure
* like Get-
Azure
SqlDatabase
- ARM cmdlets are named like *-
AzureRm
* like Get-
AzureRm
SqlDatabase
Calls using
Get-
Azure
SqlDatabase -ServerName $serverName -DatabaseName $databaseName
will no longer work after December 1, 2019.
Calls should be made through ARM cmdlets like
Get-
AzureRm
SqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName
Azure SQL Database Cmdlets (ARM) documentation can be found
here
.
CLI (command line interface )
Azure CLI 1.0 is deprecated and should only be used for managing Azure Service Management (ASM)–based ("classic") resources.
For ARM deployments use Azure CLI 2.0, you can check the latest version
here
.
Azure SQL Database CLI documentation can be found
here
.
Let us know if you have any question that was not addressed here already, we would like to clear that for you.
