So the decision to move to the cloud has been made but there is a fear from people that once it happens they will lose control of their job function. Does this sound familiar? DBA’s, you will be needed but expect some sort of change (That’s my opinion).

The way I think of it is that you are not really losing total control. Some individuals look at the move to the cloud as a “delegation of duties”, i.e. you no longer need to look after the physical hardware for something like Azure SQL Database.

This is very true, I have been using Azure technologies for a while now and I can’t remember the last time I had to carry out a patching exercise, because you don’t have to! Don’t forget I am specifically talking about Platform as a Service (PaaS) here. If you have many VMs with SQL Server installed in Azure, then it will feel very similar to your current virtualised estate.

There are different services available which naturally means less involvement for some, for example (SaaS) Software as a Service will have lower admin overhead when comparing it to Infrastructure as a Service (IaaS). This diagram sums it up well.

The Microsoft Data Platform Chart

Source: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-paas-vs-sql-server-iaas

The key for me has been to “embrace the change”. I have come from a traditional DBA background, backups, consistency checks, server level configuration at the heart of things. Yes, I no longer care about SQL backups and things of that nature when operating within Azure but I have different tasks and to think about.

Sceptical? Please read on.

Firstly, it’s down to me to initially create the database infrastructure in the cloud. Whether you use the Azure portal or PowerShell– it still needs to do done. Here are a couple of tasks you as a Database professional may be tasked with in the future.

Migration

Whether you decide to use BACPACs or Deployment Wizards to move data to Azure, most likely it will be you that will carry out these activities. What good will your application be without data? More complicated migration may include other data sources such as Oracle using specialist tools like SSIS, either way your input will be needed.

You will need to get to grips with how storage accounts and account keys work too.

Creating SQL Databases

You will be the one that has to create the SQL Servers and SQL Databases (obviously all the user access setup too). PowerShell is the way forward here, however if you are not comfortable with PowerShell then the Azure Portal works well for smaller deployments, but seriously, learn PowerShell.

All this stuff can then become automated very easily.

What else?

I am sure that there are more but other tasks that I have personally done include:

• Setting up Active geo-replication.
• Configuring server / database level firewalls
• Choosing your security options.
• Setting up users via AD.
• Working with Azure Automation Accounts.
• Index maintenance? Do you even care?
• Scaling up/down.
• Setting up Sync Groups.
• Recovering SQL databases.
• Setting up Azure Alerts for your databases.

Hybrid Scenarios

Maybe your company wants to setup transactional replication from SQL Server to SQL Database (Azure)? https://blobeater.blog/2017/02/20/setting-up-sql-server-to-sql-database-azure-replication/

There are other features out there, I expect the next version of stretch databases to become more popular over the coming future. I even expect this whole area of hybrid concepts to generally grow too.

Tuning/Monitoring

This is quite a big change. As a quick summary tools you will using include:

• Query Store.
• Query Performance Insight.
• Understanding Automatic Tuning.
• Extended Events.
• Good old fashion basics of T-SQL query writing and indexing will be important too. Now Microsoft have gone down the automatic tuning route for indexes, one thing it doesn’t do is index consolidation.

Learn them and use them.

DR/HA

What do you in a disaster? Do you have a recovery process in mind? Just because you are moving to the cloud doesn’t mean you can neglect this activity. In terms of High Availability do you know what to do if your database fails over to the other data centre? Is it manual or an automated process? Should you prepare for data loss during a failover (research GracePeriodWithDataLossHours)?

 Have you written this in your operational runbooks? So many questions and much research needed.

What I am trying to convey here is that you are not going anywhere. You as the database professional will be integral to much of these talks and activities. Am I now a “cloud” DBA? Who knows, at the moment I feel like a DBA in the cloud with lots to still learn. Notice I haven’t even mentioned things like Data Lake Stores etc. I kept it to Azure SQL Databases, but I see myself learning about the other components within the Data Platform space like SQL Data Warehouse, Cosmos DB and even Azure Database for MySQL.

I like Change

Years ago I sat down and thought to myself why this change? At first I didn’t accept it. Based on the Change Cycle (https://changecycle.com/change-cycle/) I was very much going through each stage.

I was fearful (stage 1), had doubt (stage 2) and moved into a confused state as seen in stage 3. I then decided to become aggressive in learning about the cloud, more specifically Microsoft Azure and as indicated in stage 4 I became “creative”. I pushed my learnings and work into my blog and my professional work – obviously where I now have 150+ posts (I hope you find them semi useful?)

As I learnt more I become confident (stage 5) and now I am focussed and fully integrated as stated in stage 6. When I see a new feature I am on it within a day and learning about it and looking for ways I would like to see it improve. You also might go on this change journey, stay passionate and it will see you through.

That concludes my series, my aim was to make it straight to the point and squash those concerns, hopefully I have achieved that.

Embrace the change, for “when you’re finished changing, you’re finished”. – B.Franklin

Filed under: Azure, Azure SQL DB, Cloud Blog Series Tagged: Admin, Azure, Cloud, Cloud Busting, SQL database, Technology