More and more companies use NoSQL systems like MongoDB, Alexa or Couchbase. Each of them has its purpose, its pros and its cons. The biggest advantage assumed: They run autonomously, in Docker container or externally and they normally don’t require a fix schema. A reason to no longer need a DBA? That depends on the perception of the DBA:
The DBA – bottleneck of the agile development
One accusation I often heard. As a developer one just wants to add a new column to a table, but one has to get a review, change request or any other approval by a DBA. “And until this is given, the sprint or even the next is at its end”. Schema changes are intensively checked in order to not create grave performance issues with an assumed small change. But this does not automatically imply long waiting times. Sure, the DBAs do not sit in front of their mailbox and wait for the next request, they have lots of other duties like installing new servers, monitor them, analyze current performance and many others. But if the processes are set-up in a good way, it will not take longer than some hours, in the worst case a day until one receives an answer (dark figure depending on ticketing system and reviews by other teams implied in that system).
How do you prevent waiting times? Proactively involve the DBA to the task, ask in advance for hints about how for example one should add the new column to assure performance and stability. As long as you know and obey best practices of data modelling yourself, follow internal recommendations of your DBAs or ask them – as said before – proactively and take the answers for serious. If you do so, nothing should delay the change and it will quickly be done.
The DBA – the eternal moaner and challenger
„Every request gets cancelled, he has something to complain about every time, each time he responds with a question, why this has to be, if it would not be possible to normalize the table or change the datatype of a column“. Every DBA can only judge what he knows. See the paragraph about the bottleneck: the more information he gets in advance, the less he has to ask to understand and approve the current change. His task is to guarantee the performance of the system, so his job is sometimes to deliver negative decisions. If he didn’t act like this, shortly after the deployment he would report that the server will die under the load, or worse, he would have to respond to the question, why the performance is so low with the fact that it is due to the new column. Accusing the DBA for adding the new column would be a first step to insight, why – even before the deployment – he said that the column was not acceptable as scripted.
The DBA – permanent supervisor of the DB systems (and their development?)
It’s easy to assume, the DBA only installs new servers, caresses the existing ones and stares at control monitors hoping they stay green so he can enjoy the easy way of life. Maybe there are DBAs who wish to really have such a quiet working day. But we have become DBAs because we’re really fond of the systems, they fascinate us. We want to find out why they work as they do, why certain queries run slower than expected, and which internal implementation influences the creation of the final execution plans. We are interested in improvements, innovations and in helping. We have acquired our knowledge to be on the side of anybody who asks four our help and work. To be there for anyone, who is asking us to tell them our opinion about a model or a query. We take care to keep the systems in a supported state. To reach this goal, we are constantly improving our skills and developing lifecycle plans. Depending on the company’s organization we even develop application libraries, interfaces to common used data (bases), PoCs for new features as show cases and explanation towards the developers. Because we do not just operate a server staying functional and keeping it on the current state of updates. Instead we help the server to “grow up”, to be able to do more with each day it works and with each version. But everybody involved has to learn that before he’s able to apply it.
The DBA – point of contact in case of performance troubles and questions about data models
„Since our last code change, the system is running slow. Can you help us find out why?“ is a nice version. “In the next deployment we want to replace a query with the following. Can you tell us if this could have an impact on the performance?” the nicest. Also “Our system doesn’t run fast enough due to the db – can you find out why?” is still better than “Due to your db, our program has a bad reputation, the clients don’t like it, fix this instantly!”
I’m sorry to say, but I can imagine that you might find some accidental DBAs, abusing their power out of anger about them being forced into the position and block all deployment requests just because they can. Also there might be rotten apples amongst us who wanted to become DBA, exactly to get the power to behave like this. The real DBA though will be pleased if he is asked as early as possible to accompany the extension of the data model or changes to the queries of an application to help detect and prevent decrease in performance. That’s where the fun is, that’s what drives him. Analyzing code as well as data models, detecting efficient queries, develop tuning suggestions and declare warnings, or – to get back in focus – approve change requests, because the architects and developers made their job excellent as usual. This way he can be sure that he will not see the db server burning after the deployment, but instead will enjoy to see it run properly.
Fair enough, but where’s the connection to agile development?
You are looking for the connection to agile development and above all to NoSQL systems like MongoDB? Disregarding the fact that with all agile methods changes have to go REALLY FAST and the DBA often get forgotten until he speaks out his veto against a deployment, even with the NoSQL systems there is still need for someone with “a green thumb” for performance, who can support the developers when they are concentrating on the code or do not want to worry about data modelling. Because on these systems one can bring out the best while giving thought about how they work, how they organize and store data and how they scale. If then the DBA is called „database specialist“ as in our company or even – as proposed by Matt Kalan in https://www.mongodb.com/blog/post/dbas-future-database-adviser – “database adviser” – that’s not really important. The most important thing is to realize that he is not working against but hand in hand with the developers. Grant Fritchey describes the useless struggle and – more important – the missed potential very detailed in http://www.red-gate.com/blog/database-lifecycle-management/youre-not-delivering-devops-database. And as Martin Fowler identifies in https://martinfowler.com/bliki/NoDBA.html, one should not use NoSQL systems, just for the sake of modernization, coolness or the mere will to avoid the DBA. In addition, at least in the near future, there will still be applications, for which RDBMS are the better choice. Even in the agile world.