Voice Of The DBA podcast

—

The DORA organization is dedicated to helping others build software better and faster, at a higher quality, and in a way that is more efficient. They continue to compile and publish the Accelerate State of DevOps report every year, which is a fascinating read. As a part of the report, they have identified four key metrics that identify high performing organizations in terms of software. These are divided into two areas: throughput and stability. Throughput measures are change lead time and deployment frequency. Stability measures are the change fail percentage and failed deployment recovery time. For a long time, as I chatted with various people doing database work, it seemed that most people deployed relatively infrequently. They might deploy a couple times a week for software changes, but database changes were often less than once a week. There have always been people moving faster or slower, but that felt like the pace for a majority of people. These days, in the 2024-2025 timeframe, many people seem to be able to deploy database changes every week, often multiple times a week. Lots of people have moved to more throughput, with more frequent deployments and less change lead time. Most of us can’t get more work out of people, so if we deploy more often, their completed work gets released quicker. Those two metrics make some sense, and I think those are good measures, but not goals. What I find is that people often need to make changes quicker either to respond to changing needs of their organization or to fix bugs they’ve introduced. I wonder what the ratio is of the former to the latter? I suspect it might be less than one, if most of your deployments are fixing bugs. I don’t mind deploying software quicker, but the design, modeling, and testing can’t be shortened. The stability metrics are often high for most people I speak with about deployments. I don’t see a lot of failures at deployment time as code usually compiles and deploys. It’s often a day (or week) later that someone notices the code doesn’t do what they expect. Is that a deployment failure? I think not. What’s the MTTR if it’s fixed an hour after being reported a day after the deployment? Is the MTTR an hour or a day plus an hour? I don’t know how these metrics apply to databases, especially if data gets mangled and has to be corrected manually over hours/days/weeks. Is that in the MTTR? Can you even track it? Metrics are good ways to measure you progress or health, as long as the metric doesn’t become the goal. I’ve run into a lot of customers using these metrics to measure their development, and it does help most for a period of time. Whether this continues to help them improve often depends on whether they keep focusing on their goals of delivering better quality software faster, or they focus on the metrics. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
Is GenAI Coming Faster Than You Think?

3 days ago

—

If you’re a fan, no. You’re chomping at the bit, waiting to get everyone using GenAI models in their work. If you’re skeptical, then you might think it’s never coming to take your job, be a personal assistant, help you with coding, etc. Pick the task it won’t help you with. A more nuanced view, which is similar to mine, is from Kendra Little, in which she says AI will eliminate DBA Jobs Faster Than You Think , I’m not quite as pro-AI as Kendra, mostly because I see so many companies that are slow to change, slow to adopt new tech, slow to adjust their thinking. They just soldier on and keep running their business, as they’ve been doing for decades. Even when you might make a case for change, or prove it’s worthwhile, they just don’t spend the time to change. Make no mistake, change takes time. And time is a valuable and limited resource. Even if you don’t appreciate time’s value, many of you still don’t want to spend time on new things. In the piece, Kendra notes that she has been using an AI Agent to help get work done. She sees that agent getting better at tasks and helping her get work done quicker. At some point, she knows the GenAI agent will be able to help her do the work of multiple people. Not eliminating DBA jobs, but reducing the need. Can we have 3 DBAs instead of 5 or 10? Can we get down to 2, or even 1 with a part-time DBA service ? I do think that GenAI models and agents will help people get more work done, which might reduce the number of people an organization needs. However, I see no shortage of work in most organizations. In fact, I know of a few friends who can’t seem to hire a talented DBA. Perhaps a GenAI agent can support them and help them get work done without the need for a DBA. Not now, of course, but maybe in a year or two. However, humans still need to be in the process, and I suspect, even with an AI agent for every human, there’s still a lot of work to get done. I’m not convinced this will reduce employment. I think it could increase employment, though the bar for employees will rise. At least in some places. In some, they’ll keep doing the same thing they’ve been doing since 2001, or 1994, or 1983. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
The Inefficiencies of Kubernetes

6 days ago

—

A report of cloud Kubernetes usage shows that these resources are being under-utiliized, over-provisioned, and costing more than necessary for many organizations. From the previous year, average CPU declined from 13% to 10%, and memory is used at only around 23%. Companies are over-provisioning their clusters, which is understandable. No one wants to have systems overloaded and users complaining about performance. However, this is a similar tension to what we see with virtualization on-premises. Operations people want to leave plenty of CPU/RAM/IO headroom for systems to handle bursting or increasing workloads. Management wants to get all the use they can out of their investment and would prefer we provision systems as closely as possible to their expected workloads. Containers and orchestrators should allow a closer match, but only if there are workloads that burst enough to require additional containers and pods to be deployed. That does happen with memory occasionally at a little over 5% of containers exceed their memory, but that’s not a significant amount. Managing a Kubernetes cluster is a specialized skill and most organizations don’t have the skills or experience to do it well. My view is that if you want to use an orchestrator, you’re better off letting the cloud providers manage the infrastructure and scale up and down as needed. There are autoscaling technologies to help Operations staff better manage their capacity and costs, but this is an additional skill people need. While I do think some companies are adopting cloud native technologies and rewriting their applications to run in containers and Kubernetes clusters, I find many more companies are hesitant to adopt a very complex technology on top of the complexity of teaching their developers to work within containers for their applications. Certainly in the Microsoft space, I don’t see a lot of database servers running in containers. Despite some of the advantages of upgrades and downgrades, the unfamiliarity with the ins and outs of containers leads most teams to continue to manage the database separately. Resource matching to a workload is a problem we’ve had for years and Kubernetes doesn’t make this any easier to deal with. The cloud is supposed to help us better manage our resources, but there is a lot of knowledge needed to do this well. Add in the cost/performance issues in the cloud and it’s no wonder that many companies have overprovisioned their resources to ensure systems continue running. I don’t know whether lots of IT staffers are optimistic about their workload growth or scared of potential problems from overloaded systems, but unless organizations carefully manage all their resources, they are likely to continue to see larger cloud bills than they like. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
The End of SQL Server 2019

8 days ago

—

Well, not really the end. I doubt anyone running SQL Server 2019 is going to stop (or upgrade) just because mainstream support ended. Actually, I wonder how many of you know that SQL Server 2019 passed out of mainstream support on Feb 28, 2025. I do think the 6 or 7 of you running Big Data Clusters likely knew this was the end of any support. I saw a report in the Register on this, which includes a survey of which versions are still running. This is from an IT asset firm and matches Brent Ozar’s Population report . 44% of you are running SQL Server 2019, which is the largest percentage. Since there’s an additional 32% of you running versions older than 2019, I’m sure that upgrading isn’t a priority. It seems like just a couple of years ago that SQL Server 2019 was released. At the end of February Microsoft ended mainstream support for this version. There will still be security fixes released, but no more cumulative updates. The Register says if you don’t upgrade, you might run into a bug and not get a fix (unless you buy extended support), but that’s never worried me. If I haven’t hit a bug 5 years in (or likely 3-4years after my last upgrade), I’m not too worried. If I run into something it’s likely from new code and I’ll just change the code to work around the issue. I do expect to run a database platform for a decade, and I am glad that Microsoft continues to supply security patches for this period. While I certainly want every database firewalled, reducing the attack surface area of known vulnerabilities is good. I also find myself less concerned about the security of older versions. If there is a big security vulnerability discovered in 2017 tomorrow that exists in previous version and I had a 2012 server, I’d just prioritize an upgrade then. Upgrades are hard, eat a lot of valuable time, and don’t necessarily provide many benefits. Most applications tend to use basic CRUD features and whatever was available at the time in that version. If I use a tally table to split strings in 2017, I’m unlikely to rewrite that code to use STRING_SPLIT with an ordinal if I upgrade to 2022. That certainly isn’t a selling point for me to upgrade. My boss knows that isn’t something we’d take advantage of in older code. I’m not a bleeding edge person, and I wouldn’t push for upgrades. If you want to stay somewhat current with versions and are running 2019, I’d be waiting to test my application on SQL Server 2025 at the end of the year or early 2026. If I were mandated to stay current, I’d still be doing that, not jumping to 2022 right now. However, I do recommend that everyone patch their systems with cumulative updates to ensure their security is up to date. There have been several security patches in the past few years that you should have applied and if you haven’t, this is a reminder to do so soon. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…

1
Monoliths and Microservices

10 days ago