Now that 2017 is upon us, I want to officially anoint 2016 as the year that DevOps finally embraced the database. After being on the backburner for too long, 2016 was the year that the database finally took center stage within DevOps.

From countless success stories, to a wide range of influential figures endorsing the idea, DevOps for the database seems like it’s here to stay.

DevOps Mantras to Live By

For those planning to adopt DevOps for the database, and even for those on the fence, I have compiled some tips on how to optimize your database for DevOps and meet your organizational goals.

1.  Foster an environment that brings DBA’s developers, and operations together

Earlier this year at the DevOps Summit in Brussels, IT expert Dan North explained what he thought the source of this disconnect is, and why.

“Sadly, too few developers understand what goes on in a relational database…On one hand it makes it easier to develop basic applications…but things quickly become complex when your desired domain model diverges from the database schema, or when there are performance, availability or scaling considerations. At this point having a helpful DBA as part of the development team can be invaluable.”

DevOps-best-practices

For North, an expert in Agile methodologies, the ideal model is realized with DBAs as an integral part of both Dev and Ops teams:

“DevOps is about integrating the technical advances of agile development such as continuous integration, automation and version control into an Operations context, at the same time as retaining the rigor and discipline of the lights-on mentality.”

2.  Database downtime prevention and control – don’t panic!

Obviously, database downtime is damaging. And in some cases, it’s extremely hard to prevent- but possible. Vinay Joosery, CEO of Severalnines, gave sound advice earlier this year on dealing with and preventing database downtime. First:

“simulate failure scenarios – from servers running out of disk space and crashing, to network or power failures. Do your systems recover automatically? Do you have to apply manual procedures? Document your findings for future reference so you’ll be ready for the real thing.”

Joosery points out that careless mistakes can be made during planned database downtime, which could occur with system upgrades, and configuration or schema changes. While it seems obvious that everyone would be on the same page during this planned downtime, it is imperative to rehearse and prepare for these as you would for unplanned database downtime, to prevent unexpected complications that could come up during updates or changes.

The best way to ensure your system’s safety, according to Joosery, it to take a more agile and forward-facing approach to database planning using visualization and db security solutions to build your database thoughtfully and cohesively for continuous deployment — with secure backups and drift resolution mechanism integrated into the system. He suggests performing backups on servers with the least load at least once per calendar quarter, to be sure your database can survive an emergency. Also, he implores DBAs to “allocate enough space to store daily backups in the local data center for four weeks as well as monthly backup for one year.”

3.  Automate, Automate, Automate!

While it seems like a risky proposition, database automation can free up significant time for the DBA and save operational costs. We know that DevOps stresses automation, but applying this principle to the database has seemed like a risky afterthought for too long.

Joosery believes that it can be done in a safe and efficient way, which would allow the DBA to focus on other critical tasks such as “performance tuning, query design, data modelling or providing architectural advice to application developers, further elevating the performance of your DevOps.”

Conclusion

A database that functions like a well-oiled machine is critical to the implementation of an efficient and high performing DevOps strategy. The reason is simple; a slow database produces slow results – which is bad for business.

While optimizing the database for DevOps is a must for organizations, rushing into the transition unprepared could be a detriment instead of an improvement. Understanding your organization’s goals as well as evaluating the capabilities of your DBAs, developers, and operation managers is imperative for the transition to be a success.

Enjoyed this article? Find out what are the best practices for database management in our next article.