Voice of the DBA

Category: Editorial

  • Common Algorithm Concerns

    When we build software, many of us use the same algorithms to solve problems. We might choose a similar method for a quicksort or a lambda validation or a regular expression. For database work, your code for a running total (or other common challenge) is likely very similar to many other people. At least on the same platform. You might solve this differently in SQL Server and Oracle, but for the same type of database, many of us write very similar code.

    Actually, many developers might copy and paste an answer from SQL Server Central, Stack Overflow, or another site. I’m not sure if I think this is good or bad, as it’s a good idea to reuse code if it solves the same problem. If you copy it and don’t test it, that’s bad. After all, the code might not solve your slightly different problem if you don’t check it.

    In the modern world, if we build software for our business using an AI assistant, could our company be liable if we knew our competitors were using the same AI service? Is this any different than a human developer performing a copy/paste from SQL Server Central? I don’t think it is in many cases, though the same concerns about intellectual property might be present in either case.

    The concerns over AI seem murky in some sense, especially as the AI might “generate” code that isn’t directly available on some public resource. I do think that this is more of a collusion using a service than an algorithm. Still, in the hyper-connected world, where many of our applications might look to take advantage of some service instead of implementing it ourselves, this could be an issue.

    I ran across a piece that discusses a lawsuit about a common pricing algorithm being used by different hotels. In this case, it’s not that the developers at different hotels used the same code, but rather that the hotels used the same service from a company, which of course, used the same code for all their customers. Whether you think this is a valid lawsuit or not, this is the type of legal action that others might bring if two competitors ended up using the same AI service and developed very similar code that might behave the same way.

    I don’t think that AIs (at present) can actually develop new algorithms or solve problems in a new way. Instead, they predict the likely solution based on how they’ve been trained by similar scenarios. In that case, how concerned are we about how getting common solutions in disparate pieces of software? For most of us, I think we’ve be pleased that we have well-tested (hopefully) code that runs efficiently (again, hopefully) being re-used in many places. That would be better for most systems in the world.

    What isn’t better is if humans become more adept at specifying prompts and producing software without lots of specialized expertise. For many developers that might be average, or even slightly below average, this might cause them concern for the security of their position. With good reason, as labor is one of the most expensive parts of building software.

    Ultimately, just as with any other position, the best way to build a safe, secure career, is to continue to build your skills and produce value for your employer. That way it’s unlikely any AI will ever outperform you.

    Steve Jones

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

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

  • Managed Instance Impressions

    Several years ago, I heard about a new product coming in Azure that would provide an IaaS (infrastructure as a service) VM to run SQL Server, with Microsoft managing most of the admin tasks for the instance, like patching and backups. That didn’t seem like a big load to me, and I wondered if anyone would actually pay for this product. After all, don’t most companies find managing patches and backups fairly easy to manage?

    That product became Azure SQL Managed Instance, and I’ve been surprised at the adoption. Quite a few clients have adopted this as a way to lift and shift (mostly) to the cloud in an easy fashion without the restrictions of Azure SQL Database. This looks like a “normal” on-premises SQL Server, and there are both high-performance (Business Critical tier) and average-performance (General Purpose tier) versions of the product that let you choose what level of price/performance you need to achieve.

    I’m curious today, and I have a question. What are your impressions of Managed Instance (MI)? Whether you use it, you have heard of it, or if you just read this description. Give me a few thoughts on whether this makes sense, performs well, or has issues you need (or wish would be) addressed.

    I’ve heard there are some issues with I/O, but I also have clients who find it performs very well for them. I hear similar things from on-premises SQL Server instances, so I often think that either the software is designed well or the hardware architecture doesn’t match the workload. There have been a lot of enhancements to MI since its release, including the ability to backup and restore to/from SQL Server 2022.

    There is even an offer from Microsoft that lets you try out MI for free (for a period of time). This is a way for you to test migrate a database to the cloud and measure the performance. You might need to do some work to measure your current performance in a way that lets you determine how MI stacks up. You will also need to do some financial number crunching to decide whether there is an ROI that makes sense. If you do that, be sure you reach out to your internal finance people to understand the differences between CapEx and OpEx expenditures for your analysis. Paying $50k a year for an MI license isn’t the same as spending $50k for a server and hosting.

    I’m not sure what I think of MI. Like many offerings, I think there are places where it makes sense and places where it doesn’t. It’s not a simple decision for me as an abstract question. For specific situations, I might lean one way or the other, but I’d want to do some workload analysis to justify or discard my initial thoughts.

    Share your thoughts and impressions today. You might help some of us learn more about why we might or might not use MI. You might even help clarify your own thoughts by writing them down.

    Steve Jones

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

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

  • The Costs and Rewards of Speaking

    Most of the people I know who speak at a SQL Saturday or user group aren’t paid for their efforts. At many of the community events, the speakers are volunteering their time. Many are also paying for their own way to those events not located in their area. A few, such as me, might get a company to cover their travel expenses, but often this doesn’t include time. If I attend a SQL Saturday, I still have a bunch of work on M-F that needs to be done. No comp time for these events. That being said, I’m happy to donate some time and money to community events.

    Some speakers build and teach full-day sessions, usually called pre-conference sessions, for which they are paid. There can be competition at large events like the PASS Data Community Summit and SQL Bits to get a session since the payment can be rewarding. I’ve seen some speakers make USD$1k or so, which can cover travel expenses, and others make over USD$10k, which is a nice payday.

    Most of us don’t want to teach a full day of sessions, usually because it’s a lot of work to build a day of training. It’s also very nerve-wracking to try and teach people who have paid you. A lot of speakers don’t really want to deal with that stress. I’ve done it, and it is hard work. I don’t deliver pre-cons at events because I get expenses covered at lots of events and prefer not to compete with others who might want to earn some money while growing their careers.

    However, lots of people want to share their knowledge and teach others something useful. It’s been amazing to me how many people have stepped up to submit sessions and present them at events all over the world. I’ve been lucky and honored to meet many of these volunteers and call them friends.

    When Andy, Brian, and I started SQL Saturday, we weren’t sure there would be enough speakers to run 10 events in a year in 10 cities. At the time, the PASS Summit and a few other conferences were the only places to speak outside of user groups and we weren’t sure there would actually be enough people in a community willing to speak to run a conference. We also weren’t sure that many people would travel outside their home area to speak.

    I’m thrilled we were wrong. So many people have volunteered their time and energy to build a session and then deliver it at user groups and local events that there are often more speakers than spaces available for them. I’m also glad that so many of you attend and support local events.

    Speaking can be intimidating, but I know many of you can do it. It’s scary, and it’s something I never thought I’d do when I left university. It is a lot of work, it interrupts your free time, and it doesn’t pay you any hard currency after a session. However, it’s also thrilling to help others, exciting to have them listen to you, it hones your communication skills, and it is impressive to employers. On balance, I’d say that even delivering a presentation at your local user group is a profitable endeavor and a memorable experience.

    I hope we continue to see more of you willing to deliver a session for your peers, share some of your knowledge. I also hope that we see more of you stepping up to help organize a SQL Saturday or another local event in your community.

    Steve Jones

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

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

  • Invisible Downtime

    This article has a concept I’ve never heard about: invisible downtime. This is the idea that there are problems in your application that the customer sees. Your servers are running, but the application doesn’t work correctly or is pausing with a delay that impacts customers. From an IT perspective, the SLA is being met and there aren’t any problems. From a customer viewpoint, they’re ready to start looking at a competitor’s offering.

    Lots of developers and operations people know there are issues in our systems. We know networks go down or connectivity to some service is delayed. We also know the database gets slow, or at least, slower than we’d like. We know there are poor-performing code and under-sized hardware, running with storage that doesn’t produce as many IOPs as our workload demands. We would also like time to fix these issues, but often we aren’t given any resources.

    The current buzzword among executives and senior IT leaders is observability. It’s the goal of looking at how our entire system, application, database, and network, are linked and performing with an eye on improving performance. Not because they want to spend time or money here, but because customers are becoming more fickle and quick to move to another offering. Leaders know that degraded application performance (another phrase for invisible downtime) can have real bottom-line impacts on revenue.

    There are a lot of products in this space, application performance monitoring (APM), designed to look at lines of code and determine how well each is performing. They can help you spot issues in application code, but they lack insight into database and network details, at least at a level that the experts need. As a result, digging into performance issues and root cause analysis of problems usually means pulling data from multiple sources and correlating log entries.

    This is likely an area where AI/ML technologies can help, especially across large estates, though I think in many cases, what we need is just a pointer to poor-performing code. C#, Java, SQL, whatever. We need to know where the bad code is and then we need to train developers to write more efficient code. That might be the best way to improve application and database performance.

    Steve Jones

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

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