The Main Obstacles to Implementing Database DevOps

  • Kendra Little

    SSC Enthusiast

    Points: 117

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

  • Grant Fritchey

    SSC Guru

    Points: 396384

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • maroon-78

    Ten Centuries

    Points: 1014

    That is a scary thought to most people.  Change!

  • roger.plowman

    SSChampion

    Points: 10210

    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!

  • Jeff Moden

    SSC Guru

    Points: 995976

    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.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "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 5 (of 5 total)

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