Voice of the DBA

Category: Editorial

  • Waking Up to No Support

    When you wake up on July 10, SQL Server 2008 and 2008 R2 will be out of support. Microsoft has been talking about this for some time, there’s been a Migration Tour from PASS with live events in quite a few cities, webinars, and more to let you know that you might want to upgrade to a supported version.

    While I typically think that systems that run are fine and don’t necessarily need support, there are compliance and security concerns here. If you work in a regulated industry, you might need support to stay compliant. If that’s the case, you might want to ensure you have plans to move to SQL Server 2017 (or 2019) soon.

    The same goes in this era of attacks and potential security issues. While SQL Server has relatively few patches for security, you never know. I haven’t worried about this in the past, often with internal servers, but I do get more concerned over time as we seem to constantly find more complex bugs in hardware and software.

    SQL Server 2008 support is over, but you have options. Microsoft will continue to support you if you move your servers to Azure. That’s not a bad option if you need to move quickly, but don’t forget to really think through what this means for your applications. Moving to Azure isn’t necessarily as smooth or simple as you might think. Authentication and authorization need some attention to detail to get working well. It’s not hard, but it is work.

    When SQL Server 2005 went out of support, it didn’t seem there was as much emphasis on migrating. Certainly lots of people ran SQL Server 2000 instances for many years without support. You can do it, but the world feels more dangerous, and there are more implications with regard to regulation, security, insurance, and other complex topics that can impact your business.

    Think carefully about the implications of migrating and not migrating. You’ll have to make the decision, and it can be hard, but it’s something you should spend quality time thinking carefully about.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Clear Cloudy Future of Databases

    One of the things I’ve advocated across the last few years is the need to learn more about the cloud and be aware of the database options. I have written many pieces, including asking the question of whether or not you should be thinking cloud first. More and more companies are thinking that way, as you can see in the revenue growth from Azure, AWS, and GCP. This is a trend that is continuing to grow and I doubt it will stop anytime soon. I see many management and technical people more interested in the cloud than worried about it, and the numbers of adopters continue to grow.

    Gartner is a source that many organizations use to try and plan for trends in the world. With much of our choices sometimes impacted by technology media, plenty of managers look at their reports. One of Gartner’s latest reports is worth reading the short blog summary: The future of database management systems is the cloud. In this blog, Donald Feinburg summarize their report that the cloud is first, it’s the future, and that only legacy requirements should keep you on-premises. I tend to think that as well, though I think your investment in an existing platform is reason enough to stick with it for now. I also think that very predictable workloads, without any large spikes, are likely worth keeping in house.

    One neat thing is the market share trends of various platforms from 2011-2019. Microsoft comes in at #3 to start, but comfortably in #2 for the last few years. If you look closely, you’ll see AWS has grown to take the third spot from IBM, and Google is growing rapidly for a platform with the fewest years of availability. Looking at some of the others, I see downward trends from a number of on-premise vendors.

    The cloud offers amazing flexibility in both cost and performance. If you’ve looked at any of the cloud database platform vendors, they offer great scaling options for those times when things run fast  or slow. We have a customer at Redgate that actually scaled up their Azure SQL Database for a few hours to meet a workload jump. Going from tens or hundreds of dollars per hour to thousands isn’t for the weak of heart, but if it’s just a few hours and you scale down, that’s the flexibility that isn’t available on premise. At the same time, scaling down when you were overly optimistic about a workload can save a lot of money.

    Whether you like the cloud or not, it’s permeating many organizations, and it’s a skill set you should spend time learning. After all, even if this employer isn’t interested, there’s a good chance that the next one will be.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Building Helpful Commit Messages

    Using a VCS (Version Control System) is important in any modern software development environment. I still can’t believe that both application and database developers are using a VCS at less than the 95% level, but surveys constantly show this. I’m not sure if this is because of laziness, ignorance, stubbornness, or something else, but it’s a bad idea. Start using a VCS. Talk to your management, and let them know Git is free and can be run on premises, much like a file share for code, except it’s better.  Even if you hand craft scripts (or use the SSMS GUI), just start saving those scripts in a VCS.

    There are lots of tutorials and examples of how to use git (or any VCS), and this is a skill you want to build over time. To start, just learn to build a habit of committing code to the repo as you make changes. This is fairly easy, but there is one skill you need to develop over time: how to write a good commit message.

    When we commit code, we usually need to enter some comment. This is a bit of an art, and should be designed to quickly convey information to the next developer (who may be your own future self). While people may have their own view on what to include, my thought if usually to include the “why” of the commit. This helps me to go back later and understand what I was thinking. I don’t need “what” was changed, because a quick diff of the file will explain that. If possible, I like to relate a commit to a specific request, like a Work Item, a help ticket, or some place that describes the requirements in more detail.

    I ran across a nice post that describes the art of the commit, and I think there are some good ideas here. Certainly being brief and understanding that often your message is a headline is good advice. The most important parts of the post, for me, are the need to understand that I’m working with others, and it’s important that my message help them and vice versa.

    Learning to use a VCS is a critical skill for anyone working in the technology field. We know most application developers need this, and slowly I find more database developers doing the same. However, as we move to GitOps and Configuration and Code, as compliance becomes more impactful with more auditing requirements, as we try to do more with less, the infrastructure staff and others need to learn how to capture their changes in a VCS as well.

    Do yourself a favor and start learning how to use a VCS. Git makes it easy or you can play with Azure DevOps in the cloud. Just start saving some files and building skills. Your career will thank you. Learn to write good commit messages and your team will appreciate you.

    Steve Jones

     

  • More Linux than Windows

    Not for me. I definitely have more Windows running than Linux. Well, at least if you count minutes. If we’re counting instances of kernels, there might be times I have more running with Linux kernels in containers. However, on most days I have 1 or 2 Linux systems running and 3-4 Windows ones.
    That’s not the case in Azure, where the majority of instances are on Linux, not Windows. Microsoft announced this recently, noting that the use of Linux is growing for them. If you follow their work in the development area, this isn’t surprising. They are doing more and more OSS integration with their products or with other work. We have VS Code and Azure Data Studio, as well as .NET Core, running on Linux.
    We’ve had PowerShell on the Windows platform for over a decade. In that time, it has improved and grown, and become a default way for many people to manage their systems at scale, or certainly, in a consistent way. I’ve been surprised with how pervasive PowerShell has become. That’s why I’ve been surprised in the last year at //build/ and other conferences when I see Microsoft employees promoting bash as the new thing.
    I have nothing against bash, though I was more a korn shell person in University. I do like working in it at times, and I find myself doing that more and more. What I don’t like is a push away from PowerShell, especially as I’ve just started to get comfortable with -eq and -gt. I hope that as Microsoft moves towards more Linux versions of tools that they continue to keep PoSh as a first class citizen, on all platforms.
    Linux lost the desktop war. I’m pretty sure that’s the case, as I haven’t seen a Linux laptop or desktop in years. I see lots of MacOS, but more Windows, especially with the amazing hardware advances manufacturers have made in the last 4 years with the 2-in-1 format. However, I start to wonder if Linux will win the server war, or at least, become a much larger percentage of the back ends in the next ten years. I think it might, handling .NET and SQL Server loads in many cases.
    Steve Jones