Voice of the DBA

Category: Editorial

  • Removing SA from Azure SQL Database

    One of the recommendations from Microsoft SQL Server is to use Windows authentication. This has been in the docs for years, and I’ve heard many MS consultants and employees note this. Many customers and clients have tried to use Windows Authentication only, but often in a cross platform environment with Java or Linux clients, one usually has needed SQL authentication with a user and password. Client libraries have been enhanced so this isn’t necessary, but still some people prefer SQL authentication, especially with clients outside their organization. It’s simple, easy, and developers can make it work in seconds.

    With Azure SQL Databases, some companies defaulted to a username and password, as their Active Directory (AD) wasn’t extended to Azure. That has become easier to do, and many people are taking advantage of it. In fact, some customers are so integrated, they want to do away with usernames and passwords in Azure.

    Microsoft has listened, and is giving them the option. The feature is in preview, but if you enable this, SQL auth is turned off, which means whatever administrative account you set up for the server with a name and password will not work. That’s essentially the “sa” account, though with your own custom name.

    While this feature won’t be useful for everyone, it’s a good option to have. As more companies look to tighten security and limit the attack surface area, being able to make this choice is important. It’s also something that architects and administrators should be aware of and consider in their decisions on how to implement applications in Azure.

    Steve Jones

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

  • Working in a Distributed Fashion

    Recently at the Redgate Summit, Kendra (b|t) noted that all the developers working for her are doing so in a distributed fashion. She is a product manager at Redgate, and her team uses git to move source code around and share it with different members for the applications they work on.

    For database work, I often see people using a shared database, which can create issues between developers, though many teams accept this as a part of working on the same project. We often just expect that our code is in the shared database, which means we don’t need to actually move it around. Hopefully, we do put it into version control.

    Has anything changed during the pandemic for how you work with your team? Or with other teams? I assume you don’t see people, but you do need to share things, or maybe you’ve moved away from shared databases. In that case, you might have some tricks for sharing technical code or other things that are a part of your work.

    Most of our work in this business is digital, so we likely adapted fairly easily to remote work. However, it might not have been completely seamless, and if things have changed, maybe you want to leave a comment on what’s different.

    For most of the work I typically do, it was always remote. While I miss collaborating with people in person, something I used to do regularly, the actual bits I need to move and share work in the same way. Actually, they work in more ways, as we’ve found new and interesting ways to share things outside of email and chat. Mural, Kanban boards, and even more video recording and posting have become more a part of my work day than they ever were before the pandemic.

    Steve Jones

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

  • Tool Limits

    In many jobs, there are a variety of tools that people use on a regular basis. Chefs buy knives, mechanics buy tools, doctors buy stethoscopes, etc. While many of us in technology don’t always have to buy tools, some of us certainly do. When there is value and it makes sense, many of us have purchased IDEs or add-ins or a utility that makes our work easier.

    Our tools are different than physical ones. We need a place to install them, but we often have employer-owned workstations, which complicates matters with licensing and rights to install. Bringing tools with you, or taking them with you, is often a strange situation, especially as our tools often need “privileges” to connect to other systems, which may be a problem for many employers.

    Many organizations do provide some tools, and we can certainly build others. We know how to write scripts, utilities, code generators, and more. We may get an IDE or some other commercial tool, which often ensures that all team members work in the same manner, though we may find a need to extend or configure how it works. My employer, Redgate Software, builds tools like this for database developers, and we strive to ensure that our tools make your job easier, and we try to ensure you can extend or integrate our tools into your work.

    Forgetting the hassles of purchase and installs, today I’m wondering what you think about the tool you do use. What tools do you use, and what are the limitations or hassles you find? Are there issues with your tools that inhibit productivity? These might be ones someone in your organization has written, or those they’ve purchased. Or maybe you’ve extended some tools to work in a different way and you’re proud of your work. Let us know about how tools might dramatically help or inhibit your efficiency.

    Steve Jones

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

  • My Time is Valuable

    In most of my jobs, I’ve been given tasks to accomplish, often without a lot of my own input. Someone triages work, or develops a project plan and then assigns me things to do. Often these are fairly narrow pieces of work, but with some latitude on how I might actually complete the task.

    Over the years, I’ve been asked to do things that weren’t a part of my job. At one small company, I spent an afternoon making Ethernet patch cables because we needed them, I knew how, and my boss said it was a good break for the two of us. At another job, I was asked to help go through the separation process when employees left, zipping up files, archiving mailboxes, etc.

    At the same time, I recognize that for my salary, neither of those were a good use of my time. At least not from an ROI perspective for the company. Those are simpler, low value tasks, and for someone that is paid above a beginning level, these were expensive resource costs.

    As we look to improve how software is built *and* managed, we want to take away low value tasks that don’t require human intervention. We want to use computers to do as much of those tasks as we can. That’s a lot of what DevOps tries to get us to adopt as part of our daily work.

    However, this can even include tasks where we might think a human is needed. I heard someone say recently that they shouldn’t be spending time with auditors walking through logs or looking up process documentation. That stuff ought to be produced and available automatically or in a a self-service way.

    Improving the efficiency of our workforce should mean that we don’t spent time doing simple things that can be handled by computers. Sometimes it’s not easy to decide if the automation or tooling is necessary, but at each point we ought to consider the cost of building and maintaining some solution over the cost of an individual spending time there. Often, though not always, we can find a little software development saves a lot of future costs.

    Steve Jones

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