Kate Duggan

20 January 2017

Where’s the database in DevOps?

At the end of 2015, we interviewed James Betteley, Head of Education at DevOpsGuys about the role of the database in DevOps. James is a firm believer that DevOps is about people and processes, and that while automation tools are necessary, they are not sufficient for a team to be a DevOps team. Here’s what else came out of our discussion.

So, what is DevOps?

There’s a lack of clarity about what it is and a misconception that it’s just about automation. We hear people using the term DevOps almost interchangeably with automation or even tooling to some degree, but it’s actually more about the culture.

DevOps is about creating the right environment and the right kind of team to become collaborative and work towards a shared goal of delivering software effectively. Automation will help you achieve that but you need a DevOps mindset first.

How do you get the buy-in to create that culture of change
if it’s not just about plugging in a tool?

Tools can be accelerators and they can also be a way in. But ultimately it’s about breaking down walls and barriers and bridging the gap. That could mean realigning all of your teams or changing your organizational structure, so you need a high-level buy-in and the right kind of culture to be accepting of this movement. It can be quite a challenge.

We hear about companies like Netflix and Etsy using a DevOps approach,
but how well is it being adopted in the mainstream?

There are some large companies out there who have famously adopted this highly automated approach to delivering software. But we’re not all Netflix and we haven’t all got automation baked into our DNA.

There is no ‘one size fits all’ solution for DevOps for every organization, so you do need to tailor the solution to your own business. The way one company does it might be a roaring failure in another organization because there are so many different ways of adopting DevOps.

Should DevOps goals be the same as company goals? How important is this alignment?

Your company goals will have a huge impact on what your DevOps goals are. DevOps goals need to be tightly coupled with your IT strategy. Your IT strategy and a lot of your DevOps techniques need to be working towards your business goals; otherwise, you’ll be fighting the whole way.

So how does the database fit into DevOps?

The database is as important a part of the ecosystem as any other part of the application. It is as important as your infrastructure or your website. So asking Where’s the database in DevOps? is a bit like asking Where’s the website in DevOps?. At the end of the day, it’s a culture, a way of working, and your database fits in there alongside everything else.

The main thing is to get the right people in the room at the right time from the beginning, and design solutions sympathetically with consideration for the database and the architecture of choice. We need to be thinking about how we deploy, how we maintain, how we roll back, and all of those things.

Traditionally the database has been difficult to fit into this, and has always been the sticking point in the past. But there are good tools out there to support the database now, so we don’t have to just hit and hope any more.

Why do you think the database hasn’t been included before in some
of these development practices like CI and automated testing?

It was too hard to do. We’d been used to developing code that you could just tear down and replace, but DBAs would say You can’t do that with your data and your database. So instead of working together to come up with best practices and elegant solutions, developers ended up saying Okay, that’s your problem, so I’ll leave it with you.

There were all these automation tools available in dev, but in operations they were still doing a lot of these tasks manually. Thankfully, now there are solutions so we can finally work together. I’ve seen the change happen firsthand – it’s been a cultural change as much as anything else, and now all these tools are sweeping in that also help us be more collaborative.

Once an organization has decided to adopt a DevOps model, would you typically see a
‘big bang’ change to the new way of working, or would it be a more gradual approach,
starting with specific projects or databases and adopting more as time goes on?

It will all depend on your organization – its current size, existing culture, structure, and many other factors as well. However, I think it’s fair to say that a more gradual approach is far more likely to be successful than a big bang.

At DevOpsGuys we usually recommend that organizations start on a smaller, isolated product, and concentrate on making a successful transformation within that product team. Once the fire of success has been lit, you then need to fan the flames and spread that success to other teams and across the organization.

So the smaller an IT team, the easier DevOps is to implement?

Possibly, because you’ll have fewer people to convince! But generally speaking, I don’t think it’s down to the size of your IT department. You see large organizations with hundreds of IT people broken down into smaller product teams; that’s the favored framework for being successful with agile and DevOps.

Collaboration is the main issue, in just the same way as it’s easier for smaller teams and organizations to become agile. But just because it might take a bit longer to adopt DevOps in a larger organization, it doesn’t make it any less valuable.

What would be the first step or steps to applying a DevOps approach
to an already deployed application and database?

If you mean DevOps best practices, such as automation, then the answer would be to start with source control. Source control is a fundamental part of getting your database to work more like your application. The ability to deploy to a known state, especially multiple known states, is only really possible by using the mechanisms within a source control system.

Reports like The State of DevOps have told us that organizations using version control and automated deployments are higher performing – so we know it’s a good thing to do! It’s only a small part of the bigger DevOps picture but it’s still a very important part, and a key step along the DevOps journey.

By source controlling your database you make it easier to share and collaborate, find and fix issues earlier, and be able to deploy a ‘known state’. Plug in some Continuous Integration and deployment automation and you’re well on your way!

Any final thoughts about database DevOps?

DevOps is primarily about people and processes. While automation and tools are necessary, they’re not sufficient for a team to be a DevOps team. You also need to ensure you’ve got support from the team and organization around you if you’re hoping to start adopting DevOps-like practices.

James also joined us more recently to deliver a one hour online training session on ‘DevOps 101 – An Introduction to DevOps’. To hear more from him about database DevOps, what problems it can solve, and how you can start implementing it, check out the recording.