The Role of the DBA in NoSQL
The Role of the DBA in NoSQL
Join the DZone community and get the full member experience.Join For Free
See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.
What is the role of the DBA in the rapidly evolving world of NoSQL? A majority of the early NoSQL adoption is in the fast growing world of small and medium companies based on public clouds. In most of these companies the DBA role does not exist and this has led a lot of people to proclaim the end of the DBA. Is the DBA going down the road of the dinosaur? I think the answer is more nuanced than that. Firstly lets examine a few trends we are seeing in the marketplace that are going to have a great downstream impact on the technology workplace.
1. Devops - Teams today are smaller and more agile. There are very few teams that use a year long waterfall model with a month at the end for production deployment and configuration - teams just don't work like this any more. Teams are mostly developer driven, iterate quickly with a very small or non existent operations teams. All the workflows including database deployment and management are automated by the developers. Unlike traditional relational databases with NoSQL, all the code is in the application server - no stored procedures or triggers to deploy & test on the database server. This makes the whole deployment process cleaner, automatable and easily testable.
2. Public and private clouds - Clouds mean a lot of things - but one of the most important impact of clouds is on "IT automation". In the cloud world everything to do with machines, network & storage is automated. There is little room for an IT admin clicking buttons and deploying servers and storage on demand. "Self service" consoles are going to be more and more prevalent enabling users to deploy infrastructure on demand and get billed for it.
3. Database as a service (DBaaS) - DB-as-a-service is currently mostly popular on the public cloud. It essentially means that all aspects of the DB provisioning and management (availability, backup, scale, compacting etc) are all taken care of by the software - you can start using the database and not worry about machines or any other infrastructure. As a organization once you go "DBaaS" there is no going back - the benefits are huge! As private clouds become more widely deployed the DBaaS model is going to be more and more prevalent on premise as well.
4. Polyglot persistence - Databases are more specialized now and you typically see a number of database in use in a single application. E.g. You might use MongoDB as your application store but use ElasticSearch for your search & analytics. It is now important for DBA's to be experts in multiple database and how they interact with each other.
Currently DBA's spend a lot of lot of time setting up the database, monitoring the database, setting up scripts for backups etc. I think those days are done - if your a button clicker your job is toast. With the advent of the clouds and DBaaS all the mundane database tasks are going to be automated out of the gate. Where does it leave the DBA? The DBA needs to retool and move higher up into the database stack. There are still several database related tasks that are difficult to automate and need human skill and intuition like performance analysis, query analysis etc.
So to finally get to my answer - what do I see as the future of the DBA? In the smaller teams the DBA will be a developer who "specializes" in the database and uses a DBaaS. In a larger organization I see the DBA as a "consultant" who becomes a resource to help teams choose, architect & manage their database. Either way it is going to be considerably different from the way it is today.
About the author- Dharshan is the founder of Scalegrid.io and and an experienced mongodb user. The author can be reached for comment at @dharshanrg. This article originally appeared at https://scalegrid.io/blog/the-role-of-the-dba-in-nosql/
Opinions expressed by DZone contributors are their own.