Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

DevOps in Straight English - Part 1 of 2 - Enter the Buzzword

January 15, 2014
Magnus Hedemark
Related topics:
CI/CDDevOps
Related products:
Developer Tools

Share:

    "DevOps".

    If you're like me, you may be suffering a bit of buzzword fatigue, especially relating to how this word is used (or misused) within the IT community. But for those of us who have been a part of the community for a while, it holds deeper meaning than the oft-repeated platitude of "Software Developers and Sysadmins working together, riding unicorns over rainbows". Okay, while I may have gotten slightly carried away, you get the point.

    What is DevOps to the broader community that embraces it, and is helping even now to define it? What does that even mean for Red Hat's IT efforts? We're going to dive deeper into both questions in this installment.

    Don't recoil when your boss invokes the word "DevOps"; he may or may not be using it inappropriately, but he's giving you a chance to do the right thing. Become the DevOps subject matter expert and help him to help you. You may be surprised to learn that DevOps didn't originally spring from the business management community, but rather from the IT engineering community.

    Not too long ago, the industry was abuzz with another set of buzzwords: "Scrum", which is one of several methodologies of putting Agile into practice. Agile was working, it was making a real difference in transforming software development teams and getting them to produce more relevant software, releasing more frequently, and keeping their customers happier.

    It didn't take long for someone on the more traditionally curmudgeonly side of the fence, Operations, to take notice and wonder if some of this Agile magic might help the much-maligned world of Sysadmins. This really started catching on, and for reasons that are becoming painfully easy to see.

    You know, I can't tell you how many times, as a Sysadmin, I'd have some Software Developer or Project Manager come over to the IT department and go through the careful ritual of asking for something. The IT Manager would hold court, perhaps with a couple of very conservative Sysadmins nearby, and hear out the plea for making some kind of big change to his otherwise stable empire. The answer would come back, either as a resounding "no", or if it was going to happen at all, the delivery would be at least 6 weeks out (often longer). The Software Developer, who has already been reaping the benefits of Agile software development, is now soberly considering how badly this has just screwed up his next three sprints.

    Agile Operations was an approach that attempted to get a better impedance match between the needs of product development teams and operations teams. It got them using similar methodologies and cadences as well as started getting them more aligned on values. Two teams that want the same thing on the same timeline will, after all, accomplish great things together. Right?

    This Agile Operations movement really was proto-DevOps. It got Software Developers and Sysadmins working together. Wait, where have I heard that before? Ah, yes... DevOps.

    A fellow with a lot of cachet in the DevOps world by the name of Patrick Debois is credited with coming up with the word that is both loved and scorned by many today. As he tells it, he was working as a Sysadmin on an Agile software development project and needed an easy concise term to describe a collaborative organization where Agile practices were being followed beyond just the development effort. Notice we're not talking about some CIO bigwig at a Fortune 100 company here, but an in-the-trenches Sysadmin that was just trying to find an easy way to describe something that he was already doing that made a lot of sense. DevOps did not come out of a few MBA's locked in a room trying to come up with the latest theoretical way to structure our jobs of actually making stuff more tedious!

    Bringing Agile into Operations got Sysadmins and Software Developers talking to each other and working more effectively together, as well as QA and security and people in other technical roles. DevOps came in and put a name on this warm fuzzy thing that was already starting to happen. It gave engineers something to rally around, to build on.

    What happened next gets some engineers twitchy and others really excited. The DevOps community started rediscovering and incorporating some of the best practices of the industrial revolution, drawing parallels between software development and manufacturing stuff.

    The reason it gets engineers twitchy is that this is the vector for a lot of managerspeak getting injected into DevOps. This is where you start hearing things like muda, mura, muri. Or kaizen (is that a Japanese hazing ritual?) and observe-plan-do-check-act. All of this comes from what was learned in the 20th century about effective manufacturing plant management and empowering the workers to improve the way they do their own work.

    The thing is, for all of the Lean and Agile managerspeak and hand-wavy pictures of value streams and the like, the principles and practices behind the buzzwords actually work. My colleagues on the Inception team sometimes like to mock me if I use too many of these managerspeak terms in our conversations about how to foment a healthy DevOps culture in Red Hat IT. The challenge here, and the opportunity, is to embrace the really great teachings of gurus like Goldratt, Ohno, Deming, etc. and digest them into the common parlance of the Sysadmin or Software Developer.

    When I first started writing this installment on the Inception team's DevOps journey, it was meant to be a deeper dive into The Foundation of DevOps. This is something I can write a good deal about, and have given public talks on the subject that would either fascinate or frustrate depending on your interest in the inevitable managerspeak that goes with such an overview. Partway through, I tossed it all out and decided to accept the challenge thrown down by my colleagues. DevOps in English! We've even gone so far as to hang a big piece of paper on our wall with a Sharpie nearby where we can write down words that Shadowman would never say.

    DevOps isn't a role. There is no such thing as a "DevOp". Just like there is no such thing as an "Agile" or a "Lean". DevOps describes the culture of the shop you're working in, not a function that someone performs.

    DevOps is also not a combination of Developer and Sysadmin in one role. Nope. Though in a DevOps shop, the lines may blur a bit. But that happens ideally because the wall between the two functions has crumbled, and people from many areas of expertise are working together towards a common goal. Me? I've been a Sysadmin for twenty years now. I'm a Sysadmin now. But because those walls are breaking down, I'm learning some new skills, writing more advanced tools than I ever did in bash because I can (there are no walls to stop me) and because I want to (not only is it personally fulfilling, but it's the right thing to do to help us all succeed together). I'm still, first and foremost, a Sysadmin, but I'm picking up more of a Software Developer skill set to help Red Hat IT succeed in a world where infrastructure is built and defined by APIs and templates rather than racks and bare metal (obligatory use of "cloud"... there, I said it).

    So, in a DevOps shop, people are working together towards a common objective. The barriers to effective communication between contributors is very low. There is a cultural allergy to walls. And Software Developers and Sysadmins are no longer set up for constant war because they're sharing values. You might wonder how that works. I alluded to this earlier. Let's foray a little deeper.

    The bottom line in the old world of Developers vs. Operations, which can still be seen in shops that haven't started making the leap yet, is pretty simple. Developers are rewarded for and measured by their success in getting new features into the hands of customers. But these changes tend to be big and risky, and happen far apart, so confidence is very low about how likely the new code is to work in production on the first try.

    The world of IT Operations is traditionally one that strives for perfect stability, and status quo. Get things super stable, and then don't touch a thing. Any changes made must go through at least one change management committee, requires an outage window, and may carry a lot of risk due to the size and complexity of the change requested by the customer. This foments a culture where the Sysadmin wants to create a perfectly stable hermetically sealed environment where nothing can change once stability has been achieved. With Operations teams being measured first and foremost by uptime, it's no wonder they've been jerks all these years to Software Developers; the system is rigged for strife!

    Good grief! No wonder these guys can't get along without getting all stabby! For one to succeed, the other must fail!

    A DevOps culture changes the equation. Changes happen all the time, many times per day. But they are really small changes, and they are really well tested. So Software Developers and Sysadmins all understand there is a very low risk of failure, and confidence of success is high. Releases to production happen so often, it's really just a non-event. It's probably a bigger deal to walk from your desk to the break room for a caffeine fix.


    Frequent releases reduce risk and increase confidence in success. Artistic value provided by Tim Bielawa

    Join me next time in Part 2 where we'll talk about the main areas to focus your attention, in plain English, to get started on this DevOps thing that everybody is talking about.

    Last updated: February 7, 2024

    Recent Posts

    • More Essential AI tutorials for Node.js Developers

    • How to run a fraud detection AI model on RHEL CVMs

    • How we use software provenance at Red Hat

    • Alternatives to creating bootc images from scratch

    • How to update OpenStack Services on OpenShift

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue