Voice of the DBA

Category: Editorial

  • Serverless Databases

    I wrote about serverless applications recently. Not a lot of people are using serverless technology for their code, but a few have had a lot of success. It seems like a move that makes sense, though there are some challenges in managing the code when you deploy functions or snippets instead of an entire codebase. I worry a bit about tracking billing, usage, versions, and deployment pipelines with serverless, but I know things will get better over time.

    Now Microsoft Azure has included a new option for databases: Azure SQL DB Serverless. This is a SQL Server database that bills you for the compute cycles used by the second. This works by essentially pausing your use of the database processing when clients are not accessing the system. You are still billed for storage all of the time, which makes sense, but storage is cheap. The system also has quite a few automatic scaling features, many of which aren’t as simple to understand as I might hope.

    How many times have you purchased a server (or rented one) and found it is barely used, trundling along at 10-20% CPU? I’ve done that quite a few times, especially when I had no idea of the workload early on. Later, it’s often not been worth my time to try and consolidate the database on another machine. Often this is often a fear based response where the cost of the machine is already gone, and I don’t want to take the chance that a burst in workload will overload another system.

    For sporadic use applications, serverless databases might be a good fit. I can avoid paying for compute during low periods, such as overnight. I’m essentially renting a machine at specific times and not at others, but the compute layer gets provisioned as I need it. That seems like the ideal situation for a lots of apps, assuming I can run them in the cloud. There are some restrictions in preview, such as the inability to pause the system unless there are 6+ hours of no activity, but I’m hoping that changes. Six hours seems like a long time.

    The one thing I think about this database service is that it will require longer timeouts and more resilient applications that can handle a warm-up period if the computer layer has been shut down. I also worry a bit about cache and the buffer pool. If you’ve ever dealt with servers that regularly restart, there is a bit of a slow period as the buffer pool fills and code is compiled. Perhaps Microsoft has ways of saving off some of these states, perhaps capturing plans in the Query Store that can avoid excessive compilations on restart, but I do worry that slow starts will increase user complaints and tickets filed. Those costs might not be worth the savings from shutting down your database resources.

    Steve Jones

    Listen to the podcast at Libsyn

  • Republish: Where Do You End Up as a DBA?

    Traveling to the City of Angels today. Read: Where Do You End Up as a DBA?

  • Communicate Smarter Not More

    I recently installed Microsoft Teams. Not because I wanted to, or because Redgate is abandoning Slack, but because Microsoft requires it for some MVP calls. This replaces Skype for Business (S4B), and while it worked OK, I’m not sure it worked better. In fact, for the use cases I have, Teams feels like an abandonment of the Skype codebase for a newer version of the same thing. That’s fine, and I don’t really care. It’s slightly annoying as I have S4B for internal stuff at Redgate and didn’t need another tool, but with a modern, quad core, 2.xGHz CPU and 32GB of RAM, one more application isn’t going to break anything. It is, however, making me less productive.

    We have lots of ways to communicate. In fact, I have Twitter (social media), Slack (work comms), Outlook (email), S4B (calls) and a mobile phone all running as I write this. I don’t get too caught up in any of them, and I have most notifications disabled, precisely for the reasons outlined in this article: the tools can be a productivity drain. I know this, and most of these tools actually live in the background, behind the various tools I use to get work done. I check them at times, but try to stay off most of the day. I need to focus, and having more communication methods is distracting.

    There was a day not too long ago when I needed to find a person that had missed a meeting time. Messages went out through Slack DMs, Twitter DMs, text, Skype IM, and email, hoping that a notification would pop up for someone on some app. I know I’ve used Slack like a PA system at times, pinging other people to go find someone that wasn’t responding to messages. For someone working remotely, it’s frustrating to try and reach out to others, but I’ve seen people in an office take the same tactic, reaching out electronically, which often creates more interruptions and distractions for others. I don’t know if this is that much worse than walking around an office and physically interrupting others, but I do think it can be more pervasive as too many of us have constant notifications on devices that don’t go away when the workday ends. We also do it more, because it’s so easy. Getting up to walk around is a bar that deters some people from interrupting others.

    What might be even harder to deal with is the linkage of various applications together. Now I see GitHub messages in GitHub, Slack, and Email. It’s a barrage of items that aren’t hard to handle, but they each take away a little bit of time and attention.

    That’s the downside of communication methods. Each requires a little time, even if just to click/swipe/eye roll at a notification. Those little bits of time add up and don’t necessarily help us be more productive. Some things require too much time as I’ve watched people look through and consider just the right emoji to use for a reaction on Slack. Most of the time I think there should just be a couple choices, because the richness of the variety equates to the decline of quality time spent on work that needs to be done.

    We constantly hear that communication skills, those soft skills of relating to others and exchanging information clearly, are important. They are, but I think there is another element to communicating well: brevity. Learning to communicate effectively, in a way that allows you yo get your message across quickly, while also being able to focus for long periods of time is a skill more of us need. Being able to turn off distractions, or delay responses when quickness isn’t needed will help you be more productive and efficient. I think one of the interview questions I’d ask in the future would be around how to deal with the constant barrage of Slack/Teams/Skype/Outlook/Github/whatever-comes-next messages.

    Do you know how to reduce the overload of communications in your job? Let us know today.

    Steve Jones

    Listen to the podcast at Libsyn

  • The Impediments to Change

    SQL Server is releasing a new version of the engine every 12-24 months at this point. That puts pressure on all of us to learn constantly about the changes. Even if we don’t look to upgrade all of our existing instances, we can’t buy older versions when the new one is released. Often many of us would like to install the latest version for new systems, but that isn’t always possible. If we can, then we have a new version to support.

    Recently I was reading ArsTechnica and they posed a question about the impediments to adopting new technology at work. Their query was in the form of a survey, and they’d like you to answer if you can. I took the survey, and I thought it was a bit vague in some sense, mostly around networking and communications rather than other areas, but perhaps that’s their focus.

    In any case, it often can be difficult for some companies to decide to upgrade their database servers. Licensing cost is a real concern, and while it pales with the cost of labor, I am not sure I’ve seen many features that would actually reduce labor costs significantly. Most the features might make some aspect of development easier (or quicker), but often we have solutions or code in place that we don’t want to spent time changing. Upgrading older platforms is also a nebulous proposition. The improvements in HA/DR, quicker data loads, and more might be worth changing versions, but the capital cost can be hard to justify. Deciding to install the latest version for a new server isn’t necessarily going to reduce any labor costs, and it could increase them, since staff now needs to understand the new platform.

    Perhaps hardware inhibits you from making changes. Is there a point in upgrading from SQL 2008 to SQL 2017 for working applications if you don’t change hardware? Is it worth buying modern hardware? Glenn Berry would argue yes, but not everyone agrees, especially in upper management. This might even be true in upgrading minor parts of your existing system. Can you add RAM? Cores? Does your storage subsystem ever receive improvements? While hardware is certainly a capital expenditure, small changes could make big impacts to users, despite the reluctance to invest in older systems.

    Are there other reasons you don’t upgrade? Is staff knowledge an issue? Perhaps you have concerns about support personnel having to work with new systems. There might even be other reasons to avoid change. Time might be the biggest one with people busy on other projects. If you have some thoughts, drop a note in the discussion today. I’d be especially interested if you have Software Assurance and don’t regularly take advantage of that to upgrade. We’d also love some short articles on your experiences upgrading if you’re willing to write about them.

    Steve Jones

    Listen to the podcast at Libsyn.