DevOps Paradox E-Book

Viktor Farcic

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 596

Veröffentlichungsjahr: 2019

Beschreibung

Discover DevOps secrets from leading experts. Viktor Farcic interviews DevOps industries voices including Mike Kail, Greg Bledsoe, Jeff Sussna, James Turnbull, Kohsuke Kawaguchi, Liz Keogh, and more.

Key Features

• Leading DevOps experts share their insights into modern DevOps practice
  


• Engage with the real-world challenges of putting DevOps to work
  


• Strengthen your DevOps practices now and prepare for future DevOps trends

Book Description

DevOps promises to break down silos, uniting organizations to deliver high quality output in a cross-functional way. In reality it often results in confusion and new silos: pockets of DevOps practitioners fight the status quo, senior decision-makers demand DevOps paint jobs without committing to true change. Even a clear definition of what DevOps is remains elusive.

In DevOps Paradox, top DevOps consultants, industry leaders, and founders reveal their own approaches to all aspects of DevOps implementation and operation. Surround yourself with expert DevOps advisors. Viktor Farcic draws on experts from across the industry to discuss how to introduce DevOps to chaotic organizations, align incentives between teams, and make use of the latest tools and techniques.

With each expert offering their own opinions on what DevOps is and how to make it work, you will be able to form your own informed view of the importance and value of DevOps as we enter a new decade. If you want to see how real DevOps experts address the challenges and resolve the paradoxes, this book is for you.

What you will learn

Expert opinions on:

• 
  


• Introducing DevOps into real-world, chaotic business environments
  


• Deciding between adopting cutting edge tools or sticking with tried-and-tested methods
  


• Initiating necessary business change without positional power
  


• Managing and overcoming fear of change in DevOps implementations
  


• Anticipating future trends in DevOps and how to prepare for them
  


• Getting the most from Kubernetes, Docker, Puppet, Chef, and Ansible
  


• Creating the right incentives for DevOps success across an organization
  


• The impact of new techniques, such as Lambda, serverless, and schedulers, on DevOps practice

Who this book is for

Anybody interested in DevOps will gain a lot from this book. If you want to get beyond the simplistic ideals and engage with the deep challenges of putting DevOps to work in the real world, this book is for you.

Leseprobe

DevOps Paradox

The truth about DevOps by the people on the front line

Viktor Farcic

BIRMINGHAM - MUMBAI

DevOps Paradox

Copyright © 2019 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Acquisition Editors: Dominic Shakeshaft, Jonathan Malysiak

Project Editor: Kishor Rit

Development Editor: Alex Sorrentino

Technical Editor: Saby D’silva

Copy Editor: Safis Editing

Proofreader: Safis Editing

Indexer: Pratik Shirodkar

Production Coordinator: Sandip Tadge

First published: August 2019

Production reference: 1290819

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham B3 2PB, UK.

ISBN 978-1-78913-363-9

www.packt.com

Contents

Introduction 2

Jeff Sussna 10

Damien Duportal 36

Kevin Behr 60

Mike Kail 108

James Turnbull 128

Liz Keogh 146

Julian Simpson 180

Andy Clemenko 202

Chris Riley 232

Ádám Sándor 260

Júlia Biró 284

Damon Edwards 314

Kohsuke Kawaguchi 342

Sean Hull 364

Bret Fisher 390

Nirmal Mehta 418

Gregory Bledsoe 454

Wian Vos 490

Introduction – what is the DevOps paradox?

I love sharing with others. That's my main motivation when I write a book. There's a hard-to-explain joy in knowing that our work as authors might be helping others. But strangely, that's not the case with DevOps Paradox.

This time, my motivation was much more self-serving. I wrote this book because I personally wanted to understand what DevOps is. Now if you know anything about me, or have read any of my multi-book DevOps Toolkit series (https://www.devopstoolkitseries.com), then you're surely thinking that I should already know what DevOps is, especially if I'm trying to spread my knowledge of it through these books.

The thing is, if there's anything that my years of working in the field have taught me, it's that DevOps is not a well-defined process. There is no set of rules that must be followed. As I discovered in my journey, and as you'll read in these pages, it's even questionable whether there is such a thing as a "DevOps department" or a "DevOps engineer." This ambiguity is exactly why DevOps is so fascinating to me, and I hope to you, the reader, as well.

I love going to conferences, but not for the obvious reasons. I rarely listen to talks. Instead, I tend to roam the corridors of conference centers and convention halls looking for the next victim who will allow me to pick his or her brain. The best thing about conferences is networking. The most interesting conversations are not taking place at scheduled talks, but rather in corridors and at the after-parties.

I consider myself lucky for being able to dedicate an important portion of my time attending conferences since I know that I benefit greatly from those "corridor-talks." I wanted to do something similar with this book.

This book is called DevOps Paradox. For those of you who may be wondering what it means, the Oxford English Dictionary defines the word "paradox" as:

A seemingly contradictory statement or proposition which when investigated may prove to be well founded or true.

Over the course of these interviews, my objective is to look at these often-contradictory views of what DevOps is, which, as we will investigate, may prove to be well founded.

What we have right now is an idea that people should work more closely together and that we should remove the barriers that slow them down.

As such, anything can be DevOps.

Almost every software company is marketing its products as "DevOps," and "DevOps engineer" is the most sought-after role in job listings. That's not to mention the fact that "DevOps departments" are popping up like mushrooms after the rain.

Yet despite this, almost every person I spoke to in this book gave me a different answer to the fundamental question of "What is DevOps?"

DevOps brings sanity into a very chaotic world created by a misunderstanding that software development is similar to factory production. DevOps continues where Agile left off, and urges us to remove the obstacles that we were often not even aware existed.

The idea of DevOps builds empathy between team members that ultimately results in greater cooperation. It's about culture, but it's also about the processes and the tools. At least, that's what I originally thought, even though I received very opposing definitions from the teams I worked with.

To answer the questions I had about DevOps, I asked a number of DevOps practitioners what they thought DevOps was. Some of them are industry veterans, while others are up-and-coming stars. Some are my friends, while others are people I have admired from afar.

Many of these conversations were recorded via remote sessions, while others took place in pubs or in conference corridors. Whenever I could, I did my best to speak with someone face-to-face.

I wanted the interviews to be casual. I did not want people to answer predefined questions. Instead, my goal was to bring to a wider audience the types of conversations I normally have with experts I meet in conferences and in companies I work with as a consultant. I do believe that some of the best breakthroughs come from corridor-talks. That's the spirit I wanted to maintain in the interviews.

Each conversation starts with the question "What is DevOps?" or some variation thereof. It is only meant to be a conversation-starter and to facilitate something that is an unstructured, unprepared, and very casual conversation. Think of each interview as a conversation with a friend or an acquaintance that I've met in a pub. As a matter of fact, a few of them were actually recorded in a bar over a few beers!

In this book, I wanted to share casual conversations with people who practice and often shape DevOps. My hope is that we'll get insights into what drives those people and come away with a better understanding of what makes DevOps so powerful.

The only thing the people I interviewed have in common is an interest in DevOps itself. You'll see, however, that some of them have very opposing views of what DevOps actually is (or is not), and even whether it's a worthwhile pursuit. You may often feel that what is described by one person contradicts what others have said. This is intentional and, in my opinion, reflects the chaos DevOps is trying to tame. It also serves as a reminder that we are still in the very early stages of adopting DevOps to our workplace cultures, while trying to navigate the complexities of the software industry and finding different solutions to the same problems.

1

Jeff Sussna

Founder and CEO, Sussna Associates

Introducing Jeff Sussna

In 2011, Jeff Sussna founded Sussna Associates, a company specializing in corporate workshops, coaching, and strategic design that enables clients to integrate DevOps. The author of Designing Delivery: Rethinking IT in the Digital Service Economy, Jeff has more than 30 years of IT experience, from software development to IT integration. You can follow him on Twitter at @jeffsussna.

Viktor Farcic: Hi, Jeff. Before we start talking about DevOps, could you introduce yourself?

Jeff Sussna: I'm an independent consultant focused on Agile, DevOps, and coaching design thinking. Through my company, Sussna Associates, I've been in the IT industry for 30 years and during that time, I've built systems and led organizations across the entire development QA (quality assurance) and operation spectrum.

I was introduced to design thinking and, in particular, service design and cloud computing in 2008, which was somewhat of an epiphany for me because I realized that in the 21st century, service is really at the core of cloud computing and IT. Whether it's infrastructure as a service or software as a service or microservices, you're talking about service that needs to be user-centered at every level of the organization.

I've really built that into the heart of my consulting practice, helping IT teams, whether they're enterprises or start-ups, to get them to really think in terms of whether it's their users, customers, database team, network team, application team, or whatever you may have. Because of that, I was responsible for introducing the idea of empathy into DevOps.

In my opinion, at the heart of what I'm doing is learning about how development and operations can think in terms of each other's needs. I brought all of those ideas together in a book I wrote called Designing Delivery: Rethinking IT in the Digital Service Economy.

What is DevOps?

Viktor Farcic: In your view, what's the meaning of the word "DevOps"? It's as if nobody has a clear idea of what it is, or at least everybody's idea is different. Some say it's about new tools, some claim it's a change in culture, while others associate it with a DevOps engineer role. Some even say the word DevOps doesn't exist. It goes on and on like that as if DevOps is a conspiracy meant to confuse everyone.

Jeff Sussna: For me, the meaning of "DevOps" is right there in the word itself. We have to start thinking about development and operations as part of one larger unified entity. The guiding principle I used to come to that conclusion again returns to this idea of service. The way we deliver service is digitally, and the thing about service is that the way you make it is part of what you make.

If you look at some of the public relations nightmares that have occurred in the airline industry over the last couple of years, flights are being canceled because reservation systems are going down. There was one incident recently when an airline couldn't check people in because their computer systems went down, and they were trying to use their cell phones to check people in.

"For me, the meaning of 'DevOps' is right there in the word itself. We have to start thinking about development and operations as part of one larger unified entity."

—Jeff Sussna

Viktor Farcic: I think that everyone takes software for granted these days. We are impatient and expect things to happen immediately, and if things fail, users just move somewhere else. There's no loyalty anymore.

What many have not yet realized is that it's not only about the features a piece of software offers, but also the stability of its systems. Would you agree with that?

Jeff Sussna: More and more, what's happening is that the user experience of the customer is very powerfully impacted by operation successes and failures, as much as by features and functionality. The example I like to use is that we imagine there's a new restaurant in town. You try it on a Saturday night, and when you come to work on Monday morning people ask you how it was, and you say, "Well, the food was great, but the service was awful." People are a lot less likely to try the restaurant because they think of the food and the service as part of one overall experience. In my opinion, DevOps reflects the idea that we have to think about functionality and operability together.

It doesn't matter how wonderful your design or how well coded your website is, if it's very, very slow or if people are constantly getting 500 errors, their level of satisfaction will drop.

You have to think about system architecture and application architecture. You have to think about how deployment happens, and you have to think about security all as part of one equation. In my mind, DevOps is a portmanteau, which means that we took two words and smashed them together, and the reason we smashed them together is that we started to understand that they're really part of one thing.

Viktor Farcic: Like one big theme instead of departments?

Jeff Sussna: Yes, and one thing that's important to me is the idea that smashing DevOps together doesn't necessarily mean that everybody must work for the same manager or VP. Everybody has to think about their work as part of something larger. You have to think about your code in terms of, "how will this code get deployed, how secure will this code be, how efficient will this code be, and how well will this code scale?"

That doesn't necessarily mean that you have to be the person who deploys it into production or answers the pager, whatever the case may be. I work with a lot of enterprises that have this notion of segregation of duties, and the idea that developers aren't allowed to push code into production doesn't mean that they can't do DevOps. If you're a large organization, whether it's a multinational insurance company or Netflix, with a lot of layers and a lot of pieces of technology, then maybe there are a lot of microservices. If not, there's still a lot of applications. The idea that you can have them all as part of one big department with one big giant foosball table and one big giant open office space doesn't really make any sense.

You have to think about DevOps in terms of collaboration among groups that don't necessarily report to the same person, don't necessarily sit next to each other in the office, or don't necessarily even work in the same city, and there's no problem with that. The problem comes when each group thinks, "Well, this is my job, and I worry about my job, and anybody else who wants something from me has to get in line, and I'm just going to think about my part of the puzzle."

"You have to think about DevOps in terms of collaboration among groups that don't necessarily report to the same person, don't necessarily sit next to each other in the office, or don't necessarily even work in the same city."

—Jeff Sussna

DevOps in the team environment

Viktor Farcic: I often see the same thing happening, with people saying, "This is my job, but that's not my job." With that being said, how do you prevent this type of thinking if different managers are giving different teams different objectives, especially ones that are not necessarily in line with the global vision because everybody thinks only, as you said, of their part of the puzzle?

Jeff Sussna: The way that I coach teams to do it is by getting them to think of each other as the customers, in the same way that the company thinks about people who pay the money to their customers. The network team has customers, and it's really funny because in DevOps, we engage in this little bit of magical thinking where we're all thinking, "Well, one key component of DevOps is the cloud." The cloud solves a bunch of problems, and I agree with that, but if you think about an AWS, Azure, or Google Cloud Platform, it's the ultimate silo. There is no bigger silo than the one between your organization and AWS.

AWS won't even tell you where the data center is, let alone who works on your code, your systems, or whatever the case may be. The thing about these organizations is that they understand they're in the service business and their job is to help you succeed, and they're continually innovating in order to help you succeed. I think exactly the same model applies inside the organization; whether it's split, whether you have two pizza teams that are cross-functional, or if you have departmental breakouts – it doesn't really matter. The question has to change from how do we run the network to how do we help people use the network, and that's a very, very subtle but very important and really significant mind shift.

If you're thinking in terms of how do we run the network and somebody wants an IP address, a DNS entry, or a firewall change, they'll have to get in line behind your process. But if you put them at the center, and you say, "Okay, our job is to make sure that these applications can successfully run and scale on top of our network," then things such as IP addresses, DNS entries, and firewall changes become the core of your job. So, through that, your job becomes primarily one of thinking about who are the people who need to use our services and answering the traditional question of, "Well, how do we make sure the router doesn't fall over?" It doesn't go away, but it becomes an implementation detail as opposed to being the core of your job.

Viktor Farcic: That makes perfect sense. Everyone's work becomes user-centric, no matter whether those users are external or internal. Meanwhile, everyone's job is to help someone, even when that someone is a colleague from a different department.

Empathy in DevOps

You've both written and spoken a lot about empathy. I'm not sure whether you coined the term EmpathyOps, but can you elaborate on what you mean by empathy?

Jeff Sussna: There's a lot of confusion and anxiety about its meaning, and a lot of people tend to misunderstand it. Sometimes people think empathy means wallowing in someone else's pain. In fact, there's actually a philosopher from Yale University who is now putting out the idea that empathy is actually bad, and that it's the cause of all of the world's problems and what we need instead is compassion.

From my perspective, that represents a misunderstanding of both empathy and compassion, but my favorite is when people say things like, "Sociopaths are really good at empathizing". My answer to that is, if you have a sociopath in your organization, you have a much bigger problem, and DevOps isn't going to solve it. At that point, you have an HR problem. What you need to distinguish between is emotional empathy and cognitive empathy, and I use cognitive empathy in the context of DevOps in a very simple way, which is the ability to think about things as if from another's perspective.

If you're a developer and you think, "What is the experience of deploying and running my application going to be?" you're thinking about it from the perspective of the operations person. If you're an operations person and you're thinking in terms of, "What is the experience going to be when you need to spin up a test server in a matter of hours in order to test a hotfix because all of your testing swim lanes are full of other things, and what does that mean for my process of provisioning servers?," then you're thinking about things from the tester's point of view. And so, to me, that's empathy, and that's empathizing, which is really at the heart of customer service. It's at the heart of design thinking, and it's at the heart of product development. What is it that our customers are trying to accomplish, what help do they need from us, and how can we help them?

"I use cognitive empathy in the context of DevOps in a very simple way, which is the ability to think about things as if from another's perspective."

—Jeff Sussna

Viktor Farcic: So, everyone has a customer, and we all need to start thinking about whether our work makes our customer's life easier or better, no matter whether that customer is internal or external. We shouldn't hide behind artificial objectives anymore.

Jeff Sussna: I'll give you an example of that. I actually got a little grief about this recently because I tend to be a bit of an AWS fanboy, but the reason for that is that I think they understand the idea of user-centered innovation better than anybody else.

A number of years ago, I was helping a client port an application from a colocation center to Amazon. It was a fairly simple app, and it was primarily a forklift port. It was running on old hardware that was starting to fail, and they didn't want to manage their hardware anymore. So we said, "Okay, let's just put it to Amazon." In this case, we were not going to try and do anything fancy like re-architect the application or anything like that, but we should take advantage of some of the more basic Amazon capabilities, like being able to run the web server auto-scaled across multiple availability zones.

It's a pretty straightforward thing to do, and there's no reason not to do it. We then came to one piece of our architecture, which was a Memcached server, and we couldn't figure out how to cluster it. It turned out that in those days, it was fairly hard to do. There was a product available that was very expensive, and we weren't sure if it really worked. So, we went around for a while, before we finally decided, let's not worry about it; it's a cache, and if the cache falls over, the application is smart enough to fall back and go straight to the database. Yes, it'll be slow, but it'll survive until we have a chance to tip the cache back up. Let's not sweat it, let's just go on with our work and finish.

We finished, and I think it was something like a few weeks later when AWS announced a new service called ElastiCache, which was – guess what? – a clustered Memcached server that ran across data centers. All you had to do was push a couple of buttons and type a few things into the console, and you could spin it up as a service. I remember thinking that it was as if they had been reading our emails.

The point of the story is that Amazon wasn't just resting on their laurels and saying, "We do infrastructure as a service, and we do storage and VMs and networking." They were looking at what it was that their customers were struggling with and how they could help make it easier. I think that is the essence of what we're talking about with DevOps: how do I, as a developer, make operations' lives easier and better, and as an operations person, how do I make development's life easier and better?

Viktor Farcic: But then what prevents companies from applying this type of thinking? Is it that they don't want to take this approach, that they don't see value in this line of thinking, or is it something else?

Jeff Sussna: I was talking with a client just the other day about this blockage in their process, to do with deploying code to a test environment. I started the conversation by asking, "Why can't developers deploy their own code? It's not production. There is no segregation of duty issues." They just hadn't thought about it. We talked it through, and they said there were no underlying reasons they couldn't. We would need to make some technical changes but there were no rules that say they shouldn't. It's a simple example of making available that which would make developers' lives easier. I think that expands out from there.

It has to do with the relationship between development and design, product and development, development and operations, and security and development. We all need to think from the perspective of, "How do we help each other better accomplish what we're trying to accomplish?" Empathy is what enables you to do this. But empathy is also thinking in terms of, "Forget about what I'm doing, what is it that you're trying to accomplish and how could I use my expertise to help you accomplish it?"

The big DevOps guy versus the little DevOps guy

Viktor Farcic: When you visit companies, do you see any recurring themes, or any commonalities between them? Are they facing the same problems, apart from the obvious of one company is smaller and the other one is bigger?

Jeff Sussna: I'm surprised at how common they are, regardless of the size of the company. For example, pretty much every single client that I've had, regardless of size, has compliance issues.

Maybe they're a start-up, but they're a healthcare start-up, which means they have to deal with HIPAA (The Health Insurance and Accountability Act of 1996); or maybe they process credit cards, which means they have to deal with PCI (Payment Card Industry); or they provide services to the Federal Government, which means they have to comply with FedRAMP, which is as draconian as any of the other compliance rule sets as you can find. Issues about audits, and segregation duties and access control; all of those things are common across my clients, regardless of their size.

"Pretty much every single client that I've had, regardless of size, has compliance issues."

—Jeff Sussna

I see the challenges between development and operations as being surprisingly universal. I think the main difference is that in the big companies, the dysfunction tends to be structural, as in, "I don't like your organization because we have different VPs and the VPs are competing for power," or something like that. Or maybe they're not competing for power, but they're just sort of separate and they're in competition with each other in some fashion.

There are institutionalized boundaries that keep people apart. In smaller companies, it tends to be much more personal. For instance, "I don't trust you because two and a half years ago, you broke things in a major way and so I don't ever want you deploying to production ever again," but these sorts of struggles to trust and to understand are surprisingly universal.

It's funny because in both Agile and DevOps, we talk a lot about feedback loops and how we can learn faster. If you look at the three ways of DevOps, you have flow, feedback, and continuous learning. It's surprising how difficult feedback is.

Viktor Farcic: I think that people tend to adopt practices, but where they fail is in understanding the goals behind those practices. As a result, we implement practices but fail to connect with them and gain any real benefits. Almost everyone collects feedback these days. The real question is, how many use that feedback to learn and adapt?

Jeff Sussna: I did a workshop with a client, a whole section of which was dedicated to feedback loops. The client was a very mature Agile and DevOps organization, and at one point I gave them an exercise, which was to take some linear processes they had and reimagine them as circular, feedback-driven processes in order to see what was different. They all chuckled and nodded wisely at me. Someone raised their hand and said, "We don't really have any linear processes anymore; we've made them all circular," and I said, "Alright, well, indulge me – just try and see what happens, this may be a very fast and easy exercise."

I'd split the group into four teams, and three of the four teams independently came to the same conclusion, which they reported to me very sheepishly after the exercise. They all came to the conclusion that they were very, very good at collecting feedback but they didn't actually do anything with it. They realized they were wasting an incredible amount of time and energy because they had this whole feedback loop mechanism that they never really closed all the way. If there's a danger that I see both with Agile and DevOps, it's that we get really focused on how fast we can get stuff to production, and we see it as essentially a push problem. One of the misconceptions I see about DevOps is that DevOps is about deployment automation.

"If there's a danger that I see both with Agile and DevOps, it's that we get really focused on how fast we can get stuff to production, and we see it as essentially a push problem. One of the misconceptions I see about DevOps is that DevOps is about deployment automation."

—Jeff Sussna

The problem with that is it's one-way, and you don't actually learn. If you push stuff to production and then all you do is go and pick the next thing out of your backlog, how are you really going to know that that's the right next thing to take out of your backlog unless you pay attention to what's happened to the thing you've just deployed? I would say the struggle to really get beyond this sort of an industrial-age approach, of the kind of pushing products out the factory door, is a universal challenge.

Viktor Farcic: Isn't that an example of blindly following processes without understanding the reasoning behind them? The idea behind short sprints is not to be able to do more work but to get that feedback sooner and better decide what to do next. If we just pick up a new item from the backlog, we are missing the point.

With that being said, let's change the subject. When you work with teams or companies, what is the approach? Are we starting from the top, from the bottom, or in the middle?

Jeff Sussna: I start all over the place; it really depends on the client. I mean, generally, it's anywhere from the CIO to some director of operations or director of development. It very much depends. It's an interesting question because what I find is that at some point, the two have to come together.

There's this interesting question about whether DevOps requires an executive buy-in or whether it should be a grassroots thing. In my experience, it doesn't matter where it starts, but at some point, it needs both.

I've seen places where, particularly with Agile, a CIO comes back from a conference and says, "We're doing Agile now," which is great; the process of actually going from that to an organization that implements it really doesn't require a lot of on-the-ground activity. Some of it is very grassroots: propagation of new behaviors and activities. One of the places that I focus on more and more is what the adoption process looks like, and in my opinion, in my experience – and I think this is another place where organizations struggle – changing how the organization behaves is no different from changing how your website works, or changing how your continuous integration pipeline works.

It's something that has to happen over time, and it has to happen in an Agile way. What I mean by that is that there has to be learning based on feedback; you can't just drop a plan in and do it, because what happens is people interact with that plan, they struggle, they resist, they learn, they make mistakes, and you find out that your plan maybe needs a little adjustment based on your corporate culture, so it's something that really has to unfold.

Changing the culture around DevOps

Viktor Farcic: When you try to change the culture, do you have a plan? I remember someone told me that you could not really predict a complex system; the only thing you can do is poke it and see what comes out.

Jeff Sussna: You're correct in thinking that you can have techniques that you use to introduce people to your system, and then you have to relate to what happens when they interact with those techniques. Everybody is a little bit different.

I teach, and when I do a coaching engagement, I always start with, depending on the size of the organization, anywhere from a week to a month spending a lot of time doing an embedded observation to really understand who and where they are. From there, I start introducing new techniques; whether it be stand-ups, continuous integration, or automated server provisioning, it really doesn't matter.

Then the fun starts when we're introducing Kanban. We're thinking, "That's straightforward – we simply show people how it works and explain the principal tool." But what actually happens is that when people start to work with it, they struggle in ways that are very unique to who they are, what their personalities are, and what their corporate culture is. And that's where the real work starts, trying to actually relate to those. I don't think you can really predict that. That's something that's very emergent.

Viktor Farcic: Right, we cannot blindly adopt anything since each of us is very different, as is the culture of each company, and our projects. To think that we can have such a vast difference and yet hope that a single solution will solve everyone's problems is childish, in my view. We all need to gain experience, understand ourselves, and use that knowledge to discover what works best for us.

I'm curious about design thinking, which is something you've mentioned a few times now. Can you elaborate on that?

Jeff Sussna: Design thinking is quite simply the notion that you can take something about the way designers solve problems, whether it be graphics, industrial, or user interface designers, and you can extract that into a methodology that you can then apply to other problems. For example, how would you introduce DevOps to a new company?

At the heart of design thinking is the notion of user-centered design, which is based around empathy, but it has particular techniques for helping you empathize, which are all based on observing and interacting with your customers.

One of the things that I tell teams even deep within IT is that if you're going to redesign something – for instance, you're the database team and you want to redesign the process that application teams use to get new database instances – start by just observing how they do it, and actually go and sit with them and just watch; and then from that you come up with a solution, prototype that solution, and get feedback on it.

"Current Agile and DevOps practices are incomplete because we don't really have a mechanism to incorporate true feedback from the people we're trying to serve."

—Jeff Sussna

Too many times IT does this thing where we sort of figure out what the right solution should be, we build it, and then we send out these emails saying that we're going to roll it out over the next three months with training. What we've failed to do is take the time to understand how well our solution actually works for the people who are going to be using it.

The idea of design thinking starts with empathetic observation. It can get more or less formal in terms of how it actually does that, and from there uses a very iterative process of prototyping, user testing, redesigning, and re-implementing to, almost in an Agile way, find its way to a solution.

Part of why I talk about design thinking so much is that I think current Agile and DevOps practices are incomplete because we don't really have a mechanism to incorporate true feedback from the people we're trying to serve. But validating our ideas, beliefs, solutions, and strategies with them is the reason why I think it's important to incorporate design thinking into what we're doing.

Viktor Farcic: How about Agile and DevOps, then? Are they separate things that you adopt, do they extend across each other, or are they different names for the same thing? Because from what you've said, there are things that sound similar about the two.

Agile versus DevOps

Jeff Sussna: DevOps completes the Agile equation. Agile talks a lot about delivering value and working code, but the problem is that by itself, it doesn't actually deliver anything. Instead, Agile kind of stops when you have code that's been written and tested, which nobody can use, so it doesn't do anybody any good.

The reason for that is Agile grew up in the product age when you would take your code, put it on a CD, and send it to your customer, who were the ones responsible for actually deploying and operating it. Those days are pretty much gone now, so that development and operations elements are really part of the same equation. Agile can't actually deliver the value unless that code can be deployed, and that deployment environment can be operated, and the problems can be fixed, including where new code can be deployed, and so on.

I don't think development without operations is meaningful anymore; and again, to clarify, when I say "operations," I mean in the largest sense of overall operability, so that includes not just running servers or running infrastructure, but also security, which is an integral part of that.

If your code or your infrastructure isn't secure, that's probably worse than if they don't scale. If your code doesn't scale, your website is slow, or your data entry application is slow, and that's annoying.

Viktor Farcic: Being slow is definitely better than not being available at all due to a security exploit that someone has used to bring your whole cluster down. If my data gets stolen from your system, not only will I not be your customer anymore, but I am likely to sue you as well. The part that confuses me is the talk about DevSecOps, because I come away feeling, like, why are we even talking about security? Isn't security something that is mandatory anyway and therefore part of DevOps? Or, did it somehow become optional and now we need to talk about including it as a separate practice?

Jeff Sussna: If my personal health data, credit card, or social security number gets stolen, then that's a lot more than just annoying. I know that when people talk about DevSecOps, they talk about rugged DevOps, which is the idea of DevOps with security built in. But the thing is, would you ever want to propose doing non-rugged DevOps? I certainly wouldn't.

I certainly wouldn't want to go to my CIO and say that we don't want to do rugged DevOps, we're just going to do unrugged DevOps, and that we're not going to worry about security. I wouldn't think that would go down very well. But, going from there, I think I would say that if we were trying to be Agile, at this point, you can't really be Agile without extending that into your operational approach to things.

I think it's more and more questionable how meaningful Agile and DevOps are without each other. I look forward to the day when we have a better word that just encompasses the whole thing, and we don't even worry anymore about whether there's a division. I mean, if you think about it, the dividing line between Agile and DevOps is still this strange space between development and operations, which is what we're trying to get rid of with DevOps. You could say that if you take DevOps seriously, you can't really believe in a fundamental separation between Agile and DevOps.

"I think it's more and more questionable how meaningful Agile and DevOps are without each other."

—Jeff Sussna

Viktor Farcic: In your experience, are there expertise groups that are more or less willing to adopt this line of thinking, or is that a universal problem for everybody?

Jeff Sussna: I think that more and more people are comfortable with the idea of joining Agile and DevOps together from the perspective of how fast we can get something from the product manager's brain into production. I think the backside of the feedback loop is a lot harder, and I think most people are still struggling with that, and that's a sin. As I've said before, I think both Agile and DevOps discussions often share the same sin, which is we think it's one-directional.

I'll give you an example: I worked with an organization where I was told by the head of development that they did sprint demos to show people what they were going to deploy before they deployed it. The point of a sprint demo is information; it's gathering feedback, it's making sure you're about to deploy the right thing in the right way before you deploy it. This head of development was approaching the sprint demo in a pure sense: "well, we're done, and we're going to let you see it before we ship it, but don't expect us to make any changes or listen to your feedback." I see that problem all over the place.

Viktor Farcic: It's almost as if I'm giving you permission to see it but whether you see it or not doesn't matter much to me.

Jeff Sussna: That's exactly right, and I think part of the benefit of infusing design thinking is that at the very heart of it is the idea that you're going to show it to somebody, and then you're going to make changes based on their response to it.

Viktor Farcic: If I understand it right, that means that even if we go years back, in many places Agile didn't work, because if it did then that type of thinking would be engraved already, at least, in parts of an organization.

You mentioned complex systems, and I think that's actually worth talking about a little bit.

You hit the nail on the head when you said that complex systems are ones that you can't predict. So, in that sense, you can't plan for them; you can only really probe them and interact with them based on what you learned from that probe.

Jeff Sussna: The systems we are building are complex systems, so even in enterprises where there are very legacy environments, I see more and more that they'll have outages that are caused by interactions between the application, database, network, load balancer, and firewall.

In order to understand the outage, you have to understand how all of the components interact with each other, and if any of those had been different, then the outage might have been different, or it might not have happened at all. What digital business and the digital economy and all that the fun stuff is doing is breaking down the boundaries between these different systems.

Viktor Farcic: When I see things like this whole idea of bimodal IT, to me it doesn't actually connect to reality, because what I see is customer-facing applications that, in order to work properly, have to interact with ERP, or Enterprise Resource Planning, systems, and the lack of agility in the ERP system becomes a blocker to agility in the frontend system.

Nowadays, we have to think about our whole organization and all of our systems together as this one complex system.

Jeff Sussna: If we can't predict or control complex systems, what do we do? Do we just give up? No, we have to have the ability to continually learn. So, why do we need Agile? Why do we need DevOps? Why do we need design thinking?

Because when we approach them correctly, they give us the ability to very efficiently, and effectively, continuously learn from each other, from our customers, from our systems, from our incidents, and I think that's ultimately what we are trying to accomplish with all of these new practices.

Viktor Farcic: In my experience, when I dig a bit deeper, beyond what people tell me, I find somehow that the blame is always the biggest obstacle because when those things happen, like what you said – for example, an outage – somebody needs to be blamed for that, and that means nobody's going to give me enough information so I can learn from it.

Jeff Sussna: Even beyond that, the idea of blame assumes that you could isolate causes.

Viktor Farcic: Right, which brings us back to the complex system.

Jeff Sussna: Exactly.

Viktor Farcic: I think that gives us a nice place to wrap up unless you have anything else to say, Jeff?

Jeff Sussna: No, I don't, but it's been great talking to you, Viktor. I can't wait to see what everyone else thinks about DevOps.

2

Damien Duportal

Træfik's Developer Advocate

Introducing Damien Duportal

According to Damien, being a DevOps engineer is all about the people, culture, and tools. Alongside his work at Træfik, Damien is a training engineer at CloudBees, where he focuses on the CloudBees Jenkins Platform and Jenkins OSS. You can follow him on Twitter at @DamienDuportal.

Viktor Farcic: I'm going to ask you a question that I want to use as a springboard into our discussion of DevOps. Simply put, what is the Duportal definition of DevOps?

The Duportal definition of DevOps

Damien Duportal: Today, DevOps is a trendy buzzword that is used to try to achieve focus on value, and not only for the technical or cost concerns. At its core, DevOps is really about how we should work together in the IT industry. I'm not just talking about the process, but also about the culture, tools, and the people involved in it. This is why I said it's a trendy buzzword because there is no strict definition as you could have for IT service management.

"DevOps was focused not on the tools themselves but on the way these tools could achieve either a new way of working or a breaking down of the barriers between teams and departments, which means working and talking to each other, in order to generate cross-team awareness."

—Damien Duportal

More recently, DevOps has been taken over by a different sphere of influence, but initially, for me, it was a movement that started around the idea of tooling. DevOps was focused not on the tools themselves but on the way these tools could achieve either a new way of working or a breaking down of the barriers between teams and departments, which means working and talking to each other, in order to generate cross-team awareness.

I define DevOps as empathy, which I think is the main key here. DevOps is a way of bringing empathy back into our work, and the tools—Docker being the most famous, but by no means the only one—that can help you to do that. But it's important to understand that when I say empathy, I mean empathy with your other colleagues, not just between the two sides of DevOps—development and operations—but also between engineers and salespeople, executives and employees, and all of the local departments of an organization that should focus on the global optimum and not on their local optimum. You need to be aware of the issues that your other colleagues could be facing and not just those issues affecting you or your local departments. The tools are just one way of achieving that, which appeals a lot to engineers because engineers love their tools.

Viktor Farcic: So, DevOps is really using tools to help bring empathy back?

Can DevOps bring empathy back?

Damien Duportal: Yes! If you have a tool that helps you to share empathy, then you have a great foundation for starting the conversation. Even if this seems boring to engineers, at least they'll start talking and listening to each other. I mean, once they've stopped debating sterile tabs versus spaces or JavaScript versus Java—or whatever sterile debate it is—they'll have to focus on the value they're going to provide. So, this is really how I would sum up DevOps, which again is about how you bring empathy back and focus on the value creation and interaction side of IT.

"I would sum up DevOps as how you bring empathy back and focus on the value creation and interaction side of IT."

—Damien Duportal

Viktor Farcic: But why is that particularly important?

Damien Duportal: Because of the different human behaviors. But more than that, empathy is one of the most advanced bricks you can have for building human interaction. If we are able to achieve so many different things—with different people, different opinions, and different cultures—it's because we, as humans, are capable of having high levels of empathy. As soon as you have empathy, you can understand why you provide value. If you don't, then what's the point of trying to create value? It will only be from your point of view, and there are over seven billion other people in the world. So, ultimately, we need empathy to understand what we are going to do with our tools.

Viktor Farcic: That's a good one. You mentioned that Docker is one of those tools; could you expand on that?

Damien Duportal: Before I went freelance, I worked as a developer, but because there were only a few of us, I was quite close to those working in operations. Despite taking Java development courses as an engineering graduate, I was always interested in how we could start coding the infrastructure from very early on. I can't remember who said this, but I believe it was someone at Netflix—If you build it, you run it. I love that mindset and it's what brought me to provisioning tools such as Docker, SaltStack, Chef, Puppet, and Ansible.

Overcoming the fear of change

We used a lot of these tools to help to bring operations teams' concerns to developers. Bear in mind that a lot of developers didn't want to learn these tools, and what I quickly discovered was that this was because of fear. Developers were driven by fear because they didn't understand these new tools and, because they lacked a lot of knowledge, they were closed off. They were terrified by the idea of operations knowledge and failed to actually see that these tools presented a lot of new things for them to learn and try. But what the developers didn't realize was that that fear was also present in the operations people on our teams, and that was just locally.

Viktor Farcic: That fear of change is a really great perspective, but did you ever manage to remove that fear from both the development and operations teams?

Damien Duportal: I should add that I can't generalize to other contexts, but that's how I understood things and behaviors from our end. In response to your question, it took me three to four years of trying to build a bridge between both parties and convincing them not to be scared. That bridge was me saying that we can work together and choose pair programming, even something as simple as sharing a beer after work or a coffee before, or doing sports together outside of work. Was it successful? Well, it was helping, but not completely solving the problem because at the time I lacked the ability to bring empathy to the team.

When Docker landed, it was as if I had seen the light at the end of the tunnel because, finally, I had a development tool produced by a person who shared the same concerns of those in operations at the heart of the development. That's really the reason why I used it. The good thing is that whenever a person started with Docker, they had the same learning curve. Why was this important? Because it made it visible for everyone that we all had a lot to learn.

Docker managed to be the bridge because it successfully broke down the barrier of fear because operations not only saw what they had to learn, but it turned out that they really liked learning the new tools. The only thing missing now was the time to learn. But the time issue was also seen as a potential investment opportunity, with those in operations thinking that if they spend time learning Docker, then gradually, the developers would follow us or our recommendation. At the same time, on the other side of the bridge, the developers were starting to think along the lines of: "Hey! That tool Docker sounds good! It could help us. It's easy to use, and it works very fast." Docker was just a way to turn a lot of this scary-sounding technology into a fancy tool. So, with that thinking, even marketing got on board and helped spread awareness of it everywhere.

"Docker managed to be the bridge because it successfully broke down the barrier of fear because operations not only saw what they had to learn, but it turned out they really liked learning the new tools. The only thing missing now was the time to learn."

—Damien Duportal

Viktor Farcic: But apart from building a bridge between the two teams, how was Docker able to create a feeling of empathy between them?

Damien Duportal: What Docker did was make the learning curve linear. You were able to start with just a few lines of code and get something done very easily. Through this, you could then see that if the coding worked, then it's already gained value. The teams were able to choose the moment when they would learn and add more quality or more completeness to what they wanted to achieve with Docker. This method was quite linear when compared to whatever tools you could have used before for finding the gaps. But back then, you had to learn Linux and Linux configuration, and possibly even Unity or systemd—all of the distributions—which were all learned in big steps. This was how I discovered and was subsequently convinced, in a very short time, that these tools brought empathy.

It reminds me of situations we, as an industry, have been completely locked on for years, such as an operations person coming to the development team and saying: "Hey! Nice application. Do you know where the application is expected to write files on the filesystem?" Because, by saying that, it implied the intention was because we have an issue in production right now, a performance and/or security issue or an audit, and we needed that information because it's valuable. But in that case, the communication was just: "We need this, and it's mandatory." But all the developers heard was: "Oh, yeah. We want information that's really boring, and we don't want to search by ourselves."

Viktor Farcic: So, did Docker remove that barrier?

Docker, containers, and the rate of adoption

Damien Duportal: The message was totally transformed. By using Docker as a support for the base communication, we just removed that barrier. In Docker, you can just say: "OK. Let's use the read-only flag," and by default, everything will be forbidden in writing except when you have an exhaustive list of the data volume. This is technical stuff, but once you've tackled the technical problems, you remove the stress, and then you can start talking. We were in need of Docker because we needed to remove that stress. You just removed the engineering part and focused on the discussion of needs in advance, and that's why Docker was a big game changer here, but it stands on the shoulders of giants.

In earlier years, this work was being done by the likes of Puppet and Chef, who were already bringing the development mindset back to operations. Operations people are just developers for the system. For example, all kernel developers are developers, and their operations people help. So, there is no such thing as operations or development because, at the end of the day, we are all doing the same job. It's just that the amount of knowledge required for each area is much more than one person can handle on their own, so we have to partition that knowledge. But still, the daily job is editing text files, planning, and testing that that change locally, and then globally, is the same for everyone. We just have to be reminded of this, and Docker was a great aid for that.

Viktor Farcic: That's interesting because, if I understand you correctly, what you said is that Docker made it possible to implement DevOps without companies having to plan the change. Basically, Docker made it happen naturally without any enforcement of the idea that you need to talk to this guy. Otherwise, the consequences are going to happen.

Damien Duportal: I used to say that Docker was just uncovering the dust that you hide for a year under the carpet, and suddenly, you put Docker somewhere, and you can use it as a maturity indicator. If you put Docker somewhere and everything explodes, then you don't know how to monitor Docker, or even how to build an image. If that's the case, the real question then is what were you doing before Docker? Were you just covering your eyes and throwing code into production without thinking about it?

"I used to say that Docker was just uncovering the dust that you hide for a year under the carpet, and suddenly, you put Docker somewhere, and you can use it as a maturity indicator."

—Damien Duportal