No Such Thing as a DevOps DBA

Home / Uncategorized / 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.

7 Comments

  • Grant, I agree with you 100%. I have a similar struggle at my current job, where we have a DevOps team that does not have a single database pro on the team. This means that they, frankly, suck at writing database automation. They don’t understand the peculiarities of the platform and the needs of managing data within an automation framework. I’ve purposefully injected myself into their work around our databases. The truth is, they appreciate my knowledge and insight.

    There’s a DevOps gap when it comes to databases, one that we can fill. I agree with the premise that we need to be “eliminating DBAs” only from the standpoint that we need to automate things like deploying servers, managing diskspace, and executing backups. The tedious stuff. DBAs should be doing that anyway. But this doesn’t mean we get rid of DBAs. Instead, DBAs need to be automation architects and building tools instead.

  • Dave Wentzel

    Grant, these are great posts you are writing.

    In your buddy’s defense I have heard some managers tout DevOps as a way to get rid of expensive DBAs/Ops Guys. This obviously means that management is not very enlightened as to exactly what DevOps is.

    But this is no different than managers touting that agile/scrum/kanban is just a way to make developers more of an interchangeable cog in the enterprise software machine. And that of course is no different than managers who are scared of pair programming because they are scared their staff productivity will be instantly cut in half. Or managers who think that unit tests mean that real coding isn’t getting done. Or…

OK, fine, but what do you think?