Voice of the DBA

Category: Editorial

  • Learning to Stop Being a Hero

    A few weeks ago I re-published a piece on whether we might be giving too much of ourselves for our employers. At the time I was on holiday with my family and since this was a popular piece years ago, I decided to run it again. I was surprised at the response, with quite a few individuals writing about their experiences in their current positions.

    A good friend of mine read the editorial and then sent me a link to a post by Paul Cunningham that looks at the IT hero. This talks about some of the ways in which we put ourselves out as employees. It’s a good read, and it’s certainly something to think about when you look for a new job. When I talk about finding a dream job, I’m not talking about a specific job or career path, but rather, what’s the right fit for you. That might not be the job I want, or even that your friends want. It’s the job that you’d want.

    To find your job, you really need to think about more than the work, the company, the location, or benefits. Instead, think about everything and start to rate those items against each other. A friend always tries to scale everything to some monetary value to make it easy to compare jobs. You can put a value on a 5 minute commute v a 45 min commute by thinking of the cost of time. Same for other benefits. Perhaps you can even do this in terms of future opportunities. You certainly can do this in terms of expected work week, on call time, and more.

    What you don’t want to do is let an employer take advantage of you by asking for a lot more of your time than you feel comfortable giving for the salary. Most of us are happy to pitch in when extra work is needed. I’ve seen this in restaurants, lawn care, and IT. What we don’t want to do is get taken advantage of when extra work is required on a regular basis. You don’t need to be a hero to be successful.

    Perhaps the final caveat in all of this is that you can’t control how all employers treat or view employees. Sometimes you might take a job that isn’t a good fit because you need a job, or maybe because you’re trading a poor situation for some experience. Just be sure you know you’re making that trade.

    The other thing I’d note is that finding a dream job, or maybe just a job that fits your life well, means you need to be able to compete with the others wanting that job. Work on improving your technical and soft skills to ensure that when the time comes, you are in the best position to get that job.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • 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