Voice of the DBA

Category: Editorial

  • Is the Time of the DBA Ending?

    I ran across a piece on the fall of the DBA (or part of a piece), and wondered if this is the time when the DBA is disappearing. I do know that plenty of organizations never formally adopted the DBA as a position, and plenty more have abandoned it. Not that there aren’t people managing databases, but they have moved into Database Engineer, SRE, or plain old sysadmin. They might even have another job but function as an accidental DBA.

    The DBA role has often been a mix of many things. Certainly, this is a tactical, operations role that keeps systems running, dealing with performance, security, and availability. DBAs also fix quality issues in production, deploy code changes, and often advise developers on what works well and what doesn’t. They tend to be a bit of insurance against things going wrong as well as the scapegoat when anything does go wrong. I found the DBA role to be a constantly changing, never-ending grab-bag of challenges on a regular basis.

    Those tasks don’t go away with a title change, nor with a move to the cloud, the adoption of NoSQL data stores, or the move to a DevOps style of software development. They might get handled by another role or team, but they still need to be dealt with. The DBA might need to change titles or groups, and they might need to learn how to use automation, GitOps, or some other new protocol for handling the work. As the article linked above mentions, they may need to tackle work at a higher level, not the manual, click, click repetitive process they might have followed in the past. The trend is often to work smarter, not harder.

    As with any change, there will be people who succeed and do better in the future, as well as those that find their best days behind them. I find change often brings opportunities if I am open to them and make an effort to look for those opportunities. You might find your title changes and you can ask for more compensation or more interesting work as the role changes.

    Embrace change, learn something new and find a way to make change work to your advantage. There is always a way to make this happen.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Test Mistake

    Last year a company was testing their software in a dev/test environment and accidentally sent out an “Integration email” to their customers.  They blamed this on an intern, though a little jokingly, and plenty of people shared their own stories about making mistakes.

    I did this once, and only once. I was doing some software testing on a copy of the production database and accidentally sent out thousands of emails to customers. I hadn’t scrubbed the email addresses in the copy, but since I also hadn’t scrubbed the data, customers got an “extra” email for their account and few complained. My boss, however, complained quite a bit and with good reason.

    These days using production data in dev/test environments isn’t really an acceptable practice. Plenty of organizations do it, and hopefully, they are taking precautions. Kendra Little wrote a little about what happened and what should be done, including scrubbing out sensitive data. Not enough people do this, though I am seeing more and more companies looking for solutions that prevent data release.

    This isn’t an intern’s issue. I appreciate someone making a bit of a joke here, and hopefully, there were engineers that taught the intern something. The bigger issue is that we make mistakes as humans and our protocols and processes should expect that. This is one reason why adopting automation in our software process is important. Whether that’s deploying code to the right production server or refreshing the non-production databases, we want to be sure that we limit the number of human mistakes.

    There are always places where we will use humans to perform a process. Whether that’s typing code or clicking something. It’s entirely possible someone clicks the wrong button or types the wrong item. As much as possible, we can use automation to provide a safety net to prevent these issues from reaching customers. We can’t prevent every mistake, but we can continue to improve our process but adjusting it over time. At the very least, we ought to prevent the same mistake from happening over and over.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Less is More

    The world of Information Technology has changed a lot during my career, but in some ways, many things remain the same. There are still mainframes in use, and plenty of jobs. Lots of companies maintain their infrastructure in data centers, even though some are turning to private clouds for their infrastructure. There are plenty of jobs in that area as well.

    There is a trend to consolidate resources into a bucket and then allocate those as needed for various applications and services. This is what mainframes do, albeit at a very high degree of reliability (and cost). The cloud seeks to replicate this, not with high reliability, but with redundancy, expecting systems to fail. In fact, plenty of the data centers these days involve a lot of similar hardware systems tied together with software, with failed systems being left in place rather than replaced.

    This trend aims towards a lights-out data center, where humans don’t work inside the location with servers. As someone that used to keep a coat by my desk in the summertime for trips inside the locked “computer room”, it’s a welcome trend. While a few people might actually need to check a cable or service an AC or UPS unit, most of us these days never see the systems we work on, whether those systems are owned by our company or rented in the cloud.

    This doesn’t mean that we won’t have as much work. In fact, I think that most of the trends in computing over the last three decades have opened up opportunities for workers. This article talks about some of those changes that allow workers to morph along with technology to tackle different aspects of similar jobs. I certainly expect that anyone who wants to improve their skills and adapt to the new data center of the future to have plenty of work.

    This reminds me of a scene from Aliens, where workers use enhanced suits to load heavy crates. I think this is the type of future I see, where humans work alongside new technology rather than being displaced by it. The need for humans to monitor, manage, adjust, and configure software systems and physically work alongside high-tech software is not going away anytime soon. The more that we adapt new technology, the more it seems that we add humans to work alongside it in some new way.

    Continue to learn, adapt, and adjust your skillset and you can remain employed for a long time.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Usefulness of Database Features

    SQL Server is constantly growing and changing, as are most database platforms. There are lots of platform changes, among them enhancements to the T-SQL language. Microsoft has added window functions, in-memory structures, the ability to execute code in other languages, and more. Some of these features are well built and some need more work. What’s always interesting to me is what actually gets built and what doesn’t.

    There was an article recently on evaluating features in an RDBMS, and the article uses the JSON data type in Google’s Big Query as an example. The evaluation is interesting, examining whether the feature actually helps the user, or if it is mostly marketing. In this case, the feature is outside of the “normal” conventions of the platform,  but it is useful.

    When I look at SQL Server, there are features that I think are well implemented and others that aren’t. There are some that are very helpful, but some that don’t perform well, at least not at scale. There are also changes that people have requested, but Microsoft hasn’t decided to build (please upvote the numbers table).

    Many of us use a limited number of features inside the database platforms. We SELECT, INSERT, and UPDATE often, sometimes with the built-in functions, sometimes not. Many data professionals know what to use and avoid, but often developers may assume that any feature added will perform well. Most of them do very well with a few rows of data, but can be problematic at the scale of millions of rows. While we would want all features to work well at all scales, that isn’t something that’s going to happen.

    I accept that some features are there to help customers in different ways. I can’t imagine wanting to run Java code from a database call, but some organizations see value in this, so it’s a capability in SQL Server. I’m sure some people can’t fathom why I think a built-in numbers table is needed when there are easy ways to build one. I guess that’s why my priorities, yours, and Microsoft’s will differ, at least with regard to what things should change in the platform. What gets built is up to Microsoft.

    When you use a feature in any datastore, there may be tradeoffs with other techniques, and there may be problem domains where the feature works well or doesn’t. It’s important that you understand and learn the limits and advantages of any particular feature. It’s also important you know how to adopt a feature when it’s better or abandon one when it doesn’t meet your needs.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.