DevOps Isn’t a Department with Jeremy Duvall

Jeremy: [00:00:00] Favor process over tools doesn’t say thou shalt useth Jenkins on the 5th Sunday of every, you know, December or something of that nature. It just simply says focus on your people and stop worrying about the stupid shit you use to get things done.

Matty: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matty Stratton. We are going to dig into a topic that everybody loves to talk about with DevOps. Where does DevOps belong? Is it a team? Is it a technology? All of that fun stuff, as the great Andrew Clay Shafer would like to say, who would like to argue about the definition of made-up words with me. I would like to argue about the definition of made-up words with my guest, and I will introduce our guest in just a minute. But first, a word from our sponsors. Let’s face it, no one likes writing or maintaining documentation. But when you start a technical project or pick up a new task, missing information can cost you valuable time. GitBook is a technical knowledge platform that fills that information gap, making it easy for your team to capture, maintain, and find information from a single source of truth. For example, with Git Sync, you can set up a 2-way sync between your repository and GitBook so you can turn Markdown files into awesome user-friendly docs. And if you make a change in your codebase, the edits sync between the two automatically.

[00:01:31] Or what about when you need to find something in that knowledge base? Forget about searching. Just ask GitBook AI. You’ll get a neat summarized answer that is sourced directly from your docs. These are a few examples of what GitBook can do, so why not give it a try? Head to arresteddevops.com/gitbook to find out more. Thanks to our sponsor, Gliffy. The leading diagramming solution for teams using Atlassian products like Jira and Confluence. Drag and drop shapes to quickly build a diagram, capturing anything from code structure to a simple concept. You can start your free evaluation by visiting gliffy.com/arresteddevops and signing up via the Atlassian Marketplace. That’s gliffy.com/arresteddevops. DevOps. Get started today. So Uffizzi is a platform for platform teams. You can stand up your developer platform in minutes, not months. What I like about Uffizzi is that it gives platform teams control and dev teams autonomy. It’s Kubernetes native and extensible, so you can customize it with tooling that meets your team’s evolving requirements. And these clusters, they spin up fast.

[00:02:46] Like super fast. Out of the box, Uffizi combines a great dev experience, secure multi-tenancy, and cost efficiency. But try it out for yourself at uffizzi.com. Download their CLI and you can spin up your first sandbox cluster in under a minute on their free starter tier. That’s uffizzi.com, U-F-F-I-Z-Z-I dot com. Joining me today to argue about the definition of made-up words is Jeremy Duvall. Jeremy, thanks for joining me and Why don’t you introduce yourself to the Arrested DevOps audience?

Jeremy: Sure, thanks, Matt. Super excited to be here. Probably don’t deserve to be on your podcast, so I appreciate it. I’m Jeremy. I’m the founder of Seven Factor Software. We’re a software engineering consulting business based in Atlanta, and I’ve been doing DevOps for a very long time.

Matty: I mean, if it helps, I certainly don’t deserve to be on my own show, so it’s fine. But there’s a little bit of a funny thing about when we first started doing the show. And there is a little bit of a like, well, they wouldn’t just give anyone a podcast. And you’re like, turns out they would, but totally fine. Yeah. When we started to talk about an idea for something to talk about and the topic was DevOps isn’t a department. I kind of like that. Well, I like it a lot, but I mean, I kind of like the turn of phrase. Let’s put it that way.

Jeremy: [00:04:05] Yeah.

Matty: And we’re sitting here 10+ years since 2009, which is the great inflection point that the birth of DevOps, if you would, the opposite of the birth of cool, let’s be honest, right? And we’ve been having these conversations a lot, right? Like, it’s not a tool or a team or a technology. Do we just give up on this? Maybe this is what the platform engineering movement is, is we just give up on the word and make a new word that means the same thing. But when we think about this, how much of this is being pedantic and how much of this is actually rooted in— it’s not just that you’re doing it wrong, but you’re doing it ineffectively. Like, kind of what got us where we are, maybe?

Jeremy: Yeah, I think you go back to that 2009 inflection point, right? One of my first introductions to DevOps was DevOps Days here in Atlanta, and John Willis was speaking. And I remember just sort of taking it all in and saying, okay, this is the next goddamn buzzword we have to deal with in our industry, right? Because we had just survived big data, so now we have this next one that we’ve got to kind of slog through. But I was really attracted to the concepts that John was talking about. John was actually discussing burnout. And he told a story about a very talented engineer that he knew, unfortunately took his own life because of how much pressure was on this individual to deliver. And that sort of brought it home to me that DevOps wasn’t just about playing with Jenkins, right? Because we’ve all played with Jenkins for years. I cut my teeth at a company called Danger. We built the T-Mobile Sidekick, and then I went to work for Steve Ballmer’s version of Microsoft. Again, not the version you want to work for. Sorry, Steve, if you’re listening, but it was a complete shit show. And then ended up learning a lot about how to deploy software after going to college through those industry jobs. And nobody sat around and said, you know, we need an entire department to deploy our Jenkins servers. It was like 2 guys in the basement of, you know, on the air quote tools team that would build all of the machinery that we would then turn around and use to deliver, uh, the software that we were putting into production every day. And so I think what, what the DevOps movement brought to infrastructure and generally to engineering culture in general, in my opinion, that’s super valuable is a refocusing on the ideas that developers are humans, which again, I don’t necessarily couple that directly to the DevOps movement, but I think the DevOps movement used that as a vehicle to sort of get this information back out. And then as with most buzzwords like digital transformation and big data and all the things that we hate, once the dust settled, it all turned into these giant corporations just took these ideas and they threw them in a department and they did a bunch of like pay scales around it. And they said, now you’re a DevOps engineer. And they took their infrastructure teams and just pivoted them over to a different title, but they’re doing the same things. And you mentioned platform engineering. I’m sure we’ll get to it more on the show, but platform engineering to me is the next logical evolution of what DevOps should really be and really should have been taken in the first place. But I think we’ve kind of gotten away from the original ideas that were ingrained in the movement in the first place.

Matty: [00:07:05] One of the things when we go back and we had an episode not too long ago with Adam Jacob about, you know, again, We’ve been doing a lot of, we’re doing a lot of looking back this year at Arrested DevOps. Fun fact, again, this is the 10th year of Arrested DevOps. We’ll be recording the 10th anniversary show in a month. So, so I guess we’re all, all getting a little, a little nostalgic, but when we look back and say, you know, what were some of the contributing factors? I mean, the one thing that we talked about, and I think this is true, is that while, and I’m going to use the word we generally, we as an industry, while we maybe did eff it up. It’s still a hell of a lot better than it was. So let’s, let’s at least know that. But one of the things that I think was really common, or, you know, a kind of a running theme in the early days of the DevOps movement was to not be prescriptive. There were, there’s a lot of talk early on about, well, why isn’t there a DevOps manifesto? Like there was the Agile Manifesto. And I think Michael Ducey even would talk about this and say, because that’s not what this is, right? The practitioners were very against this, like, telling you how to do it. It’s about thinking about what’s the general idea, what’s the general idea. And the thing is, people have to do work, right? And you can only go to so many DevOps Days and think big thoughts, and then you still have to go and sit down. And so, if no one’s going to tell you how to do it, when someone else comes along and tells you how to do it, that’s a way to do it. So, I think we ran into, we started to see this too, where it did become prescriptive in terms of tools. And tools are, someone’s got to make money, you got to sell a thing. Let’s go all the way back. You know, you mentioned John Willis, and I put a link in the show notes. I have a link to his talk from DevOps Days Atlanta in 2016 on burnout. He’s given that talk other places. Yep. And, you know, I’m sure many of our listeners are familiar with this, but we’ll bring it up in case you haven’t, because we always have different types of folks coming in this. But very early on in 2010, in the first US-based DevOps Days in Mountain View, John Willis and Damon Edwards came up with this acronym called CAMS that was Culture, Automation, Measurement, and Sharing. And that was what DevOps was. Then a year or two later, Humble came along and said, let’s also throw lean in the mix. So then you had CALMS and/or CLAMS or SMALC, depending upon how you want to spell the acronym. And so when you look at those things, with the exception of automation and I guess measurement a little bit, but a lot of it is all, it depends, it’s an idea. And so it’s hard to early on when these things were happening, when you said, okay, well, I need to sell something, I got to make a buck. As a tool or as a product or something. The automation is what’s the natural gravity. And I think that’s what brings us to this, well, then DevOps is automation. DevOps is Jenkins. DevOps is Puppet, right? And I think this is something that has evolved and gotten better in terms of the how, right? Because we were talking in these early days, and these early days were 4 or 5 years, you know, up until 2015, 2016 about this, you know, it was a lot of it depends, right? It was a lot of, well, we can’t tell you the right way because, you know, and, and then those gaps get filled. And so one of the questions that I would have, again, we talk about, okay, how can we do better, right? Like, okay, and if platform engineering is a natural evolution, how are we gonna not go down this path again? Like, did we overcorrect ourselves by trying to be to go your own way, you know, with these things, you know, discover your own DevOps bliss, right?

Jeremy: [00:10:40] I honestly think it’s similar to Agile, right? Agile follows the same curve where it starts out as Kent Beck and a bunch of stupid smart people get in a room and say, building software sucks. So how do we make it better? Right? So they create the Agile Manifesto and the Agile Manifesto has given birth to such abominations as SAFe. I’m sorry if you’re listening and you like SAFe, I think it’s garbage. And it’s also produced really good frameworks and added to the concept of Kanban and Lean and Six Sigma and things that I’m a huge fan of, right? I love Kanban. It’s one of my favorite ways to work. And I think Kanban lends itself very well to DevOps as well and sort of infrastructure teams, but that’s a different show, right? But I think that you have to provide some baseline guidelines. And I love what you said. And I actually didn’t know that story that folks sat around and said, you know what, we’re not going to be prescriptive. We’re just going to, you know, provide some very general high-level bullet points. But honestly, they did the same thing that the Agile Manifesto did, because if you read those bullet points, none of them are specifically prescriptive, right? Favor process over tools doesn’t say thou shalt useth Jenkins on the 5th Sunday of every, you know, December or something of that nature. It just simply says focus on your people and stop worrying about the stupid shit you use to get things done.

Matty: [00:11:54] Well, and focus on process over tools does not mean, does not say do daily standups. It does not say do Scrum, but that’s what we did. That’s because in a lot of that, it’s very hard to like take a bunch of like big ideas and then say, now you figure out how to do it, right? Because unless you’re, you know, it’s like the wizard, right? Saying, back where I live in Kansas, there were men who did nothing all day but sit around and think big thoughts. You know what you called them? Thought leader, right? You know, exactly. DevOps podcasters, you know.

Jeremy: Exactly. And I think, you That is critical to seeing how these types of movements sort of pivot into the next phase. For now, we haven’t seen that pivot in Agile yet, and I am just really hoping one day we do. A lot of that was the business community got their claws into Agile. They also got their claws into DevOps too. Again, I’m not hating on the business community. Product owners, product managers, CEOs, they exist to provide products and services that make our lives all better, and they focus on doing it the best they can. But the traditional business thought process, getting their hands around software engineering and producing Scrum and the obsession with velocity metrics and all this other stuff, and that trickling into DevOps, I think is what produced this DevOps as a department ideology where I need somebody to metric, right? If shit doesn’t hit production, somebody’s got to get fired. So I got to know who to fire. And so it kind of produces this instead of a natural organic sociotechnical system, You’re producing, you know, again, walled gardens that have specific responsibilities because I think that’s just what a lot of business leaders know. And again, there’s nothing— I’m not attacking it. It just is what it is. But that produces bad organizations and it produces walled gardens. It produces bureaucracy, right? It doesn’t produce generative culture. It’s, it’s on the other side of the spectrum towards pathological if taken too poorly.

Matty: [00:13:48] So there’s, there’s a lot of thought you talked about. You need something to metric, right? And measurement is a key part of, of the work that we do and we have to be able to to, to, to measure things because that’s part of the culture of continuous improvement. We look at, we look at things like lean. All of these things are around measurement, right? Measurement. Now, that being said, measurement does not equal Taylorism, right? You know, necessarily. And it’s, it’s interesting. I, I kind of almost feel like if we look at the different ends of the spectrum of, you know, productivity measurement is— people are all about it, right? Because especially money ain’t cheap. All these damn engineers cost way too much money. The rent is too high, all this stuff. And I, I feel like, I don’t know, in your opinion, we, we kind of can see this being done well and being done like almost pathologically, right? You know, which, which I guess is a little bit Westrum to talk about generative versus pathological. It’s almost the measurement frameworks because we look on one side and People who are listeners of the show are probably none too surprised that we would say the work that’s being done at GitHub by Dr. Forsgren is not surprising us. That when Nicole put her eyes on measuring productivity, she— developer productivity and effectiveness is doing it very, very well. And then we have, you know, McKinsey, you know, let’s say, right? And yeah, and it’s kind of like Maybe we’re going to go a little philosophical here, but like, you know, I’ve always said, one of the things I’ve always said is when people say, what’s the most important DevOps book to read? I will say Freakonomics. Go learn about incentives and then you will understand DevOps. And this, yes, by the way, asterisk all over the place. Yes, I know, hashtag parts are problematic, blah, blah, blah. But the idea is still, point being incentives. So then we kind of look at that. So when we look at measurement frameworks, productivity frameworks, ways of implementing these things, we go back and look at those incentives. So like, where— what’s the misaligned incentive that causes this pathological, if you will, implementation of productivity measurement that’s kind of screwing us all up?

Jeremy: [00:16:02] I think the incentive is— can be traced back to the fact that what we do as engineers is difficult to measure in the first place. Right? So they’ve tried features. We’ve tried to measure, okay, the number of features that go out to production, but then, you know, the CEO doesn’t really care about that because that doesn’t map back to dollars. You know, heaven forbid you work in a Scrum framework where they say, okay, put your hours in because we have to, you know, measure your hours versus your velocity points and divide the two, and that’s, you know, how much work we can get done in any target, you know, any target framework. So I think that measurements are never going to go away, right? A measurement ceases to be a good measurement when it becomes a target. That’s the whole centerpiece of the challenge here. If we’re using measurements to make our organizations better via continuous delivery, that is one thing, right? And you look at Abhinav and the DX people, like Abhinav was on my YouTube thing, he’s amazing. Like, he’s a great guy and he focuses on, you know, talking to all of these various organizations about how they focus on developer productivity, which is a new thing that’s kind of coming up. And he and some others are championing this concept of developer productivity is more important than measurement, right? Because we’re focusing on things like happiness. And I know that’s a bit of a squishy— people are like, bullshit, who cares about your happiness, right? But I do. You know, when my teams work with clients, I want them to be happy because they’re going to give my clients much better work than if they’re pissed off and like, you know, stewing over how a client, you know, made them angry. But I think that there’s nothing wrong with measuring what we’re doing, but when it becomes targets, that to me is where we’re skewing into that pathological territory of holding people accountable to things that may or may not fall apart when a black swan comes along, right? Antifragile, right? So great book. I like a lot of what it says. Some parts are weird because he has a grudge, but anyway, in general, it’s a really good framework to think in terms of how do we build teams that don’t fall apart when something happens, like someone leaves, or, you know, someone has to take an emergency PTO because they broke their arm. Our engineering systems and our DevOps systems are so brittle that we’re not thinking in terms of how they can be more robust, and how we can ensure that we avoid those, you know, black swan problems coming along and completely destroying everything that we’re doing. And so you feed that into, at the high level, this productivity metric idea, right? If our productivity metrics are never designed to handle entropy, then they will never be able to handle entropy, which is very common in our industry and it happens all the time. So we have to be able to develop something that allows us to handle those types of cases. And I think, you know, some companies do this really well. You hear about like Google and Amazon and Facebook and like they don’t use Scrum and they just kind of put things out there, break stuff, move fast. And to my knowledge and from the research I’ve done, they do a really good job. Building software internally. I have a lot of friends that work at Google and they’re mostly happy. They enjoy the systems that they operate in. They’re empowered to go and deploy software to production whenever they need to. They’re empowered to go and build their own platforms and interface with people to get problems solved for the business. And that’s a really cool way of working. But then you pivot to my clients, which are usually in retail or something of that nature, and they desperately want to get better, but they’re so stuck in the ways of the 1990s CEO mindset that it’s impossible for them to break free and allow their teams to run and solve problems. Some, like Nordstrom, have actually demonstrated an amazing— that you can be amazing like this. There’s a whole turnaround story about Nordstrom. I think that was written by one of the DevOps books. I think maybe it was Jez Humble or somebody that wrote about it, but they did a fantastic job of pivoting the entire retail mindset over to a software mindset, and they’re doing fantastic right now.

Matty: [00:19:47] Yeah, at Nordstrom back in the olden days, Courtney Kistler, who is now the CTO at Zulily, really helped lead that transformation at Nordstrom. She did amazing things at Nike. And again, I was just looking and see that Courtney has written a whole bunch of stuff around platform engineering. There’s kind of a pretty cool talk that she gave about building internal platforms for the enterprise. And I’ll put a link to that also in the show notes. I’m thinking too, we talk about, again, getting kind of caught into the models that got us where we were and people can think bigger when things are not stressful, and then when the rubber starts to hit the road is when we start to look at that. And I still wonder how much still this ends up in that like frozen middle, right, organizationally. Because I think your CIO, your CEO, your C-suites, like they do want to look at it in this generative way. Often, I mean, that’s their intent, right? Yeah. And I mean, I think about even in early days of DevOps transformation I’m going to get the numbers wrong and it’s fine because this was from ages ago, but I cannot remember if it was either at a ChefConf that Barry Christ, the CEO of Chef, was saying this, or if it was an internal Chef event. But it was some number to the fact of that, like, at that time, you know, 80% of CIOs said that, you know, a DevOps transformation was critical to their business. And then, but all of these, but then only 15% of enterprises had a plan. And when you are in that C-suite, your, your job is to be big and strategic, and, you know, your reach should exceed your grasp and all of that. And you’re also probably a little less threatened by transformation, right? Because, yeah, you know, first of all, we can have an argument about the higher you up in the org chart, the safer you are from a reorg, you know. But a lot of times when we talk about a fundamental organizational shift, you know, if you’re leading a team and the job of your team is to execute measuring this productivity in this certain way, and then this radical change comes along, you’re going to inherently fight it. This is why we have SAFe. SAFe is how to have Agile but let project managers still have a job.

Jeremy: [00:22:01] Exactly.

Matty: Right? That’s exactly where that happened. And we saw this when I was at PagerDuty, and we’d go talk to organizations, and we’d talk about the idea of having incident command and good new ways of doing incident response. And there were whole teams inside these banks and large organizations I was working with who their job was to be an incident manager. Yeah. And so they actually— for— they weren’t bad people. I would probably have done the same damn thing. You’re like, wait a minute, hey, this asshole’s coming in to basically say that my job shouldn’t exist, I don’t provide any value, that it should be distributed, you know. So there’s some axiom about, you know, making an argument with someone if you know, agreeing with you means they lose their job or something. I don’t know, that’s something to that effect. So great, so we talked about all the problems. All right, but like, where are you seeing these successes? Because clearly some things are getting better. We’ve said, right, we’re in a better place than we were 10, 15 years ago. And you see a lot of organizations, you talk to lots of companies. So when they’re getting it right, what are the, the indicators? Like, what are the things? Because it’s not a whole bunch of failure. There is a bunch of failure, Or failure according to our definition at least, but some people are doing it right and not necessarily the big behemoths, the Googles and the FANGs and all this stuff. So these enterprises that you work with where they are making these transitions, like what are the hallmarks of that?

Jeremy: [00:23:21] Yeah, I think there are— we’re at the point now to where most, if not all, of the Fortune 500s have figured out that DevOps is a thing. And we have to embrace these ideas because you have a lot of very talented technical leadership right up and down the chain there. And so usually what I see on a team that, that is incredibly successful is that free and open trust to make decisions and to build, pave the golden road to production, so to speak, where we’re focusing on pushing a lot of the ideas that are around deploying software quickly into our software engineering teams. And that can either be through that aspect where, you know, you have a platforms team or DevOps team, whatever you want to call it, I don’t care what you name it, that are sitting there and developing the frameworks and the ideas and the general vehicle by which your, your code gets into production. And then you have the software engineering teams, which are cross-skilled a little bit on things like Terraform or whatever technology stack that you so choose. They understand them. And they know how to get their app into production quickly with little to no interference from the DevOps teams. The DevOps teams and the platform engineering teams, and again, this push to platform engineering, I really do like the rebranding. I don’t want to take anything away from DevOps because it’s such a fantastic, just a transformational force for our industry. It’s amazing. It’s done really, really good things for us as a craft, as a software craft. But that shift towards more thinking in terms of we’re here to develop platforms, especially with the big cloud, services kind of pulling into— pulling up shop, right? Because a lot of what we do as engineers is not what we did when I was at Danger, right? At Danger, I had a little dev board and I had my little JTAGs and I would write my firmware and I would flash my firmware to my modem and, and see if it worked. And no shit, it broke and I got a malloc error and I got to redo all this stuff and just blah blah blah. Or I had this giant Perl service on my laptop that I would run locally and make sure it works, and then you check it in and It gets go-throughs Perforce. If anybody remembers Perforce, I don’t know if they still exist or not.

Matty: [00:25:26] J. Paul Reed, longtime friend of the show and DevOps community person, loves him some Perforce. And Perforce, and you know, you could get Paul to like rant for hours about how Git screwed everything up and we should all be using Perforce and everybody’s life would be better.

Jeremy: I don’t think I agree with that.

Matty: I don’t know about that, but you know, that being said, yes, how else can we not screw up DevOps? Jeremy?

Jeremy: I don’t know. How else can we not screw up DevOps, dude? You’re asking the wrong guy. No, I think we don’t screw up DevOps by, again, just, you know, commoditizing it. Like, everything that’s wrong with software engineering today is commoditization and value engineering. And I’m not hating on offshore or nearshore. I’m not saying that those people don’t deserve jobs. What I’m saying is that the thought process— thanks, McKinsey— that all I do is sit around and write code and I don’t add any other value, I know they’re not really saying that, but I’m going to hate on them anyway. It is just preposterous, right? And so again, back to the idea of the platform team paving the road to production, cross-skilling your engineers. When I build teams, both for myself, for clients, whatever, wherever I’m at, I always focus on trying to build Venn diagrams across my engineers. I don’t want specialists in 2023. Gone are the days of the 20-year C# developer, like being the guy that you call. Because we have so many languages. My master’s degree was in programming language design, so I don’t care. It all turns into bits on the VM anyway, so who cares what language I’m using? But deciding how we decommoditize the idea of DevOps, and it’s not just, you know, people that you call on the support desk to get a new server, that’s the thing that we have to avoid. And again, the big cloud services, as I was saying previously, they’ve changed a lot of how software engineering is done in 2020. I don’t call up somebody and say, when is my Tomcat server gonna be ready, like I did 5 or 6 years ago, and then wait 2 weeks and hope I get it on time to get my software out the door. Now I just log in, write some Terraform, write some whatever— Chef, Puppet, pick your favorite flavor of tooling— and I have servers in Amazon with a load balancer, with a VPC. I have backend stuff. I can control my firewall. These are things that, you know, when I was developing code before all this happened, I would have to make phone calls to other humans to do this type of work. The cloud has really unleashed us, and it’s also very expensive, which is another show, but it’s unleashed a lot of the— what I like to call the cross-skilling of my engineers, where they have to learn what a load balancer is. Like, I’ll hire a developer like out of nowhere, and, and I’ll teach them what a load balancer is. It’s like their mind is just exploding because they’re like, wait, there’s a thing called a load balancer? I don’t just run it on my local laptop? I’m like, No, you deploy the thing into a cluster and so on and so forth. So I think just again avoiding commoditization and focusing on cross-skilling our engineers is what’s important because the platforms team are software engineers, right? They’re not infrastructure people anymore.

Matty: [00:28:26] You heard it here first. Here’s how to not fuck up DevOps. I feel like we had an episode of Arrested DevOps in the past with a very similar title to that. Oh, It’s not, it was not called How Not to F Up DevOps, but there was back in 2014, an episode of Arrested DevOps featuring Pete Cheslock, Nathan Harvey, and Randy Harper called How to F Up DevOps. I will put a link in the show notes to that. But that being said, we have run ourselves towards the end of the show. Speaking of show notes, if you go to arresteddevops.com/devops-is-not-a-department, That will take you to this episode’s show notes where we— any supporting links and information. If you go to arresteddevops.com/itunes, you can leave us a review in the Apple Podcast Store. By the way, hey, if you’re listening to this show, raise your hand if you’re tired of hearing me make references to the fact that that link is still called /itunes when it probably hasn’t been called iTunes in a good 5 years now. I say this every time. You all are real sick of it and say, Matty, you got to get a new joke. So please, Write me a new joke and I would tell you to tweet it to me, but that won’t work either. So I guess you guys are all stuck with the /iTunes joke. Thanks, Elon. But you can also find us on Spotify, iHeartRadio, Audible, all of those places where fine podcasts are sold or given away for free. Jeremy, this has been awesome. Any places, anything you want to recommend, places that people might want to check out to learn more? What’s the Library of Congress recommend? To get more thoughts from Jeremy Duvall.

Jeremy: [00:30:01] Yeah, this is great. Thanks for having me on. You can check me out on LinkedIn. Just look me up. Jeremy Duvall’s my name. Or you can check out the company sevenfactor.io. But yeah, I like to whine about the state of our industry. So I appreciate you giving me a chance to do so.

Matty: This is fair. This is fair. And this has been Arrested DevOps. And remember, there is always DevOps in the banana stand.