Voice of the DBA

Author: way0utwest

  • Daily Coping 11 Jan 2022

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

    Today’s tip is to make time to do something kind for yourself today.

    I booked a massage. I don’t do this very often, but I took a break from life and booked a hot stone massage, always a relaxing treat in the winter.

    I often tend to think about others before myself, so this was a good reminder to take care of myself.

  • T-SQL Tuesday #146–Changing Preconceptions

    tsqltuesdayIt’s the start of a new year, and the first T-SQL Tuesday is from Andy Yun. I’ve known Andy a long time and this is his third time hosting with a creative prompt for us all to consider.

    I really like this one as it could be taken as a technical or a non-technical prompt. What did you think was one way and you learned it was another way. Always good to stop and double check that your view is actually representing what you think.

    We all do this in our views of life as well as work, and it can be hard to change what or how we think. This is especially true for many of my customers, as I find them wanting to adopt DevOps, but not really wanting to change.

    I’ll tackle this one in a couple ways, one technical and one non-technical.

    Separate Accounts for Each Instance

    For a long time, I always used separate domain accounts for each SQL Server service. Even in a large environment, with hundreds of instances, I did the work (or have junior DBAs do it) to ensure that each service was account separated. This was important because I’ve had change passwords and other issues break services in the past. None of the incidents seemed worth saving a bit of time to set up separate accounts.

    Over time, and as SQL Server evolved, Group Managed Service Accounts came into being. I resisted using these at first, but over time I’ve realized that these are valuable and provide security as well as ease of administration. If I went back to managing servers, even single ones, I’d likely look to ensure that gMSA was the standard.

    Take Feedback as An Opportunity

    I’ve struggled with having someone criticize me for my work. I’ve even struggled when they suggest something else, bristling at the idea that I wasn’t doing something well. Often I was successful and doing something well, but there might be a better way.

    Across time, and age, I’ve learned to appreciate other points of view and not become defensive to feedback. Instead, I’ve started to look at other views as a chance to learn or grow, or even just try something. I can still reject the advice or suggestion, but I ought to consider it.

    I’ve started to adopt the “strong opinions, loosely held” philosophy at work.

    Note, I’m trying to do this in my personal life, but I still very much suck at this.

  • Data and DevOps Predictions for 2022

    All the Advocates at Redgate (Kathi, Grant, myself) got asked about some of the future predictions we might have, based on some of the data from The 2021 State of Database DevOps and The 2021 State of Database Monitoring. We each came up with a few things and then someone summarized them. Grant has an official blog post, but I thought I’d glance through the summary, see what the others wrote, and then come up with a few things.

    Side note: I hope to review this next January and see how I did.

    I didn’t do this last year, but I’m going to separate the DevOps and monitoring topics and give a few thoughts on each.

    DevOps

    DevOps continues to grow and really become almost a mainstream idea. I don’t know if I think the majority of companies are really adopting much of it, but many are adopting something. I rarely need to explain DevOps, though I do often need to define it for me and level set how I view it. It still seems everyone things about this differently.

    The main challenges for DevOps are adding automation, moving to the cloud (or hybrid) and writing better code. DevOps can help with all these things, but I think far too many organizations still want to tackle these are projects, not an ongoing habit.

    Well, all but the last one. It seems no one really prioritizing better code in most management I encounter.

    Automation is the easiest of these, and I find that more and more DBAs are embracing automation in different ways. Some still want to do everything manually, but more of them are starting to accept that a framework (like Flyway) or even a simple automated script runner can be used without them needing to connect with SSMS.

    I see this as a trend that will continue to increase, and eventually we’ll expect 95% of all deployment code to run with an automated process of some sort. Bt process I mean you aren’t connecting to a production server from your workstation.

    My prediction for 2022 is also that I won’t see anyone create new repos in a version system other than git. I do tend to work in the MS stack or the Flyway area, and I don’t expect to encounter any clients still trying to work with SVN, CVS, Vault, Perforce. or even TFVC. Any why should they?

    I also expect that we will see more cross platform work from everyone, which means that we will want a fairly consistent way of managing development, whether this is on SQL Server, Oracle, PostgreSQL, or MongoDB. I know that deploying code here means more chances for mistakes, so having a consistent high level process is important. This might mean that you use one type of framework for SQL Server and another for PostgreSQL, but the flow will be the same. Save code, run CI, deploy with automation. Hopefully testing in there somewhere.

    The cloud encourages automation, but not completely. The portals are complex, the offerings changing, and no one wants to worry about which version of a CLI you have on which machines. Still, I hope to see more GitOps or Infrastructure as Code used by clients.

    Monitoring

    I think two things here. First, people are going to rely more and more on monitoring systems to manage the disparate and ever-growing estates of data stores they have. This is going to come about with the problem for many people of not only managing different platforms, but also different monitoring tools.

    People already struggle with SQL Server and Oracle (or any other combination of platforms). I expect they will have AWS and Azure to contend with as well, though likely each organization will lean more heavily on one than the other. However, they’re also going to be dealing with different products for different platforms.

    I predict some stress, confusion, and anxiety about incidents and employees trying to decide how to find and use information.

    The second prediction is that we are going to see another security issue with a monitoring and/or management platform. We had a big one last year, but I bet hackers are working out how to attack other platforms, especially those that require sysadmin privileges and also allow the tools to change the remote systems.

    Security is always a problem and after last year’s incident, I expect other software to be targeted in this same way.

    Looking Forward

    If you are trying to find a new job, or improve your career, here’s what I suggest. First, learn to write and speak. However you can, but working with others, advocating your position, and improving your showing at interviews will matter.

    In terms of tech, get good at something but learn a bit of many things. Pick a cloud and learn how the general infrastructure of IaaS, PaaS, and SaaS work. Things will vary a bit from Azure to AWS to GCP, but the core remains the same. Learn how to spin up and work with a variety of technologies related to data. Be comfortable with version control, with repos, with CI, with CLI tools, with finding answers on how to accomplish tasks. Knowing a bit and how to find out more might be a good way to answer some of those interview questions.

  • Teams Security Issues

    At some point during my career sharing files and links in email became a security concern. There were all sorts of malware problems and issues that spread throughout organizations because someone unknowingly clicked on or forwarded a malicious item. At a couple of large organizations, we had to turn off email for days while we cleaned out systems. Fortunately, antivirus and other types of scanning software improved to prevent most of these problems.

    It seems that not all developers learned the lessons of the past. Microsoft Teams has a few vulnerabilities inside it based on link sharing in the chats. One of the issues is that the preview features aren’t well implemented, though Microsoft security doesn’t think this is a problem as a user would notice the link would be incorrect. I think that’s a huge leap and not a very safe one to make.

    I don’t use Teams often, and as a Slack user, I find it rather confusing, busy, and unintuitive. I know lots of others that like Teams and find it very productive in the Microsoft world, and I’m glad we can have the choice of a way to collaborate with others. However, no matter which type of communication mechanism is used inside of your organization, the security protections ought to be very strong. We are often busy with work and distracted. We are often expecting the information in Slack or Teams to be safer than browsing sites on the public internet. Perhaps that’s not the way things should be, but it is.

    Attack vectors that use code inside a webpage are very common, and I dislike many of the “preview” features that I’ve seen in various pieces of software. They slow down the application, especially on a mobile network, and take up unnecessary space. As someone that often can see bandwidth constraints, I’ve prefer that all of these features were optional. Let me decide if I want a preview.

    The trend to build richer experiences in applications and pre-fetch data can make the experience better, but there is a tradeoff. There are potential security concerns, but apart from those, these features can make the experience more enjoyable or unnecessarily slow things down and interfere with the way we use an application. More isn’t always better, especially when the pattern for an individual user might not match what the majority does. If 51% of users often use a feature, I’m not sure the other 49% view this as a positive way of architecting the system.

    Steve Jones

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