If you’re a database admin, you may not have paid much heed to the hype surrounding DevOps over the past decade. The DevOps movement has focused primarily on making work more efficient for developers and IT operations teams. For better or worse, database admins have not been a major part of the DevOps conversation.
That’s a shame because database admins have a lot to gain from DevOps, too. Keep reading for a list of reasons why.
Databases and DevOps
DevOps has traditionally been about bringing developers (the folks who write applications) and IT Ops teams (who deploy and maintain those applications) closer together. Instead of each of these teams operating inside their own “silo,” DevOps promotes the creation of a DevOps mindset, which integrates developers and IT engineers into a single software delivery operation, extending from initial coding through post-deployment monitoring and management.
Databases tend to come up within DevOps discussions only when they are something that developers and IT Ops teams need to deal with in order to work better together. For example, if figuring out how to provide persistent data storage to Kubernetes or Docker applications is a challenge your DevOps team needs to solve in order to containerize its infrastructure, it has probably spent some time thinking about databases.
Beyond this, however, database admins have for the most part sat quietly on the sidelines as DevOps has transformed application delivery over the past decade. Nobody has spent much time asking for their perspective, or proposing that they be integrated into the application delivery process in the same way as other types of IT professionals.
How DevOps benefits database admins
Again, excluding DevOps from the conversation is a shame. There are a number of ways in which the principles behind DevOps can benefit data admins.
Better communication across teams means better data
The core foundational idea of DevOps is that everyone benefits when developers and IT Ops work more collaboratively and transparently, rather than existing in silos.
This logic applies equally well to database admins. If the folks responsible for keeping data available and secure are left in their own silos, they’re poorly equipped to make sure those databases are available when needed.
Instead, database admins should communicate constantly with developers, so that both groups are better positioned to meet each other’s needs surrounding data. Maybe developers are trying to troubleshoot data encoding issues within an app, for example. Being able to communicate well with data admins is certainly important for that purpose.
Likewise, better collaboration between database admins and IT Ops is a win for both sides. Perhaps IT Ops wants to standardize all data into one type of database (like MySQL) instead of maintaining multiple types. Collaboration and a strong relationship between database teams and IT Ops is important for achieving that goal.
Data is continuous, too
Another principle that DevOps promotes is “continuity.” In a DevOps world, you don’t deliver software updates every few weeks or twice a year. You make them continuously, pushing them out on a near-constant basis.
The same concept can benefit database admins. After all, modern data life cycles tend to be continuous in nature, or at least they should be. Batch processing doesn’t work well for powering apps that require streaming, real-time data. Nor can you take a “we’ll fix it during our next weekly update” approach to data security issues.
For database admins, adopting the same mindset as DevOps teams regarding continuity can be a big boon for increasing efficiency and productivity.
DevSecOps includes data security
One of the most important offshoots of the DevOps movement is DevSecOps. DevSecOps promotes the idea that security should be an integral part of the application delivery process, rather than something that is done in a silo.
It’s hard to guarantee full security if the reach of your DevSecOps operations doesn’t extend to databases, too. Databases are one of the most alluring targets for attackers, and securing them requires input from the admins who create, maintain and manage them.
Sure, DevOps teams can secure access control to databases from within an application, or deploy security tools to help detect unauthorized access. But it’s only with help from database admins that they can actually maximize the security of the data inside databases by, for example, ensuring that unnecessary sensitive data within a database is removed.
When you hear DevOps and database in the same sentence, another buzzword might come to mind: DataOps.
So far, I haven’t mentioned DataOps, for two main reasons. One is that the DataOps movement takes its inspiration more from the Agile movement – which preceded DevOps – than from DevOps itself. (If you need evidence of that, just compare the websites of the “Agile Manifesto” and the “DataOps Manifesto.”) The other reason is that the core principles of DataOps are targeted more at data scientists than database admins.
As a result, database admins might feel a bit left out of the DataOps movement, and/or assume that DataOps means something other than DevOps applied to data. You could make a case that both of those viewpoints are valid.
That said, despite what I just pointed out in the two preceding paragraphs, if you do choose to think of DataOps as DevOps for database admins, then I’m all for encouraging database admins to embrace DataOps.
DevOps, DataOps and service reliability
Okay, enough splicing of buzzwords. Back to the main point, which is that, although database admins may not have paid much attention to DevOps (or had DevOps advocates pay much attention to them), it’s time for that to change. Despite appearances, database admins have much to gain from leaving their silos and embracing the same principles as DevOps teams.