Matt Hilbert

16 July 2020

The business benefits of Database DevOps

Redgate recently partnered with the analytics and data management consultancy, Coeo, in a joint webinar to discuss the benefits of Database DevOps for organizations everywhere. The presenters from Coeo and Redgate were faced with a series of previously unseen questions to answer on the spot using their expertise and experience.

The result was a fascinating insight into the questions organizations, businesses and companies are asking right now about how and why databases DevOps should be introduced, what the benefits – and obstacles – are, and how success should be measured.

This post is an edited transcript of the questions and answers from the webinar, which you can still view online.

Is DevOps right for every organization?

Who doesn’t want to release features and changes quicker, add value faster, and do it all more reliably? We would struggle to see any organizations where DevOps wasn’t beneficial. It’s where you choose to use DevOps that’s more important.

Most organizations have a number of applications, some of which haven’t changed for years. They do tertiary functions, they’re not core to the business and don’t help to differentiate them in the marketplace. Forget DevOps.

At the other end of the spectrum are applications that are unique to the business, and that’s where DevOps can offer the greatest value, by reducing the time to market for new features and allowing organizations to rapidly innovate. DevOps isn’t a one-size-fits-all approach, but one that works best where it helps organizations to differentiate, giving them the greatest opportunity to see a return on investment.

How do you diagnose when an organization should introduce DevOps?

Big, slow releases are always a warning sign, particularly if they’re on Sundays or out of hours, the failure rate when deploying to production is high, and the DBA team and Database Developers are really stressed out. If those things are already starting to negatively impact an organization, it could really benefit from the faster, more reliable release cadence that DevOps brings.

Siloed knowledge in teams and individuals is another and one of the biggest indicators that people need to start collaborating more. If you can’t say where information is or you give a response like ‘Oh that’s the DBA’s job’, it’s a sign that DevOps could help the organization. By its very nature, DevOps requires – and rewards – collaboration and cooperation.

How do you start implementing database DevOps in an organization?

We get asked this a lot and we recommend that everything comes from source control and then you build up from that. It’s much easier said than done, but it’s the basis you start with. The most important thing, though, is to start small. Lots of organizations we work with have one or two advocates for DevOps who see the benefits and the opportunity, and the greatest success we’ve seen is where they take a relatively discrete application and build an end-to-end DevOps process for it.

They introduce the culture where developers start version controlling database code, deploying in an automated fashion into test datasets, running unit tests, retrieving the results, and deploying to production. They build the capability and experience and then incrementally step up the complexity. It really is, crawl, walk, run as they move forwards on the deployment journey. They gain some success and learn the capabilities of the process, build a small environment first and then increase the size and complexity.

The important thing is not to be intimidated by DevOps and think it’s too large a thing or too complicated, because you end up doing nothing. Just focus on the area you’re interested in and where you can grow your skills.

On a similar vein, can you do any simple steps to improve your process today, get feedback and iterate, and then add something else tomorrow? What about version controlling the database code, or adding one unit test, or automating the build pipeline? You can build capability over time, so don’t be put off – start small and add one thing today.

What advice do you have for introducing version control to SQL Server databases that have been in production for a long time?

When we think about established environments, we think about persistent development, test and UAT environments. Those environments are infrequently refreshed from production, so even on a good day they’re not functionally representative, or they don’t fulfil their objective in terms of being able to release code. They’re cumbersome, complex and expensive to maintain, particularly when we’re moving to a cloud first world.

So isolating an area of application or functionality and then moving that to source control is the first stepping point to deconstructing the monolith that’s been created. It feeds the whole kind of way that developers deploy code, the way the infrastructure provides patch management, the way the business tests applications. Ultimately, businesses need to upend that process to be able to reduce the friction and deploy more frequently, more confidently, with smaller releases.

That’s a big task, especially in an enterprise environment, or even a medium-sized business, to really evolve the pattern of working but the benefits are worth it. Start with one area and then add another, and so on.

What common obstacles have you encountered when adopting DevOps, and what have you learnt from these?

The most common obstacle is that organizations often think DevOps is purely a technology project, where they can buy some software to solve their problems and allow them to release more easily. It massively underestimates the people and process change that is required.

There will be naysayers that want these types of initiatives to fail, for example. They may be resistant to change, or they could have a massive backlog of features they’re trying to deliver, and they haven’t got time to figure out a new way of working or how new tools work.

The key learning is that buying software is easy, but changing working practices and processes is hard. To make it happen you need sponsorship and commitment at a senior level and, for that, you need to speak their language.

We’re talking the costs of firefighting problems, with Developers and DBAs having to stay up overnight to unpick bad releases, employee turnover increasing because people want a better work-life balance, and planned releases being delayed and having a direct impact on customers. We’ve worked with clients like logistics companies where a failed release meant shipments didn’t go out, which delayed physical goods moving and led to compensation being paid to customers.

It’s not just about direct costs, though, it’s also about missed opportunities. Time to market for new initiatives is now critical, and lots of organizations need to radically change how they go to market. Once organizations understand that IT can be a key enabler in supporting change across the whole business, the obstacles to DevOps come down.

What key elements would you recommend including in a business case for DevOps?

Firstly, many IT development teams are over-resourced to compensate for inefficiencies in the deployment process. If organizations can free up those resources to work on adding business value and increasing productivity, the time saved – and gained – can be translated into a dollar value.

Secondly, many industries including retail, travel and tourism, and financial services rely on getting an offer or proposition out to the market to unlock business opportunities. They know that if it takes them an extra week or two weeks to release a new feature, it has an impact on revenue and profit – and weakens customer loyalty. Customers will shop around and get the feature they want right now from a competitor.

Something we’ve also seen more recently is organizations that move to the cloud but don’t change the way they work. Taking that mindset and working practice from an on-premises world and just replicating the same environments in a cloud world leads to numerous additional copies of production for testing and development. That’s a very, very simple dollar cost to quantify which makes it easier to explain how a DevOps way of working can avoid the need – and cost – of persistent non-production environments.

What’s your advice to bring around colleagues, including your DBA, who are opposed to implementing a new DevOps culture?

Whether it’s the DBA, a Developer or an Architect, most organizations have naysayers who don’t want change. It’s understandable. DBAs in particular tend to be risk-averse, cautious individuals whose job is to keep the system up and running, 24/7, and protect the performance and availability of the database.

The key is to get the process working end-to-end in a small and discrete way, then evidence the benefit and the impact to the business. Show how DevOps is an enabler for IT, deploying new features quickly and safely, helping support change faster and more predictably, more consistently, more reliably and with less stress.

Start small, demonstrate the advantages of deployments being boringly reliable rather than worrying problems, and the naysayers will be won over.

Other than the DBA, which job roles stand out as key to driving a DevOps initiative?

Firstly, anyone involved in testing, like Test Managers. Database DevOps involves using a testing tool like the tSQLt framework to automate unit tests of SQL Server code early in the development pipeline, and you need T-SQL skills to write those tests.

Nowadays it’s also not uncommon to find a DevOps Engineer role within an Operations Team, which is a natural fit for many larger organizations. They’re often involved in provisioning database copies for development and testing. Introducing DevOps can help them do that faster and smarter.

Thirdly, there are infrastructure folks, specifically cloud infrastructure. Features are frequently released which require interaction with Azure load balances, with DNS, with network topology, security, roles and permissions, so a release can be broader than the database. There’s a lot of value to be gained from using DevOps to introduce repeatable, automated processes to ease those releases.

Finally, and probably most importantly, talk to Enterprise, Domain and Solution Architects because their role is to bring about positive change and deliver better value to customers. They’re a really strong champion to have on board because they get recognition at the C-level. If they’re spearheading a DevOps project alongside the DBA, the Dev Manager, the Testing Manager, the infrastructure people, you’ve got an elite hit squad. You’ve got the full spectrum of skills that will ultimately enable people to do the right thing.

What metrics do you use to measure the success of DevOps implementation?

A big one is release cadence – how often are you releasing into production? The second one is failure rate – how many releases actually succeed. Often simply knowing those will tell you a lot. Added to that is the Mean Time to Recovery (MTTR). When a bug is reported how long does it take for the fix to move from development to production? Finally, how much unplanned work is there? How often are developers being moved away from what they should be working on, to focus on bug fixes and problems?

As a general rule of thumb, DevOps increases the release cadence, reduces the failure rate, decreases the MTTR, and makes unplanned work the exception rather than the norm.

What business value does Database DevOps bring to an organization?

What we often find is that the database can ultimately be holding some companies back from making the most of DevOps because it’s the bottleneck in the process. So including database development in DevOps is going to make sure your IT team is operating at its best efficiency and you’re unlocking all the value you can.

Better processes, training, knowledge sharing and collaboration, alongside easy, worry-free deployments also result in happier employees, which is a value in itself. If someone’s job involves doing really interesting, value added work 5% of the time, and fire-fighting, re-factoring, manually creating scripts and fixing things the rest of the time, they won’t be around for long.

Finally, database DevOps can fuel and accelerate the time to value for new features and new requests. So, once organizations have gone through the learning curve and adoption, and built the process and culture, they can deliver value to the business a lot faster.

What is your one key Database DevOps takeaway?

It’s worth the effort! DevOps will be new to a lot of people and it can initially appear counter-intuitive. You’re going to spend a lot of time writing tests and automating processes and automating your infrastructure to make everything go faster, and that can be a difficult concept to grasp. But it’s definitely worthwhile investing the time because you’ll reap the benefits of fewer errors and hot fixes, happier employees and releasing value faster.

The presenters of the webinar which formed the content for this post were: Chris Unwin, Pre-Sales Engineer at Redgate; Justin Langford, Co-Founder and Chief Executive at Coeo; Chris Kerswell, Sales Engineering Manager at Redgate; and Andy Jones, Principal Consultant at Coeo.

For more information about how Database DevOps can help you deliver value faster while keeping data safe, visit Redgate’s Database DevOps resources page online.

Coeo is Europe’s number one data platform specialist, and works with the latest Microsoft data and analytics technologies to provide strategy, consultancy, and support to businesses who need to get the most from their data. To find out more about them, visit them online.