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?