You often hear that data is the new oil. This valuable, ever-changing commodity has begun to play a starring role in many cloud-native applications. Yet, according to a number of DevOps teams, data issues continue to plague their efforts to continuously integrate, test and deploy frequent software releases. More specifically, issues with persistent data (and its underlying database engine) often appear to be the culprit.
Your organization might be pursuing emerging IoT applications that incorporate and analyze sensor data from multiple sources. Or, your DevOps team may be trying to develop applications that extract further actionable insight about customers. Whatever the use case, there's no doubt that back-end database architectures have gained growing importance to the success of such projects. Yet, in many cases, such database systems appear to be having difficulty just keeping up with the pace of today's DevOps pipelines.
According to one report on the state of database deployments in 2019, 46% of DevOps teams on an accelerated release schedule (with weekly or, even, daily releases) found it "extremely or very difficult" to speed their database release cycles accordingly. In a related Redgate report on the "2019 State of Database DevOps," 20% of respondents cited slow development and release cycles as one of the biggest drawbacks to "traditional siloed database development practices." Another 23% saw a higher risk of deployment failure and extra downtime when database changes were introduced in a traditional database environment.
Getting to the Heart of the Data Problem
Are such database issues the result of the wrong choice of underlying database technology — such as the use of an RDBMS, NoSQL or, even, a NewSQL system? Possibly.
Maybe database issues are also caused by poor (or non-existent) cross-communication between database experts and their developer counterparts? Undoubtedly, this is true as well.
Would you be surprised to learn both situations (wrong technology and poor communication) are often to blame? Also to blame is the urge to solve new data problems in the same old way that organizations approached their earlier, legacy use cases.
Ultimately, as with many things DevOps-related, the answer to the data problem is likely to require change along three, separate fronts: People, process and technology. It will also require a fundamental shift in how such issues are approached at the start.
Starting with People and Process
Instead of worrying about database slowdowns, what if you began again with how DevOps teams first approach the many facets of the underlying data layer? This means:
1. From the start of a project, include database administrators (DBAs) as part of the cross-functional DevOps team. They will help promote healthy cross-communication. They will also positively influence the development of appropriate underlying data layers and infrastructure that support your emerging use cases.
(In larger organizations that manage many data sets, these may be specialized DBAs. In smaller companies, these may be more full-stack engineers who also have high-quality expertise in database operations.)
2. Identify early the different data types, domains, boundaries and optimal cloud-native patterns associated with your data. Once these are established, the team can gain a better understanding about the different ways that might be needed to develop applications and data architectures for each new use case.
In effect, organizations need to make a concerted effort to "shift left" with their overall data architecture discussions. This shift allows more of the right questions about data to be asked, answered and incorporated early on in the design of the overall application.
Read Why Choosing the Right Data Path Can Make or Break DevOps Projects - Part 2
