Voice of the DBA

Tag: career

  • Is the DBA Title Dying?

    Not is the DBA joib dying, though we could argue about that as well. Instead, I’m asking if the title of Database Administrator is going away. Are there going to be people that really want to send out resumes and apply to be Database Administrators beyond the next few years? As I look at my resume, I wonder if that’s a job or title I want to keep around.

    Think about that for a few minutes. We’re in the age of complex systems with cloud platforms, automated backup software, PowerShell and other scripting, Chef, Puppet, containers, self-service clones, automatic indexing, query store plan fixing, and more monitoring options than you would want to spend time evaluating. We have plenty of tools to assist, or takeover, much of the daily administration of database platforms. Even security can be mostly outsourced to AD, AAD, other directory services. While there is some level of what we might consider administration, is that the core of many people’s jobs? Will it still be in five years?

    I read a few of the posts from T-SQL Tuesday #100, including Adam Machanic and Brent Ozar. They both think the DBA is dying, and I tend to agree. I know that inertia slows change in many large organizations, and I’d bet there will be a delay just because of HR. After all, if you want to be a data reliability engineer or data professional, most organizations don’t list that job title and would have no idea how to hire you. Even if they loved your resume, they’d end up hiring you as a DBA or developer (developer III maybe) just because they like those nicely labeled buckets for the HR systems. They might not even know how to pay someone in some new role.

    However, the more I talk with people, the less they seem to be doing administration. They still tune queries, but often they’re helping do more database development or even database architecture than administration. They may to more reporting or ETL work, which can easily fall under development as well. Security is still a part of their jobs, but that doesn’t seem to change as often as it used to. Many people have moved to database roles and AD integration for authentication. Then security becomes more of a set-it-and-let-someone-else-manage-it. I even see Slack bots or other tools that let people self-service requests, and others quickly (or automatically) approve them.

    We still do some work, as things like HA/DR still aren’t quite a smooth as they could be, but that’s changing. Cloud services, and the evolving Azure Stack may mean that more and more of our work will be done by templates and patterns. We may have to create the template, but that feels more like architecture and less like basic administration. I expect at some point we’ll just link a grid of machines, on premises or in the cloud, and let people self-service their requests for systems. The “template” will let a service deploy HA databases across the machines as it sees fit, providing an address to connect to, implementing monitoring, and even solving many simple problems without human intervention. I expect that security and auditing features and capabilities will also grow rapidly, becoming more automated, or at least automatic, and request less administration.

    I used to joke I was a data janitor in many jobs. Just dealing with whatever situations people couldn’t, or wouldn’t, bother working on with databases. I often cleaned up messes made by developers that weren’t sure how to build a database that scaled beyond “their machine”. These days I think I’m no less of a data janitor, but I call us data professionals. It’s a better catch-all term, and certainly sounds more appropriate. We do our best to ensure the safety, accuracy, and availability of data in whatever way works best in our environment. We’ll run your T-SQL, R, python, machine learning, SSIS, SSRS, or whatever code for you, and audit the actions.

    I think that as we do that, we’ll do more development, cleansing, and analysis than actual administration.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Learning is Hard–March Goals Update

    This is the third update for my goals for 2018. This is about 3 weeks after the last update, and it’s too soon. Not in time, but because I haven’t done a great job.

    This was a busy month. March and April are prime volleyball season, so I’ve had some longer weekends and time off to coach and watch my daughter play. Add to that some ski time and I haven’t had a lot of work or free time. As a result, my days at work are busy with catching up and ensuring I’m getting things done for work.

    Learning has suffered, and like the Oct/Nov conference season, learning is suffering here.

    My two appointments, Tues afternoon just after work and Friday afternoon, have been busy with other events, or with the need to do more work. As a result, not enough learning. Here’s an update in my two areas.

    Extended Events

    Very little here. This is Tuesday learning, and I’ve gotten myself jammed up for time every week. I’m considering moving this to another day, but not sure which one is better. I’m tempting to try and get through ski season and see if Tues then lightens a bit at work.

    I did watch more of Jonathan Kehayias’ Pluralsight course while on the bike, but not practical work.

    Python

    I spent a couple of hours working through some basics on lists and dictionaries. I realized that I haven’t been doing this enough and I needed a refresher. That was good, and it helped me build a few Questions of the Day, as well as get some practice.

    The one upside is that I was struggling with a puzzle in T-SQL and decided to try Python. I solved it in about 10 minutes, and my solution worked the first time. I was proud of that, and spent another 10-15 minutes solving another problem. So, I know a few things.

    No real formal learning, but I feel like I should race through a Pluralsight course and try to be sure I have a good grounding. Plans for next month as I’m traveling a bit.

    Too Busy

    A few things with family and then volleyball affected me more than I thought, but that’s part of a busy life and it challenges my focus on learning. I’m also letting myself get distracted with the shiny things, reading a bit on various other technologies, which is part of my job. However, CosmosDB and other items aren’t what I planned for this year.

    I’m putting pressure on myself to get through some XE and Python learning and then move into other areas. We’ll see if I can pick things up next month.

  • Are You a Traffic Cop?

    There’s a joke that a DBA’s favorite word is “no”. I think that was certainly true for the individual from whom I first learned about Oracle and SQL Server administration. He constantly pushed back on developers and management who requested changes. He wasn’t rude or abrasive, though I’ve met my share of those individuals. Instead, he patiently would explain and debate the changes and his reasons for not wanting to make them. He had come onboard after a particularly bad deployment affected a significant portion of the company and while management listened to him, development wasn’t pleased.

    One of the analogies I’ve seen for DBAs is that they are a traffic cop. They implement the rules necessary for the safety, protection, and availability of databases systems. This is sometime at odds with the pressure developers feel to implement new features and functions in their applications that require a database. This can, and often is, resolved by using some methodology like DevOps, where the DBA, the developers, and operations staff discuss changes in advance and collaborate to ensure that functionality will not negatively impact data quality, performance, or availability.

    However, this can easily take a negative turn. People often have short memories, and we are all usually busy at work. When a DBA lets a change go through that causes problems, they are reluctant to let the next one go without a thorough review. They slow down and want to double check every new line of code, or worse, they start to second guess their own decisions to allow changes, which can further exacerbate the issues.

    Are you a traffic cop as a DBA? I saw this referenced as a great analogy recently, where the DBA enforces rules, perhaps taking on a bit too much power, and using these rules to limit change. They lock down too much access, even preventing metrics and data from providing feedback to developers. They may even seek to strictly enforce security by the letter of the rule, not the spirit, upsetting and angering others.

    I think good security is important, and often bypassing security for the sake of convenience or expediency is a source of issues, including data breaches. There are policies that are outdated or may not apply in specific situations, and I’d say the sign of a good DBA is that they know when an exception is needed, they document and manage the process, and may even seek to have the guidance changed. They work with others to get things done, constantly looking to push work out to customers, while protecting systems. They may slow work slightly, but a good DBA works with everyone to minimize delays.

    If you’re a traffic cop, I’d argue your employment days are likely numbered. The world is changing, and while security grows more important, the ability to get work done securely and quickly, while working with others, will become more important over time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Learning Goals 2018–February Review

    Better than month 1. Only XE this month.

    My first week I got a reminder to spend some time on XE, so I watched a couple modules of Jonathan Kehayias’s Pluralsight course.  A lot of review, but I thought I’d start with the basics and Jon knows more about this than anyone I know.

    I spent a few days going through this. Some at my desk, but more while riding a stationary bike. This gave me the chance to actually sit and watch without being distracted by other items on the computer.

    I got through about a third of the course, but I still have more to watch. I also took about an hour in two sessions to practice a few of the items, explore how XE is setup and build some questions for SQLServerCentral. This allowed me to feel good about the process.

    Disruptions

    The first couple weeks of February were good here. Unfortunately things didn’t continue. I had travel the last week of Feb and a number of meetings that required prep and I got off track in working through XE.

    Even today, as Mar starts, I have missed an hour or learning time.

    On the plus side, I did take 3 days of vacation in Feb, which took away work and learning time, but allowed me to recharge a bit. I’ll continue that a bit in March, so it’s possible that I might not quite get what I want here, especially as I have a number of weekend commitments this month.

    This is a good lesson, allowing me to realize that I can’t count on adding to my busy schedule without having to make hard choices. Learning has been one of those lower priority items, though I am trying to continue growing in this area.