Voice of the DBA

Author: way0utwest

  • The Cloud Database Cost Analysis

    There is a skill that I think DBAs and sysadmins will need to develop: cloud cost analysis. I’ve thought this was important for quite a few years, and I’ve been (unsuccessfully) lobbying for cost information to be gathered and analyzed in Redgate Monitor. Hopefully, this work will get done soon, as I see more companies asking their technical people to provide analysis and justification of the resources being billed for in the cloud.

    Basecamp analyzed its costs in 2023 and decided it could save money by leaving the cloud. I’ve seen other companies decide they were saving money in the cloud. Many, however, are likely unsure of the total return they get compared to the costs of cloud computing. I have seen some posts (like this one) that try to help you get a handle on your costs, but there is often a lot of complexity in cloud costs when multiple departments have different accounts (AWS) or subscriptions (Azure) with a provider.

    In many ways, I think the large cloud vendors haven’t really considered how to support large enterprises that need a lot of resources, a lot of different administrators, and a wide variety of ways to both secure those resources as well as aggregate billing. I know we have an Azure account I didn’t create, where I have very limited rights to do things, but I can access some resources. However, my group has an AWS account that appears to be sending us billing statements instead of our corporate finance group.

    What can be even more difficult to understand is that applications using the cloud might want a complete picture of billing, but various different technical groups might be responsible for the different parts of the system. Data services could be managed separately from web servers or application servers, with different groups creating, configuring, and destroying them as the needs change. Billing, however, be something accountants would want to separate by function/area/application, not group. Knowing all data services for all databases cost $xx/month is different than knowing the retail website (containing web servers, databases, and networking charges) costs $yy/month.

    This is far different from the days when one group was responsible for most of our computing resources. Often we had a group of IT staffers who managed hardware, ordered it, and could link costs of different machines to a specific application or department. Now we often don’t have a central group who is even aware of all the resources that the company has provisioned.

    I suspect this will mean that many more technical people will not only be asked to account for the cloud resources being used, but also split out those costs in different ways, allowing people in finance departments to aggregate the different costs from the various technical groups. I don’t know who will actually track network resources, but I suspect applications will often have this data included with the servers or services that access public networks.

    Controlling costs and carefully removing unnecessary or unused resources is going to be a continual problem in the cloud. I suspect that quite a few data professionals are going to be integral to helping manage this, especially for dev/test systems that are easily forgotten about over time.

    Steve Jones

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

  • Apr 9 Webinar: Accelerating Success: De-risking and Streamlining Releases with Flyway Enterprise

    UPDATE: This moved to Apr 9

    Join me Tuesday, Apr 9 for a webinar, 10:00am CDT. You can register here and then come watch live with questions or get the recording.

    In this webinar, we’ll look at how the Flyway suite of tools can help your team better build and manage database deployments. I love Flyway, and it does a lot of things I was doing in 2001 when DevOps wasn’t even a term and we were releasing every week.

    You can do the same thing, with some of the advanced things Flyway brings to the table that you don’t have to build and maintain.

    • script generation
    • code analysis rules
    • change and drift reports
    • a comprehensive view for impact assessment

    There’s more, but join us on Thursday by registering today

    Tell your friends as well, pass this along, and bring your questions.

  • Book Review: 100 SQL Server Mistakes

    I was approached by Manning Publications and asked to review 100 SQL Server Mistakes and How to Avoid Them. They gave me a free copy of the book (and offered a second one as well), but didn’t put any conditions on my work.

    This is a preliminary review of the EAP version of the book, which is still in progress as of now. If you buy the book, you can get digital chapters as they are written and edited, as well as the final book.

    This is part of a series of book reviews I’ve done on my blog. You can see them all under the book reviews tag.

    100 SQL Server Mistakes

    The book is designed to give you 100 things that people commonly do wrong with a SQL Server instance and/or database, and starts with mistake 0 being that people think

    From there, the book goes into an explanation of the 4Cs diagrams, which are ways of representing systems. This was mildly interesting to me, though less useful when I was reading on my mobile as seeing the details of the diagrams is hard.

    The first few mistakes are on standards. Naming, prefixes, using sp_, and more. I liked this as I think that having some good basics communicate information between team members, or even users of your database for reporting. There are reasons given for why each of these is a mistake, as well as example code to showcase potential issues.

    Data Types are the next set of mistakes, showing common things people do when designing their data model or objects. There is also a few mistakes on database design with common mistakes that people make.

    There are sections for T-SQL mistakes, including error handling as well SSIS mistakes and installation problems. Each of these is grouped together with a variety of common issues that people may run into.

    The version I have of the EAP is 8 chapters, with a few more to come. Overall, this is less a what you should do, and more of a what you shouldn’t do. I like this approach. Aaron Bertrand did something similar with his Worst Practices series. Often we are stuck with certain designs, and we may not be able to implement best practices. However, we should try to avoid worst practices.

    I’d even say that if you have some worst practices, don’t continue them for the sake of continuity or consistency. Start refactoring or at least improving new development.

    This book is a good reference for beginner to intermediate SQL Server developers and administrators, and might even be a good gift for welcoming employees early in their SQL Server journey. Many of these would be guidelines I’d want to implement for  a team.

    If you’re looking for some knowledge to help you avoid producing bad code, check out this book. It doesn’t have all the answers, but it has some good thoughts on code smells and ways to correct them. It might give you inspiration to fix some code in your shop.

    If you want another view, Kevin Feasel has his own thoughts.

    You can pick up the book here: https://www.manning.com/books/100-sql-server-mistakes-and-how-to-avoid-them

  • Another View of DevOps

    Chocolatey Solutions Engineer Stephen Valdinger said, “DevOps isn’t something you do, but rather, it’s a way of doing things. What works for us here, may not work for you there, so you adjust.” He then went on to say that DevOps is a way of working that reduces time to introduce changes, while at the same time making changes traceable, accountable, and revertable.

    I’ve seen many companies try to copy what another company has done, especially with regards to DevOps and software development. I see companies copy the organization of teams from Amazon, Spotify, or others. Often quite a bit of time and effort is spent changing the way your development team works, and often without a lot of success.

    DevOps is a lot like my studies of martial arts, where you learn some techniques, but it is up to you to implement and use those techniques in your own way. While we may practice in patterns, the actual use of the skill is up to the user. That’s what DevOps really is, a goal and set of ideals you aim for, but the actual implementation varies from company to company.

    Most of us want to build better software, and most managers want better quality applications, but often we can’t get out of our own way because either too many people are resistant to change, or there isn’t any incentive to work in a better way. This might be from individual contributors or from management, but without both groups making an effort to improve the software development process and quality of code, we won’t achieve much.

    To get better at software development, whether C# or SQL, you need to read and learn about how to write better code. You need to learn how to automate the testing, compilation, and deployment of your code to downstream systems. And then you need to discuss and debate what works well, what doesn’t, and adjust how the team writes code. Not just you, but the team. We might also need to adjust how we store, package, test, and run code on other systems. We have to experiment in small ways, testing out new ideas, algorithms, designs, and more.

    In short, we need to be a team. I like the quote above, but I also hope most of you realize the “you” in that quote is not singular, but plural.

    Steve Jones

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