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.
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.
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.
