I’ve been reading about the death of the DBA ever since I first made the jump from full time developer to full time data professional. The first time I heard it was when SQL Server 7.0 was released. Did you know that SQL Server 7.0 was self-tuning? In fact, it was so self-tuning that the DBA is a relic of the past and no one will be paid for that kind of work any more.
Right.
So, twenty years later, several versions of SQL Server with tons of improvement from back in the day, and I’m still working (and I hope you are too). Object databases were going to eliminate the DBA. ORM tools were going to eliminate the DBA. Then of course, NoSQL absolutely eliminated the DBA. In fact, it’s amazing that any of us are still employed with all the things that were going to make us obsolete and out of work.
Now, I’ve heard this: The automation inherent within DevOps will lead to the elimination of the administrator from most work forces.
<sigh>
Let’s talk about automation.
Automation Will Eliminate the DBA
I love DevOps. I love DevOps the most because of it’s focus on automation. While I try, over and over, to emphasize that the key to DevOps is your communication and environment, not tooling, tooling plays a factor. All the tooling in a well run DevOps process is in support of automating that process and then monitoring it. So, is that going to eliminate the DBA?
One of the reasons I love DevOps so much is because I’ve done it successfully. I’ve worked on teams that built fully automated deployment mechanisms to get code from Dev to Production. Further, we automated the creation of dev & test servers. We automated the creation of production servers too. We automated the heck out of everything.
And then they fired me…
Kidding.
When we started building our DevOps processes, I was supporting two development teams. As we got better at automating our work, I was supporting three teams. By the time we had fully automated all the various processes, I was supporting between five and seven teams at different levels.
In short, automation changed where I spent my time, certainly. Instead of lots of work getting the right script to deploy from dev to QA, I was spending more time tuning, picking indexes, all sorts of other work. However, at no point was I eliminating myself from my job.
Fear of DevOps
Fear, uncertainty and doubt (FUD), can be a great driver for human decisions. FUD is frequently fundamental to resistance to change. “Ah, a new thing. It’s scary. It won’t work. It’s not how we always do things.” Ta-da! Now I don’t have to pay attention to DevOps.
If it was possible to completely automate the DBA out of a job, then we really don’t need DBAs. However, automation isn’t going to eliminate a really skilled DBA. Instead, automation does two things.
First, your job becomes creating, maintaining, and improving that automation you built. Like any other program, it’s not written once, it’s perfect, nothing needs to be fixed or changed or improved. No, there’s lots of work around the automation that has to be done.
Second, automation frees you from drudgery. Instead of having to do dull work, you automate it. Now, your time frees up to do other things and those other things will absolutely fill your time. You’ll be tuning, designing, troubleshooting, all new and better databases. You’ll be adding additional systems like CosmosDB to your work. Automation removes thoughtless, repetitive tasks. It replaces them with tasks that require thought, that aren’t repetitive, that are more challenging and more interesting.
What’s more, by automating tasks, you make your production environment safer. Sure, you can automate stupid stuff. Don’t do that. Instead, you ensure that tasks are properly scripted so that they run one way, ever time. This is added protection.
There is no reason to fear automation unless you really think that your job should be to do simple tasks that should be automated away. Please tell me you’re not manually running all your backups? You’re not right? That’s automated. You’ve automated consistency checks too, right? You’ve automated index maintenance and a host of other processes, right? When did any of these make it so the company didn’t need to bother paying you? What’s that? They found more work for you to do?
Exactly.
Conclusion
I think people can honestly debate whether or not following DevOps practices is a good thing. I think you’re wrong if you’re against them, but I can understand how people might resist it. However, I don’t think there’s any way in the world to honestly debate that automation is a good thing. No, the only reason people resist automation is because of unreasoning fear, crippling uncertainty, and doubts that prevent action. Break away from fear, uncertainty and doubt and you can actively embrace automation. Embracing automation, will make you much more valuable to your employers. Automation and DevOps will not eliminate the DBA.
Well hey, back in the day, the DBA’s main job was running DBCC every night to fix the corrupted pages (SQL Server 6.5), and running the tape drive and putting the backup tapes in the safe every night. And individual passwords, of course. Maybe writing stored procedures, in some shops, but that already shades off to a separate “database developer” role.
Today there are also various roles. There are the “platform” guys who build servers and set up Always On, DR/HA, run and administer same, including backups. There are operational guys who watch database growth, performance counters, fragmentation, and such. There are developers and architects who design the schema, indexes, FKs, and such. There are tuners who look at the actual query traffic and determine what’s going on there, diagnosing and fixing blocking and deadlocks. And maybe, just maybe, somebody actually looks at the data to determine if it adds up consistently – which if it’s going to work, requires that some of it be designed into the schema and not fragmented into the app.
How many of these are DBA jobs? How many of these are DevOps jobs? I dunno. A lot of them seem to get dropped. Running in the cloud helps, of course, the platform guys do more in those environments. Azure SQL is apparently Microsoft’s lab for new SQL Server self-tuning tricks. They could be doing more, OMG could they be doing more, but until they do, we have to do it out in the field. “We”, whoever “we” are!
Oh yeah, the jobs are ever changing. I’m just convinced that automation isn’t an issue. It’s a net positive all the way.
Love it — the constantly changing (or evolving) role of the DBA. It’s really a simple role: do everything, be everything to everyone under every circumstance.
🙂
What a job!
No. I don’t do Excel. That’s where the line is.
Ha!
[…] Grant Fritchey argues that the DBA role is here to stay: […]
Any primers you can recommend on starting the process of automating everything?
This is a book that I helped write that covers a lot of that process: https://www.red-gate.com/wp-content/uploads/2015/11/Database-Lifecycle-Management-preview.pdf
You want to look to DevOps and associated documentation as your driver.
Spot on. I’ve been hooked on automation since I started working as a DBA nearly 20 years ago. I haven’t automated myself out of a job yet, and believe me when I say I’ve tried. 😀
Excellent!
Help! Help! I’m being replaced! Now we see the automation inherent in the system!
OMG! Perfect. Well done. I’m stealing that.
LOL … I even read it in that voice … LOL
[…] not going to be put DBAs out of work any more than ORM tools, NoSQL, Big Data, Virtual Machines, DevOps, or any of the other myriad supposed DBA-killers that have traipsed past our doors over the last […]
[…] not going to be put DBAs out of work any more than ORM tools, NoSQL, Big Data, Virtual Machines, DevOps, or any of the other myriad supposed DBA-killers that have traipsed past our doors over the last […]