The State of DevOps in 2018 - With Nathen Harvey (Part 1)

Part 1: An Overview of the Situation

How has DevOps changed in the 3–4 years since Metricly published its two blog posts, Follow The Thought Leaders In #DevOps and Follow the DevOps Thought Leaders – Part 2? In some ways, very little. It’s still about getting development and operations people to collaborate more closely, with the help of cloud-based environments and automation tools, to deliver products and services more quickly to customers, whether they’re external customers or employees within an organization. On the other hand, the mission appears to have become broader and more inclusive. You can see this push through the crazy add-ons to the “DevOps” core—BizDevOps, SecDevOps, DevSecLegalOps, MobileOps—that threaten to turn the concept into some crazy Germanic compound word that is impossible to remember.

A few weeks ago I met with DevOps evangelist Nathen Harvey, vice president of community development at Chef, at the 16th Annual Southern California Linux Expo (or ScaLE) to discuss how DevOps has evolved over the last several years, as well as DevOps trends in 2018 and beyond. This first post will look at how far we’ve come. The second will look at ways to effectively implement a DevOps approach in organizations going forward.

Defining DevOps in 2018

Nathen says that DevOps offshoots like BizDevOps and others have come about as the movement becomes an umbrella for more than just Dev and Ops people. Although these original practitioners came up with the basic concepts, it’s ultimately a “cultural and professional movement that focuses on how we build and operate high-velocity organizations,” Nathen says. “And if you want to build a high-velocity organization, you have to look at the entire organization.”

Over the last 4–5 years in particular, DevOps has become more widespread, generating interest from people who don’t fall in the traditional DevOps camps. “It used to be you would go to a DevOps Days, and most everyone there [was] on the same page. Now we’re starting to see larger organizations show up and say, ‘I’ve heard this word, but I don’t understand what it means. How do I get started? What do I need to do?’ It’s becoming more widespread and touching a lot more people,” Nathen says.

How Has DevOps Evolved Over the Last Five Years?

In addition to the increased interest in DevOps, Nathen sees DevOps having evolved over the last five years in three key ways:

Increasing Rates of Change and Levels of Innovation: New and better tools are being launched faster and faster than they ever have before—and as a result, people are rethinking the way they manage these tools. “It’s kind of a trend. If you go back to the very beginning of DevOps, DevOps started to take hold right at the same time cloud started to take hold,” Nathen says. This ability to access cloud to handle processes previously relegated to a physical data center has enabled technologies like containers and serverless to rev up the rate of innovation. “Automation frameworks [mean that] we have more compute at our fingertips, and so how do we control that? It’s no longer the case that any of us can keep in our head the state of our systems. Whereas, 10 years ago maybe that was easier to do,” Nathen explains.

In addition, technologies are more ephemeral today, which is a good thing for improving on the way things work. “In the past, maybe I was excited that I kept a server up for 400 days. Today, if a container lives for four minutes, maybe that’s too long,” for the process it’s been programmed to do. “Because how long does it take to add 1+1? It doesn’t need four seconds, let alone four minutes.”

New Technologies Leading to Faster Rates of Change: Many of the tools that have revolutionized DevOps were not available five years ago. Of the ones, Nathen and I discussed, only Platform-as-a-Service offering Cloud Foundry, whose initial release was in 2011, was around, but the open source Cloud Foundry Foundation wasn’t founded until early 2015, nearly four years later.

For his part, Nathen says Cloud Foundry has gained a lot of momentum because it enables developers to create a PaaS instance and eases the deployment and management of applications.

Here is the timeline of some other technologies have had a fundamental impact on DevOps implementations:

  2013: Docker
  2014: Terraform
  2015: Kubernetes (v. 1.0)

“If you’re talking about containers and trying to understand how we get to containers, Kubernetes is the thing,” Nathen says. I’ve talked to some other DevOps thought leaders over the last few weeks, and when I’ve asked them what tools and technologies have had a large impact on DevOps growth, every one of them has listed Kubernetes.

The Need for People to More Quickly Adapt to New Technologies and Innovations: Given the pace of technology change, humans need to adapt to these evolving and new technologies much faster. So, as this transformation accelerates, people need to focus less on learning these changing technologies, many of which will mutate out from under us, and start thinking on a different level.

“We’re really changing the way we think about applications and how we manage all that. What’s starting to gain more momentum is this idea that … we really need to focus on: ‘How do I learn to learn? How do I learn to adapt?’” Nathen explains. “Because we’re not going to stop the innovation.”

The Biggest Challenge to DevOps Adoption

The biggest challenge to DevOps adoption is the one thing that hasn’t changed much over the last five years: silos and distrust. To understand why this didn’t occur to me before, let me give you some background on my admittedly spotty DevOps education.

While it may seem obvious these two are a linked problem, in the past I thought silos were more a symptom of inertia and a lack of common goals between development and operations. When I think back to the (now ancient) “Wall of Confusion” graphic I first saw in a 2010 Damon Edwards post on the old dev2ops site, I took it for what is was: confusion. Development wants change, and operations wants stability, but once the two sides got talking, they would see the value in moving forward together for the sake of their business.

I should have had some inkling of the deeper problem back when I read the Forrester blog post “I Don’t Want DevOps. I Want NoOps.” the following year. Analyst Mike Gualtieri writes:

“The last thing many application developers want to do is have a sit-down with the ops guys.”

At the time I took it as just stupidity, knowing that access to technology and hardware rarely leads to humans avoiding other humans, even though people, including myself, are lazy and avoid conflict. It’s just easier to remain in your silos than have to reach out, even if it isn’t beneficial in the long term.

But Nathen points out that the problem goes much deeper than inertia or laziness. Instead, there is a general distrust among all the many silos in an organization, particularly large ones, where bringing everyone together to discuss anything is pretty much impossible. And he defines silos in a way I hadn’t thought of before:

They have this sort of scar tissue that [makes] up their silos, like: “We know what we have to do to silo our information because that is what gives this silo strength within our organization.”

Moreover, this distrust manifests itself as a sort of defensive unwillingness to come to grips with the problems DevOps could solve. This becomes more apparent as you try to add other groups, such as security, legal, financial and others, that make up any organization:

They don’t trust, and they don’t understand. They don’t necessarily want to understand. And when you come to them … to bring … DevOps, they’re like: “I’m not interested in the DevOps. … That’s just a made-up word. It doesn’t mean anything, and it’s not me. I’m not a Dev or an Op, and I’m not a DevOps, for sure, so why do I care?”

Nathen says that any successful transformation ultimately revolves around communicating why these groups should care and come on this journey. “We can’t just go in and say, ‘There’s a better way.’”

Fortunately, Nathen has several thoughts on how to get organizations to embrace DevOps—and that will be the focus of my next post.

For next post, steps that will be addressed:

• The need to embrace failure and, in particular change how leadership views failure.
• Bringing everyone into the conversation—and making that a priority (with examples)
• Automate more, not less (minimize human error, generate trust by focusing on what really matters, needs to change)
• Generate trust in people and systems (through first three)

About the Author

Robyn Weisman

Robyn lives in Los Angeles and is the founder and principal of WriteTech Content– a content marketing firm for companies in the enterprise tech space. Robyn has written about the enterprise since 2000, both as a reporter and copywriter.