DevOps and Overcoming the Great Divide

The following post has been excerpted from Deming’s Journey to Profound Knowledge: How Deming Helped Win a War, Altered the Face of Industry, and Holds the Key to Our Future by John Willis, with Derek Lewis.

There is a stark difference between software operations and software development. If a tech company were a restaurant, the developers would be the cooks and operations would be the waitstaff.

In a poorly run restaurant, the kitchen staff are often prima donnas, who believe the entire world revolves around them. The servers are always angry at the cooks because the server gets the customers’ wrath when the order is wrong, when the steak’s overdone, or when the cook didn’t know the cilantro-baked fish came with cilantro. The kitchen staff, on the other hand, gripes that the servers don’t do anything but carry food back and forth and screw up the tickets in the first place. If it weren’t for the cooks, there wouldn’t even be a restaurant.

And so forth.

This divide was really the last great bottleneck before the digital Cambrian explosion was well and truly underway: There was a wall—often literally—between the people creating the software and the operations people supporting it. In 2009, John Allspaw and Paul Hammond identified this gap in a landmark presentation called “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.” At that time, releasing a software update (or deployment) once a month was ambitious. Ten times a day? What madness was this? The two men had created what Jez Humble would later term continuous delivery (he later authored a book by the same name), describing it as a way for software development and operations to work as a seamless, transparent, integrated team. During Allspaw’s and Hammond’s presentation, I saw a tweet from fellow attendee Andrew Clay Shafer, a software developer friend of mine. He used the hashtag #DevOps.

Watching the presentation from afar was the Belgian programmer Patrick Debois. He, too, was sick of organizations putting development in one silo and operations in another. While at a US-based agile conference the year before, Debois had suggested an informal conversation (also known as a “birds of a feather” meeting) to discuss how the two different professions could begin to collaborate. Unfortunately, only one person signed up for the conversation—Andrew Clay Shafer. Both decided to blow off the “birds of a feather” meet-up.

Allspaw’s and Hammond’s presentation was the proof and final push Debois needed. He created an event in Ghent, Belgium, later that year called DevOps Days. About fifty tech professionals came from the UK and other parts of Europe. I was the lone American.

At the time, I was working for a company called Chef, which automated coding that allowed system administrators to create thousands of data servers in the time it usually took them to build one. The CEO, Jesse Robbins (whose official title while at Amazon had been Master of Disaster), handed me a credit card and told me to figure out what this DevOps thing was. At this point in my career, I’d been programming for thirty years. I was naively certain I’d seen it all. Sure, I was excited about the promise of DevOps, but my expectations in no way prepared me for what I encountered in the stories of my European counterparts at the world’s first DevOps Days. Young women and men related unbelievable implementations of code at a level of automation, speed, and scale unprecedented anywhere in the world—not at three-person tech startups but by global banks, huge insurance companies, and national healthcare organizations. It seems Allspaw’s and Hammond’s experience was not a fluke unique to Flickr but could be replicated by all sorts of development and operations teams.

After Ghent, Debois posted, “I’ll be honest, for the past few years, when I went to some of the Agile conferences, it felt like preaching in the desert. I was kinda giving up, maybe the idea was too crazy: developers and ops working together. But now, oh boy, the fire is really spreading.”

When I got home, I convinced my friend Damon Edwards that we had to have a DevOps Days in the US immediately. A few months later, in June of 2010, we ran the first US conference at LinkedIn’s headquarters in Mountain View, California. Three hundred people attended. Whatever I felt at Ghent was dwarfed by Mountain View. The sheer potential in time savings, agility, productivity, and opportunities was staggering. There was no doubt in my mind that DevOps was the final piece of the digital Cambrian explosion.

Damon and I tried to codify what DevOps meant and came up with the acronym CAMS: culture, automation, measurement, and sharing. Jez Humble would later add an L for “lean,” resulting in CALMS. The main ideas emerging from this movement were heavily influenced by the Agile Manifesto and Lean Software Development. However, DevOps added two significant components: collaboration between developers and operations and explicit examples of how to automate both agile and lean principles.

Of course, you can’t tell the story of DevOps without talking about Gene Kim. When Gene attended DevOps Days in Mountain View, he was already a legend in my crowd (operations professionals). Something of a prodigy, he was a UNIX systems administrator for Sun Microsystems while still in high school. He was there when one of the first computer viruses in the world, the Morris Worm, took out 10% of the thirty thousand servers that were connected to the internet. After graduating from Purdue, Gene and a former professor named George Spafford launched Tripwire, an early and quite successful cybersecurity company. What cemented Gene’s reputation was probably his 2005 book The Visible Ops Handbook, based on research by Gene, George, and Kevin Behr, where they found that 80% of IT outages were self-inflicted.

Even after Mountain View, Gene was still a little suspicious about the whole DevOps concept. We agreed to meet up at South by Southwest a few months later. There, I tried to lay out the beauty and potential of DevOps as well as I could. “Think of it this way: DevOps is a lighthouse bringing all of us ops and sys-admins lost at sea back home.” I think that did the trick.

Gene began to discuss a book he, George, and Kevin had been working on for five years. It was a modern retelling of the bestselling business book The Goal, a novel about supply-chain management in a manufacturing setting. These three men gave it a modern lens: a novel about software development and delivery. They called it The Phoenix Project. (He included DevOps in the subtitle, I might proudly add.)

In discussing the book, Gene and I realized that people would want a prescriptive solution after reading it. A few years before it was published, Gene, Patrick Debois, and I began working on what would become The DevOps Handbook. Jez Humble joined us and we published the book in 2016. The books have sold almost a million copies combined.

Around 2014, I had seen a DevOps presentation at a local DevOps Days event in Minneapolis featuring Target’s respective heads of operations and development, Ross Clanton and Heather Mickman. Their presentation reminded me of John’s and Greg’s Flickr presentation, but this was on a retail enterprise scale, quite different from a tech company. For a few years, corporate naysayers—including the Big Five (Accenture, Deloitte, EY, KPMG, and PricewaterhouseCoopers)—refused to believe DevOps could work as-is in an enterprise setting. They discussed how to run a gentler, less aggressive/ambitious version in a corporate environment. I knew this wasn’t the case, but how could we show everyone else? Target wasn’t an isolated case. I’d also met Courtney Kissler at Nordstrom doing some incredible things with DevOps without compromising any part of its principles.

Gene, Damon Edwards, and I discussed the need for a showcase event; Gene decided to put together the DevOps Enterprise Summit in 2014. We put out requests for proposals and the response was overwhelming. Over six hundred people attended with presenters from not only Target and Nordstrom but also Nationwide, Macy’s, Huawei, PNC Bank, Ticketmaster, and MITRE, as well as the CIO of US Citizenship and Immigration Services and even representatives from Her Majesty’s Revenue and Customs (with roots going back to the thirteenth century).

Today, there’s not a major company on the planet that isn’t discussing DevOps. Tech giants like Google, Netflix, Amazon, and Facebook have completely embraced it. It’s been mainstream in the Fortune 500 since 2018. It is the human capital piece of the Digital Cambrian Explosion.

As far back as 2012, my friend and mentor Ben Rockwood suggested I read Deming’s 14 Points for Management if I really wanted to understand the roots of DevOps. Once I did, it was clear to me that most of what I knew about this movement had already been codified over forty years before. Reading Deming, I realized how powerful his ideas were on cooperation and human potential. At that point, I became focused (some might say obsessed) on learning and sharing more about Dr. Deming and how his ideas related to the digital Cambrian explosion.

Today, my all-time most requested presentation? “Deming to DevOps.”

- About The Authors

John Willis

John Willis has worked in the IT management industry for more than 35 years and is a prolific author, including "Deming's Journey to Profound Knowledge" and "The DevOps Handbook." He is researching DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Previously he was an Evangelist at Docker Inc., VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell), and VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.

Follow John on Social Media

• 
•