Last week at SQLRally, I heard yet another session with the line, “DBAs are dinosaurs.”
And: “DBAs must learn the analytics and cloud right now.”
This is a total load of crap.
1. Most companies aren’t moving to the cloud or succeeding at analytics yet. Sure, they’re putting SOME stuff in the cloud, but not most, let alone all. They still need your help with their on-premise mess.
2. Analytics and cloud tools change dramatically every year. If you learned a lot about the cloud a year ago, you would have decided that SQL Azure was garbage, Azure VM throughput was a joke, and Amazon was the only game in town. Today, the game is completely different – Microsoft has caught up, Azure SQL Database has new capabilities and new ways of sharding data, and Azure VMs are a real possibility. In another twelve months, there’s going to be another new set of decisions and best practices, and probably new leading products to boot. If you don’t need cloud services today, you’re wasting your time learning it, because what you learn will be outdated in months.
3. On-premise techniques are still relevant in the cloud and with analytics. If you learn query performance tuning, for example, your skills pay off not just on your bare metal servers, but also your virtual machines and your cloud servers. Tried and true skills like that are useful at more companies, meaning they’re a safer bet if you need skills that will get you paid.
4. You don’t have unlimited learning time. You only have so many hours per week to learn things, and you should learn things you love with the best chance of paying your bills. If your company is moving to the cloud, great – learn it. If not, learning the cloud isn’t going to get you paid. If you want a different job, talk to your local recruiters and ask them how many people are looking for help with the skills you already have – versus help with the cloud.
When you need to pick your training plan, go to your manager and ask them, “What’s the biggest problem you’re facing right now, the problem that you’d give me a raise if I could solve?”
Learn to fix that problem – ideally, using skills you can build upon.
I’m not saying analytics or cloud are bad – they’re awesome. But if you don’t love something, don’t learn it – learn what you love. Without cloud knowledge, you’ll still be just fine next year, and the year after that.
Anybody who tells you otherwise is either a salesperson, a “thought leader/analyst”, an idiot, or all of the above.
26 Comments. Leave new
Well said Brent. Every time a new DB technology comes out (cloud offerings, NoSQL, etc.) people start screaming that the sky is falling for DBAs. I can only imagine these people don’t have any actual experience in the trenches. If they did, they would understand the speed of business is much slower than marketing campaigns would have you think.
and I spelled my own last name wrong… I blame DST.
The ability to identify and admit a mistake is what us DBAs do.
I remember all the initial hype around NoSQL which was supposed to have removed the need for any form of normalisation but here I am following Codd’s Twelve Commandments.
Also, I remember that database engine tuning advisor should have removed the need for for dedicated DBAs but I am still here.
” In a distant future when the developers and users hold the power and the DBAs are now extinct and can only bee seen mummified in museums we ill solve all problems by buying faster processors, more memory, faster and larger disks and giving SA to everyone “
Quite a lot of DBAs I know live in a rut. Like just because the place where they work is not going for the cloud, or analytics or any such thing does not mean the rest of the world is that way. Quite a lot of companies are also into outsourcing dba work and using remote dba services. Understading how the world is moving on and how your role will change is hugely important, regardless of what your firm is doing (there are firms stuck with SQL 2000 still). Personally I thik seriously, almost every day now, on what I will be doing even 5 years from now and it may definitely not be transactional dba work. I was really not that way but a couple of job transitions have taught me the lesson that the way we work now is going to change quite a bit.
Context is everything. DBAs will not be extinct a la the dinosaurs. But perhaps the “DBAs are dinosaurs” analogy may be more the perception that DBAs are lumbering hulks not interested in change. I was told by my lead DBA a few months ago that, “we can’t roll out Service Broker because the technology is too new”. I guess 10 year old technology is too new. The perception at my clients is their DBAs are too resistant to change and the introduction of TNT (The Next Thing) is a response to that. I was around when ooDBMSs were going to replace databases, then it was xmldbs, now it’s NoSQL. It won’t happen.
But businesses need to be agile. Certainly my comments are anecdotal and you can find MANY arguments to the contrary and I would agree with you…I’m merely saying that the perception is that the DBA is often the roadblock to being first-to-market.
This is a great point. The problem is many DBAs are seen as obstacles. We need to be enablers, shepherds, agents of responsible change. I recommend Grant Fritchey’s articles on devops and not saying ‘No’.
Sure, many of the tried and true methods will last a while. Tuning is actually more valuable in the cloud than on premise. But unless you want to be stuck in that niche or rut of keeping the lights on for legacy systems, you need to expand your skill set. Pay attention to what’s coming down the road. Adapt as necessary. True, your learning time is limited, but that doesn’t mean you shouldn’t learn.
In my experience, part of the developer perception of DBAs being obstacles comes from the way developers tend to approach DBAs. If they have the mentality of “I’ve come up with solution X and I expect you to implement it immediately” then if I find a fault with their plan or suggest something else then I’m seen as an obstacle to them meeting some project plan or deadline. If they come to me with the mentality of “I have a problem X that I’d like you to help me come up with a solution for” in the design stage, then they tend to view me as a valuable partner in their process. I’m sure there are some DBAs who are about the culture of NO, but the perception is bigger than that set of people.
I actually agree with you on that. There’s nothing worse than a developer asking for a DBA’s opinion as a matter of “courtesy” even though the solution is already coding-complete and 3 months late and there is no possibility of any change. That’s why many shops are *trying* to be DevOps.
I’m talking about the DBAs I call The Nopes. “You want to add a column to a replicated table? Nope.” “You’re thinking about FILESTREAM? Nope.” “You want to be able to query the log shipped standby db? Nope.” “You expect me to learn about readable secondaries? Nope.” “You want to enable snapshot isolation? Nope.” “You want to use schemas? Our reindexing scripts don’t support those, so…Nope.” “You expect me to research buffer pool extensions for those under-utilized, expensive SSDs? Nope.”
Your experience may be different, just a trend I see at my clients…new work is being approved using non-relational technologies because of The Nopes. Not because of some technical merit. In fact, these clients often regret their decisions later when they realize, for instance, that Excel and Crystal Reports don’t work so well with NoSQL out-of-the-box. I’m serious, the choice of something non-relational is due to the corporate polity.
Point is…too many Nopes equals the business and developers looking for alternatives…today that seems to be NoSQL. That, I think, is why I too hear the mantra, “DBAs are dinosaurs.”
Dave – yep, and it’s so awesome that NoSQL doesn’t need any administration. The backups, security, patching, and upgrades are totally self-managing. Isn’t that fantastic?
Oh, wait – that’s not true at all. NoSQL != NoAdmin. Thus, the entire concept of this post – the role isn’t going away.
I couldn’t agree with you more. The NoSQL DBAs aren’t (yet) ingrained with “The Nope” culture. Mostly because the NoSQL DBAs are usually still the developers who brought these technologies in-house.
As I said in my initial comment, the “DBA is a dinosaur” statement may be more about the DBAs’ resistance to change than the extinction of the role. Based on your comments I believe you disagree.
Anecdotally, every time a client brings in a NoSQL vendor to do a presentation at least one of the vendor’s first 10 slides will say something like, “you don’t need a DBA anymore”, “ditch your expensive SAN for cheap JBOD”, and “we are schema-less so you don’t need a change control board and you can ‘discover’ your data.”
We all know this is complete bullshit. I love to debunk this with an example where all collections need to be rebuilt due to a schema partition change, but that’s another story.
So my question to you is…why do these vendors do this? My firm belief is it is an appeal to the stakeholders who are fed up with the lumbering, resistant-to-change DBAs that are viewed as being the reason new products can’t get to market faster.
Totally my opinion.
I agree 100%.
“They” have been saying programmers were going away for almost 35 years. It hasn’t happened yet!!!
I like to use the data at http://www.itjobswatch.co.uk/ as an imperfect measure of what skills employers are looking for. Right now Azure and Azure SQL Databases are pretty far down the list but growing.
As a Senior DBA I’m in on a lot of the cloud discussion. It’s just another part of our infrastructure. And we still have plenty of applications to migrate to new versions and plenty of servers to retire and licenses to manage and code to promote and…
I have issues but job security isn’t one of them. And we’re working on plans to train new DBA’s.
Somebody just needed a “cool” phrase for the conference. Or they don’t understand the big picture at all, because they’re too junior. Sad truth is that many DBAs are pissing their coworkers and business managers by being not a business enablers but innovation holders, like the one about Service Broker which Dave mentioned. Personally I’d fire such a DBA who’s reluctant of implementing great features to solve business problem.
I think that DBA role will ultimately evolve into something else with all the data analytics gaining more focus. And it should be DBA to guide adoption of new tools, not just cling to what they have felt comfortable with for last 15 years.
DBA roles always evolve, but fundamentally, have the basic tasks changed that much in the last 20 years? Monitor and test backups, check for DBCC problems, improve performance, monitor space, monitor logs, work with sysadmins on security, patch.
There are different types of DBAs and yes, some need to keep on top of analytics and cloud stuff and such, others need to continue to be concerned with keeping production going and maintaining recoverability.
SSMS is infinitely easier to use than the interface we had when 4.21a dropped on us, yet I still use batch files and Perl to help with my admin tasks.
Until SQL Server and/or other database systems become self aware or have full AI, then the DBA is here to stay.
Rudy
Quite right. When our Cloud exploratory team started looking around we got the call pretty quick. And once you get past connecting to AWS, it looks just like a db. There are tables, system tables and views and queries. We started building our query libraries for PostGres in the training session.
And BTW, we cannot find DBA’s to hire. As long as that is the case, the DBA is not dead.
[…] who want to use it, and the burgeoning technology. I agree with Brent Ozar ( b / t ) in that I don’t think that the role of the DBA is going away. I do think that, for small / medium businesses, some folks might find that they become the […]
[…] Heh. http://ozarme.wpengine.com/2015/03/no-the-dba-role-still-isnt-going-away/ […]
Hi Brent, I agree the DBA role isn’t dead today, but in the UK at least; what happens when most companies are using a cloud host for their databases in say 10 years maybe – that takes the need away for all the stuff like HA/DR, patching, upgrades, backups etc. from my experience working in a few organisations big and small with SQL Servers; most databases look after themselves and don’t really require performance tuning if configured correctly (which cloud hosts will do). Will it be a matter of only the large companies or companies with very highly transactional databases will need DBAs?
Yes there are more complex features such as Polybase, Hadoop etc. but once these features are setup, they wouldn’t require a full time DBA to support those features surely?
I’m slightly concerned that in 10 years or so, a full time DBA just wouldn’t be needed in most organisations, unless you can write T-SQL queries so you can be in devops as a developer/DBA (when required)? So not sure whether to stick with this career?
> most databases look after themselves and don’t really require performance tuning if configured correctly (which cloud hosts will do)
Hmm, given the number of consulting gigs I have these days where the database is in the cloud, I’m not sure that I agree.
People don’t realize that the role of the DBA is changing and not going, they look at the tasks they used to perform.
It is becoming comon-place to leave out the DBA on projects as the thought is the databases will look after themselves.
When a new environment or database is installed everything looks fine until it isn’t. But by that time the users of the application connected to that database are already frustrated about performance or reliability and in the panic the developer or operations tries to find workarounds on issues that could of been avoided from the start.
Andrew – that isn’t new. That’s been happening since the dawn of databases. When I was your age…
“What’s the biggest problem you’re facing right now, the problem that you’d give me a raise if I could solve?”
What a Question!!!! If only…
But it clearly helps one to raise our own bar. And if you can win some money in the process, so much better!!!!