The role of the DBA on modern data platforms
There have been many blogs, opinions and articles on “DBA 2.0”, “the changing role of the DBA”, “Next generation DBA” and such titles. It is a hot topic and the discussion rages on. Do we still need DBA’s in the (near) future, will my job as a DBA become obsolete, what value can a DBA add in modern data platforms? In this blog, I distinguish between two types of DBA and show you the impact of the changing data(base) world on both types of DBA.
Two types of DBA
In my experience, there is not just a single description of “the” DBA. A distinction I tend to make is between an “application DBA” and an “Infrastructure DBA”. Looking at a full software stack from storage at the bottom all the way through applications on the top, somewhere halfway through that stack we see the database. In my view, an “application DBA” focusses mainly on the database and the layers above that. The “Infrastructure DBA” has their focus on the database and the layers below.
Is the distinction always this clear? No, of course not. This is a simple view, but helpful in understanding what a shift to cloud, managed, or even self-managing, databases means for the role of the DBA.
Application DBA
Focusing on the database and the layers above means that a DBA is concerning themselves with the best possible way to run applications on top of their database. Topics like (SQL) performance tuning, data modeling and user security come to mind. Connectivity with various middleware solutions and applications will play a major role in the day-to-day activities of the application DBA.
These DBA’s typically either come from a development background and have grown into the role of the DBA, or they were trained from the start as generic, all-round DBA and have more affinity with the business side of the job. That means more interaction with the end-users, talking about business needs, etc.
Infrastructure DBA
As the Infrastructure DBA focusses on the database and the layers below, their main tasks will consist of installing, configuring and patching DBMS software, making sure that the underlying hardware is utilized in an optimal way, taking care of backup and recovery procedures. In short: infrastructure stuff.
The infrastructure DBA often starts out as a system administrator or infrastructure specialist and at a certain point in their career gets the maintenance of the database as an extra item in their job description. There is usually less direct interaction with business users, as the database is treated as a building block and tailored to fit certain specifications.
The change with modern data platforms
With the growing maturity of all database offerings, the way of deploying and maintaining databases changes at an increasing rate. There have been large shifts in the database world, but the momentum is still growing. In the last decades, we saw that databases automated or at least simplified a lot of DBA tasks.
Where a DBA had to really think about where to place their datafiles, this has become almost transparent as storage arrays offer limitless virtualized storage to your systems. Where we had to work several days or even weeks on a disaster recovery strategy and implementation, this has become more and more an out-of-the-box feature that we can switch on or off as we please. Where we had to prepare the system for patching and get a timeslot for downtime from the business, we can now do online, push-of-a-button patches and upgrades.
Especially all the DBaaS (Database as a Service) offerings available today make it very easy to order and deploy a new database, regardless of vendor or platform. With a few settings and parameters, any authorized user can now deploy a database that includes all these features in a few minutes. And DBaaS isn’t reserved for the public cloud, either. More and more database vendors offer their databases and engineered systems as fully managed or cloud-on-premises solution. This makes creating databases almost as easy as carting in a rack of hardware, plugging it in and start using your database environment.
Impact on the DBA
Does all this mean that soon we won’t need a DBA anymore? Will I be out of a job soon? I don’t think so.
The work of a DBA will certainly change, as some tasks are simplified, automated or not even necessary anymore. For example: DBaaS often includes the fully automated backup of your database and a convenient way of recovering and restoring your databases. Cloud environments by definition unburden you of the tasks of keeping an eye on your hardware and can take care of hardware failovers if necessary.
Most of the tasks that are impacted are in the realm of the infrastructure DBA. Most of the tasks on the layers below the database are taken over by the cloud provider. Depending on the service model you choose, you don’t even have access to the OS anymore. And even if you have OS access, your options for changing and configuring things may be limited. Depending on the database deployment, the effort needed to maintain your databases on an infrastructure level decreases up to 90 percent.
The application DBA on the other hand still has a lot of work left. Several tasks will be made easier or are automated, but overall, the impact for this kind of DBA is less pronounced. We see a shift to self-managing databases that also include features like self-tuning, self-securing and other self-“something” features, but this has less momentum than the infrastructure changes. In general, most of your work on the application side of the database is still required.
The future of the DBA
As is often argumented on other blogs, the DBA role changes, but is still not obsolete. If anything, the work will get more interesting. Instead of having to focus on routine and repetitive tasks, the DBA can put more time and effort into what matters most: adding value to the business. When the database is running itself, you have time left to make sure that the end-users get the best database experience possible.
For the infrastructure-type DBA, I do see the need to rethink their focus. Depending on your affinity, you could move in the direction of cloud data engineer or cloud architect, or in the direction of a more application-oriented DBA. I always think of this in terms of how much fun I can have in my work. I always like interacting with the end-users, so the logical choice for me is to shift even more towards the application-type DBA. If you really enjoy working on (virtual) hardware, then the cloud architect or data engineer would be a logical choice for you.
