Voice of the DBA

Tag: Database Weekly

  • How Important is Software?

    I have a mechanical gaming keyboard, not because I’m a gamer, but I did want to tactile, mechanical feel and I like the idea of lights on the keys. I’ve enjoyed the experience, but the software leaves something to be desired.

    I thought about my experience as I read this review of a more complex keyboard, with the title that notes it’s so pretty you can almost forgive the software. The poor UI and the complexity of operations, not to mention the splitting of the remap functions being unnecessarily complex. That was my experience as the only thing I cared about was remapping the home and end keys to the places I was used to them being on Logitech devices. I have spent a few hours across the last year learning how to map keys, and then relearning when my profile is lost in an upgrade or hardware glitch.

    How much does software matter to customers? I’d argue it is becoming more and more critical all the time. The experience of using hardware, or really any device or service, is impacted by the software that drives it. Software is eating the world, and I think we need to understand that better software design and quality is needed.

    I find that the most talented hardware companies sometimes have the worst software. It’s almost as if they assume their customers will be as talented as their hardware engineers and don’t spent enough time understanding how to better design a user experience for their products. Keyboards, routers, motherboards, and more often use archaic, confusing methods to have customers configure or update the systems.

    I know UX is hard. This isn’t even about graphics or visual appeal. In many cases, it’s about just better understanding of how others view the process and what information they take from what appears on the screen. Over the years I’ve learned that this is not only hard, but also that it takes time and debate, just like features do. I enjoy these moments, and I like to think that I help my employer produce better software for our customers with my feedback.

    I urge developers to have others look at what they present on the screen, and spend time learning from users, both experienced and novice. We often forget how something appears to others when we look at it every day and rush through workflows as we test our latest code. It’s easy to gloss over daily changes as minor when the sum of all changes can be a jarring experience for our users after an install or upgrade. UX is important, and it’s worth putting effort into our software designs, our data models, even the metadata we expose to others.

    Steve Jones

  • New Cloud Licensing Limits

    Licensing is always a complex discussion with SQL Server. Depending on the way you run it, the edition, the version, whether you’ve purchased Software Assurance, and more, you might struggle to ensure you are in compliance with Microsoft’s terms.

    This can be even more complex when you move to the cloud, as sometimes your setup could include a license, and sometimes it doesn’t. If you lift-and-shift to cloud VMs, Azure lets you bring your existing licenses with the Azure Hybrid Benefit, which is tempting for organizations that want to get out of the data center business and move their workload to the cloud.

    However, that isn’t necessarily the same for all clouds. While Amazon lists various ways you can bring your licenses to AWS, Microsoft hasn’t felt that was legal. They’ve noted in 2019 that their “cloud partners” couldn’t support workloads on non-SA licenses. I can’t quite determine if SA licenses can be used, as lots of information out there is conflicting. Microsoft’s FAQ seems to support the idea that you need dedicated hosts, not just any shared VM.

    Not all cloud providers count, however. This week Microsoft noted that some cloud providers can let you run your workload by bringing your licenses. These are smaller providers in Europe who filed complaints. Likely these providers can’t offer the scale or pricing of GCP, AWS or Alibaba, so they aren’t as big a revenue threat as these providers.

    I don’t know what I think is the right thing, as once I’ve purchased a license, why does the location or ownership of the VM count? I ought to be able to run the software within the same guidelines in Rackspace, EC2 or GCP just as I would on-premises. However, such is the strange world of software licensing.

    If you deal with licensing, I’m sorry, but also, you should note that there are rules and restrictions when you move to the cloud. That’s something I see increasingly happening in many organizations, so educate yourself so that you can make the right recommendation. And when you get ready to purchase licenses, think about how SA not only affects upgrades, but also the flexibility of migration.

    Steve Jones

  • The Case for Patching

    Recently I was testing a feature in SQL Server on 2017 and 2019. There was supposed to be an improvement across versions, but I didn’t see it. Then I realized that I was on SQL Server 2019 CU 2 on my laptop, and the current CU is 17. I took a few minutes to download that and install it.

    I have often been a lagging patcher in production environments, often looking to stay a CU or two behind, depending on my workload. SQL Server has been a very security -table platform, so that’s often worked well, though there are security updates at times. For those, I usually prioritize a patch getting applied.

    Windows (Linux, MacOS, etc.) tends to get patched more often than other software, especially by administrators. At least on desktops. Servers sometimes lag a bit, which can be a problem. I saw this week that a lot of attacks in 2022 Q2 were for a vulnerability Microsoft patched in Sep 2021 but hadn’t gotten all their customers to apply the patch. That situation was a problem early in my career with many vulnerabilities, and it’s still apparently an issue now.

    If you’re wondering how big a deal patching can be, remember the Equifax hack? This occurred because administrators hadn’t patched a system. Whether it’s a host OS, a database platform, or some other software system, it’s important that you keep somewhat current with patches. We never know when vulnerabilities will appear, and honestly, for most of us, we can’t spend the time tracking every piece of software and the various vendor disclosures.

    We can, however, patch relatively quickly. While I don’t expect that most, or even many, people will patch within a month, I do think that delaying six months is probably a bit long. That being said, I need to check a few of my servers and make sure my admins are keeping them up to date.

    Steve Jones

  • GitHub vs. Azure DevOps

    I work often with Azure DevOps. I have enjoyed the platform and it does what I need. I also work regularly with GitHub and GitHub Actions. Those rebuild SQL Saturday and SQL Memorial when I need to make changes. It also works very well.

    This week I saw a post on choosing between Azure DevOps and GitHub, which is something I get asked at times. The post goes into some of the differences and provides a lot of links that you can use to read about features. There also are plenty of links on using the two products together, which is something I see regularly. Code in GitHub and the build/test/release in Azure DevOps.

    On the question of which one, the author doesn’t give a recommendation, but rather some questions on things you might think about. The author asks about the features you use or think you will need and using that information to help guide your decision. I think that’s fair, but here’s what I’d say.

    If you have no automated version control or build/test/release tool in your organization, then choose Azure DevOps. It has a lot built in that I like and it’s simple to use. I think it’s visually pleasing and I think it is easier to teach people how to use it for this reason. GitHub is fine, but I find it slightly more confusing to move around in, though to be clear, I spend more time in Azure DevOps, so I’m likely biased.

    I’ll also separate out version control. I assume your organization has someone using version control. Whatever system they use is the one to adopt. There’s no reason to argue or get them to change. Most people use Git and all Git host services are essentially the same. We could argue some small thing you want, but really Git is Git. Use what others use.

    I would say the same thing for build, test, and release. Use what software developers use. These systems are all good, and they all have pros and cons. They all do some things well and have some disadvantages, but they are really interchangeable. I wouldn’t move build systems or release systems without a really good set of reasons to do so. Just because the new lead or CTO likes another system or has experience there isn’t a good reason. If you don’t have any system in your organization, then see my recommendation above.

    Modern software development needs a team, and for teams to work well and efficiently, you need version control and an automated build/release system. Use what others use, or have some people conduct a few pilots and then take vote and go with the results. Really, all these systems are similar enough that it’s not worth more than a few minutes of discussion.

    Steve Jones