No Such Thing as a DevOps DBA

Sjor Takes (b|t) has just barely started blogging, but he’s got a great post about a discussion he had with a colleague. It’s worth a read. When you get done, I’ll provide my answer to the question posed at the start and conclusion of his post.

I had a great discussion with one of the smarter people I know late last year. Since I’m going to disagree with this person rather vehemently, I’m going to keep them nameless. We were discussing databases and DevOps and how it relates to the developer, the data professional, specialized DBAs and businesses. It was mostly a great conversation except for this person’s opening. This isn’t an exact quote, but it paraphrases their beliefs fairly well:

The DevOps movement is, intentionally, about getting rid of the DBA. We shouldn’t have them involved in the process any more. The technology coming out is helping us to eliminate that job and that is how DevOps is supposed to work. We’re just going to put all the power into the hands of developers and we won’t need operations people, especially DBAs, any more.

Sigh.

One, this goes back to my most recent post on the word “NO” and DBAs. Two, it’s just wrong.

Doing IT work is hard. Being a very good C# developer who has a full grasp of appropriate patterns, service methods, proper use of tools & tooling, and all the rest, that takes time. Let’s toss in learning T-SQL and database fundamentals on top of that. More time. Let’s also throw in server hardware and OS configurations and PowerShell to manage it all. While we’re at it, virtual machines and virtual machine management. Oh, and Azure.  So, there are probably, a few people, who are legitimately good at all this stuff. But, it’s been my experience that most of humanity (myself included) are adequate at a few things, less than adequate but functional on a whole lot more, and, frankly, suck at everything else. And that adequacy assumes you work at it. So, all developers, by virtue of the magic of DevOps, are not only going to learn all of the above and more, but they’re going to be so capable that they’re able to appropriately respond in emergency situations with all of the above and more. No.

That means that there’s going to be specialization. Let’s assume one area of specialization is around data management. Even if it’s just in DocumentDB (and saying “just” about most technologies is setting yourself up to fail). There’s going to be a developer in the organization who catches the first glitch or hiccup. They’re going to do a little extra work and gather a bit of knowledge to deal with this. Next time a problem comes up, guess who gets called? In short order, guess who is the DocumentDB expert and is consulted on development, deployment, tuning, troubleshooting and disaster recovery? And, guess who is spending LOTS more time in and around DocumentDB and less and less in C#? But we won’t call this person a DBA because that would be bad…. even though that’s the job they’re doing now.

Sorry, but specialization of knowledge means that there are going to be people who do the job currently occupied by a DBA, full time. Further, these NotCalledDBAs will need to be directly involved in DevOps. The NotCalledDBAs will be the experts in the right way to set up automation around deployment. NotCalledDBAs know the pitfalls to avoid in design. NotCalledDBAs have a better grasp of the internals so will be important during development and later during optimization. NotCalledDBAs will have a full understanding of how DR works and some of the design choices necessary to ensure business continuity. All of this is fundamental to a well functioning DevOps team. Oh, and by the way, it’s all the stuff that your DBA should be doing today.

Yes, a DBA is, and should be, a part of the DevOps team. But if it makes you feel better, we can call them NotCalledDBAs.