Voice of the DBA

Author: way0utwest

  • 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.

  • T-SQL Tuesday #116–Always Linux

    tsqltuesdayThis month is an interesting invitation from Tracy Boggiano. It’s on Linux, which I like. I hadn’t thought about this in terms of T-SQL Tuesday, but I think it fits and more than that, I think Linux will be the future of the backend data platform from Microsoft. I’ve said it in a few presentations, and I think we’ll get there in 10 years.

    In any case, I wanted to write about how I use Linux and SQL Server.

    Containers for Work

    One of the technologies that I see gaining a foothold in many companies is containerization. More and more developers are using containers, and asking for their databases to work in containers. At Redgate, we’ve been investigating this and are looking to build solutions that will use containers.

    As a result, I’m experimenting with SQL Server in containers on my laptop ad giving some presentations that share the way in which they work. I’ve written a little at SQLServerCentral as well as on this blog.

    In setting up my laptop, I installed Docker and experimented a little with Windows and Linux containers. I’ve standardized on Linux containers, because they’re more mature for production (Windows containers are in preview now), and I think with Kubernetes and the growth of how the SQL Server 2019 Big Data Clusters will work, I expect more Linux for servers in the future.

    I’m also using this as an opportunity to brush up on some bash and Linux skills, connecting to my containers with the –it (interactive) switch, as well as using the Windows Subsystem for Linux.

    It’s slow learning, and it’s interesting trying to juggle things in bash and PowerShell at the same time, but I expect these skills will become more hand in the future.

  • 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

     

  • Learning More about Kubernetes (K8s)

    I know a bit about this, but I’m always looking for more. I had the chance to see Brendon Burns recently and I was impressed. That is one seriously smart dude. In any case, I saw a link from Microsoft: 50 days from zero to hero with Kubernetes. It’s at this link: aka.ms/learnkubernetes

    I decided to dig in a bit, because it’s a complex subject in some sense and going through some resources can help solidify how this works.

    Day 1

    It’s a children’s story of a visit to a zoo, with an attempt to explain what pods, replica sets and other items. The first few items made sense to me since I’d worked with K8s slightly before.

    However, as the story delved into more complex subjects, like Ingresses and Daemon Sets, I had a vague idea of what ese were, but not really. I’m not sure I could explain back what some of these do. I hope future days will help me understand.

    Day 2

    Day 2 is a video on Containers from Brendon Burns. He talks about the history of VMs and then lightly on what a container is and how this fits together. Since I’ve watched some of Nigel Poulton’s courses at Pluralsight, this makes sense and reinforces what I know. It also gives me another way to explain things.

    However, for others, I wonder if this makes sense to them. It’s a very high level, but fast view of containers. Worth watching if you want to know more.

    I’ll continue on with the series as I get time, likely a very sporadic look at this technology.