Voice of the DBA

Category: Editorial

  • The Selfish Case for Learning AI

    I ran across this article on a survey about AI usage recently. The headline is this: 55% of businesses admit wrong decisions in making employees redundant when bringing AI into the workforce.

    That sounds a little ominous for those making these decisions, and a lot of you might be saying, “I could have told you that. Using AI to replace people is a bad decision.” On the surface, I agree. I dislike the idea that companies will opt for a semi-competent AI bot or agent to replace people, thereby further exacerbating the challenges faced by many workers in the modern world.

    However. 55% means 45% didn’t feel that way. That’s almost a coin flip for executives who want to make a decision about whether to terminate some employees and replace them with GenAI tools, especially workers who might do things like customer service or tasks that are narrower in scope and “seem” like good fits for an LLM.

    A lot of the stats in the piece are presented in a way to paint AI as risky, but the numbers are often less than 50%. To me, I worry that this is a bet executives might make. Especially when this might result in a bigger bonus or dividend for them personally. I never discount the selfish nature of executive decisions.

    So, what is my selfish case for learning AI if I might get replaced? The big number is this one: “…80% of business leaders plan to reskill employees to use AI effectively…” For me, in my job, I want to be one of the people execs see as effectively using AI.

    I need to spend time learning how to, and how not to, use AI tools. They can be helpful, but they can also cause problems. I need to examine where they help, how much time they save, and when to abandon them and just handle a task myself. That last skill might be the most important. I also need to ensure I learn to work efficiently with the tools to save time and become more effective. That takes some effort and focus to learn to use the tools well.

    There are always going to be executives who will make the decision to let someone go. Your (selfish) job is to ensure that you aren’t the one chosen.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Reducing Cloud Cost

    Cloud costs are high and growing. Some orgs think they’re out of control and are trying to limit spend. Some orgs are looking to leave the cloud. A lot of IT spend over the years has been seen as a cost center, with many executives trying to limit the growth or spend, even while they aim for digital transformations of their businesses. Throughout my career, it’s been interesting seeing the tension of groups trying to take advantage of technology and the finance departments trying to manage costs.

    The cloud brings some of the same debates/arguments/concerns to the forefront. Partially because of scale, as we can add cloud resources much quicker than we can with a CapEx purchase. Partially because we’ve also often lost some control over budgeting with the move to OpEx and the subscription paradigm.

    However, the bigger problem is that we get a true chargeback for all the resources we use. This is done in a way that exceeds what I used to see with mainframes. In those days each department got a monthly report of their usage, applied against their budget. In the cloud world, finance gets a real bill they have to pay, and the chargeback is not a made-up number for internal use.

    How can you reduce the cost in the cloud for your database (or all data) resources? The easy answer to start is to get rid of those resources that aren’t being used. How many databases have been created for dev/test and aren’t actively used? That’s often an easy chore, and one that could be scripted. Though I’d want to include backups of anything I get rid of that might be reused. That might include dev systems rarely used. Keeping a backup that I can use to restore to a new resource later is always a good idea.

    In line with this, you might look for underutilized instances, especially for VMs or expensive services like Managed Instances. There can be a cost overhead for these systems, and if every application/department/etc. uses a separate system, there might be cost savings from consolidation. However, don’t just move databases. Ensure you aren’t creating a security risk or overloading the system with moves. That requires some analysis of the current systems and buy-in from those with security concerns.

    However, the biggest win in reducing cloud cost is to performance tune your code. This is something many DBAs request on a regular basis, but often there isn’t any push to write better code, or utilize better patterns of querying that might reduce the amount of CPU, memory, and network traffic. Learn how to write better performing queries, limit the data returned (no SELECT *), watching out for datatype conversions, and using other techniques that people write about at SQL Server Central every day. We constantly answer questions and publish articles on better ways to write code, so invest the time to ensure your teams can and do write better code. Make sure you train your staff and they use their training.

    Lastly, you are in the cloud because you’re willing to change how you work. Don’t be afraid of changing your existing code. If you refactor and break something, change it back. The cloud makes this easy, so take advantage of that and keep improving your code.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • DevOps is DevOps

    DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code.

    That last one only comes if you use testing and try to ensure your code is well-written. It’s easy to just use DevOps to throw out more poorly written code that doesn’t perform well.

    Recently, I went to a presentation on Fabric CI/CD, looking to see if I could learn something about how you might handle Fabric in a DevOps software development flow. What I came away with was the idea that DevOps is really just DevOps. In this case, Azure DevOps was being used to orchestrate the CI/CD flow, and the pipeline looked the same way as one I had set up for a relational database.

    There are differences, such as the need to have multiple Fabric workspaces and a need to understand how the code is stored and managed in Git, but the idea is the same. We use a build step to verify that any code changes can be successfully compiled and that those changes can be deployed to a new location. A workspace instead of a database, which means the automation doing the work is slightly different, but the process is the same.

    Testing? You want tests to verify that the code does what is expected. A lot of people skip testing with data, but I’d argue it’s as important in Power BI or SQL Server as it is in C#. We ought to include tests, not because we don’t know how to write code, but because others might maintain/extend/refactor our code, and we want their changes to pass our tests. Again, the details are different, but including a step to run tests is still there. The same idea.

    Using a flow to approve and deploy changes between environments? This is no different, and having an automated process reduces the effort, time, and risk of mistakes. This is again the same, though the details are different specifics because the automation is different. Deploying a semantic model is different than pushing out a new .exe or running database changes, but the idea of an automated deployment is the same.

    We, as an industry, have learned over time how to better move code through a software development life cycle. The ideas work for data-based projects as well, and we ought to be learning and adapting these to ensure we can be just as agile as application software developers.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Can/Can’t Do/Don’t

    The other day, I asked my daughter if she wanted me to make her some eggs. She responded with a “Yes!” in text and came to sit up at the counter while I cooked for us both. We chatted a bit, and at one point she said, “Thanks for cooking, but it’s not that I can’t cook.”

    I laughed a bit and responded with “this isn’t a can/can’t situation, it’s a do/don’t or will/won’t one.” I know my girl can cook; I made sure all my kids learned how to cook. It’s that they often choose not to, hunting for leftovers, going for takeout, or skipping meals.

    I’ve never been one who likes to hear “can’t” from anyone. Even today, when I coach kids and one say “I can’t do that,” my response is “yet. You can’t yet.”

    It’s easy to think that because you don’t know how to do something, or don’t have confidence, or you’ve not done it well (or right) in the past, that you can’t do it now. That could be true, but often I find people default to “can’t” when they really mean they don’t want to do something or won’t do something. Easy to confuse those, and easy to brainwash yourself when using the wrong words too often.

    There are things I can’t do. For example, I can’t run a 10.0s 100m dash. I can’t dunk a basketball, though there was a time I could. However, on the ranch or at work, I rarely find that I can’t do something if I apply myself with a little curiosity, effort, and experimentation. I can learn most things and do them well enough to meet a goal. Someone else might do them better, but I can learndo them.

    I see too few people in the world who aren’t curious at work, aren’t willing to put in extra effort to get a task completed, or don’t feel an urge to tackle tasks outside of their comfort zone. I see fewer people dedicated to making an effort to learn outside of work time, whether on their own or at an event like a SQL Saturday.

    Most of the people I see succeed and thrive in jobs aren’t smarter than others. They just do the work. And if they don’t know something, they teach themselves what they need in order to get the job done. They drive themselves forward.

    Life is hard, but it gets easier when you want to put in effort to make it better.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.