Tips for Implementing DevOps for the Database
Tips for Implementing DevOps for the Database
Databases are perhaps one of the last holdouts to the DevOps movement, and for good reasons. See how this is changing and what you can do to foster it.
Join the DZone community and get the full member experience.Join For Free
pppNow 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.
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.
The Right Environment
Foster an environment that brings DBAs, 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.”
For North, an expert in Agile methodologies, “The ideal model is for DBAs to be an integral part of both Development and Operations 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.”
Managing and Preventing Downtime
Database downtime prevention and control — don’t panic! Obviously, database downtime is damaging. And in some cases, it’s extremely hard to prevent — but it's 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 establish a secure backup 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.”
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 modeling, or providing architectural advice to application developers, further elevating the performance of your DevOps.”
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 are imperative for the transition to be a success.
Published at DZone with permission of Yaniv Yehuda , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.