Voice of the DBA

Tag: DevOps

  • DevOps and Exhibits

    Last month I did a webinar with the ATARC group on DevOps and databases. I was on a panel with a few government employees talking about the COVID-19 pandemic and how this may have changed work inside the US government.

    One of the panelists is a full stack developer for the Smithsonian. Ravyn Manuel talked a bit about her work in trying to build new exhibits for the African American History and Culture Museum, which will look to open up soon. Many of the exhibits in the museum were built to be interactive and touch capable. With the COVID-19 pandemic, they need to revisit their approach, finding ways to avoid having visitors touch shared surfaces.

    There was an article after the webinar that included a bit more information. The idea for the immediate future was to use a visitor’s mobile device with QR codes or Augmented Reality apps that engage and excite people. It’s a great challenge, and as Ravyn notes, it’s an exciting time for DevOps and developers.

    I think that’s one of the things that DevOps is supposed to produce. Some experimentation, and along with it, the excitement that comes from meeting and conquering challenges. Rather than big projects, we try smaller things, and adapt as they work, or don’t.

    DevOps is helping many organizations reinvent how they perform software development. Many of the techniques are the ones some of us have been using for years, but the focus on the term has helped lots of managers rethink their processes. I’d urge you to look at DevOps ideas, but be sure you include the database. It’s an important part of the DevOps process.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Automation is a Key Skill for the Modern DBA

    This month we had T-SQL Tuesday #130, hosted by Elizabeth Noble. Elizabeth and I had some good talks about database development and DevOps last year, and I managed to convince her to host one of the blog parties. I had expected that people might focus on the software development side of automation, but many of the posts cover administrative topics.

    The recap is coming next week, and I look forward to it, but I shouldn’t have been surprised. Good DBAs, as well as many sysadmins and Operations staff, have known that automation is important for years. It helps to ensure a smooth running environment and helps us cope with the volume of work that is thrust upon us.

    There were a few interesting posts. Greg Dodd talks about the advantages for his employer when he automates things, which is important to think about. Spending time automating things can slow down the initial closing of tickets, but it pays dividends in the future. It’s an investment, which is something to think about when you try to reduce repetitive work. Especially if your boss is concerned about the time taken to solve some tickets.

    One of the big advantages of DevOps, as well as general automation, is consistency. Taoib Ali explains how he enforces trace flags with automation, and Kevin Chant talks about SQL Server updates. Deepthi Goguri explains how to handle DBA work at scale. These are all situations where a little automation is not only useful, but perhaps essentially to reducing mistakes and human error.

    As we move to a larger number of versions to support, a great variety of platforms, including the cloud, it’s critical that a DBA not be required to click around in SSMS or connect to lots of systems to manage them. Learning to automate can produce some great blog posts for your brand, give you interesting conversation ice breakers at events (or on social media), and generate some stories that will impress interviewers.

    If you aren’t sure how to get started, consider reading Eitan’s Laws of Automation. It’s a look at what to automate, why, and a few ideas on implementing changes.

  • Automation Ideas for T-SQL Tuesday #130

    tsqltuesdayThis month we have another great T-SQL Tuesday topic, and again, a host that I pressured into writing the invitation. Elizabeth Noble (@SQLZelda) and I were talking DevOps last year at a SQL Saturday, just as she was effecting some change at her employer. At an event later in the year, I challenged her to host, and here we are, with a great topic, Automation.

    That’s this month’s invitation. Elizabeth describes the process of using automation to smooth out their deployments to SQL Servers. They slowly built a CICD pipeline and migrated projects over and over to save her time.

    This month, what have we done to automate things? I have a few stories.

    Automating Data Collection

    One of the things that I am passionate about is the SQL Saturday events. I loved that PASS maintained a site, and made a feed of event data available, but over time, we’ve lost some data and I don’t think there is much impetus to maintain this over time.

    As a result, I build an automated process to grab data from the feeds and save it as an XML file on my local machine. I have the basic code up at GitHub, though I need to improve and refactor it a bit. These files change as the organizers update them, so I need a good merge process. Right now I tend to delete all 1-2KB files periodically, as the file is built once the event is approved. However, until all the speakers and sponsors are scheduled the file size is just a few KB. Most events are > 100KB once they are set.

    This is a basic way of grabbing some data, and I’m looking to build a few more data collection processes to grab data in my life and keep it around, just in case some service I use goes kaput.

    Automatic Databases

    I work at Redgate, and one of the things I’ve been spending more time doing is the automation of databases for development with the latest code and test data. This is a challenge, but a few of the things that I’ve done with Redgate that help are as follows:

    1. Use Powershell to automate the creation of SQL Clone images.
    2. Use PowerShell to update SQL Monitor alert values and add instances
    3. Use Flyway in a container to deploy changes
    4. Use our SQL Change Automation cmdlets to deploy changes to databases

    All of these items can be automated so that a user just needs to run a script, or sometimes just click a button.

    I’m slowly getting the PoSh code up on GitHub as I build demos and help customers get things done. Right now, getting organized is the biggest part of my job, because I find these questions coming over and over.

    I’m a bit proponent of DevOps and automation. Use tools and computers to do the tedious, repetitive work. Keep your day focused on solving problems and building/improving scripts.

  • Better Government Security Through DevOps

    Most teams building software seem to go a little too fast to ensure their code is both secure and of high quality. I don’t think it really  matters whether you are working in a waterfall process, agile, lean, or any other methodology. Whether fast or slow, humans will make mistakes, new code can introduce a vulnerability. Even if you follow great practices, it seems that hackers and criminals find new attack vectors all the time. I’m not sure we really can go slow enough and stay in business.

    Those of us working as data professionals know that protecting the data in our databases is important. We are reluctant to allow too much change too quickly, especially when there might be changes that affect security. However, is limiting change the best idea?

    I’d argue no. DevOps preaches the ability to update on demand, and often, as soon as code is complete. This doesn’t mean we don’t test or pen test or run security scans or anything else. It does try to limit the work in progress, which means that we aim to allow updates to our lives systems regularly.

    An article for CIOs notes this that DevOps helps us improve security, precisely because we can fix things quickly. This might be especially important in high security environments, like government systems. The ability to patch, correct faulty code immediately, and respond to threats is important. There could be breakage from fast moving code, but another part of DevOps is improving your knowledge and skills, working to improve not only the quality of existing code, but also the quality of all future, first written code.

    I would rather manage database systems that backed applications being updated on demand in a DevOps flow. I’d rather be able to patch and update libraries, platforms, and frameworks quickly. We’ve seen the problems in systems that aren’t updated with the Equifax breach. We should learn from this incident and ensure we can patch and update systems on demand, whenever we need to do so.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.