The topic of database changes put me in mind of a recent discussion on a professional SQL Server related discussion list. Someone sent an email declaring the DBA role dead. He said that with most people doing DevOps these days, that is the final nail in the DBA coffin. When I disagreed with him, he compared DBAs to COBOL programmers who make a lot of money only because there are so few of them left.
DevOpsI don’t know what percentage of people out there are doing DevOps, but I’m going to go out on a limb and say that it is most likely some number LESS than MOST of them. I don’t think more than half the companies or people out there that do Ops are doing DevOps. I also believe that DBAs that make really good money aren’t making it because DBAs are rare. They are making it because DBA is a tough job to be really good at and the ones who are really good at it are rare. All DBAs are molded by the environments they work in, but really good DBAs are ones that eventually learn to mold their environments to them.
A normal DBA may say something like, “I do it this way because that is the way it is done here.”
An exceptional DBA says, “We do it that way here because that is the way I have it done.”
No, I’m not saying that a DBA controls everything and everyone they come into contact with, but the things that DBAs control, they should control, not be controlled by them. For example, almost every place I have worked at, the systems administration team at some point has tried to take over control of SQL Server backups. They can just back it up with the same software they use to back up systems and VMs. I regularly encounter DBAs who allow this to happen. But how can a DBA be responsible for restores if they aren’t responsible for backups? They can’t. That’s a situation where great DBAs control their environment and other DBAs get controlled by the environment.
My DevOps World
The place I work at now doesn’t do DevOps exactly. They sort of do it. The development team is responsible for their own deployments. DBAs and systems admins have no role in deploying code. But does that mean the DBA role is dead here? Obviously not. In fact, my team is currently looking for another excellent DBA to add to the team.
My role here is different than other places. A large majority of what I do is performance tuning. Our developers are data scientists. They are hired for their analytical skills. They have doctorates in things like physics and mathematics from places like Harvard and MIT. T-SQL coding skills and SQL performance tuning are not considered core skills for my developers. That’s what we have DBAs for. In fact, we may not even know that some new code has been deployed until it misbehaves, and it needs fixing.
We spend a large part of our time tuning SQL code, analyzing and correcting database architecture decisions, and helping developers make good SQL Server decisions for their works in progress. Another way to put it is to say that we get to spend our time doing the things we used to wish we had time to do. Thanks to our implementation of DevOps, we are freed up to do things that have a bigger impact.
It also gives us the time to think intelligently about planning our SQL Server infrastructure to best meet our analytical needs and make sure that the things that we care about are handled appropriately like backup retention, storage capacity and capabilities, etc. We manage our own SANs (the systems team, who are excellent in their job roles as well, still does the infrastructure work for it), define what the backup retention policies are and how to best meet those goals, and ensure that we have a business continuity plan in place that is verified and tested.
The DBA role is alive and well. We’re hiring another excellent DBA. Some DBA roles may disappear. Many roles will change. Some may never adopt DevOps and the role in these case may stay the same. However, to misquote Mark Twain, the rumor of the death of the DBA role has been greatly exaggerated.