As I interface with large clients as a Technical Account Manager (TAM) at Percona, one thing I have noticed is the evolution of the DBA role. With the rise of the cloud, DBAs seem to be spending less time doing traditional DBA roles of performance tuning, configuring backups, and so on. Instead, DBAs are moving more from System DBA roles to more application-centric (App DBA) duties. The cloud has largely taken over the System DBA functions and automated many of them.
So What Is the Next Evolution of the DBA Role?
How long before App DBA functions, such as query tuning, become a thing of the past? Already, work is progressing in the MySQL arena for developing the ability for code to recommend (and perhaps even automatically implement) indexes to optimize query traffic and as well as find redundant indexes. Auto-tuning of configuration settings is also becoming “a thing” for MySQL, and why not? For years, MySQL monitors have suggested changing certain values by monitoring system metrics and applying formulae. Why not allow monitors to make the changes as needed as well, especially with the increasing role of Artificial Intelligence? Where will this evolve? The sky is the limit.
One thing I am seeing with my clients is the increasing demand for DBAs to foresee issues and resolve them proactively. Technology in this arena is evolving, and monitoring tools are becoming more predictive in their approach. In the past, monitoring has largely been reactive and is even still mostly the case today.
Want to Be a Real Asset and Be Prepared for the Future?
The DBA needs to be able to see trends across applications, especially when working with different teams who may be facing the same challenges. Often, teams are distributed and the DBA may be one of the few roles that can span across teams and bring institutional knowledge across the various teams.
As the role evolves, and databases become even more fault-tolerant, highly available, self-healing, and so on, the DBA must evolve to remain highly relevant. When the DBA is highly-engaged from the initial development of the application, they can advise from the onset of schema design, query writing, indexing, and so on. Unfortunately, many organizations still bring the DBA Teams in after the application goes to production and expects them to solve problems after it is too late to make app changes. But, what else can DBAs do?
I believe DBAs need to be able to see the bigger picture of the database and be able to work more as architects. If this is done, DBAs will be able to predict bottlenecks in the database layer and drive solutions to resolve them – before the code is even written. As it stands today, few DBAs have the luxury of looking into the future and are instead consumed with only the immediate present; but, I am not sure this will always be the case. After all, who knows the database layer better than the database experts? Why, then, do more organizations allow developers to make all the decisions on database deployment when that is not their primary forte?
Again, I think the evolution of the DBA role will facilitate a shift in focus as time is freed up from mundane tasks that become more highly automated. Are you able to drive this kind of change in your organization? Are you looking this far forward and seeing how your role will evolve? I think you should. As more DBA responsibilities become consumed by the cloud, we need to take on different ones. I don’t foresee the DBA role going away, but we need to always be ready to adapt as technology advances. If we don’t, we may be left behind. The need for a database expert will likely be there for the foreseeable future, but it may not always look the same; at least that is what I am seeing in the market.
What do you think? Let us know in the comments!
Our latest white paper “Does Migration to the Cloud Eliminate the Need for a DBA?” provides additional in-depth analysis of the role of DBAs in the age of DBaaS.
Agree 100%.
Regarding involving DBA into design – it not about clouds, let me explain. Most of developers do the same errors and even with traditional application design involving DBA helps to solve a lot of problems.
Typical issues:
– misunderstanding of indexes and how they work.
– DB schema design – normalisation.
– DB schema design – choosing proper data type.
– Application HA design(ready to handle bottlenecks on any layers like network/DB)
If the DBA role will evolve, it will be an evolution around the cloud – where the majority of cloud users believe that their provider already functions as a DBA, so they do not need to hire one.
The best situation when DBA and application developer is the same person.
What is needed is clear metrics at the beginning set by a system engineer or architect. Someone in a developer role and not in a database role should not be making these decisions. I find when a person in a database role confronts the developers about operational boundaries and process, little if anything has been thought about. In addition the monitoring of these metrics need to be made available to everyone and translatable to the wider business so anyone can call out problems in the system’s lifecycle which makes it clear to database folks (and the wider business) what the real priorities are.
In my organisation, the role of DBA is expanding to include many aspects of DevOps: software development, systems administration, hands-on management of monitoring systems, automated deployment of databases, application support, and adoption of tools such as Git and Ansible as part of the standard DBA toolkit alongside “traditional” tools like PMM, OEM, the ‘mysql’ command-line client and so on.