Grant Fritchey

22 March 2021

DevOps As a Bludgeon

When I first started trying to figure out how to automate database deployments, over 15 years ago, I will freely admit, I was both skeptical and reluctant. I had to be dragged up to the notion that automating getting the database code out the door wasn’t just an excuse by the developers to find a way to bypass the DBA team. As per the traditional, biased, story, our favorite word was “No!”. However, I listened to our development team (however reluctantly), did some experiments, and, sure enough, they were right. I was wrong. I learned from them. A story with a happy ending.

However, that’s not always the case. At the most recent Redgate Summit in February, the following question came in:

“Could you talk a bit about the statement: We should move sql out of stored procedures into the application code to achieve better flow in the devops process. By avoiding a database deployment. This was in a context where it was talked about avoiding too much logic in the database. Since databases are more expensive and harder to scale.”

There’s a lot to unpack here, and most of it is bad information. Understand, ever since my education by a great bunch of developers, I’ve been a huge advocate for DevOps (heck, my job title is DevOps Advocate, so…). I have personal experience with how adopting a DevOps style approach to development and deployment has enormous benefits for an organization. I also have the State of Database DevOps survey results to back me up on that with real world evidence. I can say, unequivocally, a well-implemented DevOps process helps the organization. The trick of course is the “well-implemented” part.

Sometimes though, what we sometimes see is that an organization tries to adopt DevOps for the wrong reasons. In addition to some of the bad information in our question above, let me share a few places where people have attempted to use DevOps as a bludgeon to just get what they want, whether it’s helpful to the organization or not.

SA For Everyone

There are two fundamental aspects of a DevOps-style approach that everyone should embrace. The first is the breakdown of silos, eliminating the walls between teams to enable better communication and collaboration. The second, is, of course, automating your deployments, preferably, all the way into production. Sadly though, I’ve seen on multiple occasions that these two things lead to a bad conclusion: everyone gets administration rights on the production server.

I mean, after all, if I have admin rights, deployments are so much easier, and you want to do DevOps don’t you? We’ll just open everything up to everyone and then we’ll be doing DevOps.

Now this is just wrong. Not to mention that it violates all sorts of laws & regulations from all around the world. No, implementing DevOps doesn’t mean eliminating security. In fact, a good DevOps process should have quite strong security. In fact, a good implementation of DevOps ought to enhance security because you will need fewer personal privileges on the server since the automation takes care of a lot of the necessary changes.

Get Rid of Stored Procedures

I’m a weird DBA (for a lot of reasons and in a lot of ways, but that’s a different discussion). I support the use of Object Relational Mapping (ORM) tools like Entity Framework or nHibernate. This means we should eliminate stored procedures, right? After all, you want to do DevOps and if we get rid of stored procedures, we can just deploy everything through code, it will all be easier, we never have to get any where near the database ever again.

Once more. No. In no way at all would the implementation of a DevOps approach to deploying your code require that you eliminate stored procedures. In fact, as much as I support ORM tools, I fully recognize that some of the code generated by those tools is heinous, horrible, and just bad. Estimates vary wildly from between 10% and 1% of the code generated from an ORM tool is of questionable utility (see, I can be nice). For that code, a hand built SQL statement is probably necessary. The best place to keep that statement, for code reuse, etc., is as a stored procedure. Further, there may be security needs that can’t easily be done through ORM code but are better addressed through stored procs.

Too Much Logic in the Database

This is a very old argument and it’s one that some individuals are attempting to win by using DevOps as leverage. The argument goes that the database is only, ever, meant to be an information store. An business logic, of any kind, must be eliminated from the database. All logic, of any kind, is only, ever, in the code base. After all, you want to do DevOps don’t you?

This is, of course, nonsense. Is it possible to put too much work, logic, business processing on your database server? Absolutely. However, the reverse is also true. There’s a lot of different kinds of data manipulation that is going to be best done, right on the database server using whatever flavor of SQL that server supports. Do you really believe that the best way to manipulate data is to pull it all out of the database, over the network, onto some application server somewhere, do the manipulation, then transmit it all back across the network again and restore it into the database? No? Then some logic goes into the database.

Let’s also talk about business logic and the database. The argument for an absolute moratorium on any kind of logic within the database really makes no sense. Are all your columns VARCHAR(MAX), or do you have a DATETIME or NUMERIC slipped in there somewhere? It’s the latter isn’t it? So you’re putting business logic, this is a date, it will only ever be a date, into the database.

I can’t even begin to fathom how implementing DevOps means we have to move business logic out of the database, but, clearly, DevOps is being used as a bludgeon.

DevOps = NoOps

Now that we’re automating testing and deployments, we really don’t need that pesky old database team any more. Instead, we have DevOps.

This is one of the single most common myths that comes up when we start talking about DevOps. The idea is that the automation is so thorough, there’s just no need for anyone except the development team (who all have ‘sa’ privileges too). There’s no other way to put it, this is just nonsense.

The core idea behind DevOps is to foster communication and collaboration between teams. The idea is, if we work together in better ways, we can improve what we’re delivering for the business. Note, at no point does this suggest that we don’t need the skill sets that your Operations team brings to the table. From database administration to disk management to network configuration, and beyond, these are skill sets and knowledge bases that most developers are only going to have to some degree. By more tightly integrating all these different skill sets, we support one another better. We deliver better software.

Conclusion

I really do enjoy building out DevOps solutions, especially in and around the database. The increased cooperation that teams can have make everyone’s work lives a little bit better, not to mention helping the business. It’s a shame when people bring misinformation or old vendettas to the table when we start talking DevOps. However, these uses of DevOps as a bludgeon are very easy to spot. Any time someone starts talking about relaxing security, eliminating positions, weakening processes, they are not talking about DevOps. If they attempt to cut off teams from communication and collaboration, they’re not talking about DevOps. Watch for these tells and you’ll know if someone is simply using DevOps as a bludgeon.

For more information, I’d suggest looking at the panel discussion on the Wednesday session of the Redgate Summit.