March 4, 2022 at 12:00 am
Comments posted to this topic are about the item Is the Time of the DBA Ending?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 4, 2022 at 7:32 am
With the rise of the Full-Stack Developer and the current cult of generalism, the perceived need of a DBA is greatly reduced. The development of the database is now in the purview of developers, rather than DBAs, and since many developers regard databases as little more than a place to dump data, one doesn't expect optimal database design. Modern hardware is anyway cheap enough that reasonable performance can be bought to compensate for the developers' mediocre knowledge.
The DBA is a specialist in one particular group of systems — SQL Server services, their instances, their databases (maybe their servers too) — and if management are of the opinion that can be done by a combination of the Cloud, sysadmins & full-stack developers, then the DBA role in these companies is doomed.
I do see a role for DBAs in larger organisations where more specialised parts of SQL Server are at play: cubes, tabular models, replication, availability groups & high availability in general and anywhere performance is considered important, in short, in realms where ORMs & services from Microsoft don't really offer an alternative.
On a final note, I do think, though, that this is cyclical and that there were will be a renewed respect for DBAs in the years to come. How soon though, I cannot say. I'm not even sure there will be a version of SQL Server after this year.
March 4, 2022 at 1:23 pm
It seems that it is changing. With a more automated cloud version that you click, click, click and it installs it for you, automatically backs up and patches your SQL Servers there is less day to day involvement. In small shops the 'dba' either doesn't exist or is a jack of all trades type role. In large shops I don't see it going away at all.
March 4, 2022 at 8:55 pm
I am now in my third job (4 years, then 3 years, now five years) in a row where I am the first DBA in the history of the company. None of these companies thought they needed a DBA during the design phase of their applications, and all suffered mightily due to that short-sightedness as production use of their software started to scale up, eventually hiring me far too late to save them from fundamental design issues.
I'm sure there are lots of companies out there right now who desperately need a DBA, but don't know it.
Even truly great Systems Administrators or .Net developers don't know much about data modeling, or TSQL performance tuning or optimizing indexes, or many areas of being a DBA that go beyond managing backups and patching.
My current employer is "all in" with Azure, and almost all applications were designed specifically to use Azure SQL Databases. I still see those same design and coding issues. Being in the cloud doesn't change the need for good schema design and SQL-specific performance tuning. This is the part of the job I love the most, so I'm happy with losing all those other job duties like backup and patch management to Azure. (Automatic Tuning Recommendations are helpful, but anyone who blindly applies them all is asking for trouble, just as with the old fashioned Missing Indexes recommendations or what came out of Database Tuning Advisor. They are a great as an alerting tool, but I refactor code to resolve them as often as I add an index.)
We even have an Infrastructure Team that handles security, copying data between environments, and routine restore requests.
Will the cloud eliminate the need for DBAs? Of course not. Will it make more companies think they don't need DBAs? Yes, because of marketing from the cloud providers. I got lucky, and have been recruited by companies that realized they reached the limit of what they could accomplish without a DBA. But often the burden falls on DBAs to try to talk themselves into interviews with companies that have no DBA or any job opening for one. That would a significant challenge, except that demand for DBAs is much greater than the supply, at least at the moment.
March 5, 2022 at 2:45 am
I think you’ve pretty much hit the nail on the head, Steve. My perception (which could be incorrect so correct me if I'm wrong) of what you said is that there will always the need for a “DBA” even if the title disappears. It may be that certain aspects of being a DBA disappear (as many aspects already have) because of the advent of supposed “managed systems” but even those systems are going to need people that understand the sometimes extreme limitations there and know the work-arounds to keep the proverbial poo from hitting the fan or to be able wipe the blades in a timely manner while the blades are still spinning when it does. And there will always be a need to support the statement “Go see so-and-so they’ll be able to figure it out”.
As for throwing hardware at a problem, I have to laugh there a bit. Frequently, having more CPUs come into play only means that you have code that will use more CPUs for some really bad code to do their accidental cross-joins with or just a whole lot more runs of some really bad, long running, high resource, single threaded code that will still squeeze other code out of the picture (causing a fit of blocking or deadlocks as I've seen happen too often) as bad or worse than the accidental cross joins do. There's also the question that comes up after you've thrown hardware at the problem and that is "Ok... we doubled the CPU's (now costing twice as much as a good DBA in licensing fees alone) and have a TeraByte of memory and it's still slow... now what"? 😀
There are also the full-stack experts that do think a database is just a place to store data and, when they do run into a performance problem, will frequently brush it off by saying "Well... it has a lot of data and so it's doing a lot of work" and "It's because we're using a database instead of <insert shiny new software name here>". It's always funny when they have to dump that new software for the next shiny new software because they didn't understand that the software wasn't the problem nor is the database server the problem. Instead, it was and continues to be a PEBCAK problem, instead. 😀
A lot of people just don't know what they don't know nor what some of the possibilities are (the latter of which is sometimes difficult even for really good people to keep up with). An example of the former is all the TF 3605 messages in my SQL Server Log Files that were put there by experts that wrote monitoring software and serious growth of allocated but unused space in the related MDF file by those and other experts that don't understand the true nature of "Fast Inserts" or the experts that actually help you fragment your indexes and cause your log file to explode by helping you to follow "Best Practices" that actually aren't and were never we meant to be.
That even caught me for well over a decade until I figured out what was causing it all. That brings up another problem... documentation that is written by experts and then interpreted by other experts. Like one very good man in my life said long before the internet was a sparkle in anyone's eye, "Jeff, be careful how you look at what you read because half of all that is written is wrong and the other half is written in such a fashion that you can't actually tell".
There will always be the need for that "Go See" person, even if others don't recognize the need. Unfortunately, the "others" I speak of are usually the ones that control the purse strings yet have no idea how much they could actually save in rework costs and embarrassment in front of the customer, possibly causing them to lose business.
And to be sure, I used to be a front-end Developer. I know what those poor buggers have to go through and I know also know that management frequently doesn't understand that you can't be an expert at everything (even in one discipline because there's just too much to know to do it right nor why "it's taking so long". And the people they work for also think that a database is just a place to store data and so they never fund any database training the for people that should know everything.
To summarize, I have to quote @m60freeman from above... "I'm sure there are lots of companies out there right now who desperately need a DBA, but don't know it."
As a bit of a sidebar, a good number of such people cut their teeth on this very site for becoming the “Go see” person I spoke of. Thank you and RedGate for keeping this site online and healthy and for the awesome community that developed because of it.
--Jeff Moden
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply