In this post I want to cover deploying SQL Server services in Azure with Visual Studio subscription. Because somebody made a comment on Twitter previously which got me thinking.
It was about the fact that they could not afford to run one of the SQL Server related services in Azure.
So, I thought it’d be a good idea to experiment with deploying various SQL Server related services using a standard Visual Studio Professional subscription. Because I wanted to see if it all worked OK.
To clarify, Visual Studio subscription is the new name for the old MSDN subscription. Which is something I suspect a fair few of you have if this quick Twitter survey below is anything to go by.
I decided to focus on some of the Azure related services, which I had discussed in a previous post here. I decided not to test virtual machine deployments and focused on PaaS offerings instead.
Furthermore, I decided not to focus on the pricing much. Because Microsoft explain it clearly for most offerings here.
Powershell module used to deploy SQL Services to Azure
In addition to using a standard Visual Studio Professional subscription, I decided to do all the deployments using the most recent Az module for Powershell.
To clarify, the Az module is the replacement for previous Powershell modules for Azure. Which I discussed in a previous post here.
Of course, I could have used Azure Resource Manager templates instead. However, I thought I would keep it simple with Powershell scripts.
Which in the end was easier to manage. Because at the end of the script I could delete the resource group ten minutes after the deployed items. You can read my previous review about ARM templates in detail here.
Below is an overview of how my testing went in order of complexity. Starting to the least complex to the most, which highlights things you should be aware of.
Azure SQL Database DTU model
Deploying a single Azure database using the Azure DTU model was certainly the easiest. I created the resource group, deployed the logical server and then finally the database.
I deployed the database using the New-AzSqldatabase cmdlet, which is part of the Az module. Furthermore, I deployed the S0 performance tier. So I had a decent amount of functionality without using too much Azure credit.
In addition, I was able to state that it was based on the AdventureWorksLT database and it still used the least number of parameters.
Azure SQL Database vCore model
Next, I deployed an Azure SQL database based on the vCore purchase model. Again, I created a resource group, deployed a logical server and used the New-AzSqlDatabase cmdlet.
However, this time I specified a few different parameters instead to reflect it was using the vCore purchase model.
Azure SQL Database Hyperscale
Afterwards, I decided to deploy a single Azure SQL Database using Hyperscale to see if I could on a standard Visual Studio Professional subscription.
Which I deployed easily using the same steps as previously with same cmdlets. Main difference being I specified ‘Hyperscale’ in the Edition parameter instead to reflect it was a Hyperscale database.
Azure SQL Datawarehouse
Now some of you might be expecting this to be really complicated to deploy in comparison. In addition, some of you might suspect there would be an issue deploying this on a Visual Studio Professional subscription.
However, you can also deploy this easily using the same steps as above with the same cmdlets. You just use a few different parameters instead in the New-AzSqlDatabase cmdlet.
Azure SQL Managed instance
To clarify, Azure SQL Managed Instance is the official name for Managed Instances. Something you can see in this overview here.
Because this installs an entire instance and not just a database you have to use the New-AzSqlInstance cmdlet, unlike the others above.
However, before you can use this cmdlet you have to use Powershell to deploy other things first to prepare for a managed instance. Which you can see for yourself in the official guide here.
With that in mind, I went ahead and attempted to create a managed instance only to find it did not work. After further investigation, I discovered that managed instances are not available on all subscriptions yet. Which you can see here.
However, all is not lost as there are workarounds for this. For instance, you use another subscription that is supported instead for immediate use.
Alternatively, you can raise a support request with Microsoft to see if they will add it to your existing subscription for you.
You can see for yourself if you are affected by this by attempting to create one using the Azure Portal. If indeed you are then I recommend you do either of the steps above.
Deploy SQL services in Azure summary
To summarize the experiment. You can install most of the SQL Server related services on your standard Visual Studio subscription.
However, you must use an alternative to work with managed instances at the moment. Which will hopefully soon be available on standard Visual Studio subscriptions by default.
SQL Server 2019
On a side note, the latest CTP for SQL Server 2019 (2.5) was announced during the checking of this post.
When I first published this post about deploying SQL Server services in Azure using Visual Studio subscription the latest CTP was not appear to be available for any virtual machines in Azure. However, since then SQL Server 2019 CTP 2.5 is now available for both Windows Server and Ubuntu 1604.
Of course, you can also get it in other ways here.
Final words about deploying SQL Server services in Azure
Well I hope todays post about deploying SQL Server services in Azure using Visual Studio subscription has been insightful for some of you. In addition, I hope it has given you some realistic expectations.
Of course, if anybody wishes to add to this feel free to add a comment.
[…] To explain the issue better, back in April I published a post about deploying certain SQL Services in Azure using a Visual Studio Subscription. You can read that post in detail here. […]