Voice of the DBA

Author: way0utwest

  • Baby Steps to DevOps

    I’ve been re-reading the book, Continuous Delivery, as part of the current San Diego Technology Immersion Group monthly meeting track. This book was the focus of the first meeting in May, and will continue for the next couple months. Continuous Delivery and the related, DevOps, are fascinating concepts, but mostly I find the discussions really interesting for me to see and hear how others view the DevOps, Continuous Integration (CI), and Continuous Deliver (CD), and where they apply in each person’s organization.

    One of the things I’ve noticed is that lots of people get overwhelmed with DevOps. They hear stories of how others are running an extremely efficient software development shop and think they couldn’t implement CD in their organization. Or they think that CI/CD/DevOps is just a way of building software that’s so far removed from their own experience. However, DevOps isn’t really anything new or special. It’s not even one thing, as there are many divergent views of what DevOps means. However, plenty of people have been applying and adhering to the various definitions of DevOps for decades, just viewing their process as efficient, effective, and empowered.

    I use DevOps and CD somewhat interchangably, as they often proceed along the same path and each is a intertwined with the other. Note that going to a CD process doesn’t mean that you release every day/hour/whatever. If means that you release when you want, which could still be every few months. It’s just that you have a process set up to allow smooth process flow.

    As I talk to people who are looking to build a DevOps process, and I hear about more and more of them all the time, one thing I stress is to take things slow. You won’t build your DevOps process, whatever that looks like, this month. In fact, what you should expect to do is learn as you go, and whatever your vision of the process is today will change. You will learn, grow, change the way you do some things, and also change the way you implement new processes, even if you’re copying how other companies have implemented their own system.

    Most importantly, what I try to stress is to slowly move to CD (or DevOps). Look at the process you have now and just change one thing. Let’s imagine that you:

    • manually track changes to the database in email
    • then build a change script manually
    • then have a DBA apply those changes
    • then let QA run tests with an application
    • then modify the script that goes to production

    Leave that process as is. Let’s implement one thing. Add some version control that will let you build a base for other changes. Your new process would be (changes in bold).

    • manually track changes to the database in email
    • then build a change script manually
    • store the change script in a VCS
    • then have a DBA apply those changes
    • then let QA run tests with an application
    • then modify the script that goes to production

    Or change to this instead?

    • manually track changes to the database in email
    • then build a change script manually
    • then have a DBA apply those changes
    • then let QA run tests with an application
    • then modify the script that goes to production
    • track all changes to production in an automated fashion (hopefully using a tool)

    Over time, you can make another step. Maybe you use something like SQL Source Control or ReadyRoll to build change scripts and put them in a VCS. Or perhaps you build a process that takes the changes from the VCS and applies them to a test database without requiring the DBA to check things out and execute them. Both are valid ways to evolve your process. (Disclosure, I work for Redgate Software, maker of those products). I’m giving you a few suggestions here, but there are multiple ways, methods, and tools you could use.

    And that’s the key. You evolve your process, evolve your communication, learn to work together to accomplish goals. Not big goals, little goals. Add small items to your process as you realize they can be automated. Change communications in ways that help ensure everyone knows where to find code and how to deploy it. Or everyone knows how to set up environments (hopefully automated).

    Slowly get better and better, and before long you’ll find that you can make changes in smaller batches, and ensure those changes can be deployed at a rapid pace. Or maybe you’ll have confidence to begin moving to a feature flag architecture so that you deploy changes well in advance of users being aware of them. Note, they’re not perfect or the solution.

    DevOps is about learning and growing. This is really the same basic principles that have driven Six Sigma and Kaizen and various other philosophies that recognize that we can do better over time. Make small steps, measure, learn, and improve.

    Steve Jones

    The Voice of the DBA Podcast

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

  • T-SQL Tuesday #80–Chris Yates’ Birthday

    tsqltuesdayIt’s the 80th version of T-SQL Tuesday. You can see all the parties from the past on my page, but feel free to jump in here or elsewhere. This is a monthly event, where anyone can write on a topic.

    This month’s invitation is from Chris Yates, with today being his birthday.

    Happy Birthday, Chris!

    The topic is open this month, so here we go.

    SQL Server Isn’t Easy Enough

    I think that SQL Server is a fairly easy system to work with. I first started working with SQL Server on OS/2 1.3, and had come from working with lots of Unix, DOS, and Netware command lines. Windows 3.1 was still new, and we thought all the various command line tools for SQL Server were great.

    Even as I continued on in my career, working with Oracle on multiple platforms, DB2, and other relational systems, SQL Server was the easiest to use.

    However, I still find some simple, easy things that aren’t easy to handle. I think there is work being done with some of these items in Redmond (nothing specific I know or can say, but just a feeling), but these items have been an issue for some time.

    Database and Log Backups

    One of the really simple things many SQL Server professionals know is that we need to schedule at least one full backup to run, and then regular log backups, at least by default. The alternative is to set the database to simple recovery (not the default).

    The problem is that for many installations, people don’t realize that they need to do this. While it’s easy to say they should learn this, it’s also silly. This could be easily handled with software setup. Create a default backup setup for each new database, as part of the database creation wizard.

    I’d really like to see these defined in the database themselves, and loaded into the instance from the database, and hopefully we’ll get there.

    Replication

    I don’t have specific complaints here, though I could come up with some. The real issue I see is that replication is very brittle. The way replication works, and it’s barely changed in a long time, is that it requires lots of setup, and isn’t tolerant of issues. Far, far too often the solution when deploying changes to the database, or troubleshooting issues is to drop replication and re-enable it.

    Most people running replication have been burned and end up scripting everything as soon as it’s set up.

    This shouldn’t be that hard, or at the very least, some work should be done to improve the robustness of replication.

    More

    There could be other things, but I’ll stop here, and see what else people say about SQL Server this month.

  • A New Look

    I was browsing around the Internet recently, collecting links for Database Weekly when I came to Michael J Swart’s blog. I love Michael’s writing and drawing. On a whim, I asked if he’d do an avatar.

    He agreed, and sent me some costs. He’s creating art, and I was happy to pay for a new image. We went back and forth a bit and ended up with this:

    SteveJones-Big

    I like it. It captures me life in sunny, outdoor Colorado and has a nice Hawaiian shirt in it. Plus, it has my colors. I’m a Virginia grad and Broncos fan, and like the blue/orange look.

    Photo Feb 26, 11 32 19 AM (1)

    If you want an avatar, I’m sure you can contact Michael. I know it’s not for everyone, but it was fun for me. It might make a great gift for someone in your life as well.

  • Going On-Prem?

    When I started in this business, every company owned their own servers, and had their own data center. Now, some of those data centers were closets (including that for one state government Senate). Some were offices-converted-to-computer rooms, rarely with separate air conditioning until I requested it. Some were actual data center rooms, though usually for larger companies. The idea of putting your computing resources off-site was seen as ludicrous.

    As time passed, the idea of using a co-location facility grew. In fact, SQLServerCentral went from a couple machines in a residential basement to a locked rack at a facility in Denver. Many companies started to use third party data centers, and in the late 90s and early 2000s, this was common, with facilities springing up. Full time employees will often racked equipment and visited data centers when they needed physical access.

    This changed over time as virtualization grew, and more and more companies started to rent a VM, rather than purchase a physical box. Some still used physical machines, but they rented the machine, allowing a third party to setup and mount the equipment, sometimes even installing the OS and then providing access to the lessee. We’ve come to the place now where we have cloud services that are often just platforms or services, where we have no idea of the underlying equipment. In the case of things like Salesforce, Azure SQL Databases, or Amazon’s RDS, we don’t even care, just asking for a certain level of performance.

    Is this the future? Will we now be asking ourselves if we “want to go on-prem” as the default question? I ran across the blog linked, which is from a SaaS perspective, that is trying to always get customers to use the service (or platform) and never have a local install. I know Microsoft would like to do this, especially for Azure databases as they make more profit on compute services.

    Some of you think this is crazy. In fact, I know plenty of industries that struggle with this from a regulatory standpoint. However, I’d point out that the idea of letting someone else run your email system was seen as crazy 20 years ago. Today many people (myself included) would never think to install Exchange or any other email software. We would always purchase this service from someone else.

    Tim Mitchell had a podcast interview recently talking about whether the on-premise data warehouse is dead. While I think the Azure Data Warehouse has some great advantages, and is worth considering, I’m not sure the local DW is dead. In fact, for lots of tasks I perform, including software Continuous Integration builds (.NET or database), I prefer to have some local resource doing the work. Especially when I can’t predict the number of times I’ll build and that task is easy to scale on local machines.

    I don’t think that we are at the point where we’d put more databases in a cloud service than on premise, but I do think that for new applications, it’s a valid question to ask whether the database and application could be hosted in the cloud.

    Steve Jones

    The Voice of the DBA Podcast

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