Long before the “full stack developer” phrase became fashionable, us early developers did exactly that. We didn’t do any of these full time, mind you – full stack doesn’t mean full time.
Here’s a grid I use to explain the work involved in building and troubleshooting database apps:
Developers start from the top and work down. Systems administrators start from the bottom and work up.
If you’re reading this blog, you’re most likely a database professional – but think back to how you got your start, and it was likely either as a developer, OR as a systems administrator. You loved learning, so you tackled more and more roles until you were kind of a full stack developer. You ended up specializing in databases, though.
As companies grow, they separate roles.
When companies have enough work in a department that they have dozens of developers, some specialized roles emerge. This is especially true when they have dozens of servers, some of which require specialized knowledge to administer, scale, and troubleshoot.
Developers who know a database well end up becoming the Accidental DBA – or eventually, just The DBA – and their role looks more like this:
Full time database administration roles tend to focus on the middle parts of that grid: queries, performance, and database server outages. The more time you spend administering databases, the less time you spend writing code or installing hardware.
But you see some gaps, right? Even with separated roles, the “Deploy changes” and “Tune queries” steps are still only done sometimes in shops like this. Historically, this has meant that we’re just not very good at either of those two tasks.
In our industry, we’ve historically had a lot of training classes and tools targeted at monitoring performance and tuning queries & indexes.
But we haven’t had much around deploying changes.
DevOps is about trying to change that.
I need to step back here for a second and explain something before the Well Actually crew eats me alive. Technically, DevOps isn’t a job role: it’s a set of job duties that many people on the team may be required to perform, just like writing queries. However, it’s a specialized skill, just like databases: lots of people may kinda-sorta know it, but as your team grows, you might need at least one person on the team who knows it really well to help mentor the others and define good practices – just like you need a database administrator.
If you’re a database professional, and you’ve gotten good at your specialized part of the stack, but now your company is trying to deploy database changes faster, you need help. You need to learn what tools to use, how to deploy them, and how to integrate with the pure developers on your team.
That’s why Alex Yates is teaching a 2-day online course, Database DevOps. It focuses just on the parts you’re missing, and helps you get started on a similar – but slightly different career, one that’s hot as all get out right now.
15 Comments. Leave new
My job has morphed from a straight DBA to a DevOps engineer involved in everything from writing C# and SQL Code to service engineer responsibilities in a fairly short time frame. I still identify as a DBA, but it’s not what I spend 85% of my time doing anymore.
Dale, I was wondering what set of circumstances, if any, might have led to this? And, do you see any correlation with what Brent has written?
I strive to be both a developer and DBA, to some degree. Though I am a DBA for the company, I jump on chances to be involved in development efforts because I like the job diversity that it offers. It challenges me to continue to grow my skills in other areas other than straight up DBA related skills.
Also, great article!
Such nice articles need to come out BEFORE you offer the promo for the trainings, it motivates a lot and gives a CLEAR picture. I was thinking about enrolling in the training but didn’t get as clear of a picture from the modules as I got after reading you article. Will keep a look out for the next promo to come out.
Deploying changes is getting automated more and more. Here we are using IBM UrbanCode Deploy. So actually we appear to be involved less as time goes on. And with looking to move things to the cloud the DBA role is changing a bit in ways that are not so certain.
And, like anything else you get what you pay for. If a company wants people to be a ‘Jack of all Trades’, then expect the ‘Master of None’ that comes along with it. Honestly I see very little difference between DevOps and RAD, or the Prototyping we did in the 70’s. What will be the next Karmic wave that someone makes millions on, that in the long run will over run Dogmatic DevOps?
What would you call a high paying development job? I prefer development to administration, but I prefer money even more, so I’m an administrator.
In quite a few of the shops I’ve visited that are practicing DevOps, the “jack of all trades, master of none” ideology has a firm grip. I’ve seen where over time, having to support a vast array of tool sets seems to diminish peoples ability to provide high level knowledge and support. This has lead quite a few to late nights and plenty of googling for questionable answers.
In regard to the DBA role, it’s most certainly evolving. With the advancements in VMWare/SQL Server/Microservices/Containerization/Kubernetes/etc, it’s going to be a game changer for the way DBA’s do their jobs and provide support. We’ll start to see more of the “reliability engineering” aspect take front and center in my opinion. FYI, if you haven’t yet, go out and get a copy of Database Reliability Engineering by Laine Campbell and Charity Majors. Brent posted about this book a while back(https://www.brentozar.com/archive/2017/11/book-review-database-reliability-engineering-campbell-majors/). There’s a lot of good information in this book that could change how you see being a DBA.
I can’t wait to see how things unfold for the DBA area in the next decade. It should certainly be a fun ride.
Tune Queries – Developers should be doing this daily, performance is a feature!
David – I think you might be missing the point of the post. If you don’t do something full time, it’s pretty hard to get good at it. If tuning queries is just one more thing in a long list of things you do, you’re not gonna be great at it.
It’s kinda like saying “everybody should be doing security, it’s really important” – yes, everyone should keep security in mind, but as your company grows, you generally end up with full time staff focused purely on security. It’s just too hard to tackle the entire surface area of “security” part time just like it’s too hard to tackle everything going on with black hats these days if you’re just spending 30-45 minutes a day reading about it and working on it.
Brent,
One other thing if I may. So, I’ve been working for a little over 30 years now in all sorts of capacities, mostly data-related. During that time, being more of a generalist had greater cachet and the general shelf life of one’s knowledge AND the pace of change allowed for approximately 12-14 months of solid ROI. Not so much now.
The ONE genre of program type that has *always* allowed for business to invest in technology has been the ability to accurately “know the bottom line”. Starting with VisiCalc on the Apple II with Lotus 1-2-3 on the IBM and going forward, it is ALWAYS about this issue. So, developing software as a profession emerged.
The ‘business’ ONLY cares about index speed when it impacts their bottom line. And, it does. And, they do care. However, elastic search, AWS and so forth, particular products like Amazon Aurora, are going to kick some serious butt. I think in this process cause SQL some ‘gas’ perhaps but more importantly, perform index tuning at a whole new level. And in a much more automated fashion. Add to this the security that a blockchain ‘type’ enabled product can offer and the justification for having an in-house IT resource goes down considerably – with exceptions of course.
I suppose this could lead to “the bigs”, who can afford the buy-in which increases the cost of entry to everyone else don’t mind but the net result I’d assert of this is that, as you suggested, specialization is now required more than ever.
The world continues to change beneath our feet.
Depends on the definition of good. I guess there’s varying degrees to that, so some times you write a query and it just works and you don’t need to think about it too deeply, other times you might need to spend an hour on it and finally you might event spend a whole day plus on it because it’s really gone wrong.
But yeah I can understand if I’m only doing tuning then perhaps that issue which took me a day to resolve may have only taken an hour to solve if I had more practice.
The problem with the DevOps idea is nobody seems to be an expert in DevOps itself. What we really need is the industry to properly define DevOps and then management training in what DevOps is and is not. I’ve heard that DevOps means continual improvement, or even striving for excellence in all we do, but I think it basically means the industry has put a bunch of bad managers in the C level or Middle Management spots, and they don’t know how to properly delegate and assign tasks or hire good employees and fire bad employees. Therefore, DevOps eventually rears it head as everyone is a jack of all trades. You end up with a select few who do the job of everyone, and the rest ride along happy that someone is carrying their water. That ends up being bad for the employer and employee.
How do you combat management by phrase du jour? The problem with changing management thinking in this is apparently a proper catch phrase or term for defining “doing your job well and letting others do their job well and everyone wins.”
We’ve had some attempts in the past. (Insert task) Ninja was too arrogant or childish for it to catch on with management. “Teamwork” is so … 80s. However, we need to figure out something soon, or we’ll all be relegated to a life of trying to understand how everything works, but only faking it to keep our jobs.
For obvious reasons, names have been changed to protect the warriors in the battle.
Much LOVE for writing that. Lu, this is Anon.