How to future-proof your databases with DevOps

With all the turmoil and uncertainty in today’s global markets, changes in regulatory compliance such as the recent European GDPR regulations and ongoing competitive pressures, most organisations know that they must be able to react quickly to external forces. Businesses are looking to become more agile so they can adapt to these changing dynamics and are requiring their IT departments to embrace DevOps.

IT managers know they have to change the way they’ve traditionally thought about database change management to better align with the way they’re doing application development. They need the confidence that they can bring database develop­ment and deployment operations into an agile DevOps process.

But the question looms – where to begin when your organi­sation has a traditional database development culture, hybrid database environments with both on-premises and cloud plat­forms, traditional and open source databases combined into one complicated infrastructure?

Traditionally database change management operations have been a long, tortuous process with release cycles typically between six weeks and three months. While more companies are embracing Agile methodologies into their organisations as a way for their business to be more proactive and innovative, incorporating database changes into these methodologies remains tricky.

This is because development processes such as unit testing of procedural code are not automated and this raises concerns over the risk to data.

Still, there are many organisations that have already fully embraced DevOps and have become very successful. Because they can release changes faster, they spend a lot less time on unplanned rework so their costs are lower and some even see revenue growth as a consequence.

But why change? If this was an easy thing to do, companies around the world would have moved to DevOps for database change management long ago. However, moving to a DevOps culture requires executive leadership to make the necessary organisa­tional changes, and takes commitment from IT to research and invest in the right tooling so you can automate processes that have traditionally been manual.

You know the database is what is holding you back from becoming fully agile but making a change like this is a big step. So, why not just keep doing what you’ve been doing? There are three primary reasons to integrate database into your DevOps infrastructure:

1. Release delays: if you have database changes that correspond to application changes, you can’t release anything into production until the database catches up. This causes a big bottleneck limiting your ability to move to an agile process.
2. High costs and risks: commercial database vendors typically impose very expensive licensing and maintenance costs that can lock you in to their technology stack for years if you aren’t careful. But you should have the freedom to choose the database vendor that best serves your business and the type of data your business stores. If you want to use MySQL or Postgres, Amazon or Azure you should be free to do that and not be locked into your current vendor because you think it’s hard or risky to change.
3. Competitive disadvantage: While you might think you’re safe doing what you’ve been doing, you’re actually falling behind. Your competitors have already embraced the move to DevOps and can now adapt to changes more quickly and innovate faster than you can.

With a DevOps culture as part of your database develop­ment cycle you can:

• efficiently produce software changes
• quickly test, QA and optimise code changes
• effectively monitor these changes
• confidently deploy changes into production without impacting the business.

Database teams that have embraced DevOps don’t work the same way they did before adopting DevOps. Before DevOps, the production DBA would be the recipient of any changes that the development DBA created and tossed over the wall then the production DBA would have to figure out if the changes would cause the application to break, despite not having insight into the appli­cation.

However, in the new DevOps culture of tribes, the development and operations teams, and other functions, collaborate from the beginning, sharing plans, changes and updates to move changes through the pipeline more quickly. Barriers between the various functional groups are erased. Updates happen more quickly and accurately and IT teams are able to support the business more efficiently.

DevOps is the new reality. Gone are the days of siloed database teams and processes. Today, the more interconnected your development, testing, QA, UAT and operations teams are, the more effective your IT organisation can be. While you may think it’s too time consuming or costly to convert to a DevOps culture, the reality is that if you don’t convert, you will fall behind.

Your competitors are embracing the change. They are now able to innovate more quickly because they can adapt to changes faster in a DevOps culture. So to keep up and surpass your competition, it’s time you embraced a DevOps culture.

John Pocknell from Quest