back to article Whew! How to tell if a DevOps biz is peddling a load of manure

If you are a data centre provider with a new DevOps division that is actually just two blokes sat in a call centre who kind of know what DevOps is, then you're probably not doing DevOps. Also, if your DevOps toolset doesn’t include quantifiable tasks metrics and call stack analysis technology, then that's probably not DevOps, …

  1. Lysenko

    My Bullshit detector says that...

    “In the old days, ... optimised for reducing Mean Time Between Failure [MBTF]. This was appropriate in a world with a high cost to repair, ... In the new DevOps world, you optimise for Mean Time To Remediate (MTTR), because you make the cost of repair very low by allowing very rapid deployment and limiting exposure,”

    ...is just our old favourite: "Beta test in Production". No surprise it comes from an industrial scale patch factory like MSFT. Poster children for this approach are IE, Java and Flash. Don't worry too much about shipping security holes because you've got high performance patch servers that allow you to fight a continual rearguard action against your own continuous delivery of agile defects.

    The problem is 'cost of repair' isn't a simple metric. The cost to Adobe of shipping continuously insecure Flash is destruction of customer confidence in the brand, which is not something a DevOps toolchain can track and churn out pie charts about.

    Cost of remediation is already way too low and has been encouraging bad practice for years. Lowering it further is solving the wrong problem and it only takes one serious economy updating it's Trading Standards and Consumer Protection legislation to invalidate the entire premise.

    [*] And lets not even think about IoT with millions of units with embedded firmware that is next to impossible to update efficiently if at all.

    1. Destroy All Monsters Silver badge

      Re: My Bullshit detector says that...

      IE, Java and Flash

      Putting Java into the same pan as IE and Flash is a tad unfair, though.

      Even very unfair, TBH.

      1. Lysenko

        Re: My Bullshit detector says that...

        Yes, you're right. I'm being biased here by that search toolbar hijack BS. Mentioning Java in the same sentence as Flash (except as a counterpoint) is unfair.

  2. Camilla Smythe

    DevOps...

    Is this 'new' as in DevOpsOrrhea1 or should we wait for DevOpsOrrhea2 to solve all of our problems?

    Trust me. I do not have a fucking semblance of a clue but beer might make me prescient.

    1. Mark 125

      Re: DevOps...

      Don't you mean DevOpsOrrhea2.0

      This entire subject was a whiff of Web2.0 BS about it.

      1. Anonymous Coward
        Anonymous Coward

        Re: DevOps...

        > This entire subject was a whiff of Web2.0 BS about it.

        A whiff? Pass the salts!!!

  3. JLV

    IBM Rational ClearCase? Really???

    If there was ever a product that did not conform to any notion of stability, usability or simplicity then CC would be it, no? Contrast with git, for example.

    I wonder why it's quoted here as anything but as a bad example. Maybe it was meant as part of the 'vendor BS' demos?

    And I agree with Lysenko about the production beta bit. It's all fine and dandy for twitter or facebook instances to fall down on their butt and get replaced, hopefully invisibly. Not quite the same when your messy code has been installed on someone else's machines.

    DevOps is a great idea, and it can be used to improve quality by speeding up test cycles. Or production web deployments in appropriate cases. But it doesn't really help if the code has shipped/been installed with errors in it - it just makes recovery hopefully somewhat less painful.

  4. Doctor Syntax Silver badge

    "Mean Time To Remediate (MTTR)"

    How about aiming for something different: NNTR (No Need To Remediate) AKA Get It Right First Time?

    1. Destroy All Monsters Silver badge
      Holmes

      Do not be so pretentious.

      You will never get it right first time, unless someone already wrote the book on how to do it before you.

      And even then you need to be able to read.

      POGUEs collecting medals for bravery etc.

      1. Anonymous Coward
        Anonymous Coward

        > You will never get it right first time,

        Speak for yourself, lad.

        Couple tricks that helped me:

        * Know your business domain inside out, outside in.

        * Start from a really basic minimum viable product (prototype).

        * Reality-check the thing constantly as it develops / evolves.

        * Be humble, accept criticism, be in control.

  5. Anonymous Coward
    Anonymous Coward

    I just joined a DevOps team... seems like normal Ops, but without the grown-up stuff.

    1. allthecoolshortnamesweretaken

      That's as good a definition as any.

  6. Anonymous Coward
    Anonymous Coward

    DevOps smells like BS

    How would you like your bank to tell you after they screwed up your account "Hey, we're using failure as an opportunity to learn here".

  7. allthecoolshortnamesweretaken

    "Let us collectively agree that the last half of this decade is a DevOps bullshit free zone and (hopefully) use some of the provisos and technical components described herein to separate the wheat from the smelly chaff."

    The rest of this decade (or the beginning of the next) will be free of DevOps BS as soon as DevOps gets replaced with the next buzzword.

    How about "brisk OpsDev"?

  8. John Smith 19 Gold badge
    WTF?

    "..in the old days," "..optimised for reducing Mean Time Between Failure [MBTF]. "

    From the head of MS Developer Studio.

    Hahahahahahahahahahahahahahahahahaha

    "..optimised for reducing Mean Time To Market" maybe

    "..optimised for getting developers hooked on cheap tools that are inadequate for large scale development definitely

    Yes, I think I'm starting to calibrate my DevOp BS detector quite well.

  9. Gene Cash Silver badge

    DevOps bullshit detector

    A siren connected to a battery. No "off" switch.

    Today is throw half-finished software out there and let the users QA/beta test it. That goes for anything from internal tools to video games.

    That's because of the "we gotta get it out there before the other guy does" mentality. I don't see that going away and I don't see anyone giving a shit EVER about quality any more. This is because users don't expect quality. They're used to broken shit and don't demand anything different.

  10. Long John Brass

    washed up bunch of sysadmins and DBAs

    > A washed up bunch of sysadmins and DBAs who thinks they know how the finer points of operations should work in the 21st Century

    And that's the attitude most Devs seem to have of OPs teams. Fine by me, give em root & put em on call

  11. Anonymous Coward
    Anonymous Coward

    BS Detector alert

    "Customer: Hi, I need ..."

  12. STZ

    "..optimised for reducing Mean Time Between Failure [MBTF] " ...

    ... equates to having failures more often. A good descripting of current IT trends ...

    (;-))

    However, you would need to increase MTBF if you want better quality. Just another example where BS detection failed ...

  13. LHGFLICOD

    Washed Up DBA

    I am making a good living cleaning up after badly DevOpsified stuff, much like agile its not some kind of magical unicorn tears that you sprinkle around and everything works.

    Currently I see a lot of the following:-

    Agile = Waterfall without the testing.

    DevOps = Writing puppet modules that only sort of work then finishing the configuration by hand.

  14. JLV

    throwing babies out with bathwater?

    A good deal of skepticism certainly seems warranted, and I agree with pretty everyone that states that DevOps is not an excuse to shove turds out the door.

    But at heart, it is just tools and methods. You can use them responsibly or not, depending on your mindset.

    2 things stand out for me:

    - automate your server/app/<whatever> builds.

    I.e. don't configure by clicking or manually running stuff. Slow, error prone.

    But it's not just automate everything via laboriously hand-built shell files. You can use config management tools like Chef that do an amazing lots of things around package and library installation and configuration file scripting.

    You can take those install and configuration directives and put them under version control.

    The outcome is that, once it's done, you should be able to build a server really quickly, without worrying too much about it. Whether you are brave enough to do so on a production server is one thing, but surely things like resetting a QA server or copying the production environment to a dev server will benefit from less manual intervention.

    - have your dev and ops team work together more closely.

    That's not necessarily saying let devs anywhere close to production. But breaking down communication barriers and working together on configuration tools will give them a better feel for the moving parts their programs will interact with in prod. Surely not a bad thing either.

    Coming from the dev side, using Chef has given me way more insight into Linux system internals than I would have had if I was doing all the configs by hand willy nilly.

    But, yes, DevOps is not fully mature yet.

    Fail fast, fail often isn't too cool when it means code that hits paying customers or users. In Chef at least, a lot of the ecosystem at least seems to assume you are operating in an freebie/open source-y context: your programs' codelines are coming from open GitHub, so no authentication is needed. Your packages are all an apt-get repo away, without worrying your pretty head about the $50K/server license that the vendor has in mind for his amazing enterprise app. The programs you are using are amazingly all script-configurable, no click-only GUIs to be found. Unicorns are merrily dancing on rainbows.

    At heart however, DevOps tools allow configuration automation and versioning and I see that as a benefit if not abused.

    1. Lysenko

      But at heart, it is just tools and methods

      >>- automate your server/app/<whatever> builds.

      Devs have been doing that since forever. From a BAT/shell script to compile and link everything to BitBake/BuildRoot to assemble the entire "server" image - including recompiling (or cross compiling) the linux kernel and everything else from source where needed.

      TDD and unit tests aren't new either (SUnit - 1998) and you can host config scripts in Subversion or even (shudder) Visual Source Safe!

      Having said that, I think some of the skepticism is due to the DevOps cheerleaders not clearly articulating the market they are aiming at. Apparently because they don't realise other segments exist.

      They writing for a world where everyone is building InstaSnapTwitBook, obsessed with "teh shiny" over quality, where bugs don't kill people, melt down $250k machines or require expensive re-certification. This isn't obscure stuff. Rolling out new firmware for a tablet or phone works that way. That's why there is so much dodgy old Android still out there (and why it's so weird these Gitters don't "get it").

      In my world Devs write firmware for microcontrollers/embedded Linux SBCs and Ops oversee burning the resultant images to thousands of devices that get shipped out and installed in some hard to access places - often with no TCP/IP connections. We have some trivial edge cases where web browsers, cellphones and javascript are relevant, but not many. We call it M2M, hipsters call it IoT and if one brings this "release now, fix it later" (MTTR) mindset to the field you get FUBAR.

      1. Destroy All Monsters Silver badge
        Windows

        Re: But at heart, it is just tools and methods

        I like this reference to SUnit.

        And then I notice that - in 2016 - we are still not at the level of Smalltalk.

  15. Stretch

    "Real DevOps is about bringing teams together to build a technology stack that can support agile deployment and dynamic workloads without sacrificing security and stability."

    Woah. And you fall face first into the management bullshit there.

    DevOps is just the latest buzzword for deployment

  16. SpicyNeuron

    Sam has history

    Sam Guckenheimer, Senior Director of Technology for Automated Test for Rational (now @ MSFT) has deep background in the automation aspect of DevOps. Agree that there is lots of fertilizer in this trend and that the next buzzword will resolve all current limitations. Basic DevOps can be achieved with IBM RATL ClearCase UCM, but why even bring it into the conversation when Rational Team Concert (RTC) and Jazz tools (jazz.net) is the new development churn engine? Be vigilant development teams, start with baby steps, expand automation slowly, and attempt to make steady gains. Yes, plenty of smelly chaff out there waiting to take your $$$ budget. Now...where did I put my pitchfork?

  17. Spod

    Anything that calls itself a biz will automatically set off the BS detector!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like