During a DevOps implementation, some organizations incorporate the database and its key overseers, including database administrators and data architects, after the fact -- when DevOps has already been tuned for non-database coding. But databases are the heart of business-critical apps. Any DevOps implementation that doesn't incorporate the database will be an ongoing source of CIO frustration.
A DevOps team without a database administrator (DBA) to fix database-related performance issues doesn't know what it doesn't know. App performance can be a particular source of angst. Conventional database designs expose key performance parameters to the coder, allowing some developer control over per-app performance. But the typical developer deals with C++/Java or some variant, with data persistence carried out on the server or internet, and object-relational layers plus mapping layers further abstracting the underlying databases. This leaves many developers with little or no experience with database performance optimization and little control over database performance tuning. That's where a DevOps DBA comes in.
Approaches for database, DevOps integration
The DBA is the obvious person to include in a DevOps team, but many DBAs are so consumed by fixing problems, even with administrative automation, to the point where they cannot set aside the time to work in a cross-functional group. An alternative and often more successful approach is to split the DevOps DBA role into two: a front-end DBA who handles the overall administration of the enterprise's database architecture, and a back-end DBA, who acts as the fire fighter dealing with issues and production deployment optimization. As part of the team, the front-end DevOps DBA reports any changes in transactional patterns and improves database performance.
A DevOps strategy that doesn't factor in the database also leaves out a key IT role: the data architect. This half-business user, half-developer creates deep-dive analytics for the CMO -- but app performance problems due to poor database tuning can prevent that from happening.
Consider adding data architects to the DevOps team's list of clients. If a DevOps team creates its own analytics apps, the data architect may request specific tools. In turn, DevOps and database administrators can deliver greater IT value to the data architect.
Busting common DevOps myths
Experts Stephen Hendrick and Chris Riley share ways to tackle DevOps problems at their source. Listen to the full podcast below or check out the article that breaks it down into five specific DevOps problems.
A third part of DevOps-database integration is setting up DevOps database tools. IT teams should integrate these tools with the overall DevOps tool chain, but also focus them on database needs. One important example is database change management. In most databases, changes that involve database semantics tend to be complex; the wide range of end users, and of databases in the typical enterprise, means that a simple change in one database can cause a ripple of disasters across other areas of the overall database architecture and key applications.ing common DevOps myths
A database DevOps tool automates and restricts those changes. For example, database administrators could use a data governance tool as part of database builds and change management to begin continuous delivery of patches and upgrades, as well as enhance the overall quality.
Seeing database administrators as part of the DevOps process, and data architects as agile DevOps users, is a new way of thinking about databases that allows enterprises to create better database administration customized for an enterprise's needs, as well as avoid major DevOps adoption problems.
Understanding the top responsibilities of a DevOps team
CMDB tools ease change management projects
Does my data center need configuration management?