Voice of the DBA

Category: Editorial

  • Republish: Looking Back

    Aloha!

    First day in Hawaii for me, so I’m re-running Looking Back.

  • When Is Technology Good Enough?

    I just paid off my mobile phone. In my case, this is a phone from Google Fi, which provides fantastic service for me. The phone works well in any country I travel to, without any extra roaming costs outside the US for data. That works well, since it’s a data device, and not really a voice device for me. Even overseas, lots of my calls are through some data service, like Facebook Messenger.

    The decision for me now is whether to upgrade my phone. I’ve been getting some promotions and I’ve seen some deals from other retail outlets on phones, so I’ve been considering changing my Galaxy S20 for an S22 (perhaps plus) or a Pixel 6. There have been some improvements in cameras, and those are really the only change I’d notice.

    Mobile devices have mostly become a commodity for me. The screen is a certain size, and the camera has a quality level, but outside of this, I don’t know that I’ve noticed much of a change in how I use the device or what I notice in quite a few years. If the screen and camera are the same, one phone is fairly interchangeable with another. Even the battery doesn’t seem to change that much between phones.

    I think the same thing is true for databases for many of us. A lot of applications, and even developer T-SQL, target the basics of what a relational database platform provides. I suspect most of our needs could be served by MySQL or PostgreSQL as well as SQL Server. Apart from changing the dialect of DDL and DML we write, all those systems work well. In fact, I suspect most of what is run against the SQL Servers backing SQL Server Central could work against an older version such as 2005 or perhaps even 2000.

    Some of you use newer features. Plenty of people have learned to use Window functions and the OVER() clause. Some of you might use In-memory tables. Others certainly need Availability Groups. However, a majority of code I see uses nothing newer than a CTE, which means they could run in SQL Server 2005.

    A new version of SQL Server is coming later this year. SQL Server 2022 is in preview, and there are some neat things in there. Do you need them for your application? Perhaps you could use them, but the better question is will you actually change how you write code to use the new features? Or change how you set up infrastructure? I’d hope that many of you would, but change is hard for humans, and developers struggle as much as others. We get stuck in our habits and tend to work as we have for years.

    When is the technology platform, tool, service, or application you use “good enough” for most of your work? I don’t know, but I find myself less excited about newer tech in many cases. Perhaps because I’m old, or perhaps because my needs are relatively simple. Is that the case for your organization?

    Steve Jones

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

  • 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

  • How Hard is Kubernetes?

    We’ve run Kubernetes inside Redgate for some research projects (like Spawn) and we are building some skills running this orchestrator. At the same time, we’ve had no shortage of challenges in keeping the clusters up at times, patching, fixing issues, upgrading to new configurations, etc. Like any software, there is work involved with managing the orchestrator.

    I’ve watched Andrew Pruski and Anthony Nocentino write about containers and Kubernetes and overall they’ve made me view the clusters like email. It’s useful and I want to use it, but I don’t want to manage or administer it. I’d want some service like AKS or EKS instead. Let someone else build expertise.

    If you use containers, do you have an orchestrator running in your data center? Mercedes does, with over 900 clusters. They found value early on with container technologies and built in-house expertise within their research arm. I think a large organization like Mercedes likely can make this investment pay off, especially as they likely don’t depend on any one person to understand and manage Kubernetes. They can afford someone like Andrew or Anthony quitting and taking another position.

    The rest of us can’t really do that, certainly not without our organization feeling containers and orchestration is a core competency.

    The key for Mercedes is automation. They note that if they added 500 more clusters, they’d need just one more engineer. That’s a key for any of us that want to manage growing numbers of systems without spending a lot of our time reviewing resumes and hoping we can hire good staff. Hiring is hard, and finding good people even harder. When you find them, set them free codifying their knowledge using DevOps, scripting, automation, and more.

    Then educate others and teach them what your talented engineer is doing. Mercedes notes that finding people is hard, and educating existing people is easier. DevOps, better coding, understanding APIs and declarative scripting are not hard skills, but they are something people need to practice to develop familiarity and skill. We want staffers to be able to easily pick up the work of another, understand it, and extend or improve it. We don’t want to depend on the person that wrote it.

    The way Mercedes has attacked this technology is the way I’d have developers and administrators tackle DevOps. Take advantage of the power of modern software development and infrastructure tools and empower your staff to make things better. They are likely to enjoy their jobs more and remain employed, reducing your need to struggle with the vagaries of finding and hiring good people, a problem no one has solved well.

    Steve Jones

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