Patrick Debois Reflects on The DevOps Handbook

Patrick Debois (00:00)

My argument would be, yes, it's a pain, but on the flip side, I hope as a developer, you actually care about your users and their running production, not during your laptop, right? So if they fail and they fail consistently, I hope you actually do something about it.

Carter Morgan (00:26)

And three, two, one, go. Hey there, welcome to Book Overflows, the podcast for software engineers by software engineers where every week we read one of the best technical books in the world in an effort to improve our craft. I'm Carter Morgan and I'm joined here as always by my cohost, Nathan Toops. How are doing, Nathan?

Nathan Toups (00:40)

Doing great here, everybody.

Carter Morgan (00:42)

we're very excited because we have another interview for you today and it is with Patrick Dubois, one of the authors of the DevOps Handbook, which was so exciting. We talked to them a bit before we learned that he personally did not write much of any of the DevOps Handbook, but rather was one of the kind of chief consultants and thought partners with Gene Kim, who actually authored most of the book. But he is

It one of the forefathers of DevOps and such a fascinating guy and so generous of him to come on the podcast. Great interview. Nathan, what'd you think? What do think our listeners are going to think?

Nathan Toups (01:13)

Yeah, fun fact, Patrick was the creator of the term DevOps. ⁓ Looking for ⁓ an easy phrase to go with DevOps Days, which is the name of the conference that started in 2009. It was a really cool conversation and it's also interesting to see like, we see how mature everything is now. And it was cool to see a glimpse of like how much has changed, mostly because a conversation has been happening back and forth. He keeps coming back to the fact that like, yes, we have all these tools and the tools are important.

but it's these relationships and a reset of like how, you know, we talk between stuff, but we even get into very modern things like AI and other, you know, modern practices and just a really cool conversation. I think you're gonna like it a lot.

Carter Morgan (01:57)

Yeah, Patrick, class act. We are talking about, he falls in kind of that Brian Kernahan camp, another guest of the podcast who has every right to have a huge ego and to be very proud of what he's done. And yet he is very down to earth, very humble, just very classy in all regards. So we're so excited for you guys to to hear this interview. So please enjoy this interview with Patrick Dubois as he reflects on his book, the DevOps Sandbook.

Carter Morgan (02:26)

Well thank you so much for joining us Patrick, it's such a pleasure to have you.

Patrick Debois (02:29)

It's my pleasure to be here.

Carter Morgan (02:32)

Well, we are so excited. We read the DevOps handbook. It must have been a couple months ago now, uh, but loved it. Um, and obviously it's kind of one of the seminal works in our industry. know we were chatting, but before the podcast started, you said that while you didn't author a ton of it, you were a contributor to it, obviously. And Gene Kim heavily drew on your expertise for it. Maybe describe to us kind of like what the industry was at the time of the book was ready. Cause when was it published? I forget. Is it like 2013 ish? 2016.

Nathan Toups (02:59)

Originally it was 2016, I think, right?

Carter Morgan (03:02)

Okay,

Nathan Toups (03:02)

Yeah.

Carter Morgan (03:03)

so at 10 years old at this point, maybe describe to us kind of your take on the industry at that point and what motivated you to, if not write the book, then to partner with Gene Kim on writing the book, maybe how that all came to be.

Patrick Debois (03:15)

Sure, Well, a lesson in history. I don't know if everybody is interested, but for the sake of this episode. In 2009, I ran the first DevOps Days event. So that was several years before the first book. Right. But that was a community, let's say, from practitioners and people kind of sharing stories and a very community-led conference. There was like no big companies and

Carter Morgan (03:21)

Ha ha.

Patrick Debois (03:43)

and things that were maybe a few unicorns that were like trying to kind of do that. I think at the time the first book came out, there was a bigger craven from the enterprise to kind of like be part of this like fun story that like bubbled up from the community. And as happens quite often is when there is a new kind of idea or a new movement, they kind of want to hear stories of other companies kind of doing that. Now,

I think in 2009 it was, and I think still in 2016, there was kind of throwing software over the wall, as we typically call, like one group of operating whatever hardware infrastructure, and then moving to the cloud, and another group writing that software. So kind of was kind of the throwing over the wall. And while that moved a little bit in the community with...

things like CI, CD, more integrations and more agile. ⁓ In big companies, it was still the way of working, very silos, ⁓ that. So the enterprise came a little bit later, but that was roughly sketched in the industry where we were. Agile was already there, Project, that was common in industries. Cloud was emerging, but not anymore that emerging. ⁓

but just enterprising, needing their own story to be convinced or convincing their boss.

Carter Morgan (05:18)

Talk to us a bit about, maybe some of our listeners aren't as familiar, and honestly, even I'm not as entirely familiar. You're one of the very first people kind of in the DevOps space. If I'm not mistaken, are you credited with coining the term DevOps?

Patrick Debois (05:33)

Yes, people say that of me and it's a very nice kind of compliment. But I always say it was kind of like by accident and the name kind of got coined because of that conference, that kind of gathering that I called DevOps Days. And after the first event, kind of like, was Stephen Nelson Smith.

Carter Morgan (05:39)

Hahaha.

Patrick Debois (05:59)

kind of wrote a blog post related to the event and said, what's this DevOps thing anyway? We had no clue this was going to be big. There were like 65 people at the first event, but there were like, you know, people experimenting with Agile system administration. And that was kind of the, the backstory that I tell is Agile system administration days was just too long for a conference. And then DevOps days kind of like felt more natural. And my

internal pun was, deaf ops days, DOD, dead on delivery, but kind of that never took off. Anyway, that was the back story.

Carter Morgan (06:35)

you

I mean, so something I've always been really interested in the industry is Nathan and I, obviously we do a podcast where we read a lot of books. We try to stay very up to date on Martin Fowler told us we don't call them best practices, but sensible defaults, right? We try to gather the collective industry or collective wisdom of the industry and figure it out. But you're kind of on the very forefront of this. mean, what motivated, what motivated you or maybe still motivates you to try to be ahead of the curve, to try to be recognizing these problems in our industry and to really be making

the moves necessary to be a force for change in the industry.

Patrick Debois (07:13)

I think it's different for every person individually. ⁓ think I, over the years, I learned that what makes me thick is I want to learn new stuff. And when I learn new stuff, how do I get my daily fix of learnings? That's kind of reading books, all right? That's one thing, and blog posts, and podcasts. But I found that while you're talking about that stuff, you kind of have people telling the stories back to you.

And so that's kind of where that first event was kind of instrumental. Hey, ⁓ let's talk about this problem space that we're all experiencing. ⁓ It's not coming with a solution. wasn't vendor based. We weren't like pitching products. It was more like, and I say that in a very gentle way, kind of like the AA meeting. Hey, I'm Patrick. I'm having a problem with my company. It's not really working here. Like, what do I do? And then we kind of.

Carter Morgan (08:08)

You

Patrick Debois (08:11)

start discussing. ⁓ I think part of the program of the DevOps days was that half a day was presentations. that's, I always say that was aligning people on the similar stories. And the second part were open spaces where people could bring their own topics. That was instrumental as that kind of like, you know, not just being dominated by anybody, but more like, hey, I am thinking about this. How about that?

And then early people came from the Agile movement, from the CI CD movement, from the clap movement. And they're all had like opinions on collect, you know, things that I've been trying. So ⁓ as you probably, you know, I think it was very similar to Agile or ITIL or anything else. starts with a bunch of people usually kind of looking for, Hey, we've been trying to do this. Like how we can we improve ourselves? ⁓

It wasn't like a grand scheme and that's why I'm saying it has been an accident or we're not like trying to coin a term and then like create an industry or that. And I often get these questions like, how do I grow a community? like, well, big actually a problem that exists and everybody has, right? So don't make up your own problem and try to sell it as the problem everybody else. Well, you could do that. I can't, but you know, other people can do that. But that's kind of how I think about this.

Carter Morgan (09:24)

You

you

Patrick Debois (09:36)

And maybe to finish off that thought, how I roll into this is that I got very excited about Agile and the way that it kind of changed the way development worked in general and kind of the openness and the human aspect of this. And I came from the sysadmin world originally, although I kind of always pivoted across both. And I said, what would it mean?

to bring that into my world. And ⁓ even in 2008, before that, I had somewhere a talk at an agile conference, which was ⁓ using Kanban for operations. How would that work? So that had nothing to do with cloud, but it was like, OK, how do we collaborate in a more ⁓ kind of agile way? And then cloud came, made everything more flexible. It wasn't like pulling wires anymore, became virtual. So that kind of extension.

a lot of things, it's building on prior art and thinking of previous people, whether that's like, there are constraints or agile or ITIL and kind of then people try to move and navigate around the new problem set that they have. you know, now maybe we'll get to that later, but right now we'll probably have a different set of problems. So we kind of can't use the past approaches to kind of look at the new thing.

Nathan Toups (11:02)

Yeah, I'm a bit biased here. ⁓ I've made an entire career out of being in, ⁓ I was assistant man, got into DevOps and infrastructure as code. And so I followed these books over my career. One of the fun things about this podcast is that we've kind of introduced these because, you know, most of our audience is software engineering. And it was a joy for me to share some of these DevOps ⁓ platform engineering, you know, all the new terms that are coming up. ⁓ One the things that I've appreciated about this and why I think like the second edition,

aged well, right? There's 2016 to 20, I think it was 2021, something like that. I liked that this book is built on this like three ways, the flow, feedback and continuous learning. And I could hear this in your voice, right? Like you're talking about, like you get excited about the learning and the changing parts. With this in mind, like, what are you excited about?

We've already started using terms like platform engineering or developer experience. Now we're talking about AI enablement. What things do you see on the horizon that are kind of pushing this industry and making us ask new questions?

Patrick Debois (12:12)

So I'm personally, and I'm also biased because what I do and kind of what I work on, ⁓ I think on the one hand, there's a scaling aspect ⁓ that's interesting, but it's only for fewer people. Let's say we're not all operating at Amazon scale and so on. But they do have some interesting problems about like, hey, how do I keep like a thousand systems in sync, which is different from 10.

as an engineer or how do you like to observability? Same patterns might apply, but you kind of bump into like other bottlenecks in that system. And then I think over the years, ⁓ I was somewhere on the forefront of, know, kind like when we switched to more container stuff or serverless stuff or mobile. But I think that like wasn't that big a change for me as such. ⁓

For me right now is AI, but I guess that's the whole industry. What keeps it exciting? ⁓ And ⁓ one of the questions then I often get is like, well, how does AI change the DevOps world or the developer world or kind of stuff like that? ⁓ while it's very ⁓ interesting to, and I have that in my presentation, if you sprinkle on AI on your product, you can call it a product.

but we learned also with the same thing, if you sprinkle out a ⁓ cloud or cloud native on your platform, right? So it doesn't mean it is like that. And so it usually takes a few years to settle what that new way of working kind of actually becomes. And I'm excited to see what are, you we move from, hey, you know, this is cool in our coding agents to IDEs are that let's do terminals and collect. It's going like every

three, four months, there's like a twist in the plot, which is kind of like changing the narrative there. And I think that's the exciting part is that it goes way faster than maybe in the past where it was like an incremental buildup. And they all have a chaos spirit like we have right now, but usually it's like over a longer term period and you see it maturing. Now I feel like, you know, the rules of the game are just changed.

every six months and we're like rethinking what is actually possible and what it should do. And I like that period, like I mentioned, I like to learn. So this is, I'm having the time of my life, kind like looking at what it could be. ⁓ But I also understand that people are like afraid and kind of maybe don't like change or kind of kind of try to figure out ways to absorb kind of that change into their daily lives. And that was quite similar to do DevOps. well, you know.

am I still gonna have a job, right? I'm already writing all these scripts. And then it turned out, our industry made it more complex than it probably should be. And then we have more jobs and we're getting better paid. And I can't predict whether that's the case with AI, but it's just like interesting ⁓ every time they're like, let's say the people who are afraid, the people who are like risk averse and then kind of that.

I think now the adoption with AI was kind of like, came at a moment where the economic climate was maybe on the one hand, not that good. And that required people to push them if you're on kind of the downside of the industry to push and see if they can kind of leverage something cool there. But other industries kind of don't care and they will be slow.

because they are risk-averse and it's not because they want to be slow, but it's because they take a different strategy on that piece. And maybe one funny anecdote on the days of DevOps then. ⁓ You try to explain all the benefits of DevOps to a C-level executive and you do the elevator pitch and you say, hey, this is great. We should collaborate and we're getting better results and we automate that stuff. And I remember. ⁓

He looked up to me and he said like, you know what, I get it, but it's a lot of change in my company. What if I just change my pricing with $0.1? I'd probably get the same money effect. And he's probably right in a perspective that it was less risk. It could just turn on a few dollars and from that perspective, but it would have eventually a different company dynamic.

that was behind all the others. So it's kind of like, when do you pick your battle to step into that field?

Carter Morgan (17:03)

That's something I wanted to ask about and we talked a bit about it when we were recording our episode, which is that a lot of the DevOps handbook seems to be targeted almost to like senior leadership or people who are really in a position to change. We were joking that like, if you were an individual contributor at one of these companies and you read this book, you'd be just like,

cursed with knowledge because you'd see like, there's a better way to do things, but then now you have to like run it up the chain and try, know, to, especially at kind of any more enterprise place where these kind of more legacy ways of delivering software might be kind of built into the org structure. I mean, if you're an individual contributor and you're interested in kind of introducing DevOps, is there a way to kind of break through or is the DevOps handbook really designed more for people who have the ability to

make those decisions.

Patrick Debois (17:52)

I think that's a fair comment that it was more kind of supporting people in their decisions as such. Although there's a fairly kind of even a senior IC would probably find the stories relatable of things that they've kind of done. But it's kind of like them going to management or management kind of trying to translate it back to what they want. And I think that's

definitely been the, how do you say that? Not only the benefit, but kind of the impact of that book is that we got the C level or somewhere in between that level kind of onboard. I think you have to see that we were already five years into the DevOps days, which kind of like brought a lot of community and blog posts and kind of that stuff. But it wasn't until that book was able to hand it out into an enterprise and say, hey, you know.

kind of read this as more management and other banks were doing this or other big companies are doing that. That was more like effective. ⁓ It did kind of go with a certain way in hand in hand, but not into the conference called the DevOps enterprise, which was also kind of targeted to leadership and kind of more C level, kind of talking about their set of problems because it is one.

thing to kind of, hey, I need a Kubernetes, which didn't exist at the time. I mean, just whatever VM or something to spin it up where I need a test framework or monitoring. And on other hand, it's like, how do I scale this out into an enterprise? How do you break the barriers of the silos, which is more of a management kind of aspect? People have been able to do it grassroots by kind of showing the differences. But

The ideal is always when it comes from both sides. And both are kind of know, enthusiastic about this.

Carter Morgan (19:52)

Have you ever seen it in reverse where it's management who's really excited about it, but the engineers are reluctant to change? Okay.

Patrick Debois (19:58)

Yeah. Yeah. I've seen several

cases and at banks or others where they just go in, we were all in on the DevOps handbook and they buy like a ton of books. No, no, just kidding. But they kind of send them off to their management and say, hey, this is where we had actually want to head towards. And then they find like allies. then what was nice at the time the book came out, there was more tooling.

Carter Morgan (20:11)

Hahaha.

Patrick Debois (20:27)

that kind of supported some of that. Although, in general, the collaboration doesn't need particular tooling. But it was nice that there were two stories, the cultural story and the tool story. And there's always this debate on DevOps is about the culture. DevOps is about the tools. in my opinion, both go hand in hand. If you don't have the right tools, you might likely not be able to change your process. And if you're just talking process and

Anyway, so I think they go hand in hand and let's say in ITIL, it was ticketing systems, right? That kind of broke the barrier. ⁓ In Agile, it was the Scrum and kind of like the TDD that broke a barrier. So I think both go hand in hand in kind of like changing ⁓ behavior there.

Nathan Toups (21:22)

So this book has a lot of success stories, Netflix, Etsy, Amazon. One of the things I really, I wished that it included were some failure stories. I think those are also useful as far as like a misimplementation or anything like that. I would love it if you had any war stories of organizations that have like struggled to make the transition or maybe took a strategy that just didn't hit the way you thought it would.

Patrick Debois (21:52)

tell you all my failed stories. ⁓

Carter Morgan (21:54)

Hahaha.

Patrick Debois (22:00)

So I think you're coming this fair in that there were kind of the post-war trials, Like Etsy had like John Osbaugh as an engineering manager was really driving that church of metrics as they call it, like that was there. Netflix had like ⁓ Adrian Cockroft. So they had like strong engineering and technical managers that kind of threw that story. Now, obviously at the time we didn't have enough traditional, traditional

enterprises maybe, to kind of like see the patterns of the failures of that kind of bigger company impact. Now, probably on the second book, that would have been like a fair thing to kind of include more and kind of probably there were a few more stories on that part. But I think it's in general hard because

A lot of people think, we're just going to replace that infrastructure layer, which it isn't about. imagine without DevOps and, ⁓ imagine you didn't have Kubernetes. You didn't have the cloud. ⁓ You also had these problems, but you could have also solved it without it. And I take the example like, hey, want to do an agile kind of migration? ⁓

just by a very long cable. No, we can't pull long cables in our kind of ⁓ data center. That's impossible, right? And I'm not even talking about virtual or kind of anything, but you see kind of it's the mentality. Like, are you able to kind of do something more flexible and kind of see the collaboration? Even before, people were talking to each other and they had a better way of documenting things or supporting stuff. So people say we were doing DevOps before DevOps, which was totally fair, and we didn't have to do all that.

So what you have to break is, hey, ⁓ we're just so used to doing things a certain way. Or the scary part was, hey, we're going to do more deploys, but the biggest problem is when we do deploys. So it was very counterintuitive. making that case is challenging. ⁓

a certain level of return on investment of, ⁓ we're going to automate everything to the cloud and, you know, it's going to cost us. ⁓ So there is kind of an optimist story, which can work, but if, if the stars don't align or you don't have the support from the right people or the right manager, or it's not being backed by financial or certain stuff, it can definitely easily fail. So it's not because you have that story of

a successful company, but that's in general. You take the Spotify model, which was known to work well at Spotify, but you take actually the people and the history of that company away, or not with you, I mean, to the new company. And that's kind of been a challenge for with every story of transformation as such. ⁓ Maybe you have a vendor contract that you can't get out of and it becomes harder. Maybe you have your boss as a culture of

you know, very strongly believing in have everything needs to be requirements and kind of pick up front design. So those were all like struggles that we go to. ⁓ Even on a smaller scale and then I can talk to maybe like some of my stories. If you think that's, that's, ⁓ you're the DevOps engineer of let's say a five person startup and you say, Hey, I'm going to do all that cool stuff. Right.

⁓ It doesn't bring any money, right? So of course, we might think as engineers that we're the center of the universe and this is the coolest thing ever, but the bottleneck might be, we do not want to spend any effort on that automation because we actually need to work on getting customers. And I mean that in a good way. So it's okay to...

cut corners and take certain risks. That's part of like taking that. But those choices, we might not like them. And that's an alignment you do at the management. Like how much are we going to invest in that automation and that platform piece? Or how much are we actually going to do on sales? And how much time does anybody get? Or like how much do we care about security? How much do we care about observability? They're all investments and

Nathan Toups (26:30)

Right.

Right.

Patrick Debois (26:49)

I think the challenging part is a lot of it, and I had to do it multiple times, how do you justify it? How do you make it visible? And some of early stories were like, well, if I can do it faster than my competitor, that's easy. But that's an easy thing to do. But if nobody really cares about performance and nobody really cares about the backup, but only your contract does,

Well, if you don't get the money in the time, that's going to be a hard sell. So that brings up a lot of frustrations. But guess what? That's actually in all parts of the business. As a developer, you're thinking, hey, I want to do my job. And this is the most important thing. As a marketer, I want to do that part of the job. And that's why it's not a clear rollout. Like, hey, this is what you do. Just buy that infrastructure, roll it out, and done. But of course, I'm talking about the cultural change and the collaboration spaces.

I'm not talking about like, hey, set up a virtual machine, put it in the cloud. Yes, that's a lot easier to repeat. And that's often why a lot of people start with that. And it makes sense also to bring that piece together with your transformation. But the actual transformation is so hard in many companies.

Nathan Toups (28:11)

Yeah, the, I've been in a lot of like series a to series C level companies and we're going through these ideas of like how much formality are we putting in place and finding that sort of like maturity model of crawl, walk, run. And I've found that one of the ones that it's like really nice to have this conversation with is sort of the local first methodology because it's like typically pretty low hanging fruit. We don't have to deal with all the infrastructure decisions that are coming down the road. And I can still point them in the right direction, like

There's probably containers involved. It probably has to do with how quickly we can have our first commit for a new engineer on the team. These kind of early wins sort of optimizations where the engineers are happy. And I ended up getting some street cred so that when I do have like, know, crazier ideas like hermetic builds and a monorebo or whatever thing that we're going to advocate, it's like with that trust that was built. ⁓ At least that was been a useful pattern for me, especially when we're growing. ⁓

You talk about fail fast, and I think that is a big part of this. I think maybe sometimes people misunderstand what fail fast means of actually shoot for failures versus safety. ⁓ How do you approach things like fail fast? I guess this ties into some of failure stuff too, which is ⁓ building a culture of experimentation, building a culture of failing fast, especially in regulated industries like finance or healthcare or something like that.

Patrick Debois (29:31)

Mm-hmm.

Yeah. So.

I think you're right that it's often mistaken by ⁓ the cowboy or any island would say like the Yolo mode, right? Just like do whatever and kind of click all accept. If you want to introduce kind of a safety, you got to have a safety net. And one of the phrases I use quite often, and I think it was in the CI CD book is to go faster, you need better breaks.

And it is just a way to like, if I teach my kids how to ride a bicycle and I'm maybe in the beginning, not like, you know, keeping an eye on them, right? That's disaster going to happen. If I have somebody deploy, you know, from a new intern to the pipeline and I do not have a pipeline with tests, that's disaster, right? Now there is a difference, nuance to that is how much

risk are you willing to take, which is different for different parts of the industry, different parts of your infrastructure. So there is that as well. So even though in general, I don't advocate like having a safety net, I cannot tell you what level of safety net that is appropriate for your risk level that you're willing to take. ⁓ Maybe as a startup, you're willing to take more risks. Maybe not in an enterprise, but depending on your enterprise, if you're competing, you're back to more risks.

That's kind of hard thing, but it is fundamental that we have a way of recovering things and going back ⁓ as such. Now, you might think of this as backup, restore, and kind of those things. The other part is obviously fail fast on the business side. I mean that, like, OK, experimentation, the one is more like, ⁓ we building the product right?

but the business is are we building the right product? So that's kind of the difference. And they also have to do experimentation. so if you have, they have like five product IDs and you bring kind of the compliance hammer to them, they're never gonna get that feedback. So you kind of have to work a little bit with them to kind of see, hey, I understand this is learning. So I'm relaxing, but I'm giving you kind of the boundaries of that.

kind of safety net on how we do. And it's a lot what people are doing right now with AI. Hey, we know it's not fully compliant. We know that's not, but let's carve out like a small piece of our environment, given these constraints and that creates that safety net again. that's anyway, that's how I would approach it in my head ⁓ from kind of that perspective. And then the learning from people, that's the other thing is, I don't know how many people have told me, hey, DevOps changed my life. And that's because

they felt more empowered in a certain way. Obviously it's not a guarantee and they could still be managed top down and with requirements and kind of that way. But that was something I heard quite often in the way that that throwing of the wall was kind of hurting them ⁓ in that way. And that safety feeling of we're not like ultimately like all responsible and kind of the world will come down if we make a failure.

but kind of designed to make sure that happened. And that was more rewarding for me than saying, hey, we build a company and we sold it for a couple of million or something. Just somebody coming up to me and say, hey, you changed my career and I feel way better on how I work. that's, yeah, I know, it's the biggest compliment I could get in that perspective, yeah.

Nathan Toups (33:30)

That's so cool. That's so cool.

Carter Morgan (33:33)

I think. ⁓

I'm purposefully challenging you here because when we were emailing back and forth, you said, Hey, I like that you guys had some criticisms of the book. So I think when, when I think from like a developer perspective, I'm thinking back to when I had my very first job out of college and I was working at kind like a more enterprisey kind of company. And I remember when I had my first kind of experience with an on-call rotation and I had to like get up at 4 a.m. once a week to like do some system health check. I don't even know what I was doing. And now that I think about it, I'm like, why wasn't that automated? That's crazy. ⁓ but.

⁓ I remember talking to my manager about it he was like, I'm thinking of hiring like an overseas contracting team who like they'll be responsible for like all of our failures in the middle of the night. And as a developer then I was like, Hey, that sounds great. Like I can be on call, but I don't have to do any of that stuff. ⁓ and then you kind of get more mature in your career and especially you fall more into the DevOps world and you realize like there was a lot of problems with that kind of throw it over the wall method.

But from a developer lifestyle perspective, I see two big criticisms with DevOps, which is, one, you are introducing a lot more pain into my life because I no longer throw things over the wall and then have another team deal with it. And two, I am now required as an engineer to be much more than I used to be. You you go back 20, 30 years ago, you could make a career out of just writing like HTML and CSS. You'd be like a pure front-end dev.

These days, full stack is more the expectation and it's expected that you kind of understand how your code gets from your machine out, you know, to the internet and to recover failures and to do on call shifts. ⁓ So you're mentioning, hey, I've had a lot of people kind of come up to me and say, this made my life a lot easier. I feel like there's also the potential for someone to say like, ever since the DevOps philosophy has introduced, my job got a lot more complicated.

What's your response to someone who might have those sorts of feelings?

Patrick Debois (35:29)

I think you're right that was all SysAdmin who said that to me, not a dev. But ⁓ I'll use kind of the word ⁓ empathy. ⁓ So there's this also kind of know, narrative, like DevOps should not be a team, it's a culture, it's a mentality, and kind of the work together with kind of the dev teams. ⁓ I mean, the comparison is,

Carter Morgan (35:32)

Hahaha!

Patrick Debois (35:58)

Well, ⁓ at a certain way, there's the agile team, but there's still a product owner who kind of does this part of the job. it kind of, so, so it, is more important in my opinion, after my experience is that you have an empathy and an understanding what the other person is doing as a job. Right. So if you've never experienced an outage, you've never experienced like having to restore from backup. You've never experienced kind of like being there.

As you said, like I had no clue what to do and I am responsible. This is exactly how a lot of CSIS admins feel. They get paged, they have no clue what you changed in the day. They have maybe like 15 teams committing. Nobody actually gave them any information and then they have to solve it. So it's a very frustrating thing. I think.

Carter Morgan (36:33)

Ha ha.

Patrick Debois (36:54)

My argument would be, yes, it's a pain, but on the flip side, I hope as a developer, you actually care about your users and their running production, not during your laptop, right? So if they fail and they fail consistently, I hope you actually do something about it.

And that pain will be less if you just get a ticket every night, right? So it's a little bit of that build it, you run it.

Like it could also be like you build it, you ruin it, but that's another story. But it's more about ⁓ having empathy. Now, does that mean you have to do all the DevOps stuff? No. So the DevOps team or platform team or whatever, if they have like infrastructure, they can make it easier for you and make it self-servicing. Right? Maybe you're not writing infrastructure as code, but you're just filling in a few variables. There's like a templated pipeline and

That means maybe you're not dealing with like the underlying big infrastructure, which they will do, but you'll be able to deal with your errors happening in your app with your log file and able to trace that issue, right? But I think it's a little bit, ⁓ if you wouldn't have experienced that, and that's typically something as a senior you care more about because the bigger problems come back to you. ⁓

And it kind of makes you actually, I think, a better developer. So did I complicate life for you? Yes. But I think it's also, and maybe that's too cheesy from my point of view, is it was also a learning and maturing ⁓ experience from your side to kind of experience that. And yeah, is it fair ⁓ to be on call? Maybe it's not your first on call. And working with a third party, ⁓

I often kind of get that question, well, can we do it with outsourcing DevOps? Well, if you just collaborate in a good way, ⁓ but it might depend on how you structure your contract. If your contract is, you should always be up. Try to be flexible from their side, because they have their contract. But it's, in a way, ⁓ a third party service like Google or anything like a cloud vendor.

is also a third party service and they kind of, you rely on them. And I was often kind of puzzled in my head is how do, like, if all we've done with DevOps was replace everybody with an API and give it to a third party, but then I learned we're actually paying a support contract for people to talk to us. We are looking for post mortems. We are looking for somebody who writes good documentation and all that stuff. So.

That kind of stays and that's the difference between kind of somebody who cares and actually does their job right or is it the throw it over the wall mentality and we're like, how do you say that? Like ⁓ the floor is lava and I don't know what happened here, but something like that. ⁓ So empathy is kind of how I would position it to do a better job.

Carter Morgan (40:02)

Hahaha. ⁓

Yeah, mean, you know, full disclosure, like I'm very much on the DevOps train and I take a lot of pride in my career being the kind of person who can kind of do it all. Like I really like, work at a startup these days and I've done kind of some startup contracting work before. I had a buddy who his developers kind of bailed on him at the last minute. And I was really proud that I could kind of create his product from start to finish, you know, front end, back end, get it up in the cloud, monitor those sorts of things, but kind of.

attention I felt in my career is that I wish there were kind of one thing I could say, I'm excellent at this. Like I really admire people who are like, ⁓ I'm a Java whiz. I understand the language inside and out. Right. And I've never really had the chance to dive really, really deep into one of those things. Cause I feel like I just keep going broader and broader and broader to understand the kind of the delivery process from end to end. think that's a good place to be as an engineer. And I think more of the industry is drifting that way where

We're admiring maybe more breadth than depth in engineers. I mean, do you feel that way? Do you feel like maybe we're losing something in the industry by wanting to employ more total full stack engineers and maybe we're losing some of those people who had really deep expertise in one area? What's your take on all that?

Patrick Debois (41:28)

⁓ trying to figure out what the name was. So the generalist is the T-shaped for person, of bridges multiple things. And then the specialist, I forgot what the name was, but ⁓ I think...

Carter Morgan (41:34)

Yes.

Right, right.

Patrick Debois (41:44)

because of that overlap of, let's say, I know certain pieces and you know other pieces. ⁓ The pattern that has been happening in a team, for example, has been, hey, let's have one person who's kind of a champion on DevOps. And kind of they go a little bit deeper because they have a natural affinity to kind of like the stuff a little bit more than other people.

then you'll have the front end person who goes a little bit more deeper because it's more in their affinity. But again, by bridging and learning another piece of the stack, they feel more empowered and less dependent on others. Now, is there a case for specialists? Of course. But there might be ⁓ because of the abstraction layers. When the abstraction layer is for a framework or a cloud or something,

they go maybe wrong less, you'll need a specialized to go if it fails. So if it kind of unforeseen, they need to dig in deeper. ⁓ Now that might be somebody you hire from outside as well, or a consultant. So it depends on where you wanna lead that. ⁓ Do you have to become a specialist? ⁓ Certainly not, but it's almost like it's...

It's a different, how do you say that? ⁓ Request and demand dynamic. So you'll be more costing a web by saying, hey, I can do a lot of things. Okay, I'll get a job. If I'm very niche, I might have fewer jobs, but it might be better paid, right? Like you would be today, a COBOL engineer that still understands the mainframe, you're gonna make good money, right? but maybe,

the database specialist is still there because when you hit a problem, people are willing to pay a lot for that. So it's a choice you make kind of in your career, how you want to position yourself. But the downside of a specialist is also that

Even in that world, you're working within other people's kind of environment. So you still need to have some affinity when you come in, you understand the language kind of on certain pieces. And a risk might be is that you're deprecated when your technology is being deprecated on a certain level. So pros and cons, it's career choices ⁓ and how you want to position. Actually, you see the same thing with

with AI agents. Am I going to build a generic AI agent? Massive market, return per agent probably low. I want to make a very specific agent. OK, maybe I can sell it to 10 companies, but I can charge a lot. So kind of similar dynamic, in my opinion.

Nathan Toups (44:46)

OK, so imagine you could travel back in time to the planning period of the first DevOps days. ⁓ What would you tell yourself that would just blow your mind as far as how far things have come and how much things have changed?

Patrick Debois (45:04)

I think it still blows my mind to see that ⁓ the simplicity of people collaborating was an aha moment for an industry. ⁓ I remember telling my daughter when she was young and she would sit in school and they were sitting together, hey, we're kind of talking about the day at school. And it's like, hey, we're talking about the problems. And she said, dad, you're actually doing the same at work. Yes, and they pay me for that. So that's kind of an irony kind of learning. ⁓

I think the more aha that I had like very late, maybe I had when I had my own company, is that we probably restricted ⁓ the narrative of collaboration initially between Dev and Ops. And I think later I saw more of the system in a way that, you if your HR is not hiring the right people,

that might be your bottleneck or if your finance doesn't make money, that's actually your bottleneck. So kind of looking broader in a company as those kind of bottlenecks. ⁓ And that's also, I learned only later that ⁓ each of those jobs has a pipeline, they're doing triaging, they're doing validation. kind of that like ⁓ similarities in each job, they're hitting silos, whether in marketing,

and sales, don't like each other and they have like a way to overcome it. In accounting and audit thing, they don't like each other. So there's like, that would probably have blown my mind kind of initially when I would go back in time to, hey, this is actually not only a problem in DevOps, but it's actually a complete company problem of that collaboration and that silos thinking. And that would be my, if I could pass that along.

But I probably would have mainly ignored it because I wasn't ready to hear that message. But that would be probably a future learning that I would tell, but probably ignore it.

Nathan Toups (47:15)

No,

that's cool. ⁓ Also, just from a community standpoint, what bit of advice would you have given yourself when you were planning these first DevOps Days events? Would you give yourself a pep talk that you're doing the right thing, or do you think you would have taken a different strategy for any of this?

Carter Morgan (47:34)

It's worked out pretty well, Patrick. I'm not sure you need to have done anything differently.

Patrick Debois (47:41)

There's an itch about being stronger advocacy on definition and what it means. But on the other hand, I think I've taken peace with the fact that we didn't take a stance on a very strong descriptive thing, that it made it flourish. But it also diluted part of the messaging, maybe, hey, DevOps equals Docker containers or something like that, or Kubernetes.

So kind of that goes into both ways, but then I always comfort myself, hey, the same happened to ITIL, the same happened to Agile. Like whatever you do, it's probably, you know, it's not even up to you. Like the industry makes up their mind what it's going to be. And the vendors have it saying that ⁓ as well. I'm extremely proud on the community and the fact that we got people talking, that it was a diverse group. It was like a safe,

to kind of chat with people ⁓ and somehow that message got picked up and changed lives, right? So, I know, like I said before, that's not something I've done industry different. I think my kids would probably say you should have trademark DevOps, but that's a different story. I'm joking. They never said that, but you can see them think like, hey, you're famous and like, yeah, we're still eating like sandwiches.

Nathan Toups (49:02)

That's funny.

Patrick Debois (49:10)

just joking, but anyway, it's probably who I am in a way that it's not that that I was after it wasn't like, like big fame or something like, but the learning and the opening of kind of seeing and talking to big companies, which otherwise from the tiny Belgium, I would never have had the opportunities that it's kind of a big reward for me that that whole story.

Carter Morgan (49:35)

Okay, I'm gonna make some assumptions here, so correct me if I'm wrong. This is just my understanding, kind of the DevOps evolution. ⁓ It seems like one of the big things that pushes DevOps into the mainstream and maybe makes it more reality is evolution in technology, specifically cloud containerization, and I'm gonna throw in open source observability frameworks like open telemetry. Are those kind of three big things that make the DevOps?

culture and way of working a reality.

Patrick Debois (50:09)

Hmm. Well, if I look at historically, there was no talk about observability. So it was mainly in the friction point on Dev and Ops. was it kind of came in with the third way of kind of giving feedback from production. that was kind of came later. ⁓ I think the containers were not even there. It was cloud only when it started ⁓ very early on ⁓ as a thing.

Carter Morgan (50:16)

Okay.

Okay.

Patrick Debois (50:38)

Containers only kind of changed the game of spinning up VMs and doing testing faster. It was still kind of machines at first. And what was the third one? kind of forgot. telemetry. Well, that came way, way later. There was kind of like, there were kind of some kind of tiny sub movements. There was kind of the monitoring socks movement, right?

Carter Morgan (50:51)

I think telemetry. we talk about cloud containerization telemetry. Yeah. Okay. Okay.

Patrick Debois (51:07)

That mainly had to do it because IT environments on hardware were relatively static and small in numbers. It kind of went like VMs that kind of changed to, hey, today I have like two servers and tomorrow I have like 50 servers. So those tools were not built for those kind of dynamic changes. So that was definitely one of the pieces that people were looking at. And then the same thing happened to, well, logging was really bad because it

it couldn't get all the logs on all those dynamic machines. So that was kind of a movement ⁓ building up at the same time than with CI-CD, which kind of was the testing, but the testing stopped that like at the test environment, which needed to go to production. So that was the other. And I think another movement very related to that time was probably Lean coming in, Lean in the software that kind of also made like an impact. ⁓

Carter Morgan (52:03)

Right, right.

Patrick Debois (52:06)

kind of around that same sweet spot. ⁓ But yeah, now that's all different, right? Now it is indeed about telemetry and kind of observability and a platform. So the narrative kind of has changed, but that's maybe like the point I want to make. Like when you read that book, you will still see about that tension about the dev and the ops kind of like working. Where now it's maybe a platform team scaling out to several different smaller dev teams. We kind of changed the dynamic.

Carter Morgan (52:14)

Right.

Right.

Patrick Debois (52:37)

in an organization, ⁓ I think. ⁓ Same thing, a platform team has to find the feedback, they have to talk, they have customers, ⁓ it's self-serving. So they're doing a very similar job. If they're not limiting themselves to, hey, I'm a DevOps engineer and I run the Kubernetes, but I don't care what's running on top of that. That for me is the wrong mentality, is like, I care who my end users were, are, and what I can do to help them, what...

I need to scale them. And that's a difference in mentality as such.

Carter Morgan (53:12)

So was cloud computing necessary to get to DevOps? Or is there a reality where DevOps, the movement starts in 1995? Or do you have to kind of have that independently scalable infrastructure where a smaller group of engineers can actually manage that as opposed to provisioning actual physical servers?

Patrick Debois (53:32)

Yeah. I think it's maybe the other way around. Cloud caused the problems to be more visible. Like I, I, now I have to manage a thousand systems. Now my whole system is kind of like broke because it's not up to that or it's dynamic and I have to deal with that. So yes, theoretically we could have done more agile.

Carter Morgan (53:43)

interesting.

Patrick Debois (53:59)

system administration even without a cloud. And we've kind of done that with VMs and VMware and locally and all that stuff. We could have done that. that's also the very weird thing. Nothing was actually stopping us from talking to developers. It just was in our minds. ⁓ But the cloud amplified the problem space. ⁓ if you look at this right now, the same thing with AI.

Carter Morgan (54:15)

Yeah.

Patrick Debois (54:27)

AI is causing an overload of code reviews and testing and something that it's pushing us to kind of like, hey, something needs to change. You cannot use the same kind of solution or procedures to deal with that part. Now, how that would be going, I don't know. But it is causing pressure somewhere in the way we work. And that's kind of like, I don't know.

That's the interesting, it's always kind of like something changing technology wise and then we'll have to adapt like cultural or procedural process wise.

Nathan Toups (55:05)

I do find it entertaining that leadership seems to be having a renewed interest and focus on structure and documentation now that AI tools need these as well. And these were always critical for good software engineering.

Patrick Debois (55:18)

Yeah, I have the same experience. ⁓ I had it a few times now where I explained, hey, they asked me, how can I make my AI coding agents better? It's like, OK, you begin by writing your tests. If you have confusing documentation, it's going to confuse the agent. If you do all those kind of stuff, you do small pieces like ⁓ that, it's better for the agent. And they start doing this. And it's like, why weren't you doing this before? Well.

Carter Morgan (55:46)

Hahaha.

Patrick Debois (55:48)

Well, now we've got a budget, which is not so fair. ⁓ But yeah, there's a certain irony. And the other irony that I tell in my stories is, so we talked about AI producing more code. ⁓ imagine the AI agents would produce code all day, and you're just reviewing. It's basically what DevOps was so many years ago. It's like the agent throws the code over the wall.

Carter Morgan (55:50)

Yeah.

you

Patrick Debois (56:16)

We are responsible for running it. We don't know anymore how it was produced. And so what do we do in case of failure? We can't even call the AI anymore. So it is a very conflicting and paradox ⁓ thing happening in that space.

Carter Morgan (56:18)

you

One of my favorite quotes we've had on the podcast is we interviewed Michael Feathers who wrote Working Effectively with Legacy Code and we were talking about AI and I said, one day someone's gonna write Working Effectively with AI Generated Code. He's like, I don't think it'll be very different. So we can't thank you enough, Michael, sorry Michael, geez Louise. Patrick, I got my thoughts all confused.

Patrick Debois (56:57)

I also thank Michael.

That's great.

Carter Morgan (56:59)

we should thank Michael. We'll give him a call after this. ⁓

We can't thank you enough, for joining us here on Book Overflow. ⁓ Do you have any books you'd recommend to our listeners? mean, fiction, nonfiction, technical, non-technical, anything that has really inspired you in your life or career?

Patrick Debois (57:15)

Now I have to pick one. I'm a big book reader, but. ⁓ So the first one would be more on. Collaboration. So there's two books on that. I would recommend Agile Conversations, which is a great book ⁓ and software for your head, which kind of like core protocols. So those two. And then ⁓ I think these.

Carter Morgan (57:17)

⁓ You can recommend multiple.

Patrick Debois (57:44)

Second order would be a book around promise theory, which is probably harder to read for most of the audience, but more fundamental as a way of working. ⁓ And I don't know for the people who don't know it, but ⁓ it's written by Mark Burgess, who also wrote one of the first configuration management systems. And think of this as like.

And you could read agents into this. Like every time there's something new, you could probably reread the book and kind of, yeah, you already got it, like from his principles, but we're just doing this now. And I really enjoy kind of that deeper structural things. ⁓ Some would say like from first principles, but I think it's a different kind of book, but yeah, I enjoy that.

Carter Morgan (58:35)

Well, that is, ⁓ that's great. And we'll, we will add them to the backlog. And we, were once worried when we started this podcast, like, we ever like run out of good books to read. We don't have that worry anymore. We just keep hearing about more and more good ones. ⁓

Patrick Debois (58:45)

Yeah. My wife told me no more books,

just buy them on Kindle. know, 10 years ago she said that because our bookcase was just so full of books. yeah.

Carter Morgan (58:54)

Hahaha!

Well, we appreciate it so much, Patrick. Is there anything you want to plug for our audience? Anything you want to draw their attention to or are you good?

Patrick Debois (59:08)

I,

if, you know, if people are interested in the AI and the dev space and the dev space, we are running an event in 18 and 19 of November conference in New York. So I'm the content curator of that event and also of that community. ⁓ so that would be my plug and I'll see you there. And I hope to hear your stories similar to the DevOps days and see what we totally get wrong, ⁓ in this new kind of era, which is great.

Carter Morgan (59:20)

Very nice.

Well,

if you give us that link, we will make sure to include it here in the episode description so our listeners can register for that. And you can always find us listeners ⁓ at bookoverflow.io. Our email is contact at bookoverflow.io. We're on Twitter at Book Overflow Pod. I'm on Twitter at Carter Morgan and Nathan's newsletter, Functionally Imperative or at functionallyimperative.com. Patrick, we really can't thank you enough. Such a pleasure to talk to you and ⁓ we're grateful for all your contributions to the industry. We know that it's changed our careers and I'm sure it's changed

careers of many of our listeners too.

Patrick Debois (1:00:08)

My pleasure. And I look

forward to having book overflow.ai soon.

Carter Morgan (1:00:14)

⁓

We will yeah one day this whole podcast will just be generated by AI agents. It's gonna be fantastic All right, we'll see you around folks. Thanks again Patrick

Nathan Toups (1:00:21)

gosh, please no.

Patrick Debois (1:00:22)

Please not. Please not.