Voice of the DBA

Category: Editorial

  • The Evolving DBA

    The world is changing. Plenty of people have written about the changes in the job of the DBA (DBAKevlar, Brent Ozar), including myself. While lots of vendors might postulate their database removes the need for a DBA, and some might believe that, I think that’s disingenuous. Microsoft doesn’t hire DBAs, but they hide that job under other titles. We still need DBAs, though the job changes a little in the future.

    Recently I saw a post from new PASS Board director, Melody Zacharias, where she notes that DBAs are more important than ever. She gives us five reasons, and I tend to agree with most of them.  There is a need to somehow keep track of and manage data, much of which will continue to live in relational stores. As much as there is grown for key-value, graph, streaming, document, and other styles of data stores, we still use relational databases for many tasks. I don’t see that going away anytime soon, especially for legacy software that will continue to live for some time.

    There is also the aspect of a DBA that involves the cleaning, checking, and verifying that data is in the form and format we expect, not to mention the need to ensure the data is intact and protected, and not changed inappropriately (or corrupt). Every system needs people that can dig through data and help decode its meaning as well as ensuring that business users can get it in to a report of some sort. Those tasks don’t go away. While end users might have more self-service query tools, that doesn’t ensure that they will actually know where the data is or how to reformat it. No end user tool is going to fix mm/dd/yyyy for a user expecting dd/mm/yyyy.

    There is also the need to just manage large amounts of data. I know data scientists have struggled to work with large scales of data in the past, and not just because of hardware limitations. They spend an inordinate amount of time gathering and organizing data that is used for analysis or AI/ML operations. Future organizations won’t want to waste their time on those tasks and turn to some sort of DBA to help manage the large data needs of those people performing high level analysis.

    The DBA isn’t going away, though the job is changing. Checking logs and backups is likely something you’ll do less of in the future if you work in Operations. Instead, you’ll manage more data, and you’ll certainly need some coding skills to ensure you can perform in GitOps environments, where we don’t click on things, but rather use code to define our systems and the configuration that we expect.

    The evolution can be daunting, but it can also be exciting. You have time to learn and change and build new skills. Embrace the opportunity to grow and change in your career as a DBA.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Finding Your Own Career

    Building a career is hard work. It takes time and focus to move along a path that you choose for yourself. What I have seen across a few decades of work is that most people don’t bother to find a path, and are happy to wander from job to job, finding new positions or projects when they are forced to do so. As much as I advocate for others to continually learn, there’s nothing wrong with wandering randomly through a career, sticking with a job or employer as long as you can.

    The one thought that I’d like to see everyone adopt is a conscious decision to do so. Make the choice to have the career you want, and the life you want, whatever that is for you.

    Recently on Twitter, there has been a lot of career advice that I’ve seen posted. One very interesting item was that a developer shouldn’t compare themselves to anyone else. They should be proud of what they’ve done and work towards the goals and achievements that mean the most to them. Good advice, but often hard to follow.

    Most of us only see a fraction of the world, and a limited view of potential opportunities for languages, projects, positions, and skills. We often do look at others’ accomplishments and then try to model ourselves in some way to be like others. Not completely but we may choose to learn a skill another has, or pass a test that someone else completed, or maybe go work for the company that a colleague has enjoyed. There’s nothing wrong with that.

    Think about what others do and decide what aspects of that you’d like to adopt. As much as I’ve coached others to think for themselves, make their own decisions, and be proud of the things they accomplish, I also want them striving forward. That often requires a goal and an ideal, which we often find in others we admire. Compare yourself to others, but don’t judge yourself by their standards. Decide on your own if you’re living up to the measurements that make sense to you.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Product Platform Teams

    Is infrastructure a product? Should an Ops team start to feel like they are a team involved in building things rather than maintaining them? It’s an interesting idea that is put forth in this blog from Forrester. The piece postulates that the Ops group should be thinking like a product team, just like developers working on an application.

    When a development group moves to a DevOps style of building things, and starts to take some responsibility for the support of their work, what does the Ops group do? If we push infrastructure as code into our VCS, is there much for the Ops group to do?

    I’d argue there still is. From the DBA side, operational staff can help determine what infrastructure is needed, or what changes need to be made. It’s easy to say that devs should add RAM or CPUs, or even another replica, but do they really know when to add them? Or do they just scale everything up? The latter might be easy on people used to writing code, but it’s not necessarily a good idea for the organizational budget.

    Ops staff can still tune systems, add indexes and rewrite code, and give feedback and knowledge to developers to help them understand how to write better code, or infra-as-code code, the first time. There’s also the need to practice and be ready for various DR situations, including the “whoops, I deleted some data”. There are skills that help handle these situations, which are far different from developer skills.

    This is in addition to designing new systems and setting templates for that infrastructure as code that the developers keep in their VCS. There’s also the need to build self-service tools, which might be where Ops becomes a product team. I think that will be necessary, as tooling is important everywhere. I think Operations might even develop other things, like reports requirements that developers don’t have time to build. Ultimately, though, there is still a need for some Ops work, albeit work that ought to be closely aligned, and shared, with developers.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Data for Defense

    It’s a dangerous world out there. Many of us hear about data breaches on a regular basis, and we often blame poor security at various organizations. Certainly there are a lot of silly mistakes made, whether in configuration or the mishandling of data in insecure environments. Security is a tough business, however, and most organizations don’t have the budget to combat all the threats they face, at least not as effectively as a larger organization could.

    I have more sympathy for organizations after reading about the work of some Microsoft security teams that go up against the world’s best hackers on a daily basis. To truly understand the vulnerabilities in software, someone must also understand how to attack it. Those of us that only have a defensive mindset are inherently limited in how we design protective measures.

    There is a group, the Microsoft Threat Intelligence Center (MSTIC), that looks for and tracks hackers around the world, trying to understand how they attack organizations. This is a group of multiple teams looking at nation state attacks, as well as complex software tricks, using the tremendous amount of data they gather from telemetry to analyze the different techniques and vectors used to exploit holes in our systems. They notify customers, letting them know when a customer need to be prepared to defend themselves.

    This is a fascinating read, and one that makes me think that most of our organizations are going to be at cyberwar for the foreseeable future. Already we know that any system on the Internet is likely to be probed and attacked if it has vulnerabilities. Most of us are careful about what we expose, but we also know the weakest link in our organization could cause us issues.

    We do the best we can, but often we do depend on other organizations, like Microsoft, to actively be identifying and helping us understand what to patch or change to protect ourselves. I assume Google and Apple have similar groups, notifying their customers of potential threats. These large vendors are likely the best positioned to help, given all the data they collect about their platforms. Certainly I worry about data privacy with these vendors, but I do think that their massive troves of data on how their software works can also benefit all of us.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.