back to article Storage greybeard: DevOps, plagiarism and horrible wrongness

Recently I’ve been spending time thinking about what DevOps really means to my teams and to me. A lot of reading has been done and a lot of pondering of the navel. The most important conclusion that I have come to is that the DevOps movement is nothing new; the second conclusion I have come to is that it can mean pretty much …

  1. David Roberts
    Windows

    Upvote the article

    If I could.

    Much like kids discovering sex, each new generation "discovers" a way of doing things and assumes that nobody could have ever done this before.

    Cue a catchy new buzz word, and kerching.

    They should learn to work smarter, not harder.

    1. Anonymous Coward
      Anonymous Coward

      Re: Upvote the article

      Make money fast! Ask me how.

      1. "Discover" a way of doing things and assumes that nobody could have ever done this before.

      2. Get very excited because this new way is better than the old way.

      3. Write books, promote seminars, invent certifications, create a lot of hype (cough).

      4. Profit.

      5. Eventually realize (if didn't know beforehand) that it does not solve some specific categories of problems (e.g. how to profit even more when the market for books, seminars, certification is already saturated).

      6. Repeat from 1.

    2. Anonymous Coward
      Anonymous Coward

      Re: Upvote the article

      So it isn't just me then.

      I've been looking at "DevOps" and trying to work out what's funky and new and what all the fuss is about. Came to the conclusion that there wasn't anything funky and new about it, and it was just lumping "Best Practices" together and giving it a fancy new title.

    3. Anonymous Coward
      Anonymous Coward

      ugh

      ... and each formerly-new generation dismisses any improvements made by the younger generation as 'old wine in new bottles', as they of course have done and seen everything before...

  2. paddy carroll 1

    Nothing new?

    You could have fitted that on a piece of toilet roll.

    Would have been more appropriate

  3. GrumpenKraut
    Thumb Up

    Holy crap!

    A DevOps article and I agree with every line in it!

    > the DevOps movement is nothing new

    Indeed. Can we now make up some new buzzword that we'll be seeing in about 100 very exciting (cough) articles? Any ideas, anyone?

    1. Anonymous Coward
      Anonymous Coward

      Re: Holy crap!

      How about KISS & 80/20? (oh wait those are old ones...)

      1. VinceH

        Re: Holy crap!

        Yes, those are old ones - the whole point is to come up with new terminology/buzzwords that mean the same thing.

        So rather than KISS, meaning Keep It Simple Stupid, how about DOCIT, meaning Don't Over Complicate It Turdfeatures.

    2. allthecoolshortnamesweretaken

      Re: Holy crap!

      OpsDev. It's the next big thing, I've been saying it for weeks now.

      Or possibly OopsDev.

  4. Anonymous Coward
    Anonymous Coward

    And then...

    At a recent DevOps meetup, I heard a proposal that it would all work better if instead of one monolithic web app, they were made up of lots of little apps that did one thing and one thing only, and did it well, all talking to each other.

    Oddly, I thought of the original Unix principles. Not quite sure why.

    1. Anonymous Coward
      Anonymous Coward

      Re: And then...

      Another principle good on paper, like DevOps, which soon becomes a nightmare when you try to apply it in the real world. It worked in the simple world of 1970s, doesn't work today, especially when all those little apps had to work on the same huge amount of data, and proper IPC adds a layer of complexity, or forces to use data storages like files and databases - and getting data to and fro is still an issue. More so since processes address spaces became protected from each other for security reasons.

      The Unix model was also a side effect of programming languages not designed to handle big, complex applications - which were simply impossible on the hardware of the time, and the scarce resources available which made compulsory to switch applications in memory.

      But keep on believing the "old way of doing things" is always better... all old people think so.

      1. This post has been deleted by its author

      2. Anonymous Coward
        Anonymous Coward

        Re: And then...

        But keep on believing the "old way of doing things" is always better... all old people think so.

        You ageist whatsit.

        If you believe for one moment that's how I think, ask yourself how I got a senior tech role in a major IT security company at age 60.

    2. Anonymous Coward
      Anonymous Coward

      Re: And then...

      I have a one word answer for that - leftpad ...

      However the article confirms what I've suspected for a long while - that DevOps is the latest bit of hooey invented by recruitment parasites/'consultants' to complicate job adverts.

      Bring back CRUD!

  5. Destroy All Monsters Silver badge
    Windows

    When you factor everything out...

    Fix Bad Stuff

    Stop Bad Stuff happening

    Do Good Stuff

    Make Good Stuff easier to do

    We are now working at levels of barely sustainable speed, complexity and technical debt, as well as unheard-of boardroom delusions of adequacy, but that's about it.

  6. Rafael 1
    Trollface

    Heresy!

    How dare you suggest that all those dozens and dozens of articles and seminars selling this new and revolutionary concept were not useful?

    Burn the heretic!

  7. Rob Isrob

    Key Differences

    Not sure how far you've come in your reading. But to communicate differences, I've had to do initial "sell" to help folks understand why they should be doing CM and what it gains them. Many better explanations of "why" then I could pen (nor care to waste time penning). Here is what I leveraged and I'm including just a small portion, but you get the drift:

    http://serverfault.com/questions/504070/why-use-chef-puppet-over-shell-scripts

    Key pieces:

    • Idempotence

    • Ease of Dependency Management (versioning)

    • Standardized Organization (accepted at an industry level)

    • Abstraction to separate server configuration tasks from system level details

    • Ability to leverage community knowledge (that is guaranteed to embrace all the above principles)

    More on Convergence and Idempotence:

    http://stackoverflow.com/questions/30615588/difference-between-convergence-and-idempotency-in-chef

    Convergence and idempotence are not Chef-specific. They're generally attributed to configuration management theory, though have use in other fields, notably mathematics.

    etc.

    But tools like this have to exist if you are managing hundreds or thousands of machines/instances.

    Scripts don't cut it (beyond a certain point of course) and we see folks that are tipping. Scripts that are no longer sustainable , the scaling fell down.

    1. Destroy All Monsters Silver badge

      Re: Key Differences

      Scripts don't cut it (beyond a certain point of course) and we see folks that are tipping. Scripts that are no longer sustainable , the scaling fell down.

      To which we can all agree...

    2. Anonymous Coward
      Anonymous Coward

      Re: Key Differences

      Downvoted for your use of "leveraged".

      You may well have been talking sense.

      Unfortunately I switched off at that point.

      1. Rob Isrob

        Re: Key Differences

        > Downvoted for your use of "leverage"

        Whatever. Grow up and separate the wheat from the chaff. If I only kept or referred to sources that were spot-on in everything they say, I wouldn't be able to leverage them for much at all.

        1. Anonymous Coward
          Anonymous Coward

          Re: Key Differences

          IMHO, leverage is one of those nouns which should never have been verbed. Whoops, "should" is a four-letter word with extra letters, that people tend to use frequently while describing an ideal universe we can't explore-- but I digress...

  8. fredesmite

    SSDD

    Same Shiite, Different day.

    Many decades ago we use to mount a nfs share on a UNIX test target that used a cvs repo that had all the current platform and integration tests. I believe that is called Puppet or Chef today. We also used a similar approach using cvs to configure machines before they shipped that would checkout a configuration from a branch.

    1. Anonymous Coward
      Anonymous Coward

      Re: SSDD

      CVS ?? Pah....

      RCS if you don't mind :-). Or even better, SCCS (now, that really was shite)

      You can tell I'm that 60-YO AC up there, can't you ???

      1. fredesmite

        Re: SSDD

        .Come to think of it ..it was rcs

  9. charles paul

    If you enjoyed this ignorant article, then you are an ignoramus.

    "

    Fix Bad Stuff

    Stop Bad Stuff happening

    Do Good Stuff

    Make Good Stuff easier to do

    It turns out that my teams are already pretty much working in this way; some folks spend more time dealing with the Bad Stuff and some spend more time dealing with the Good Stuff."

    StorageBod is obviously an insecure curmudgeon with, with providence and grace, will be shuffled out of the IT workforce hopefully sooner rather than later. Jokers like this are familiar to all devops consultants... nod nod nod, and let them go on with their spiel about how things are already running perfectly - it doesn't matter because the CTO already gave you carte blanche to remove their raison d'etre with 50 lines of python.

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