I have previously written quite a few post about how much I like the Platform-as-a-Service databases for SQL Server (and for databases in general), and I do like them quite a bit. But would I recommend them for all use cases and workloads? Heck no! At the moment there are some features and limitations in Azure SQL PaaS databases that, with some of hte SQL Server workloads I have seen, wouldn’t just work all that well.
Also when we look at Azure, there’s some really cool features available for VMs that you can start using today, which are making the good old VMs an interesting option.
I just realized that it has been awhile since my last post, so I figured it’s time to do one before the end of the year. Last few months have been rather hectic with me migrating new workloads to Cloud as well as taking the time to visit PASS Summit 2019 to learn more about Microsoft Data Platform.
I also wanted to finish up my year of blogging by writing about a topic close to my heart, the evolution of the DBA role in the Cloud era. I did have a session about this topic in SQLSaturday Finland earlier this year and I will be doing a PASS Cloud Virtual Group presentation about it on January 16th.
In this post we’ll be looking at one of the Cloud technologies that have significant impact on the DBA role in the future, Platform-as-a-Service databases.
I’ve said it before and I say it again: Understanding how database backups and restores work is one of the more important topics for DBAs to understand. This time we’ll approach the topic from the cloud, and more precisely, from Azure perspective. Why cloud perspective you might as? For one simple reason. Even if you’re not (yet) running your SQL Server workloads in Azure, it doesn’t mean that you can’t make use of it for other purposes, such as backups. And while the idea of placing your data into Azure, or into any other cloud platform, might still seem scary to some, I want to help put your minds at ease. To do this, I’ll just point you to this fine piece of documentation describing the Azure infrastructure security. I think you’ll find it quite satisfying.
As there’s quite a few topics to cover with database backups to Azure, I have split the details into 4 separate posts. You’re now reading Part 1, the introduction.
In previous post, Part 1: Creating Azure Network and Storage, we set up your Azure account ready for two virtual machines that’ll be the backbone of your own testing environment. One of these servers will run the Active Directory and the other one will host your SQL Server 2012 instance. The Active Directory server is really optional, you can do a test environment without it but I prefer test environments that mimic the production.
Now that you’ve setup your Azure account we can get started on building the test environment. First thing you should do is to create a Virtual Azure Network, this will be used for connectivity between your servers. Creating a Network is quite straightforward business. Choose Networks and then Create A Virtual Network.
Going back a few years (and then some), creating your own test environments used to be difficult requiring both time and hardware resources. Then came the different virtualization solutions, which made it bit more easier but still requiring decent amount of hardware resources and a little bit of time. With the arrival of Azure and other cloud-based solutions, things finally got considerably easier. Now we finally had the ability to set up a test environments quickly and easily.