Security isn’t the only aspect overlooked in a DevOps approach. According to Robert Reeves, co-founder and CTO of Datical, a database automation company, database deployments are often forgotten about.
“Pushing out the application is the easy part of DevOps,” he said. “It is managing and automating database changes that is the real challenge.” According to Reeves, the database deployment process is often slow, error-prone, and resource intensive because a lot of companies are still doing it manually; but that causes it to get in the way of development teams and operations working together.
“We call it the velocity gap,” Reeves said. “We are getting faster and better at application development, but none of that is available to the database team. Companies are finding their drive to adopt DevOps is being blocked because they can only move as fast as their slowest member; and right now it is the database.”
Similarly to security, the reason why the database is causing such a roadblock is because it is typically the last team to be brought into the life cycle. Databases cannot be reverted or replaced like application features. It is designed to preserve and protect data, and for that reason it must be preserved itself. “Another reason why the database has been late in the DevOps game is because solving this part of the application delivery lifecycle is so complex,” said Ben Geller, vice president of marketing for Datical. “On the application side, if the developer makes a mistake and breaks the application, they can blow away that code and start over. You can’t do that when you are updating the database. The database is always in constant motion, so you have to have a purposeful way with respect to how you get those changes made and go fast.”
To solve this, the database team needs to be engaged sooner, and the process needs to be automated, Reeves explained. According to the company, to successfully bring the database into the DevOps fold, database administrators should be integrated into the team, learn about development, and trust the development process.
DevOps means having cross-functional teams, so the database administrators should be a part of the team and able to weigh in on the architecture, according to Reeves. In the traditional way of doing things, when a change happens the database admin typically doesn’t know why the change is happening or how it will impact the overall product. Bringing them to the team will help them understand not only the function of the product, but enable them to weigh in on the architecture.
The database team doesn’t need to become full-fledged developers, but they should learn a little bit of coding to be able to support developers and operations, and understand where the team is coming from when making important changes.
In addition, bringing the database team into the DevOps team will help create a culture of trust where all parties understand the implications of a database change, and are able to do it correctly and successfully.
“If you think it is a real pain to deal with security and database administrators, try ignoring them,” Reeves said. “Try just cutting them out and doing it anyway, and see what happens to your application. It is not going to be worth it.”
