How Do Databases Fit Into DevOps?



Towards the end of 2014, we started getting to know the folks over at Redgate, and learning about what they’re doing around Database Lifecycle Management. It’s prompted some interesting conversations.

Redgate have been spending a lot of their time thinking about continuous delivery for databases. One thing we’ve discussed recently is how it’s not uncommon to see tensions mount when databases are added to the mix of a Continuous Delivery process. Particularly relational databases, and especially transactional relational databases. As Redgate thinks about the opinions among the DevOps community on how to manage and deploy databases, it’s prompted a few interesting questions – for example:


Why do the tensions around databases seem less pronounced in the DevOps community?


It’s About Perspective

Now I’m not 100% convinced that there are fewer tensions – I suspect they may just be different tensions. That said, there are plenty of good explanations – both cultural and technical – for why the CD & DevOps communities perceive databases differently. Perhaps some of it comes down to what they’re respectively is focused on.




Naturally, Redgate are coming to this from their established position in the RDBMS space (predominantly SQL Server, but with a twist of Oracle and MySQL as well), and so the second question that comes to light is:


How do DBAs fit into a DevOps world?

If we look at how the roles and responsibilities break down, it looks like DBAs are simply Ops specialists. Does that mean that database developers and DBAs should be blended in a single DBDevOps team? Having two flavours of DevOps team running side-by-side on the same overall application feels like a poor compromise, but are databases special enough to warrant it?

Alternatively, does this mean that the DBA dissolves into just another Ops facet of the overall team? Given the amount of specialist training and knowledge we so often see invested in DBAs, it’s hard to imagine how a team could be high-performing without some degree of specialization when it comes to managing data. This could be the straw that breaks the Full-Stack Engineers back, or it could be that you can actually get a very long way before you have to dip into the skills of a true specialist. I’m sure that, like so many questions, the answer is “It depends”

Either way, the fact that we’re even talking about Database Lifecycle Management (and uttering sentences which include both “database” and “DevOps”) suggests that software engineering as a whole is maturing at the pace of Moore’s Law, and starting to embrace the ideas that were obvious to W. Deming. Not only are we tackling these questions thoughtfully, but we’re also being more aware of the practices that have emerged in software engineering. As a result of that maturity, we’re also starting to see tools emerging which are actually fit to be used in a DevOps environment. In the case of databases, part of that is about treating them as stateful artifacts, and I particularly like Redgate’s SQL Lighthouse in this regard – a free little tool currently in beta for monitoring when database states drift.

So Many Questions

The sharp-eyed among you will have noticed that I’ve suggested several possible ideas, but avoided stating which one is the Right One™. That’s mostly because a) I don’t know yet, and b) it really does depend. And c) it’s hard to put together a solid case in a relatively short blog post!

We’ve seen a few different approaches to the problem, but what kinds of practices are you forming around your databases (and how are your DBAs being involved)?

And given that databases are tricky and stateful, what kinds of tools and processes are you using to monitor and deploy them? Open source libraries sanctified by Etsy, Netflix et al, something home-grown (and quite possibly a bit of a snowflake), or something off-the-shelf?

Share this:

Readers Comments (7)

  • Really interested in the question of whether stateful databases are generally just folded into DevOps practices, or whether you get a messy “DBDevOps”. I’d assume it depends a lot on what whether your database is just a “dumn repository”, or whether you’ve actually got business logic build in with SPROCs etc.

    I know Avi Cavale (Shippable’s CEO) is a STRONG advocate of the “dumb repo” approach, arguing that everything even remotely dynamic should be in non-DB code, so that the DB can be more neatly container-ized.

    On the other hand, Matthew Skelton makes an interesting suggestion in one of his Simple-Talk articles about having a DBA-as-a-Service (,-team-structures,-and-conways-law/) I think it might be more aimed at CD, but I’m sure there’s interesting ideas that could be applied!

  • Pingback: How Do Databases Fit Into DevOps? | I can expla...

  • DevOps is (just) an IDEA that brings together different functional areas of specialisation, just as Supply Chain Management brings together different business functions.

    Databases fit perfectly into the area of persistence of data which – last time I checked – was essential in most micro-services.

    Database administrators (DBAs) should get used to telling other micro-services developers to wrap their access point in something as simple as:

    import storageservice as ss

    and then let the storage service people manage the persistence.

    with open(ss, ‘w’) as connection:
    connection.write(data1, ‘SQL’)
    connection.write(data2, ‘csv’)
    connection.write(data3, ‘blob’)

    and no more.

    The micro-service developer should leave it to the highly expensive DBA to solve the problem of storage and retrieval and use a connection wrapper to make the problem go away for ever.

    We have used this with approach since the 1980’ies but commercial idiots tend to over-marketer the most logical step with obscure idea force-fed to a sales force who couldn’t care about the end-users maintenance problems as this was just another source of income.
    So stop buying the sales bullocks, grow up and make your own opinion.

  • We did a couple things when it came to databases.

    1. Server standardization. All servers were built the same way (excepting users/logins of course). We used chef to standardize our Windows server builds, created some SQL Server install scripts for unattended installation and patching, and automated those through chef as well. When it came time to spin up a new server, we just ran the script with the appropriate parameters and had a new database server ready to go – mostly hands-off. Admittedly, this also applied to our app/file servers, but it made life much easier all around.

    2. DB Source Control – all planned changes to the databases are done from the repository. We used Jenkins to get latest, build, and push the changes to each environment. If it’s not in source control, it doesn’t go. (This excludes major fixes/updates/index changes, but we make up for those in the project before the next release.)

    3. Partnering with developers to optimize code and database calls. ORMs have their place, but sometimes shortcuts are taken and the ORM option isn’t used well or just makes poor choices. Writing stored procs or re-architecting the code together leads to better overall performance.

    4. Monitoring. We used New Relic for some time to monitor all of our systems together, including SQL Server. It had minimal overhead, but allowed us to catch major issues a couple times before the customers noticed. It also helped us pinpoint the exact area of the app that had an issue – code, server, database, or file system.

  • Back in my dev days, we used dbmaintain. The SQL update scripts were checked-in to SVN and executed by the Maven deployment script. That was around 2011 and we were a small team of 5 or 6 and that DevOps approach worked pretty well.

    We didn’t do DB monitoring back then. Today I wouldn’t either, but it comes with ruxit out-of-the-box, which proved more than once that DB monitoring really makes sense 🙂

  • Pingback: How Do Databases Fit Into DevOps? | I can expla...

Leave a comment

Your email address will not be published. Required fields are marked *