What is DevOps? How does it relate to other ideas and methodologies within software development? Linux Journal Deputy Editor and longtime software developer, Bryan Lunduke isn't entirely sure, so he asks some experts to help him better understand the DevOps phenomenon.

The word DevOps confuses me.

I'm not even sure confuses me quite does justice to the pain I experience—right in the center of my brain—every time the word is uttered.

It's not that I dislike DevOps; it's that I genuinely don't understand what in tarnation it actually is. Let me demonstrate. What follows is the definition of DevOps on Wikipedia as of a few moments ago:

DevOps is a set of software development practices that combine software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.

I'm pretty sure I got three aneurysms just by copying and pasting that sentence, and I still have no clue what DevOps really is. Perhaps I should back up and give a little context on where I'm coming from.

My professional career began in the 1990s when I got my first job as a Software Test Engineer (the people that find bugs in software, hopefully before the software ships, and tell the programmers about them). During the years that followed, my title, and responsibilities, gradually evolved as I worked my way through as many software-industry job titles as I could:

• Automation Engineer: people that automate testing software.
• Software Development Engineer in Test: people that make tools for the testers to use.
• Software Development Engineer: aka "Coder", aka "Programmer".
• Dev Lead: "Hey, you're a good programmer! You should also manage a few other programmers but still code just as much as you did before, but, don't worry, we won't give you much of a raise! It'll be great!"
• Dev Manager: like a Dev Lead, with less programming, more managing.
• Director of Engineering: the manager of the managers of the programmers.
• Vice President of Technology/Engineering: aka "The big boss nerd man who gets to make decisions and gets in trouble first when deadlines are missed."

During my various times with fancy-pants titles, I managed teams that included:

• SysOps: used to stand for "System Operator", a person who ran and maintained a network accessible system, but now has been redefined as "System Operations", which has an utterly confusing definition that nobody seems to agree on.
• SysAdmins: aka "System Administrators", which is similar to SysOps, only newer.
• Project Managers: people who document requirements for a project and help engineers, testers and other people working on a team to ship whatever it is they're working on.

All of which is a long way of saying, "I should know what the heck DevOps means."

But I don't. I really, really don't. Maybe it's a defect in my brain. Perhaps I'm simply from a different era in the computer industry when different words and ideas were used. And, clearly, I'm not alone. If you do a Google search for "define DevOps", you get more than 43 million results. I've clicked on roughly 42 million of them (although I did the search via DuckDuckGo) and got no closer to understanding the elusive meaning of this term.

Luckily, I'm in a position to know some pretty doggone smart people who work in DevOps in one way or another. So I reached out to them with a simple challenge:

"Explain to me what DevOps means. Bonus points for not using any buzz words."

What followed were wonderful conversations with four "DevOps experts" during the course of several weeks. To make it all easier to follow for everyone, I've taken the key bits of those conversations and edited them together into one semi-real, semi-fictional chat with a singular DevOps expert that is a combination of all four of them.

Let's call him "Ted".

Note: as we go along, some software engineering terms will be used that some readers may not be familiar with. When that happens, I've included the definition.

Lunduke: Okay, Ted. What is DevOps?

Ted: Wikipedia defines DevOps as "a set of software development practices that combine software development".

Lunduke: Whoaaa! Gotta stop you right there. I've read the Wikipedia entry. I've read articles and the various DevOps yearly reports. I've gone to conferences and watched presentations with slide decks filled with enough buzz words to make my head spin. Give it to me in your own words.

Ted: Luckily, DevOps is a simple idea. Take Developers and Operations people and integrate them together.

Lunduke: I assume we're not talking traditional "Operations" within a company (supply chain stuff and whatnot)? Chief Operating Officers and the like?

Ted: No. More System Operations. SysAdmin work.

Lunduke: Oh, okay. So it's Developers working with SysAdmins?

Ted: And QA (testers)—everyone involved in the software development lifecycle working together to achieve continuous integration and faster releases.

Lunduke: That sounds like Agile. Also, the phrase "continuous integration" causes physical pain to say—almost as much as "enhancing corporate synergy".

Wikipedia defines Agile Software Development as follows:

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.

Ted: I know, it's a terrible term, but the idea is still good. As for being like Agile, there are some similarities, but the focus is different. Agile is more about making it easier and faster for the engineering teams to work with project managers and customers, and DevOps is about having the engineering teams working closely with the people handling all the IT infrastructure required by a project (such as the sysadmins).

Lunduke: So, what I'm hearing is that DevOps is a way of saying "sysadmins and engineers should talk". That can't be right though. That's too simple (and obvious) of an idea that has been around since before Jimmy Carter was President (though not always actually acted upon). There has to be more to it than that; otherwise, there wouldn't be entire conferences and companies dedicated to DevOps.

Ted: A lot of ideas and best practices have evolved around DevOps to help make teams successful, but that really is the basic idea. Sometimes, in the quest for better integration of the Dev with the Ops, the two get completely merged into the same time and even the same roles.

Lunduke: That's such a simple idea (and one that's existed since before most computers had a GUI). Why does it need a new term? When I ran my own business, I wore both dev and sysadmin hats. Technically that made me a DevOps...in retrospect?

Ted: Yep. Technically! But don't get too hung up on the term. The important part is the idea and the best practices that help facilitate it. Think of it simply as a set of ideas and tools to help software run properly in both development and production environments. It's also a way of enforcing that engineers are in a place to maintain the code they produce.

Lunduke: I think a circuit in my brain is getting tripped as I look for something new here. From what you're describing, DevOps seems like a basic idea (or small set of ideas) that have been around for longer than most engineers working today have been alive. Maybe if you could give me an example of a DevOps-y best practice, that'll help me wrap my head around this.

Ted: Sure. One obvious best practice is to publish small, incremental and frequent changes. Engineers, testers and admins (or DevOps engineers) working together, releasing tiny changes rapidly. This makes each release a little less risky and bug-prone. And it gets improvements (even if smaller ones) to the users faster.

Lunduke: At the risk of being annoying (I know, it's too late), that sounds exactly like Agile Development. Everyone involved in the production working on the same team (or very closely) to release small, iterative updates on a rapid schedule.

Ted: Except it's faster than Agile—or it can be. It's certainly faster than Waterfall.

Wikipedia defines the Waterfall model of software development as follows:

The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

Lunduke: But technically, Agile doesn't have any restrictions on how frequently you can release. You can do an Agile Sprint every day—heck, every hour—if you want to.

Here's the Wikipedia definition of Sprint:

A sprint (or iteration) is the basic unit of development in Scrum (a framework typically used in Agile development). The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.

Ted: The Agile vs DevOps debate will rage on for ages. Luckily, the core idea of DevOps is a helpful one. And the series of best practices that gets exchanged (in books and conferences and whatnot) really can be helpful for engineering teams.

Lunduke: I mean, I guess I get it. It still sounds like Agile (to me). Hey, Ted, could you do me a favor?

Ted: Heh, sure, Lunduke.

Lunduke: Could you tie DevOps into Linux somehow? You know, what with this being for an article in Linux Journal and all.

Ted: Well, most DevOps people I know run Linux—especially on the server side. Does that count?

Lunduke: Yes, yes it does.