August Book Club With Mark Peters: Confident DevOps

Transcript

Mandi Walls: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me at LNXCHK on Twitter.

Mandi Walls: Alright, welcome back folks. This is our August book club episode. I hope you enjoyed our little bit of summer reading for the last few episodes. It’s August, it’s back to schools time, so we’re back with learning stuff. So it’s time to learn some things from Dr. Mark Peters, who is the author of Confident DevOps and he actually is joining me this month, so we have another author back on the pod. We’re very happy to see that. Mark, welcome to the show. Tell us a bit about yourself and maybe your interest in DevOps.

Mark Peters: Thank you. So I really like DevOps. I really enjoy DevOps. As my background. I did 22 years in the Air Force as an intel guy and got out and moved into the cybersecurity field because I’ve been working with security and security requirements for so long that it was just kind of a natural fit and in that first kind of cybersecurity I got introduced to DevOps, and I really liked DevOps. I saw it as the same type of things I was doing as an intel officer. When we talked about the flow feedback and continuous improvement as an intel guy, you handed an intel report to somebody who went out and did something with it and then they came back and they said, Hey, here’s what I got from your intel report and here’s where it needs to be changed. And we did the improvement and then the next time they went out we handed into another intel report.

Mark Peters: So that was kind of a natural fit and a natural flow for me. Over the past six years I’ve been working with a bunch of different department of defense contracting agencies and companies that do those types of things. So I’ve had a good chance to see DevOps in action and get a chance to meet a lot of the people that are kind of involved. So I love it. I describe myself as a DevOps junkie because I need to get my daily DevOps fix and that’s kind of the essential part and I think that’s a beneficial thing. I don’t think it’s a negative thing at all.

Mandi Walls: Yeah, absolutely. Excellent. So being a DevOps junkie myself, it was interesting to read your book. This thing is chockfull of all kinds of information. There’s a lot in here about a lot of just all over the board. So who did you have in mind when you were writing this one? Who is this for out there in our audience?

Mark Peters: So it is kind of for everybody and I know that’s a horrible thing to say because you don’t really want it to be for everybody, but one of the things I find with DevOps all the time is it’s very much about culture and it’s about having the right culture and part of having the right culture means you have the right terms and the right words to explain things to other people. So you need to get on that common page kind of first so that you can talk about things from the same perspective. I always use, and I use it a lot in the book, I use sports analogies because I was a big time, I did a lot of sports, I did a lot of athletics, and when you do a sport you learn the basics and then you move on to more advanced things.

Mark Peters: When you’re in a ball sport like baseball, you practice throwing and catching the ball, but just because you move on to more advanced interpretations and implementations doesn’t mean you ever stop throwing and catching the ball. You always have to focus on those skills. Malcolm Gladwell did a piece and he talks about you have to do something 500 times before you’re basically familiar with it 5,000 times before you consider an expert and that’s just the basic task that’s not even moving on, integrating basic tasks together. So the book is for people who want to reinvigorate their DevOps learning and get that kind of perspective from program managers and bosses who are seeing it and don’t really know what it is and don’t really know how to talk about it to the developer who wants a better way to explain it to their boss, what they actually are, what those terms are that they need to have, why they need a particular technology or a particular implementation to get there.

Mandi Walls: Yeah, excellent. And I love how in the book you keep reiterating it. There are so many cultural aspects and I think for folks in, I’ve had the same discussion over and over the past 15 years or so with folks, there’s culture involved here, there’s human beings. I know you want to search out all the technical solutions because that’s the thing that you have influence over and culture is hard and it’s messy and people are messy, but the message comes through culture is such a pillar of DevOps success and to reiterate that in almost every chapter I thought was really great to see that. So especially reading through the DevOps subreddits and stuff like that, those folks are definitely looking for more tactics. It’s all about technical solutions. How do I build Jenkins to do this? How do I use Azure to do that without looking at, hey, we have a cultural issue here I’m not having, I need help with my communications and with my emotional intelligence kinds of things and helping people do that. So I was really impressed that you kept reiterating that with every component of the topics that you were introducing in the book.

Mark Peters: Well, you can buy the technical pieces and you can get a new tool, but if you don’t fix the culture under that, then you just go back to the same thing. We were working with a team and they all came in and they were all Jenkins and we’re like, no, we’re going with GitLab and we’re going to use GitLab to do everything and it’s all going to be Git and GitOps. And they’re like, great, we’ve got the training, we move forward, we’re doing all our GitOps, we’re doing all our GitLab type stuff. And then they brought in new hires after about a year like you do and the new hires are like, what would fix this if we went to Jenkins? We should use Jenkins because Jenkins will do this for us, and they weren’t getting the process of the improvement, they were just concentrated on this tool will do it faster. Just changing the tools doesn’t actually fix what you know about DevOps, which is why you have to be able to learn and explain all the topics to everybody along the way. Right?

Mandi Walls: Absolutely. Yeah. So with that, you talked a little bit in one of the chapters about hiring, retaining people but also team organization and so for folks who are maybe just getting started on a DevOps journey, the idea that DevOps is, this has been a point of contention I guess maybe or maybe I just find it contentious, that folks want to sort of create a DevOps team versus having teams that work in a DevOps methodology and you kind of get into that a bit as far as how to think about that. Talk a little bit about that if you could. What the difference is of a team that does DevOps or does in a DevOps way versus assigning a team to be DevOps for an organization.

Mark Peters: I like the first much better than the second as a cultural, I hate the idea of saying we’re the team that does DevOps or this person is a DevOps engineer because they understand a lot of it or they fit a lot of it through. You really need people that want to work together and want to communicate and are kind of tied in that we’re going to flow through, we’re going to do the feedback, we’re going to do this improvement and we’re going to make things better regardless and that are less tempted to throw things over the wall to the other team that want to finish it on their own. I had done some PhD research and I looked at looking again largely from a business perspective starting of you always hear teams and they talk about delivering security versus delivering functionality. Well, when you actually get down to the individual team members and I did the interviews, there’s no difference between security and functionality.

Mark Peters: They’re all just code that needs to be written and they don’t care what the code says or what it is. If they’re given a thing, they make the thing and they do it and that. So those distinctions only occur at the higher level. It’s the same type of thing with the team. We want a product, the product has to do a certain thing, it has to do X at by a certain time, so we assign elements of that code to be written because all our teams write it and they write it the best so that they can integrate. It’s not that they’re a DevOps team that’s taking all the bits and pieces from six other teams and then assembling them together. That gets you back into the continuous silo model that it’s always being thrown over the wall. Now the one split I have in that, if I have to go back and I haven’t written, but I’ve talked to a lot of people when we say DevOps, if you build it, you run it and that’s absolutely true in that it needs to run, but you still kind of need those support and ops teams for once it’s fully finished.

Mark Peters: Once you’ve gone, I think it’s Mick Jensen from a project to a product, we’ve delivered it, we’ve given it out and if we give an Amazon web server to buy something to 8 million people, I don’t want them to call my DevOps engineer directly. I want somebody who can interface with those types of things and go to that next step and make those initial changes and do some of the help desk the configuration. That’s the easy part of it that I’ve made it easy enough that anyone could run it, but it doesn’t necessarily have to be me all the time if that kind of makes sense.

Mandi Walls: Yeah, definitely. I saw that part of the chapter. I had a couple of questions about that. So you had the chapter, I forget the chapter heading, but the subheading was about ops and I was like, okay, we’re going to talk about operations, but a lot of it seemed to cross over a bit into customer support and those kinds of things, so it’s kind of an interesting cross between maybe your customer support team, your tier one NOC and some basic operations kinds of things that would be for some folks we find them, we end up calling them sustaining operations, things that are deployed to production that maybe don’t have a plan for current updates, are not being currently developed into, that are in sort of a steady state and have sort of a known operating model that are sort of pushed in that direction. Is that kind of what you were thinking about with that section or is it more distinct than that?

Mark Peters: A little bit because the value stream part that things have value when they’re delivered and how do we define delivered? I’ve delivered it, I’ve merged it, it’s become part of the main code, so it’s going out there in every production, but has it actually made it to that next step where somebody is able to buy it or that I can sell it to a customer and go forward in open source. It’s great. I can go into my repository, I can do whatever I want. It gets merged. Everybody in the community likes it and it goes out there and if you want it, you can go through and download it. When you get into those larger business environments, it’s not quite the same. How do I sell a McAfee implementation to somebody who wants to put it on their computer? The recent CrowdStrike event, we’ve sold this with the updates.

Mark Peters: We have a problem in our updates that we have a difference in the schema between the number of rows we have or the number of expected data inputs in one area versus data inputs in the other area. We missed out testing but it made it to production and then we delivered to the customer, but then we, what’s our support to go back and fix those things when they happen or that even in using that same example when you saw Delta, Delta had a very different model for how they were doing their operations than how CrowdStrike was so that you have to go out individually to each of those computers and make that update and your DevOps guy never thinks of that I distribute it, I run my rolling update, everything’s good, it’s perfect. Nobody can get to that old version anymore because they don’t need it, but you get to the, well, how do I revert, how do I auto revert on some of these things that are more of an operations question, but they’re still more of a specialized operations question than a detailed on the developer side of it because it has to do with a different skillset.

Mark Peters: You wouldn’t want your operator to come in and write code from scratch, but they can write the interactions of the code and write the automations to get you to that next step on the operations. So you can’t forget about that part when you go forward. It’s great to have a new and shiny widget that comes up and look, I run it and not only can I run it, I can hand it to my program manager and he can run it, but knowing that it continues to run and continues to be supported all the time.

Mandi Walls: Yeah, definitely. And I think there’s a bit of a difference in mindset if you’re actually, like you say shipping something to somebody, and I think we saw that that’s something that the CrowdStrike thing illuminates for folks is like you are shipping something you’re doing live updates against something that somebody else has to run on their platforms, which is sort of an evolution of those models like the early days of Windows Life where things came out in a service pack once every 18 months or whatever versus the sort of constant flow of updates and Patch Tuesdays and now these sort of immediate updates versus targeting something that is more of a SaaS platform that folks are going to be interacting with all the time but don’t actually have to run themselves. The customers are only interacting with it and not running it and that maybe make some changes to the way the models operate.

Mark Peters: I think something people have to remember is we talk about continuous integration, continuous deployment all the time in that model. We are constantly deploying new things, we’re constantly integrating new things, but constant is a variable depending on the organization you work with and the culture you work with. There’s nothing wrong with having a constant integration that occurs once a month, once a quarter because there’s further testing required or there’s something that has to go and interact so that I can make sure that I can put that piece that does all these things and look, you’re going to get all this stuff in a new month. We’re going to do hot updates and critical updates as they come out, but for these generic things, so these new features, we’re going to make sure that not only can we get you a new feature, but we can bundle a couple of new features together so you’re not just testing one thing and then getting a new thing and then getting a new thing and not able to keep up with that flow.

Mark Peters: We saw an instance for the government where we were working DevOps and we were delivering a product and they gave us their whole list of backlog stuff that hadn’t been done that they wanted to be done and we started working on it and we said, okay, because when we deliver them, you want them loaded on a hard drive and shipped out. We’ll do that once a quarter and we will ship out all these new features and we said you wanted A through D, we did A, B and C, and by the way, we added F and G because we had enough space, we had enough cycles to get them done this time, so that’s going to go out at the end of quarter one. These are the updates at quarter two and we delivered on quarter one. We delivered on quarter two. We were getting ready to ship out the door in quarter three and the government came back and said, we can’t keep up with that.

Mark Peters: They’re like, what do you mean you can’t keep up? We’re shipping them out. They go into the systems. They’re like, well, the training that we have to do on those is such that we can’t keep up, so can you slow down that DevOps process that we actually ask you to be much quicker because when you actually delivered quicker now we can’t keep up for it. We can’t get the customers on the far end spun up with all those new things that you’re giving ‘em and then they go back to the old thing, so they call up and complain because the old thing they used to do is no longer there so they don’t have the options. So you moved it from the left side of the screen to the right side of the screen and under a different menu and now you’re like, where do I find it? I find myself on Microsoft all the time that they release updates and they’ve moved around where the little tabs are on the top of the bar, so instead of finding my crop bar now I’ve got to go through and search for it every time. They’re like, well, you can just add it. I’m like, well, I could, but now I have to look for that. Now I have to find that or

Mandi Walls: Yeah, no, I thought that the only difference between the early versions of Microsoft Office were like, where are they put things in the menus and I did the same thing. I worked at help desk and in college and we’re constantly teaching people how the stuff that we had on campus was different from what their parents had and here’s how you find everything and here’s the manual and yes, it’s a different version and it looks a little bit different and yeah, it gives folks a bit of a mind warp when they have to reevaluate where they are.

Mark Peters: You said I could rabbit hole a little bit, so I will, because one of the big things I see that teams don’t integrate enough for DevOps is in the platform engineering scope, there’s all these great IDPs to run a platform to set up the infrastructure that you can get from somebody else. In the basics of DevOps, we built all those platforms ourselves and these teams spent 12 to 18 months getting something with the right formats and the right pipelines and the right structures all into place so they could build it and they built one thing and then figured out their platform was highly specific and they could only build the one thing and then went the next thing they had to start all over. Now we get these generic platforms in the DevOps space and you can purchase a platform from somebody like GitLab, I mentioned before, the Jenkins where they do these type of things, so the infrastructure one, so just tell me what the specifications are and I’ll set up all the virtual machines that you need with the right accesses in using AWS.

Mark Peters: When you set up your AWS environment, I want so many virtual machines and this is the security I want behind them and this is the SSH key you need to use, and we don’t use enough of those in DevOps, right? There’s still commitment that we need to do everything from scratch and when we can use some of those things, we can speed up our process because it is part of the continuous improvement and as a culture that doesn’t mean using just what we continuously improve, but using what everybody in the community has improved to get to the next step. What’s another great one for that? OTel. Open Telemetry from the Cloud Native Computing Foundation is a great tool for hooking into everything to get you the metrics. It still doesn’t necessarily get you the metrics that you want, but it gets you the ability to get the metrics you want much easier rather than having to write a different script on each of those containers, on each of those pods on each of those deployments to go through and pull it back to you to get the right things.

Mandi Walls: Yeah, definitely the flexibility of the tools and the way things have improved over the past eight or nine years has been, it’s just been astounding. Given that, and we’ve talked about IDPs on the show and my last guest, the episode prior to this one, we talked a little bit about hotel as well. Bring all these things into, give everybody a place to participate has been super interesting. The early part of my career, things were very locked down and everything was siloed and only the people that lived in that silo could touch the tools in that silo and that was one of the first things to start to break away when we looked and said this would be better off in a different model, and DevOps emerged from that hiding and sequestering information and functionality and metrics and things among separate teams wasn’t helping anybody reach their goals. And so democratizing those things, bringing them all back into a central location that everybody can have access to has been hopefully super illuminating for folks. I find it super interesting and helpful when we have incidents and other things going on that we all have access to the same panes of glass really to see what is going on across all the things that are going on. So yeah,

Mark Peters: Absolutely. I talked to a gentleman at a conference a couple months back and he’s like, so we have these 40 SLAs and then we have 1500 service level objectives and we’re breaking ‘em out. Wait, stop. How many of those objectives are you actually tracking?

Mark Peters: It’s like two or three. I’m like, so why do you have so many? He’s like, well, we got the engineers and we ask them what objectives they’d like to track, but are those actually increasing the value for the business? Are they making you run faster? Are they action oriented that you can look at that objective and say, if this happens, then I need to do this thing now. And he’s like, well, no, they don’t get to that step.

Mark Peters: And I’m like, you need to get rid of 90% of those. They’re not just taking you to the right spot for the right thing to get you to the next measure. And it was just fascinating that the way people use it and that they, they’ve got the observability but then they’ve overdone it.

Mandi Walls: Yeah, so part of that, the SLOs, SLAs discussion, super interesting. Other things that you mentioned that I don’t think people think about in a, why do we do this kind of way? You had mentioned in one of the chapters about feedback and things like retros and demos being explicitly part of your feedback and I really liked that and we always sort of recommended to folks if they’re like, well, how do we prove to people that what we’re doing is working? I’m like, well do a demo, show them how it works and how things are functioning, how things are moving forward. Put that out there for folks to understand, and I like that you had explicitly included those as part of the feedback process for people to think about as something that I think a lot of folks kind get hung up on, well, what can I do without executive buy-in and you can do a demo of all the stuff that you’re doing without asking permission from a vice president, just do one, right?

Mark Peters: You’re not send your customer from or you’re not selling it and that’s what do I need to go through before I can do a thing and that if you can just do it and just do it, I always say, and you hate to say it, the ask not permission or it’s easier to ask for forgiveness than permission, but you’re not changing anything. You’re not drastically reorganizing the strategy just to do a demo. You’re just showing that it works at a basic level. There was a great book about agile conversations, squirrel, and I think David was the other auditor, and they talk about the walking skeleton before the MVP. It is just the bare bones, it’s not fleshed out at all. It’s not even a basic minimum viable construct. And of course the rabbit hole on the MVP is that MVP should be an internal thing, and I hate it that you get a lot of these contracts and I want you to deliver an MVP and well, if I’m delivering it, it’s a product.

Mark Peters: It’s no longer an MVP and that’s part of what the book tries to explain. It’s the confusion between some of these concepts and how do you have to align them so that you can tell people the right things. Don’t ask me for an MVP, ask me for a feature and I will deliver you the feature and I will deliver you steps that gets you gradually to that feature, and I may call them an MVP, but you cannot call it an MVP because the thing I give you is the thing you are paying for, right? Yes. It wants to buy. It’s like I want a car, but I don’t want a frame on it. So you want four wheels and an engine. Yeah. What it doesn’t do anything that you want from the car.

Mandi Walls: Yeah, absolutely. I liked how you get into really breaking down some of these assumptions that folks have. I feel like we’re at the point in DevOps where we do things because been doing them or someone said we should do that, and breaking down the actual background of why you really want to be doing some of the things that we do from a more intellectual standpoint was super interesting, some of that stuff. So I like that.

Mark Peters: [Some technical recording issues here] Who is the improvement for and who does it? A good story. We’re working with a team or an organization and they had a bunch of different teams and they didn’t know what any of their teams were doing. They generic in and get some broader visibility, and we looked at the teams and we found out they each had different set of stages in their scrum and sprint work for what they were doing. So one had the standard to do in progress and done, and they were working off a backlog and one had to do testing one, testing two customer review, customer process test two pre-prod, and they had all these things so that when you pulled them up and you tried to GR all that information together and see what they were, they were all in different stages and you couldn’t tell how close anybody was getting to what they were supposed to deliver because they were all in so many different stages.

Mark Peters: And as a manager, I want to know that they’re all doing the work and somebody says, well, then they’re just going to use that to fire me or they’re just going to use to the, and look, it’s not about what you actually do compared to the other team. It’s about how much can you do compared to what you said you could do during that same period of time. And you need to be able to, when you say that I’ve assigned it to a sprint, it needs to be complete in that sprint. So if I come up with 40 things sprint that I need to do, I complete 40 things or I complete 38 things and I move two into the backlog, but if you say, I’ve got 80 things to do and you’re only doing 20, that’s a problem with that team. We need to talk to that team regardless. They’re like, well, all our 20 things we’re huge and all their 40 things were so small, but then you should know that you can only get 22 done and not

Mandi Walls: Set yourself up for 40.

Mark Peters: So how do I balance those things to get to the right spot to get to where I need to be to go forward? And that’s part of that observability too that we were talking about beforehand of how can I see what is everyone is doing? And the same thing even applies. I ran a security team and we had policy and we had nine different areas for staging. I said, don’t make these all areas that we need a column for. It’s in review one, it’s in review two, just put under the acceptance criteria for the thing you’re talking about. Put needs to be reviewed by A, needs to be reviewed by B. And as those things get checked off, I can look at it and see it’s in to-do and still see how much progress it’s making across there without having to have 19 different columns that I need to be able to explain what it is I’m doing.

Mandi Walls: Yeah. Oh yeah. Just because that’s what you’re doing under the covers. Not everything everybody needs to know about. And I liked how you broke down observability a couple of different ways because when we talk observability and sort of a technical standpoint, it’s the o11y. It’s very much how we put the code into our traces and logs and things like that. But your perspective on observability is interesting too because you’re talking about being able to observe work being done, like adding that additional sort of value stream definition to having people observe the things that are going on and the work that’s being done as part of what’s on the Kanban board and how things are progressing and how the work is getting done and making sure that everyone on the team can find all of those things. I thought it was a super interesting perspective to add to that. We don’t usually associate that with observability from the application developer standpoint, but it’s so important. It’s capital observability at that point rather than logs and traces is super interesting.

Mark Peters: Yeah, I break it down. You have things that are observable, things that are observed, and then I have observability, which is my process of combining the things that I’ve made observable and I’ve observed them at a point and I move forward. One of the ones I always like is we’re measuring again, how much they complete in a sprint, but we also want to measure how much coffee was consumed in the company kitchen along that time because we think those two are related. So do I really have the observability? I need to be able to measure those that are outside of my normal scope that might still apply active and really contribute to that continuous learning even down to the points of like, well, how much did on a remote team, how much did X contribute? How often this camera on versus this camera on? Did this person say anything?

Mark Peters: We were talking about AI assistants the other day or I was talking with a friend about AI assistants and my comment is they’re like, well, how can we have AI help junior developers to do this and that with a theory that it might eventually replace them? And I said, okay, well, in that case, I need to be able to sign the role for my AI and say, this one always shows up late to a meeting. This one always shows up early. This one donuts on Thursday, this one interrupts. Whenever somebody says Kubernetes, this one never interrupts. As soon as the topic turns to security, this one will go on a six minute rant and take over the conversation about security issues. But those are the things that you get from the interaction in the team. While they might seem frustrating at some points, also help drive the team to an area of success. So when you just say, well, I’m just going to replace it with an AI that just writes code, well, okay, but you’re, you’ve got the code, but you’re not really getting the team success that it can handle the larger and more difficult problems later on because it’s still the same problem or the same interaction.

Mandi Walls: Yeah. Oh, for sure. You’re losing all of the prior experience all those folks had, assuming that you can just distill that experience into snippets of code that you’re going to download off the internet. And that’s really how software building works at scale. We need the things that people have learned over their careers to bring into it.

Mark Peters: It loses some of the creative models. I mean, how often have you stood in front of a whiteboard with somebody and you put your thing down, they put their thing down, and then you start looking at it and you’re like, oh, that’s the space we have to fill in. Yes. And neither of you had seen it before you saw that diagram. Even if something can jump to right there for you, it might not because it’s just going to give you the two things and say, well, these don’t work together and not necessarily that solution that you’re looking for at that next step.

Mandi Walls: Absolutely. Even stuff like advent of code, some of our engineers participate in in December and discuss solutions and things like that, and people will come up with interesting solutions that I didn’t even think about, and you’re just like, oh, yeah, that’s more creative. That one’s faster, that one’s more efficient. These things really come into play, but if you’re all using the same ai, you’re all going to get this hopefully, probably maybe a deterministic answer out of them. Same answer, who knows? But something more similar,

Mark Peters: I’ve heard some of the college admission departments are completely getting rid of the essay as part of the college admissions because they said they’re getting too many AI answers, and there was one that says the word brilliance increased by 7000% in submissions during a certain period of time where the AI decided it wanted this word. That word was always there.

Mandi Walls: Where did that come from? Where’d you pull that from?

Mark Peters: You still have to know and understand what’s going on. I had a great, when I was in the Air Force, we were doing targeting, so we were looking at different bombs and where you drop a bomb and what the impact was and how close it had to be and all the angles. And they had these giant books with orange covers, and you would have to use the ruler to match out the traces on the different graphs, and they short circuited that, or not short circuited, but they built it into a computer version. So you use the UI and you tell it and it gives you the answer. It’s like, well, that’s great, but you’re missing some of those little interpretations in the process that are a key part of the learning. If we expand this one, when you go into new technologies, quantum algorithms for things, quantum algorithms give you a better answer, but they give you a wider set of parameters when you’re doing the search.

Mark Peters: So one of the comparisons, an example, they were looking for what was the best fit and the best fit came up in a classical computer is 37%, and it came up in the quantum computer as 28%, but in the classical you had a 37% and then you had a 12% and then you had a bunch of little other ones. Well, the quantum had the 28%, but then it has a seven and a six and a five. It has a bunch of these little ones that are outside of that kind of balance because it can search for better fits more quickly as it uses the superposition on those qubits and all those kind of things so that there are more answers available. And while there might be a best fit, that might not always be the fit you want to get it to that next step. Maybe it’s one of those other ones that doesn’t fit quite so well but sells better or you can integrate a little better or do a little bit of different code on the outside to get to the space where you need it to move on to that next thing.

Mandi Walls: Yeah, it’s interesting you mentioned quantum. When I got to the future of DevOps chapter, at the end of the book, I was like, okay, where are we going? What’s he going to say in future DevOps and AI/ML were there for sure, and then you brought in quantum and I’m like, oh man, all quantum’s an interesting way to go with that. I talked to a few folks on quantum and I think just this week it was maybe Google or someone has announced a prize for folks who find novel uses for quantum computing and things like that. So it was an interesting thing to see included there that quantum be useful because of the domains that it might work in the future was super interesting as an inclusion there.

Mark Peters: Super. So the basics of coding is you have to be able to tell a computer to turn on a switch to zero or one at some part, and Quantum gives you different options and it gives you the range of that switch. So how would I do things differently in finding that range? Great looks at traveling salesman type comparison of what do I take to which city to get the best value and those return great fits in material models as we said, what’s the best fit for this solution? How do I build a pharmaceutical, how do I build a better material that are in there? But that’ll be part of the growing conversation of how do I write something that works in normal code that I can convert to Quantum to run a little bit differently? Amazon bracket, the AWS bracket gives you opportunity where can actually write the code and then go onto bracket and test your code on a quantum machine.

Mark Peters: But especially in search, especially in these large problems in these large data sets that we’re looking at in the comparison of a quantum ML with a neural network that looks at things. Because when you talk about growth and quantum for search, what it talks about is if I have a normal deck of a thousand items, I need to look at 999 or 501 to make sure that I found the thing that I want in the set of a thousand. Well, in the Grover’s algorithm, the quantum, it’s a root of the number of things in the set. So a root of a thousand, which gives me about 37 things. So I only need to look at 37 things to make sure I have the right answer. And while at that level it’s not really very high, but when you talk about scaling that number up massively, it can be a lot of fun at least. Interesting. Yeah,

Mandi Walls: For sure. Yeah, looking forward to seeing how those things go. It’s not anywhere that I had the opportunity to dip my toes in yet

Mark Peters: In looking forward. It is always kind of an iffy projection. If I really knew what was coming next, I’d be running my own company and not writing books, but you can guess on some of ‘em, right? Some of the storage models and the ways you may have to call things differently if the storage model changes, right?

Mandi Walls: Yeah, no, absolutely.

Mark Peters: It’s kind of a fascinating one.

Mandi Walls: Definitely. Yeah, bio computers and some of the other things that have come up, definitely interesting as that changes, especially the larger domains, science, weather, all those things that have such large compute requirements as well as large datasets to work with. Super interesting. So with that, there are so many references in this book. I love it when I talk to someone who’s done a lot of research for their book because there’s so many other things in there that if I want to know more, it’s all in there. There’s all these things in the index and things to look up. So for folks that have read through this, what do you recommend of the things that maybe you did the research on that you added into the book? Are there other books and components that folks could look at next? Are there one or two maybe that you recommend folks look at in addition to your book as a starting place? Where could they go next?

Mark Peters: I advocate reading everything you get your hands on.

Mandi Walls: That’s the easy answer.

Mark Peters: One of my own tricks is I go through the references for the books I read and try to go back to the original sets. There’s a book on my desk right now called Sard that was the late nineties about how you do symptoms, which has a huge impact on ML and ai, but it’s an older book, so sometimes I like going back and reading the older stuff. There’s a book, what is it? I’m going to miss the author, which I should know. But the cybernetics book that was written in the late forties by one of the original producers of cybernetics, and I think it’s Cybernetics in the Human machine or something like that. And those types of things are fascinating. Within the past year, I read a biography of a gentleman named Claude Shannon, and if you can find the biography, Claude Shannon wrote the basic PhD thesis dissertation research on how you take any signal and convert it to a binary.

Mandi Walls: Oh, interesting. Okay. So

Mark Peters: That you can use before they’d been doing a lot of it, but they didn’t have a theory behind how you change information binary output to move into this setup.

Mandi Walls: Awesome digitization, its earliest.

Mark Peters: So those types of things. DevOps, you have to recommend the DevOps handbook and the Phoenix Project, those are kind of must reads.

Mandi Walls: Yeah, I have my DevOps handbook behind me on the shelf right there, so always keep that handy

Mark Peters: I actually ran into Patrick Debois at a conference a year or two back and he actually signed my copy, so I was very happy that I got that one signed. Reading the very technical specifications and then reading the business level specifications about this is how you run a business and trying to match meritocracy that talked about how you run a business organizations that was interesting and challenging.

Mark Peters: Along the way. So I like reading a lot of stuff. I was talking, I actually have, I don’t know that it’s a side gig because it’s free with Packt who does production for a lot of books to go and said, Hey, send me a book. I’ll read it, I’ll do an Amazon review. And actually looked back at my log the other day for the past four years, I’ve read over a hundred books for them just on everything from Kubernetes to building a circuit to the last one was AI adversary attacks and machine learning mitigations or something like that. And every month or two they’ll come up and they’re like, here’s a list of three or four books and you read ‘em. And that keeps me sharp.

Mandi Walls: Yeah. Oh yeah. And that definitely is all kinds of topics for sure. Yeah, that’s awesome. Sweet. Well, where can folks find you if they have questions or want to interact with you? Are you on social media at all?

Mark Peters: So I’m on LinkedIn at TinyCyber or @TinyCyber is probably the best way to get ahold of me.

Mandi Walls: Super. That’s great. Is there any piece of parting recommendations or advice you’d want to give to our nascent DevOps community out there?

Mark Peters: Remember, it’s a cultural thing with the flow feedback and continuous improvement. So the more you talk to people, the better off you enter our culture because the culture is about having the right words and the right terms to talk to each other. Please read the book, I give you a discount code, it’s Koganpage20 for the Kogan Page. Get 20% off that order. And then of course I always like Amazon reviews on top of everything else a book, but yeah, flow feedback and improvement, right? It’s a constant learning process for all of us.

Mandi Walls: Yeah, we’re always learning. Always learning for sure. Something new every day. Well, excellent. This has been great. Thank you so much. I enjoyed the book. There was a whole lot of side quests and rabbit holes that I have a list of other things to look up and read more about this afternoon. I listened to a podcast on phenomenology because that was mentioned and I was like, I don’t know what this is. So I pulled up the In Our Time podcast on phenomenology to listen to that as my philosophy education is nonexistent. So inspiring, additional learning all around. So it’s been great. So thank you so much.

Mark Peters: Phenomenology. Now I could talk 45 minutes more on that easy, but

Mandi Walls: That’s another podcast for sure.

Mark Peters: That’s a great one.

Mandi Walls: That’s awesome. Alright, mark, this has been great. Thank you so much. Thank you for writing the book. Thanks for joining me today and for everyone else out there, thank you. If you have suggestions for other books we should read or things that you want us to talk about, you can get in touch with our team. We’re community-team@pagerduty.com. We’re always happy to talk to all of you out there, what you’re doing and what you’d like to hear. And in the meantime.