In this fourth session in our DevOps 101 series, we’re going to delve into Database DevOps specifically. But before we get going, I just want to do a quick check to make sure we’re all on the same page. Donovan Brown’s definition of DevOps seems to have been adopted by almost everyone nowadays because it’s very clear: “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users”.
That’s what we’re going for here, it’s not about any particular tools or methodologies. It’s about people first, process second, and products third, to enable us to deliver value. So let’s dive in a little deeper into the challenges you may face when introducing Database DevOps, and the opportunities waiting for you when you succeed.
The people challenges to Database DevOps
When we start talking about Database DevOps, a common issue that comes up is FUD: Fear, Uncertainty and Doubt. People working on applications tend to adopt DevOps easily and readily, yet from a database or data management standpoint, DevOps has a lot of FUD, often born from bad information. That can manifest into five typical objections.
Database DevOps only works for new systems
If you’ve got an established brownfield product rather than a new greenfield project, you can’t possibly implement Database DevOps, can you? I want to tell you that is absolutely not true. That’s not to say it’s easier to do it because there are a few more challenges, but when people say you can’t, that’s just FUD coming out.
Database DevOps means our development teams get increased privileges, and I’m out of a job
This is also not true and actually the opposite is what’s probably going to occur. Your development team are going to get less access to production systems because Database DevOps requires stringent processes to protect data.
‘No ops’ means we’re getting rid of the ops team entirely
Does implementing Database DevOps mean we’re going to get rid of the Ops team entirely because everything is code? Er, no. The fact is, there are certain levels of knowledge and specialization required to do a lot of this stuff. Are we aiming for code first? Yes. Does that mean that there will only be developers? No. It just means there’s a greater pool of people writing code, including the Ops team writing infrastructure as code. That is what ‘no ops’ is supposed to represent, but it frequently gets misinterpreted.
Database DevOps can’t handle security and meet compliance issues
This isn’t the case either. Database DevOps and DevOps methodologies require more stringent processes, and therefore lend themselves to better security. The idea that if you’re doing Database DevOps, you can’t do security and compliance is crazy. Implementing DevOps processes increases the security of your systems and enables you to build compliance into the normal workflow.
Database DevOps means you don’t follow any processes
As we already know from Donovan Brown’s definition, that one’s just not true. It’s the marriage of people, process, and products that make DevOps happen. We’re not eliminating process, we’re building and defining a process that is more stringent and clearly defined, and then introducing automation to it.
The data challenges to Database DevOps
Redgate runs a regular State of Database DevOps survey, and one key theme that repeatedly shows in our results is the silo between developers and database professional like DBAs and database engineers. In our 2021 survey only 22% of respondents felt that they were working effectively as a single team, so there’s obviously a lot of room for improvement here. There’s a massive need to bring everyone into the concept of being one team.
But why is the isolation of database development from application development so common? One of the biggest reasons is the fear of deployment failures leading to downtime. So instead of integrating with development teams, data management teams isolate themselves. They wall things off and oppose change to make it easier for them to control things which, in turn, makes it harder to automate processes and slows down development cycles.
So what are those data challenges that cause database teams fear (and uncertainty, and doubt) when implementing DevOps?
If you were to treat your databases strictly as code, ignoring the idea of data persistence and that you must keep the data, there is a problem. Any kind of migration that you make in terms of moving a new change into your production systems has to be done in such a way that it retains the data. You cannot simply drop and recreate a database like you would an application. The persistence of the data must remain and you have to retain it.
If you’re working on a 50 or even 100 MB database that can fit on your laptop, your pain for making changes is extremely low. Whereas if you’re working on a 1 TB or 1 PB database, your pain for implementing database changes is extremely high. Database size absolutely plays a factor and is also going to affect the speed and difficulty of your deployments. It’s something you have to plan for and consider.
Volume of change
When I talk about the volume of change, I don’t simply mean the number of deployments that you’re doing, although that can affect it, I mean the number of transactions occurring on the system. The volume of change coming into your data as you’re trying to deploy can seriously and negatively impact your ability to do database deployments. Again, this must be something to plan for and consider.
In many teams and organizations, there’s a lack of monitoring on production systems, especially when it comes to tracking changes to the underlying structures of your production systems. That lack of monitoring forces you to be reactive and not discover problems until a long time after you’ve made changes.
The opportunities Database DevOps offers
I want you to start thinking of Database DevOps itself as an act of protection. Like a seawall that protects a harbor, it means ships can come into port and be in a safe place when the storms come raging in. Database DevOps to me is that seawall, because we’re talking about introducing more stringent processes, a tighter methodology, and automation as opposed to manual changes.
The key is that it’s the same fundamentals and foundations as DevOps traditionally seen in application development, which opens the door to the same opportunities.
Communicating as one team
DevOps is actually a methodology of communication. It’s a mechanism that allows us to communicate better. Applications are all about communication, data is all about communication, and most importantly code is all about communication.
Code is just a language, whether it’s T-SQL or C#, they’re modes of communication. You’re focusing on communication to eliminate barriers between teams. Bringing your operations team, AWS team, Azure team, developers, and data management people together to work as one team is your primary goal. Remember, it’s all about utilizing people, process, and product to support your users. That’s the one thing I would drive as much as humanly possible, because it is so easy to fall into this tribal structure. One team: always start with that.
Source controlling code
The next thing when we talk about DevOps is the fact that all code must go to source control. You need to treat your databases as if they were code as much as you can. Applications are already that way and everything goes into source control. Database developers need to start adopting the same approach. Having your code in source control, specifically your database code, acts as a backup. True, it’s not a backup for your data but it is a backup for your data code. Source control gives you more ways of recovering so think of it as a backup or an undo mechanism that you never had before.
Shifting testing left
Shift left is one of the most fundamental aspects of DevOps. The concept is that you want to make your non-production environments as much like production as possible by eliminating non-production behavior. But a shift left mentality also adds protection to your production servers because you’ve got a more production-like non-production environment. Your tests are more accurate to production, and you’re testing on life-like data sets, data structures and even the size of your data in some cases. So when you finally deploy to production, you’re going to deploy more successfully, and without outages.
One of the most important elements of automation you’re going to introduce is testing, because you want to have testing run continuously as you work. That is fundamental to what you’re doing and one of the key mechanisms to ensuring that you’ve got full blown DevOps going.
You’re also adding protection as you automate your testing by adding another layer to ensure what goes into your production environments is safe and will work. You’re not running scripts for the first time in your production environment because you’ve run them multiple times in environments that simulate production as close as possible, so you can be sure of it.
This is the end goal. You want to make sure your deployments can be done in an automated fashion. The scale of automation will depend on your specific project, and you’ll figure out what’s right for you, but ideally you want to automate as much as possible.
I want to automate all the way into production, no question, but baby steps are required. You’re going to start with small steps and work your way up. Automating deployments is about practice. If you practice your database deployments, you can ensure you’ve got a good methodology that’s going to work.
When you’re introducing Database DevOps, communication is everything. If you’re not communicating well in your team, and if your business and technology teams are not communicating with each other, your chances of failure increase.
DevOps provides methodologies and mechanisms to arrive at better communication, and better communication means fewer failures. It fosters collaboration by eliminating barriers. It’s not that Dev team and that Ops team – you’re sharing information in such a way that you’re integrating these teams as one towards a shared goal.
But that’s not all, DevOps is also going to lead to faster and safer deployments, and I can’t emphasize enough how important this is from a database standpoint. We’re talking about superior processes adding safety and protection, yet with speed.
My takeaway message is that DevOps equals protection. If you work with the database, you know that protection is the number one issues that comes up all the time. Database DevOps will help you manage your databases better, so that’s why I’m in favor of it. That’s why I think you need to pursue it, and that’s why we’re going to continue talking about it a whole lot more in upcoming DevOps 101 sessions.
If you haven’t read them yet, you can catch up on the other posts in this DevOps 101 series:
- DevOps 101: What, who, why, and how
- DevOps 101: How do you get buy-in from people?
- DevOps 101: How to kick-start your DevOps initiative
- DevOps 101: The role of automation in Database DevOps
- DevOps 101: Unlocking the value of frequent deployments
Was this article helpful?