The Main Obstacles to Implementing Database DevOps

  • Comments posted to this topic are about the item The Main Obstacles to Implementing Database DevOps

  • It's funny that the biggest concern is actually guaranteed to happen. You are going to disrupt your existing work flow. That's sort of the point. I also see this as the biggest blocker. The phrase I hear most frequently when discussing changes to how people develop and deploy is "But we've always done it this way." That right there is a showstopper for most DevOps approaches.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • That is a scary thought to most people.  Change!

  • Maybe upskilling is a worry for some, but frankly a developer who doesn't understand how to leverage SQL Server to their advantage will not even see the need for DevOps. And if they don't see the need, they simply will not do it, no matter what incentives or approach is taken.

    Frankly, I don't understand that. Databases are exceptionally good at doing data-related things. Duh. Although, to be fair I've been immersed in database-essential applications development since the FoxPro days. The fact that developers treat databases as dumb persistent storage is face-palm territory.

    Train the developers in relational theory. Show them the performance difference between using indexes correctly and not. Show them the advantages of constraints. Warn them about the dangers of triggers, about the advantages of stored procedures. The security model using SPs is simply light-years easier than direct table access. Sure, there's a ton of SPs needed, but so what?

    Show them how SQL Server will reduce their pain. That will do more for DevOps adoption than anything else. Of course they'll have to learn T/SQL so they can write SPs but (shrug) once they stop laughing at how primitive T/SQL is and how many warts it has the other advantages of SQL Server should placate them.

    I will say one advantage of T/SQL's primitiveness is to encourage KISS on a massive scale. Annoyingly massive, but massive non-the-less.

    You want to turbo-charge DevOps? Show developers what's in it for them!

  • maroon-78 wrote:

    That is a scary thought to most people.  Change!

    I wonder how many people actually fear change?  I don't fear change for the better.  I don't believe anyone actually does.  I believe that what they actually fear is that it won't actually be a change for the better... and I also believe that the reason they have to have that fear is because they've had to live through borked up and missing functionality so very many times.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply