Five years ago the term "cloud" was still a buzzword, and there was a lot of uncertainty and misconception around it. I remember many DBAs, including myself, asking themselves what this revolution means for them. People asked themselves how a DBA role will look like in five years, or even if there will be a DBA role at all. . .

Well, we are now in the future for those who are asking the questions five years ago. Five years have passed, and the revolution of the cloud is certainly happening. It's a fact. Actually, in my opinion, we are now in a very important period in the history of technology. We have just passed the critical point of mass adoption of cloud services. Cloud services like Azure and AWS are mature enough and enterprise ready. Many startups are considering the cloud as the first choice for hosting their websites and applications. Many organizations are looking at migrating their current infrastructure to the cloud. It's happening. It's not a buzzword anymore, and there is no doubt about where this is going.

So now that we're smarter and more certain about the cloud and what it means, let's try to answer those questions again:

How does a DBA role look like in the cloud era?

Is there still such a role as a DBA?

We're all used to split the DBA role into two segments—the administrative or the production DBA and the applicative or the development DBA. I think that this distinction is still valid in the cloud era. I also think that in order to answer the questions above, we need to look at each segment separately, because each one is affected in a different way.

Administrative DBA

So let's begin with the administrative DBA. This role is far more affected than its counterpart. The whole idea behind the cloud is to reduce the need to setup and maintain your own infrastructure. So who needs a DBA to install and configure a new SQL Server instance when you can do it in a few mouse clicks? Who needs a DBA to create a backup and recovery plan when cloud services are offering them out of the box?

Well, as far as I see it, these responsibilities are not going away—they are changing. It's true that in many cases you won't have to plan and setup SQL Server instances as you have been doing in the past. But on the other hand, cloud service providers offer so many services and options, and there is a growing need for experts that can take architectural decisions in the cloud.

I will explain my point by using Microsoft Azure as an example. When you plan a new database in Azure, you have the choice of setting up a virtual machine with a regular SQL Server instance (IaaS) or setting up a SQL database (PaaS). There are so many differences and considerations between these two platforms, and the cloud DBA should understand them and be able to take the right decision from an architectural point of view. Furthermore, if the DBA chose to use a virtual machine (VM), then there are many choices as for the type of machine, the storage, the network, and so forth. In fact, I believe that the cloud DBA has to be more knowledgeable about the surroundings of SQL Server, such as storage, network and Active Directory—more than the traditional DBA. And I see it as an opportunity, not a threat.

Another change to the administrative DBA role is the way things are done in the cloud as opposed to on-premises servers. As an example, if you try to setup an AlwaysOn Availability Group in Azure the way you do it on physical servers, be sure it's not going to work. And if you try to setup a hybrid solution, then it's getting even worse. There are many differences and complexities that you need to be aware of, and you need to be an experienced cloud DBA in order to accomplish this task successfully. So this is another opportunity—not a threat.

Development DBA

Now, let's talk about the applicative DBA. As a first thought, you might be tempted to think that this role is not affected, because the design and code that you implement inside the database have nothing to do with the hosting of the database. A table is still a table, and a stored procedure is still a stored procedure, right?

Wrong!

First of all, there are differences in supported features and in the way features behave between the platforms. For example, you can’t use sequences in an Azure database. You have to be aware of the available features and how they behave, and you have to design and implement your database accordingly. Just like you need to design your database based on the edition of SQL Server (Enterprise, Standard or other), you should design based on the platform on which your database is hosted (physical server, Azure VM, Azure database, Amazon RDS, etc.). So here's another opportunity for you…

Second, when your database is hosted in the cloud, it means your organization pays for the actual consumption of computing power, storage, and network resources. This model puts more stress on developers, and the applicative DBA among them, to optimize the application in order to reduce resource consumption as much as possible. So the cloud DBA has to be more performance and optimization oriented, and each new development has to be done with resource consumption in mind. An opportunity or a threat?

New Opportunities for the SQL Server DBA

I think you already know my answer to the questions in the title. The cloud is here to stay, and it brings with it a lot of new opportunities for the SQL Server DBA, just like it does for many other roles. In order to jump on these opportunities, this is the time to refresh your skills and adjust to the new era of the cloud. Learn and research the various cloud platforms and services out there. Get to know the differences and the pros and cons of each one. Learn about the surroundings of SQL Server—virtualization, Windows, Active Directory, storage, networking, etc. Take a few complex use cases, such as setting up a hybrid availability group, and practice until you master it.

It’s time to make the transition to a "cloud DBA." Believe me, the cloud is coming at us fast. This is just the beginning. And as soon as you become a cloud DBA, there are so many opportunities waiting for you just around the corner. So what are you waiting for?

From the Blogs

Donâ€™t let bad data sneak up on you when and where you least expect it. Ferret out bad data with Melissa Dataâ€™s newest Profiling Component for SSIS. Learn how to take control of your data using knowledge-base-driven metadata. The truth shall set you free!...More

Now that weâ€™ve outlined the process to let servers in a SQL Server AlwaysOn Availability Group "talk to each other" by means of setting up linked servers, itâ€™s possible to set up some additional or improved checks on Availability Group Health....More

In my previous post, I provided a high-level outline of the core logic (and rationale behind that logic) that would be needed to set up regular synchronization checks on SQL Server Agent Jobs for servers where AlwaysOn Availability Groups have been deployed. In this post, I’ll walk through the steps--and the code--needed to setup those checks....More