The growing popularity of DevOps as well as virtualization, cloud data storage, and micro-services tools means that the role of a database administrator is constantly changing.
Database administrators, or DBAs, are responsible for the performance, integrity and security of their organization’s database; their responsibilities include building, tuning, and updating new systems. However, a lot of that work has been made obsolete with the introduction of automation, and as automation advances, DBA responsibilities will continue to change.
Database automation has brought an end to many of the mundane and repetitive tasks that were once DBA responsibilities. NoSQL databases provide a mechanism for storage and retrieval of data that does not require a pre-defined schema. The once-lengthy process of adding new servers has been reduced to clicking a few buttons.
Even relational database companies are pushing customers toward “desktop as a service,” in which the back-end of a virtual desktop infrastructure is hosted by a cloud service provider.
But Database-as-a-Service (DBaaS) has not been embraced fully and most companies refuse to keep their mission critical information in the cloud.
It also bears mentioning that not everything can be automated at this point. For example, there aren’t many tools around for finding and fixing slow queries or picking the best shard keys. On top of that, automation has made data environments more complex for anyone without specific administration expertise.
So where does that leave us?
Not only are environments more complex, but the job of maintaining them as a DBA is more difficult than ever. Where once knowledge of Oracle and Microsoft SQL server might have been enough to become a decent DBA, today it’s not uncommon to find stacks with 50 different integrated technologies.
Frameworks and software like Hardoop, Kafka, and Elasticsearch offer vastly different functionalities and a DBA must know which one to use – and in which situation to use it.
Databases have become so muddled by their nuances and components that it’s sometimes impossible to characterize exactly what a database is. Apache Kafka, for example, has the properties of a database in that it shuffles real-time data, but it is not a database.
DBAs need a capacity for professional adaptation to go along with a sufficiently current industry and technology understanding in order to keep up with these specific tools. Equally importantly, unqualified personnel need to be denied access to such tools.
As automation advances as well as the required knowledge of DBAs, their role in the database must also change to compensate.
The next generation of DBAs will be less involved in the hardware and software stack. They will still need to be database-intensive, but not exclusively. Instead, the DBA will focus on tasks like capacity planning, and he or she will need to know when to provision more servers and when to retire them.
Just as the definition of what exactly makes a database has become less clear, so too has the role of the DBA. With the spread of DevOps, more people within an organization will have more knowledge of the database and what makes it tick.
Given how much time people are required to spend with their own stacks of data, isn’t everyone in a sense becoming a DBA? Let me know what you think in the comments below.