The DBA and DevOps - The Last Frontier

The Database Administrator (DBA) was one of the last to enter the DevOps world. Considering our control issues, you'd think we'd been the first, but that's not how it went down. Delphix isn't the only one that's surprised by this; Robert Reeves, the CTO of Datical, a database software company that specializes in DevOps, was shocked that companies still work with their databases "the same way we did in the 1990's" when it comes to DevOps implementations. Ninety-one percent of respondents to a survey put out by Daticalstated that new solutions for addressing the database tier were required, as changes to the database tier were consistently delaying release times. I believe for many, it's an easy process to recognize the failure of having the DBA as the last introduction to DevOps and also the reason the database is viewed as the biggest delay.

Why did it take so long? As a DBA with almost two decades of experience, I've come to realize that DBAs are secure in trusted ways to complete tasks and many of those aren't compatible with DevOps practices. Where new DevOps features are quite agile, fast and automated in their approach, the DBA often choose very methodical resolutions with guaranteed outcome over speed of completion. I've been touting automation for years and I was aware how many DBAs had a significant fear of automating tasks which would be viewed as removing value from their role. The liability of the database administration resources or managers with limited vision searching for ways to work around needing administrators is where the cloud was born, which is further fed by DevOps.

The goal with DevOps, from the database perspective should be to automate what should be automated and commence with valuable resources to more valuable tasks. It's a combination of culture, processes and technology that create a fluid set of practices that aid in successful and powerful shortening of the development process. The processes and technology are easy to bridge- but, culture is not. As a DBA, I enjoyed offloading manual and tedious tasks to automation, allowing me to use my more advanced skills and engage my mind in interesting work. I also enjoyed working with other groups, having a belief that I couldn't do my job without the skilled resources around me. Our skills were enhanced as we learned from each other and DevOps concepts were simply logical to me, but how do I help those convinced that the previous, more manual and archaic way is how their value is justified? How do I help them view DevOps as worthy of their time and engagement? One of the biggest hurdles to overcome is the huge gulf between the database administrator and the developer. It's common to have some disrespect over the role the other group plays and the impact to each other's day to day tasks. The developer is often dependent to the DBA to make a database accessible and up to date for their development work. In turn, the DBA feels dependent on the quality of code and releases to production from the developer, since the DBA is the one responsible for any interruption to service and performance by new features implemented from development. In each DevOps enablement project I've been involved in, DevOps is successfully adopted at an excelled rate by organizations that have a good relationship between database administration and development.

The most successful DevOps teams have a strong rapport between groups and believe that everyone is part of the solution, not the problem. There are common areas that need to be addressed as part of any DevOps project:

• Automation/Scheduling

• Scheduling/Configuration Management

• Orchestration/Monitoring

• Version Control

• Virtualization and Containers

• Culture

While we proceed in this multi-part series into the complexities of DevOps adoption, I'll try to address a few of the cultural challenges along the way of implementation when the relational database is in the center of it all.