In an interview with Ben Linders from InfoQ, Dan North discussed many key aspects of DevOps, specifically the importance of database DevOps. “In the future I would like database changes to be as simple as code changes,” he said. “…I should be able to make whatever changes I choose to in a development database and then ‘check it in’ like I would with code.” He made many other interesting observations and points as well, regarding various other characteristics of DevOps.
He described the important role of database administrators (DBAs) and how they need to understand the mechanics and each intricate detail of the database itself so that they can be the middleman between the developers writing queries and the operations staff running jobs. Their job covers multiple production environments, development teams, technologies, and stakeholders, forcing them to be involved in everything from turning requests into work, to applying a security patch, to responding to production issues or answering questions from the developers. It’s on them to make sure that the backups and replications are done correctly, that only the appropriate systems and users have access to the right databases, and that any unusual system behavior is successfully troubleshot.
He lamented that as it stands now, too few developers truly understand everything that goes into relational databases. When developers who are used to using C# or Java use mapping layers like Hibernate or Microsoft’s Entity Framework, the internals are hidden. This may make the process easier for them to develop basic applications where the database schema maps onto equivalent OO data structures, but can complicate things by resulting in a desired domain model that is different from the database schema. It also can negatively affect performance, availability, or scaling considerations. For this reason, having an accomplished DBA as part of your development can be extremely helpful.
The DBA is notably helpful to the operations side as well, taking responsibility for implementing a business’s replication or available strategy. While the Ops people monitor the systems, diagnose issues, and generally make sure everything is functioning, the DBAs are monitoring, diagnosing, and handling any database-related issue and defining any database management and maintenance processes that are carried out by the operations team.
He commented on the traditional role that the DBA takes on as a technology silo that functions independently, often with very little context about the needs and constraints of the business or technology. For this reason, a mix of “Production DBAs” and “Development DBAs” can work really well, with the production DBAs working on the production maintenance work and the development DBAs helping the development teams interact with the database correctly, with regards to schema design and querying. When these two teams develop a level of trust, the Production DBAs can be sure that the others will maintain a level of quality in the schema design and database queries, while the Development DBAs trust that the others will take care of the various database instances appropriately.
He concluded by talking about the importance of having DBAs as an integral part of both Development and Operations teams, utilizing DevOps for database to create a better run organization. He stressed the pivotal role DevOps plays in database management and how a well-run database that is well incorporated with the rest of the development team can drastically affect your company.