Voice of the DBA

Tag: DevOps

  • DevOps and Security

    DevOps is a buzzword these days, and like many of the hyped concepts written about, it has a lot of meanings. There is this idea releasing software more often, using automation, having various groups talk to each other, and more, all of  which we might see as common sense. However other DevOps ideas, such as releasing more often (with potentially less review), being willing to break applications and fix them quickly, having developers able to release code to live, production environments, these don’t seem to be ideas that would enhance security for most organizations.

    However, that’s not necessarily the case. Security and DevOps practices aren’t necessarily mutually exclusive. I ran across a piece from the security perspective, looking at some of the ideas in DevOps that can actually enhance security.

    Writing more code, especially around the configuration and infrastructure, allows versioning, auditing, and more that can ensure we have fewer mis-configured systems. Adding some Desired State Configuration (DSR), with some automated testing of this code, could ensure that the changes made don’t open up security holes. Or, at least, allow us to determine who made the change and when the issue appeared. These are important for understand security risk.

    There are also the ideas of measurement, metrics, and feedback, which are important for ensuring security. After all, anomalous behavior should be investigated, as this could be a sign of intrusion. For databases, it’s especially important with the large number of clients that connect to our systems. Adding DevOps style monitoring can allow us to determine if a workload is normal, or perhaps a sign of intentional, accidental, or malicious data query activity.

    I enjoyed the piece, and I’d recommend you read it. Plus, whenever I see “snowflake” in an article, I think of Grant and want to read further to see how someone else has used the same analogy he does.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • What is DevOps?

    There is a lot of confusion in the world about DevOps. Some of that might be because the concept hasn’t been well defined, or implemented, in many organizations. It might also be because other companies have been running as DevOps organizations for years without having a name for what they did and no good way to talk about their practices as a whole. Plenty of those efficient organizations resent having DevOps presented as a “new” idea when it’s been their modus operandi for years.

    I an across a primer on DevOps that I thought was a good explanation for management. It’s not perfect, and the piece minimizes the problems of changing culture and attitude. There is an emphasis on breaking down barriers and silos, but no discussion as to how managers should do this. I think most people expect managers to know how to get teams to work together, but in practice, I have found few managers that could do this.

    There is no magic to DevOps. There isn’t a tool you can buy, or a consultant that you can hire to implement it. All you can do is get help and guidance in helping your staff to learn to work more closely together. Developers have to learn to consider the operational impacts of their work, while formalizing some of their processes. They need to automate their testing, but also the packaging and installation of their software, while working in standardized environments. Operations is the flip side of this, in that Operations staff must be responsive and quick to build the standard environments developers need. They must work with developers to feedback issues and requirements from Operations to the developers, including bugs that can be caught with changes to the automated testing processes.

    DevOps is about working together. With respect and professionalism, but also the attitude that we can help each other do our jobs better. This impacts our compensation and reward systems, as well as organizational structures. I wouldn’t underestimate the impact this has on the way an IT department works, but I also wouldn’t be afraid of the changes. However I would move slowly, evaluating the impacts as processes change, and working to assuage the fears and concerns of your staff.

    Ultimately DevOps, in my mind, isn’t about saving money or getting software build faster. It’s about working together to become more responsive to our clients as our software becomes ever more important to them.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Finding Production Drift

    A few years ago when I started delivering presentations about automating database delivery with Grant Fritchey, I was surprised by something. We were rehearsing a talk and Grant mentioned that there were really only two places where we knew the state of our code: in a VCS and in production. I hadn’t really thought about that before, but realized it was true.

    While the development environments are always in flux, by using a VCS, you can determine the state of your code at any point in time. However since changes can occur in production (DBAs adding indexes, changing security, etc), you can’t count on a release branch of some other designation as being a guarantee of the state of your live environment. Production is always its own version of the truth.

    Ideally all of the changes being made on your production system are tested in development, QA, and pre-production environments before being deployed, but very few companies have a mature enough deployment pipeline to allow them to push hot fixes and patches rapidly enough, especially when they need to be made in an emergency.

    More than likely some changes will always be made in production directly, especially small ones that affect data. You can’t prevent this, but you should be able to deal with the aftermath and ensure that your system doesn’t destabilize from the enhancements. Without a doubt DBAs should log any scripts they run, but it’s easy to forget things, especially when changes are made in firefighting mode or at 3am.

    That’s why having some sort of monitoring system to watch production for any changes becomes an important logging mechanism for DBAs. Whether you build one yourself, or buy some software, you use the native tools or bolt something onto SQL Server, make sure that you put something in place. Work to push your ad hoc changes back to development, and ensure they get into a VCS at some point.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Building Small Habits

    I was reading Kenneth Fisher’s piece on constraints recently and was struck by the fact that this is one of those small changes you make to your coding that has big benefits. In essence, rather than being lazy and writing this:

    CREATE TABLE mytable ( myID INT PRIMARY KEY, MyCol ....

    You decide to explicitly add a few more characters. You note this is a constraint and you type this:

    CREATE TABLE mytable ( myID INT CONSTRAINT PK_MyTable_MyID PRIMARY KEY, myCol

    It’s a small change, but it takes you from an object named PK__mytable__783FBF31F8293E74 to one named PK_MyTable_MyID, which is way easier to understand and debug when you have issues. More importantly, this is a DevOps move, where a developer can make it easier for operations people to understand the constructs and organization of a system that has moved to a production environment.

    There are all sorts of little coding changes you can make that improve the way you write code, and perhaps make it perform better. Aaron Bertrand has a whole series of bad coding habits, and at SQLServerCentral, we’ve published a number of pieces on different ways to code better, such as removing cursors from your code.

    By making some small improvements in your coding habits, changing to better techniques over time, you’ll slowly improve your entire codebase and help yourself and other developers code more efficiently in the future. I’d even recommend as a team that you choose a single change to make, and begin implementing it across the next month or two. Then repeat the cycle again. In a year, you’ll be amazed where you are.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.