Cultural backlash stifles DevOps for database pros
Source – searchitoperations.techtarget.com
DevOps for databases doesn’t lack for technical hurdles to overcome. But the biggest problem is a culture clash among developers and database administrators.
Developers want more speed and flexibility; DBAs want to protect the status quo — whether that’s the organization scheme for the company’s structured data or the nature of their jobs. In some cases, this becomes an irresistible force that collides with an immovable object and brings the whole IT automation process to a halt.
“We have such a bad relationship with our DBAs on the operations side that we only talk to them for production changes,” said Daniel MacDonald, architect and principal technical lead for a New York public utility agency. In the production environment, most databases are locked down so that developers can’t debug or tune performance on their apps.
“That doesn’t work in a DevOps model — where people have to wear multiple hats,” MacDonald said. “DBAs have to either start learning new things or be left out in the cold.”
DBAs should be more open to the ways in which developers and new app architectures, such as containers, can improve databases, MacDonald said.
DBAs hold their own despite DevOps momentum
Many DevOps pros in MacDonald’s situation want a future where cloud services replace territorial DBAs, but at some enterprises, DBAs have irreplaceable tribal knowledge about the data that is the lifeblood of the business.
Take Andy, for example, a DBA at LogistiCare Solutions, a nonemergency medical transportation company headquartered in Atlanta. Andy has been with the company since its application used a data management engine from the 1980s called Btrieve, and he helped convert the app to IBM’s DB2.
“The only guy that knows the stored procedures is Andy,” said Michael Quintero, enterprise solutions architect for LogistiCare. “Our relationships are managed in stored procedures, and they’re not well-documented.”
Still, “Andy only knows what Andy knows — he’s not bad, but he’s not a certified super DBA.” When the company added IBM HADR, a high-availability disaster recovery feature, to DB2, it contracted a third-party DBA “gunslinger” to oversee the work, Quintero said, and eventually outsourced daily management to a company called AllBlue.
This also had its drawbacks, culturally speaking.
“When you outsource, you communicate through a ticketing system, so there are no hallway conversations with your DBA,” Quintero said. “They don’t work for us, and we’re subject to their availability as well.”
Andy’s story has a happy ending: He’s still with the company and now manages an IBM Netezza data lake that’s used for reporting and data analytics. But not every transition from legacy systems to DevOps goes smoothly for database pros.
IT roles evolve with DevOps for databases
There needs to be an evolution in job descriptions for DBAs and developers if both sides of the DevOps for databases equation are going to agree. Horror stories exist on both sides — for every company held hostage by a stubborn traditionalist DBA in its attempts to modernize, there’s a story like that of GitLab, which lost data when a new developer had just enough control over a database to accidentally delete the wrong directory.
Some companies have found a happy medium. At Jamf, a mobile device management software company in Minneapolis, the lone DBA on staff wears many hats, said Manager of DevOps Michael Kren. Jamf’s DBA writes automation scripts around Amazon’s Relational Database Service, troubleshoots both MySQL and PostgreSQL installations, works with engineers that have database questions and does some sys admin work with Ansible playbooks and CloudFormation templates.
At the same time, Kren and his team of DevOps pros have seen their roles evolve. For example, they’ve recently taken on database containerization and are working to run Postgres in Kubernetes clusters.
In the end, developers must earn an organization’s trust to handle databases as much as DBAs have to learn new skills.