Simon Galbraith

22 December 2016

Why 2017 is the year of Database DevOps and why database professionals should lead the charge

At Redgate, we think DevOps is now sufficiently mainstream and that it’s worth businesses thinking of moving to a database DevOps type of world.

One of the reasons is the 2016 State of DevOps Report from Puppet Labs. They interviewed 4,500 people about their experiences of DevOps and the report provides some strong evidence you should now be taking DevOps seriously.

Firstly, companies who use DevOps report a third of the rate of failure when making changes compared to those that don’t. That’s a really important benefit and enough on its own to justify adopting DevOps.

Secondly, organizations which practice DevOps recover from an incorrect change 24 times faster. That’s something else that’s very compelling.

Thirdly, people who follow DevOps report that it’s 2,500 times quicker getting changes to customers. That is an unbelievable saving for a business, especially when you think of the working capital tied up in changes that have yet to hit the market.

Those three things – the reduced risk of failure, the faster response time to failure, and getting added value into the hands of customers sooner – are seriously valuable advantages for a business.

There’s another soft benefit, which is how feel people when they’re working for you. Teams which do DevOps find it’s easier to recruit good people, easier to keep them, and easier to make the team really successful. Apparently those teams also spend less time on unplanned work like resolving unexpected security issues.

I suspect some of you are thinking you’ve heard this before, but the evidence shows DevOps is now becoming the norm rather than the exception. 50% of businesses doing DevOps have more than 500 employees, it’s easily placed on a Microsoft or LAMP stack, and it’s not just for guys with ponytails and flip-flops any more.

The way we see Redgate fitting into this is by saying, on the Microsoft stack, we’re there to help you deliver the database side of DevOps. Whether you’re provisioning a working environment, building a database, releasing it, monitoring it, or backing it up, we offer the technology to make database DevOps possible and real.

But there’s a final point I’d like to make which is that people working with databases are in a much better position than application developers were when they were adopting DevOps a couple of years ago.

Research from Dell, for example, shows that database development is already enormously cross-functional. In fact, there’s a 60% overlap between people working on both development and operations, even without a widespread adoption of DevOps.

We know this from our customers too – when we survey people, we find the majority work in both Visual Studio and SQL Server Management Studio for database development and administration, and split their time about half and half between them.

So really, you’re already doing a lot of this. Although the database is often described as the bit that’s hard to get working, it turns out that the really hard part of DevOps – collaboration, working across organizational divisions, the bit that most companies struggle the most with – is already there.

So now the technology is coming through, we’re hopeful you’re going to decide to take DevOps to the database.

This is an edit of Simon Galbraith’s SQL in the City Streamed keynote. You can watch the full keynote below and access other sessions from the event on the SQL in the City Streamed YouTube Playlist.

You can also find out more about the benefits of extending DevOps practices to SQL Server databases.