Just What Is DevOps?

Business dinners are a mixed bag. On the upside, you get a nice meal for free (unless you’re hosting the dinner and footing the bill). For me, it’s usually an opportunity to eat at a place I would consider too expensive for myself. But, to paraphrase a popular adage, there’s no such thing as a free dinner: You’re expected to be part of the Important Business Discussion (IBD) that starts after the food is ordered. Often, your involvement is relegated to listening to a vendor’s pitch, along with pontification on the part of the customer soliciting the pitch.

A recent dinner didn’t deviate from the template. A dozen of us met at a steakhouse, the de facto choice for IBDs. This time, the customer opened with a half-hour story about … well, I’m not really sure what the story was, to be honest. The customer mentioned humble beginnings, offered a meandering middle, then ended with some level of relevant enlightenment about the direction the company needed to go. The vendor, upon realizing the half-hour story was over, happily but not-so-subtly pronounced, “Well, now that it’s my turn to talk. I want to talk about DevOps!” At which point he did — for 45 uninterrupted minutes full of marketing speak.

Where was that $54 steak I ordered at someone else’s expense? I wasn’t hungry so much as eager to get to the steak-chewing, which held the high hopes of silencing the garrulous folks at the table — or at least shortening some of their sentences.

I’ve been working in an agile sense for near twenty years. I’ve read several dozen books on it and countless more articles. Yet most of the 45 minutes out of the vendor’s mouth made little sense to me. This stuff mustn’t be that hard.

No, Really, Just What Is DevOps?

Like me at the steak dinner, you’re probably wondering if I’ll ever get to the point and provide a definition for DevOps. I was feeling frustrated at this point in my dinner, 75 minutes after sitting. The arrival of the steak shifted the conversation to question-and-answer mode. I quickly said, “I’d like to make sure we’re all on the same page.” As diplomatically as I could stand, I continued, “I’ve seen a few different takes on just what DevOps is, and I’d like to get your definition. I wasn’t clear on it from the discussion so far.”

That was a little too direct for the vendor, who attempted to sideswipe the question with a curt response. I persisted and asked again for a definition, which was a mistake. In return, I got another 15-minute barrage, the contents of which provided no clear definition.

I gave up and tried my best to enjoy my dinner. I’ll never understand how someone would actually try to sell something that they can’t define or explain clearly. This is why elevator pitches are a great idea, but perhaps this vendor works at the top of the Willis Tower.

Here’s What I Thought DevOps Is

In 2013 I worked remotely for a flat organization, where we had business folks and we had developer folks. There were no real titles, no managers, and no specialists. The business was responsible for understanding the market and customer enough to translate it into ideas of what to build. We in the development camp were responsible for building that product.

Building a software product requires more than just programming. We helped refine the business interests into specifications, designs, plans, code of course and tests. Along that path, we also defined and built support for system-oriented, nonfunctional needs: security, performance and scalability, and supportability — things that a quality production system requires. As people whose backgrounds were primarily programming, we were neither experts nor specialists in these operational areas.

The challenge to an organization with no specialists is daunting. Supporting nonfunctional needs demands high amounts of often-arcane knowledge. AWS, for example, is a large, complex platform supporting delivery to the cloud. People are hired now for jobs where all they do is manage environments running under AWS. And yet our development team was expected to take on this complexity, as well as complexity around other operational items, including security management, continuous integration and continuous delivery software, network administration, database administration, server administration and so on.

When we needed deep expertise in technologies like AWS, we ran into some problems. We needed someone with a solid background in delivery technologies and operational concerns. They needed also to be comfortable coding, typically Python scripts. As a result, we considered “DevOps” to be more of a role — someone who could provide both dev and ops capabilities — and that’s what we sought in hiring.

Our work was highly collaborative— we did almost everything through pairing. Before the “DevOps folks” arrived, I would pair with another primarily-programmer-person when we had to accomplish operations-related tasks. After their arrival, we would intermingle pairs so that the DevOps folks would bestow some wisdom on us, and vice versa. We programmers became ops-ish, and they became programmer-ish.

What DevOps Generally Means Today

Ernest Mueller defines DevOps as “the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.” At my former company, we indeed intermingled dev people and ops people, so, yes, we were “doing DevOps.” Too bad we were bungling the term: It’s a way of working, not a role.

The core implication of Mueller’s definition is that operations is no longer an adjunct effort. Operations people are no longer siloed from everyone else. In a DevOps-focused environment, not only do devs and ops folk work closely together, but the operational concerns are tackled using the same processes and practices we employ for the programming work. Delivering software well demands the involvement of operations as part of the whole team from day one.

Where does DevOps fit in the scheme of things? People in the DevOps community have proposed sets of values and principles similar to those of the Agile Manifesto. But DevOps is probably best viewed as complementing, or even helping shape, an agile process. A DevOps mentality means a concerted focus on increasing the ability of a team to continuously deliver high-quality software — by automation involved with configuring and deploying the software, and by providing automated ways to monitor and support the software in production.

The challenge of DevOps is, how do we address operational needs from day one using the same set of principles, or even practices, that we apply to programming work? The core of that challenge — how to address operational needs from day one as an integral responsibility of the team — is where the current work and exploration resides. You’ll find no end of great resources on the web, as well as a few books that dig deep into how to make DevOps work. You might even chew down on a steak while catching up.