I’ve written before about how databases are like a car engine, and DBAs are like a car mechanic. That’s been the traditional view for production DBAs for, well, forever I think. And that analogy may have been true at one time, and may still be true for some DBAs.
But the industry is changing. First we had virtualization, forcing DBAs to learn more about the world that exists outside of the database engine. Then we had cloud services forcing us to learn even more about the universe of data that is available to everyone, everywhere, at any time. Breadth is the new depth.
And with those changes, I no longer see DBAs as a car mechanic.
DBAs don’t get to touch 3rd party apps, for example. A majority of data managed today by DBAs are 3rd party apps, often offered as a service.
DBAs sit and watch as the data hoarders continue to amass data leading to ROT. This ROT then forces database vendors to find new and interesting ways to make data go faster when the simple answer might be to get rid of the data you don’t need anymore.
No, these days a DBA is no longer a car mechanic. Oh, we still have a cool collection of tools, and we know all about how the engines work, too. But we aren’t allowed to touch the 3rd party apps. We are subject matter experts, but others do the lifting. We used to do backups and preventative maintenance, remember those days? Well, with SQL Server Managed Backup and Azure Query Performance Insight we aren’t needed for those things anymore.
All the tasks traditional production DBAs have done for decades are being automated away. Right in front of our eyes.
So, no, we aren’t car mechanics. Not anymore.
These days a DBA is similar to an auto emission testing machine. We locate problems but notify someone else to take action.
Soon our salaries and tasks will be compared to PaaS costs. There won’t be a need for paying to have a DBA on staff anymore. After all, we don’t pay to have our mechanic live in our home, right? No, we take our car to the garage when needed. That’s the model for databases in the future, too.
It’s because access trumps ownership. Companies don’t care if they own databases as much as if they can access data. They don’t need to own a DBA, either. They just need to access to a DBA from time to time.
The future of the DBA is in knowing how to build solutions, not tables and indexes. It is analyzing data, not how it is administered.
The future is in our hands, too. We get to decide what we want to learn today that will help us have a job tomorrow. Data science is one choice, but not the only choice. Another choice would be cloud architect, helping people build solutions by utilizing one or more cloud services.
Heck, maybe DBA will still be a choice in the future, but I can guarantee you that our days of rebuilding indexes are ending one page at a time.
Great Article! I transformed my skills and have moved to ML, R, Python, Tableau Online, AWS, Azure. Life is good!
Yes, and you made the transition years ago, as well. Now I’m thinking we should just watch your lead so we know where to go next!
True in every sentence. I get the same feeling from the everyday work and collaboration with colleagues and partners. Great piece, Thomas!
Thanks!
It’s hard to accept but it’s so true. No pure DBA’s anymore!
First and foremost great article. It should make every DBA think of the endless possibilities where their career may be able to take them. I’ve seen exactly what you are talking about locally and elsewhere in terms of the direction of where the DBA may be heading. I also see a flip side regarding cloud based architecture and entities who haven’t fully embraced it yet such as financial districts etc. Will be interesting to see how it all plays out. This article is definitely a thought generator. Thanks for taking the time to write it.
Thanks for the comment Chris, much appreciated.
Let’s just hope this shift in focus takes some time. I kind of like being a managed service provider DBA for clients! I have never been a fan of development.
let’s hope places with PII information, like medical facilities fear the cloud a little while longer! 🙂
The shift will take time, yes. But it will happen.
Hi Thomas,
Great post !
My exposure to ‘Azure Query Performance Insight’ made me disappointed and happy at the same time. SQL Azure database can measure impact after index creation (and may be after drop too) and can take certain actions based on configuration – This has been made performance tuning so easy and efficient.
With the time as the technology develops itself, certain tasks are bound to be automated and non-repetitive tasks would be more complex. Because of so many new features in last three releases of SQL Server and development in cloud segment, learning curve for DBA is going to have spike but with lots of people coming forward to share their wisdom and knowledge via blogs, forums,etc, would certainly be of help.
Thank you !
Welcome! Thanks for the comment!
Azure has a lot of moving parts. SQL Database in my world is holder of metadata, not the data itself. The real data is external. I submit that we’ll still be around for awhile because until people come to understand that Azure Query Performance Insight they’ll want someone to tell them what it means. I have one foot in on-premises and the other in Azure in a (currently) split environment while moving ultimately to all-Azure. Think cattle, not pets.
As a DBA for over 30 years (mainframe, then Unix, then SQL Server), I can tell you there never was a “pure” DBA role. My earliest experiences were to increase availability as mainframe servers could crash suddenly — and perform database restores afterwards. As server availability increased, performance tuning was the watchword. Performance tuning initially involved disk placement analysis, but that role was later assumed by storage management. When relational databases arrived, a new world of performance tuning came on the scene, along with an explosion of database design and architecture. Then came data warehouse and BI. Now we have Cloud, Big Data and AI/machine learning. What I am trying to say is the role/function of database administration will constantly evolve and grow. I don’t think any enterprise will ever have a single sourced Cloud provider. With the requirement to integrate data across applications, an on-prem DBA might simply evolve to an integrations specialist. With the growth in artificial intelligence predictive/prescriptive analytics, the hosted site DBA might evolve into a data scientist. My advice to anyone in the IT field is the same now as it was 30 years ago: know the technology in what you are working on, keep track of the “big picture” where it is heading, and decide when to make your periodic career adjustment. Your current company didn’t hire you out of the goodness of their heart. When you start to see a reluctance in your current company investing in you (assuming you are adding value to the company’s bottom line), consider that the time to bail. You will soon get pigeon-holed.
Thanks for the comment! You’ve added a lot of thoughts to the discussion. Much appreciated!
LIke
@T@ThomasLaRock:disqus What do you think are the areas where Machine Learning can be applied in Database Administration tasks ?
Here’s one: https://azure.microsoft.com/en-us/blog/improved-automated-tuning-sql-database-advisor/
Companies like Microsoft can churn workloads through ML and use it to gauge performance for queries, servers, and applications. They can use ML to automatically tune the environment without having to wait for bottlenecks to happen. ML will allow for a more predictive method of tuning, as opposed to our current reactive methods.
This is a great line: “When you start to see a reluctance in your current company investing in you…, consider that the time to bail.” Good. True. Stuff.
I am reading this post after 3 years.. it’s so true. I made the transition into a devops role more focused on Linux and python , think am satisfied:)
I also noticed that the market for a dba was shrinking 4-5 years ago.