This post was originally written for
Trend Micro .Reasonably Accurate 馃馃 Transcript
Mark: Hey, everybody. thank you for joining, yet another episode of Let's Talk Cloud. if, the live demo gods, and streaming gods are with us, this is all working correctly, from the appearance of everything. We are live on LinkedIn, on YouTube, and on Twitter. you can, comment and join the discussion there with the #letstalkcloud. as always, we've got a great team behind the scenes who are monitoring, that chat, so that we can make this a very interactive discussion, and bring your thoughts, into, this discussion, and this show.
[00:05:05]with us today is a very, very special treat. We have a phenomenal guest, Patrick Debois, who is, I don't even know how to describe his impact on our community. he is the co-author of The DevOps Handbook. He is, the Director of DevOps Relations at Snyk. He is one of the, if not the originator of the actual term DevOps, let's welcome, Patrick to the show. Patrick, thanks for coming on.
[00:05:30] Patrick: Yeah, thanks for having me Mark. I'm glad, I could be on a webinar again, [laughs], right, [laughs]?
[00:05:36] Mark: I heard you haven't done one in a long time, so I thought why not?
[00:05:39] Patrick: [laughs], yeah, of course, yeah, yeah, what a I, you know, everything is secure at the [inaudible 00:05:50] that I'm operate, so.
[00:05:45] Mark: Good, good, so, you know, in the, in the intro I mentioned, because I was doing some research for this, you know, obviously I read this phenomenal book when it came out, The Devops Handbook, it is amazing. We will talk to you on this in a little bit. but one of the things that popped up, was a very interesting Wikipedia reference, from, I did check the English, it was somehow I was surfing the French, Wikipedia, and it credits you, it sites you with originating the term DevOps. Is that accurate?
[00:06:12] Patrick: It's accurate, and it might not be accurate. So, [
[00:06:16] Mark: [laughs].
[00:06:16] Patrick: ... it depends on how you see things, right?
[00:06:18] Mark: Okay.
[00:06:18] Patrick: I was already working in 2009 around Agile, er, in general doing Agile infrastructure.
[00:06:26] Mark: Mm-hmm [affirmative].
[00:06:26] Patrick: but then I saw a, a talk by John Allspaw, and Hammond around how dev and ops collaborated at Etsy, right? So, but that just had a slight dev loves ops, right?
[00:06:40] Mark: Yes.
[00:06:40] Patrick: And then I- I wanted to do a conference, and I called it, I wanted to give it a name, and I said, "What about Agile System Administrator Base, but that's just gonna be too long," I was like, "How about DevOps Base?" And then so the term was coined by accident, like many things of my life.
[00:06:59] Mark: Yeah.
[00:06:59] Patrick: But that's the original story how we got to the name. And then after the first conference, I didn't even knew it was a thing until somebody wrote a blog post, "What is this DevOps thing anyway?"
[00:07:12] Mark: Mm-hmm [affirmative].
[00:07:12] Patrick: So, and then it kind of took off to the world. and that's, you know, now my kids are like, "Hey, what's this DevOps thing," so?
[00:07:21] Mark: Would, would-
[00:07:21] Patrick: It's that old.
[00:07:21] Mark: ... right, and I mean that's- that's absolutely crazy, but that's how most of this stuff kinda happens, right, er, it's- it's good intentions-
[00:07:25] Patrick: Mm-hmm [affirmative].
[00:07:26] Mark: ... and it just starts to pickup. but, you know, where, and I think that's- that's very credible as far as you're the originator of the term, so, you know, as one of the originators, obviously as one of the key, influencers in the community, to this day a decade plus later, I'm gonna ask you the worst question in DevOps, which is, "What is DevOps?"
[00:07:46] Patrick: DevOps is, the way I explain it to my, to my kids, when they were younger, is when you're at the playground, and you have to play nice with somebody else on the playground, [laughs], that is DevOps, right? [laughs], and, [laughs], so and then obviously it in company terms it's the developer working with the ops group, because-
[00:08:11] Mark: Mm-hmm [affirmative].
[00:08:11] Patrick: ... there was this throw over the wall mentality, I say was, there probably still is in many places, but, and then I think later it expanded more to looking at the- the, company as a system, more in systems thinking that the different groups got to align themselves to kind of achieve the business goal, better. so the, whether that is Dev, that's Ops, that's Sec, and in- in some of my latest talk, I said like sales has to be aligned, marketing has to be aligned, HR, legal, you know, everybody's working towards this collaboration, and whatever one of these groups does, or doesn't, has as an impact on all the other groups.
[00:08:55] So, for me that is kind of the essence of achieving this result by playing nice with other people in your company.
[00:09:02] Mark: Mm-hmm [affirmative], yeah, and I think, you know, that really, and that's an excellent answer and also the vagueness of this answer kinda expresses the philosophy, right of that, you know, the- the analogy I think is really the- the key part is playing nice with others, right, working towards that common goal. so, you know, you have a ton of experience in the Agile community, in fact, you know, that's, you, how you explained you came up with the term. and you've seen this transition for Agile to now into the DevOps philosophy and the movement, it's, what's the biggest surprise you think you've seen, you know, being involved with this for 20-plus years?
[00:09:36] Patrick: reading a blog that said again Agile and DevOps work together. That was a big surprise. [laughs], and that, you can Google that-
[00:09:45] Mark: What?
[00:09:46] Patrick: ... and those blogs exist, right, like they are two separate things somehow, and- and- and that was kind of a surprise in a way that, so I understand in the beginning Agile wa- was already, they were pushing for more stable, software delivery as the artifact delivery.
[00:10:04] Mark: Mm-hmm [affirmative].
[00:10:05] Patrick: I remember sitting in a, at a conference and then listening to, David Anderson who coined liked Kanban-
[00:10:11] Mark: Yeah.
[00:10:11] Patrick: ... for, for, you know, development teams to pick that up, and he said like, "Oh, where's the workflow?" I remember saying in the, like raising my hand, "What, how about the Ops group?" Then he said like, "Good luck," [laughs]-
[00:10:22] Mark: [laughs].
[00:10:23] Patrick: ... so I remember those words from him. but the fact that, the thinking kind of extend that, in Agile that the- the lines are blurring, but, so a lot of the developers are taking over some of the practices and continuous integration went to continuous delivery-
[00:10:39] Mark: Mm-hmm [affirmative].
[00:10:40] Patrick: ... and so the whole pipeline got kind of part of a the development. yet Agile, if you look at it as an ecosystem kind of stayed s- n- not completely separate, but not enough integrated to the DevOps community.
[00:10:56] Mark: Mm.
[00:10:56] Patrick: They're still seen as two different kind of communities where, people think about, er, aspects of- of the, of the differences-
[00:11:04] Mark: Mm-hmm [affirmative].
[00:11:05] Patrick: ... I think Agile in general is strong-headed. They moved w- way more to the business side in a way that they will be more looking at, "Okay what does it mean to get the business involved?"
[00:11:19] Mark: Yeah.
[00:11:19] Patrick: Where DevOps talks about this value, but it's probably closer to the user aspect, like how can we make it more stable, how can we make it more functional, in a way. There's some truth in the middle, but that- that are, like I would've hoped to have them kind of almost like better integrated, that it will be like, what, you know, what's the next big thing of DevOps, and I would s- usually say Agile, right?
[00:11:46] Mark: Yeah.
[00:11:46] Patrick: And- and people look, would look confused, because, [laughs]-
[00:11:49] Mark: [laughs].
[00:11:49] Patrick: ... but that's kind of the idea that these two worlds somehow would merge together.
[00:11:54] Mark: Yeah, and I think your- your point about Agile being closer to the business, while DevOps is closer to the user is- is a really important one. When some people maybe like, "Whoa, aren't those the same things," and, you know, they're definitely not, like they can overlap, but they're, you know, that's two sides of the same coin, but if you've never crossing the side, er, you know, or maybe two sides of the same river, and there's no bridge, is probably more accurate, but I think that's a really important point, especially, you know, I find it interesting the parallel of how Agile has changed in its definition somewhat over the years, and it's sort of hazy, because if you say Agile to, people who've seen it go across, we have a very different idea than somebody else who's like, "It's scrum."
[00:12:33] And, you're like, "Well, no, it's more than that." It's, you know, it's- it's not just one little thing, but there're definitely parallels there, and yet that's still gaps, so I was writing down that DevOps and Agile can they coexist title, because I'll add those into the show notes, and for the audience, just so you guys know, everything we reference here, we'll put in the show notes so that you guys can, find those links really, really easy, and the team will drop the, shows URL in, in LinkedIn, on YouTube and on Twitter as well, so you guys can get those references.
[00:12:58]because there's gonna be a ton of stuff. I know, er, just, based on, er, you know, having spoken to Patrick before and seeing his content, we're gonna bring up a lot of weird stuff probably today, [laughs].
[00:13:06] Patrick: [laughs].
[00:13:06] Mark: And it's good, it's good to have links so you can check it out, later on.
[00:13:10] Patrick: Yeah.
[00:13:11] Mark: ... so it's interesting as a surprise. So I wanna bring back another, parallel, that I saw, again researching the stuff, so one of the things I saw was, you know, you gotta love everything living on the internet, and, you know, I think we got started around the same kinda time online. but you were way more advanced than I was I think off the bat, because I found a reference to you in an academic paper, from 1994, on project work you had done around, web indexing,
[00:13:36] Patrick: Yeah, correct, that-
[00:13:37] Mark: ... yeah, which I thought was amazing-
[00:13:39] Patrick: ... [laughs].
[00:13:39] Mark: ... very cool to have a reference, in an academic paper from, Adorf, and again in the show notes the links there for the PDF, this, person had gone through and looked at how people were, accessing resources online, in the mid '90s, because it was the Wild West right, pre Google days. For those of you-
[00:13:53] Patrick: Pre Yahoo days.
[00:13:54] Mark: ... yeah, for those of you in the audience, yes-
[00:13:56] Patrick: [laughs].
[00:13:57] Mark: ... there was a time before Google existed, and indexed everything on the planet. but what I found interesting is looking at the parallel of you were tackling that problem of finding disco- like discovering resources and helping people find them, you know, through, it was URL Heaven, wasn't it?
[00:14:11] Patrick: Correct, yeah. Good research Mark.
[00:14:13] Mark: I- I tried, I gotta, I, you-
[00:14:15] Patrick: [laughs].
[00:14:15] Mark: ... come on the show with a big name, I gotta, I gotta hold up my side of this, right? but I was in my mind when I was reading it. I was drawing parallels to the challenges we're having now as a result of changing how we develop, and pushing into microservices, where enterprises are having a hard time discovering the resources they've already got built, within, their organization, right, and it's funny because I talked to these teams, and like, "Oh, yeah, we got a g- great microservice design," and you hear the services they've built, and you talk to another team in the same org, and they'd built same resources a lot of the time.
[00:14:46] There's a lot of overlap, have you found that to be the true for your experience as well? What do you, what do you think about service discovery in the modern age here?
[00:14:54] Patrick: Yeah, I think the, obviously depends a little bit on your size, you know, er, of your company, but the bigger your gap, obviously the- the number of people you can talk to, or the teams that you're are working with. they- they have that problem, and I think what also ties into that is the fact that, we're giving teams the freedom to use whatever tool they deem necessary, right?
[00:15:19] Mark: Yep.
[00:15:20] Patrick: So, it- it's kind of this empowering of the team, but then it might go somewhere in this tool spread somehow of things that are using, and that, whether that's a tool, or a service that is somewhere in your company, or, you know, and then especially, for example, if you're all remote, like you don't need even met all the people, you don't even, know what they're using all the, all day long and then you just, the whole time you're just discovering, "Oh, A from department B is doing this, and they're using this cool tool."
[00:15:53] And- and all of a sudden you have like 15 tools for analytics, 15 tools for CRM, 15 tools for monitoring your systems, I- I can't recall the name, but the other day when I was researching, vulnerability scanning tools.
[00:16:08] Mark: Mm-hmm [affirmative].
[00:16:09] Patrick: there were, there was a tool that basically aggregated the results of all the tools to make sure that whatever was marked in one tool as we got that-
[00:16:21] Mark: Mm.
[00:16:21] Patrick: ... wasn't surfacing again in the other tool.
[00:16:23] Mark: Yeah.
[00:16:23] Patrick: So, it's, that is probably a difference spread, but it- it just reminded me of the fact that, you know, there can be so many things going on, and this- this kind of overview is something you need, but just automatically discovering things, I've never seen that work perfectly, right?
[00:16:43] Mark: Yeah.
[00:16:43] Patrick: So, it's like, and- and to your point then, I've never seen a search engine index correctly without having some of the top creation as well. So, there's always like some automation aspect, and some kind of, human aspect that drives both, things. I think Google understood that pretty well, you know, by clicks and then, you know, surfing, surfacing stuff-
[00:17:06] Mark: Mm-hmm [affirmative].
[00:17:06] Patrick: ... and then, re- discovering new things, but not enough new things. So, yeah I- I kind of see, where you're coming from, so.
[00:17:13] Mark: Okay, okay. and that brings up a lot of stuff that I wanna dive into, but there's one more question on the Dev side that I wanna talk about before we dive into your security journey here. and that was, you know, reviewing, er, a- again, you know, I'll just keep holding it up, because this is an excellent, excellent book, and if everybody, if you haven't read this yet, you need to read this, front to back.
[00:17:32] Patrick: But can I tell you a secret, Mike?
[00:17:33] Mark: Yeah, absolutely.
[00:17:35] Patrick: I- I haven't read it back to back, [laughs].
[00:17:38] Mark: I think that's fair, given that you wrote a big chunk of it, along with Jez, and John, and Gene. I think that's okay.
[00:17:45] Patrick: I did most of the talking, they did the writing-
[00:17:49] Mark: [laughs].
[00:17:49] Patrick: ... and that's how I got on the book somehow, [laughs].
[00:17:52] Mark: That sounds like the best-
[00:17:54] Patrick: But I will, I definitely know like loads of the stories, because we were being chatting for so long.
[00:17:58] Mark: ... Yeah.
[00:17:59] Patrick: Actually my kids sometimes joke the fact, in my calendar they would say, "Is it Gene Kim time again?" And they knew it was kind of a new session of just discussing all these things. So, but yeah the book's great, I- I, you know, I- I get a lot of feedback from people saying, "This is a consistent work,
[00:18:20] Mark: Mm.
[00:18:20] Patrick: ... which is kind of hard to find in our field."
[00:18:22] Mark: Yeah, yeah.
[00:18:23] Patrick: there are many books that also relates more to, the tooling side, but I- I think they're sometimes quite, volatile, because it- it isn't conceptually, and this kind of ties in nicely in a, in a, you know, in a consistent, that brings all the threats together that we've been discussing for years, so.
[00:18:41] Mark: Yeah and I- I love the fact that it's- it's somewhat timeless in that it's not like, this is referring to Chef version 1.2.3, right? You're talking about the workflow, about the process, about the principles behind it, and- and that was what I wanted for this question, and was, er, one of the key principles here, in building, you know, continuous delivery, and building out your pipeline is that of the Andon Cord, right?
[00:19:02] The ability for somebody to stop the deployment, and stop the build, if there's a problem, so that you can go back and fix it. it's pretty well accepted, most, you know, teams are- are deploying that who are adopting the DevOps philosophy, but what I wanted to ask you given your experience, how do you get people, over that hump of being comfortable and actually yanking the cord? Because I know especially with a lot of junior folks, whether it's their first time maybe and they, there's a lot of if perceived stigma, or, concern about pulling it, when, you know, the idea is, when in doubt, stop and pull the cord, to make sure that things don't blow up.
[00:19:35]what's been your experience kind of introducing that concept, or helping people get over that [00:19:40] psychological hurdle?
[00:19:41] Patrick: Yeah, I think there's, the first hurdle that everybody has it that, yeah, it- it won't be me, like you say. You know, I- I don't wanna be the person who blocks the whole thing. so I've seen companies kind of shift that around in a way that, they look at it as a positive thing, if you find something, you know, you're like almost like celebrated that you- you brought something, to the table.
[00:20:06]in the beginning of the process usually it's a little bit stop and go, stop and go.
[00:20:10] Mark: Yeah.
[00:20:10] Patrick: if you, if you want to have people do that and- and you have to really make sure that there isn't that fatigue of, "Oh yeah, we're down again, and oh we're up again." So, I- I wouldn't usually start doing it without having a little bit more of a maturity that, some of the tests are kind of caught, more automatically-
[00:20:34] Mark: Okay.
[00:20:34] Patrick: ... because otherwise, it will just be different. so I'll- I'll typically start out with maybe, the team writing tests and- and understanding why the tests are- are valuable.
[00:20:44] Mark: Mm-hmm [affirmative].
[00:20:44] Patrick: Still going a little bit to a QA, but that could be a group QA.
[00:20:49] Mark: Okay.
[00:20:49] Patrick: Instead of saying this is something, that we do continuously, and then when that kind of flow is getting better and better, then, you know, where- where if somebody says stop, it's probably worth the stop. but I, if you would immediately say, "Stop," all the time, I- I- I think it's creating some fatigue-
[00:21:10] Mark: Yep.
[00:21:10] Patrick: ... and I'd rather do that in a group, and it- it- it only makes sense if you have some maturity in your process. That's something people forget, is like to reach the continuous delivery, it requires a lot of time, and maturity for the team to pick up skills and- and things to do. I know they're always so eager, let- "How can we go in five days to continuous delivery?"
[00:21:34] And in my work if- if all the team members have experienced that, and they're on the same page, but-
[00:21:41] Mark: Okay.
[00:21:41] Patrick: ... it, you know, looking at, you know, one of the canonical examples with Etsy, that was like four or five years, their journey.
[00:21:49] Mark: Yeah.
[00:21:50] Patrick: Netflix didn't have that from the start, so, w- like everybody has to build this up somehow with the team. I remember being on a, like my previous company we were checking out, kitcode on production, right?
[00:22:05] Mark: Mm-hmm [affirmative].
[00:22:05] Patrick: And, [laughs], we- we shouldn't be doing it, but it- it took me almost like a year and a half to get the team into, writing tests that they needed, [laughs].
[00:22:14] Mark: Yeah.
[00:22:14] Patrick: Not because I asked them-
[00:22:16] Mark: [laughs].
[00:22:16] Patrick: ... but because it- it was useful.
[00:22:18] Mark: Mm-hmm [affirmative].
[00:22:19] Patrick: because they were committed, because it was, you know, they were on- on kind of on-call. So they- they knew when they changed things that that was important, to do. So, that commitment and that-
[00:22:30] Mark: Yeah.
[00:22:30] Patrick: ... reason to do it, is- is half the battle, I guess, so.
[00:22:34] Mark: Yeah and I mean, I think that brings up a really good point, and I'm gonna pull that up on screen right now, I showed you this before we jumped on, unfortunately you- you can't see it on the screen yourself, but this is a, table from a talk you gave in 2014. So, six years ago, that showed a, maturity model, of, you know, intro, novice, intermediate, advanced and insane, which I love. [laughs], for, organizations as they're going towards continuous integration.
[00:22:58]when I was digging through this, what surprised me, well it surprised me, but it shouldn't have surprised me, was that how closely this aligns with, the maturity model we see in the state of DevOps report from DORA, every year for the last few years, right?
[00:23:10]and I think that's one of the biggest things that people forget, and what you just hit on repeatedly was that, the tech side is pretty simple, like you can setup the tech side of a pipeline relatively easily with a bunch of services, you know, you get your code repo, you got your test runner, you got the deployment, like that's not hard. It's the mental side, the cultural side of the team to get through these stages, to understand that, you know, and we saw this at Trend Micro ourselves.
[00:23:39]I was part of our initial trans- transformation years ago, where we went from deploying, you know, Enterprise software, we chip it to customers, big version every year, with updates throughout the year, to continuous delivery on a service and even there, a few years in, I mean, we're six years into that transformation for that team, and they're still, you know, basically they deploy once every two weeks I think, once every week, two weeks.
[00:24:02]which for them works great, and it's, they're meeting customer demands, but it took years to get to that point. So, with that maturity model in mind, you know, I think a lot of people can get out of intro into sort of the middle pretty easily, but it takes a lot of effort to get over that hump of sort of the mid range up into the, advanced or sort of experts. what- what do you think the key is there, what's your experience of those teams who, you know, they've got the basics, how do they get t- truly to that next level, you know, the Etsy's, the Netflix, the Flickr's, way back in the day, being-
[00:24:34] Patrick: Mm-hmm [affirmative].
[00:24:34] Mark: ... being able to do that continuously, you know, and deploy multiple times per day, roll back, you know, fix things, move forward, whatever they need to do? How do they get to that el- elite level?
[00:24:45] Patrick: So, one- one process that helped me, pretty well was, the first thing is- is kind of build the almost like the- the value stream, or the mapping of everything that's, going on, right? So, making it, like the system visible is one thing, but making it a shared understanding across everybody, is another. So, that's usually an exercise I do, is like, "Okay, write everything that you know about the system on the board, like put up every piece that you know," and then low and behold there's gonna be these two pieces nobody knew, or the one thing everybody knew, but what, and I, like the documentation server went down-
[00:25:26] Mark: Mm-hmm [affirmative].
[00:25:27] Patrick: ... or all these kind of things, and then once you mapped it out, you start thinking, "Okay, where did things go down, frequently, right?" And then you start looking for your bottleneck, on the system, and then you start saying, "Well, okay if we," like you, first you look at the- the- the larger bottlenecks that purely, surface from your ticketing system, [laughs], or from any fires, you noted down.
[00:25:52]and then you say, "Well, you know, they might be at a two on a scale of 10, how can we get them to five," right?
[00:26:00] Mark: Yeah.
[00:26:01] Patrick: Not to a 10, but, I usually make the, and I might be, lost in translation here, if you have a barrel of water, right? There's the sides in wood that has been made up.
[00:26:13] Mark: Yeah.
[00:26:13] Patrick: It's- if one of those sides is broken, the water will flow out through the lowest side, right?
[00:26:20] Mark: Mm-hmm [affirmative].
[00:26:20] Patrick: So, we'll kind of have to, each of those sides probably level up, you know, part by part, instead of going, "Oh, I'm gonna do all this automation, because that's fantastic," or, "I- I'm gonna go all in with system A." It- it's kind of this gradual approach that builds the fort-
[00:26:40] Mark: Yep.
[00:26:40] Patrick: ... and- and kind of, levels things up. And then it's- it's more and more gonna be, not a technical discussion, then it's gonna be a priority discussion, pulling the business in, evaluating risks over the things you're doing, and kind of work on that. But in generally the guidance like, "Where's your next bottleneck?" And have consensus on that, and work on that, is actually the simplest process that there is. it's something I- I describe, like I mentioned before in my previous company-
[00:27:11] Mark: Yeah.
[00:27:12] Patrick: ... we had the tech all working, and where was our bottleneck, in sales, right, in hiring people, and it- it's just so simple if you look at that, from a higher perspective, and you don't stay in your local optimization, whether it's your, in your team, in your personal, interest or whatever, but you start looking at the system, what needs improvement? So that- that'll be my general advice on- on doing that.
[00:27:37] Mark: That's fantastic, absolutely fantastic. It reminds me of, you know, the water analogy works really, really well. what I always find funny is like, the- the bodybuilder, the gym muscle heads, who all they ever do is bench press, and then you ask them to do something simple, you know, in the real world, and they can't do it, because they've overdeveloped just one set of muscles, and haven't worried about the rest of themselves.
[00:27:56]and, you know, like we see that in teams all the time, where you get really, you know, Cracker Jack side of like one or two engineers who are, you know, the best at one thing, but they ignore everything else, and it's like, "Well, I can't have a hundred percent in one thing, I need, you know, I'd rather have 40 percent across the board, because we'd actually be better off as a team."
[00:28:13]but that, brings me to something you Tweeted out, this week, because I know you have been, I appreciate you taking the time for this stream, because let's just say you're a tiny bit busy with something right now-
[00:28:22] Patrick: [laughs].
[00:28:22] Mark: ... I think that's, you know, the world's biggest understatement. let me pull up the page for it actually first. So, I'll give you the quick intro, and maybe you wanna give it, but you're, the engine behind, Snyk's hosting this new conference, All.The.Talks online. Do you wanna give us a little 30 seconds on what it is?
[00:28:39] Patrick: Basically it's for people sitting at home, that, were bummed not to get content, although that's not true anymore. but it's gonna be about DevOps, Decs- DevSecOps, security, Java, JavaScript, and we're doing this conference for a good cause, all donations go to the World Health Organization, so part of watching the talks and raising money and learning things, I think that's like the 30 second, or 35 second, or 37 second right now, [laughs]-
[00:29:07] Mark: [laughs].
[00:29:08] Patrick: ... episode of that.
[00:29:10] Mark: Perfect, and so I've been following along on Twitter trying to help out when I can, because you've been Tweeting out various requests for software for different things, and what I pulled up on the screen right now, is something you were just talking about on getting those team's sort of the elite level, is your list that you Tweeted out of possible failures for this conference, because obviously you've got speakers, you've got the audience, there is a ton of things that you're trying to connect here, so many moving parts and for the first time, so, I didn't wanna dive into this, because I- I didn't want to make you sad, [laughs],
[00:29:41] Patrick: Yeah, [laughs].
[00:29:41] Mark: ... but what I thought was, it's a really good public example of that process you just talked about, of walking through, "Okay, I'm doing this, what could go wrong, where's the bottleneck? Where is the issue, what- what could be a problem?" So, instead of going line-by-line, maybe just walk us through your process of, you know, er, you've got a small team I hope helping you, [laughs]?
[00:30:04] Patrick: [laughs].
[00:30:04] Mark: this is all, you know, this is not building, you're stitching together a whole bunch of stuff, you know, how do you-
[00:30:08] Patrick: Yeah.
[00:30:09] Mark: ... why- why go on through this, what's the, what's the goal here?
[00:30:12] Patrick: Well the rationality is that a lot of the streaming solutions actually exist for, people who are doing it with a production team, on a single location, and on a location that has a stable internet connection, and that it is only run for a couple of hours. So, we're running for 24 hours on the livestream with three tracks, so that's three times the livestream with people across the globe who are all sitting at home with crappy internet, right?
[00:30:42] So, we can't depend on my computer to stream things out, we need somebody to take over if they have to, and, the same thing with the guests-
[00:30:53] Mark: Yeah.
[00:30:53] Patrick: ... if the guests aren't available, but, so all these, failing modes, and whether that's the streaming side for YouTube, you know, they put on their website there might be some irregularities, so better think of an alternative. So, we got Mixer as an alternative, and- and- and the other day when I actually, when I Tweeted that out, I was testing, because we're- we're, one of the options was obviously using Zoom to stream things in.
[00:31:20] Mark: Mm-hmm [affirmative].
[00:31:20] Patrick: And usually stream worked fine and everybody's happy, and all of a sudden I just couldn't hit the livestream button on Zoom for- for hours, and that meant we couldn't have any guests. So, we need that backup solution for onboarding guests. and then it just the- the list keeps going on, the alternatives-
[00:31:42] Mark: Mm-hmm [affirmative].
[00:31:42] Patrick: ... but I think it's finding a balance between having non-professional streamers running the show, being able to do a handover and not having to rely on a central point, or a central system, in case that, goes wrong, and that's kind of been a challenge. I've- I've tested quite a few tools, and also quite a few platforms, and, they are pro and cons, [laughs], yeah. Like, I didn't know, I, we- we had the DotOnline domain.
[00:32:11] Mark: Mm-hmm [affirmative].
[00:32:11] Patrick: That is another funny story, so I learned through, some people Tweeting me back, or not Tweeting me back that the DotOnline domain is actually blocked by some, er, URL blockers.
[00:32:24] Mark: Yeah,
[00:32:24] Patrick: And I did a test on Twitter, where I Tweeted the, all the talks handle together with the DotOnline URL, and it wouldn't show up for somebody else, because Twitter just would filter that out.
[00:32:36] Mark: Mm-hmm [affirmative].
[00:32:36] Patrick: And that explains why, I wasn't getting any retweets on stuff.
[00:32:40] Mark: Yep.
[00:32:41] Patrick: that sometimes I did, and sometimes I didn't, and like online wasn't, again it- it's o- one of those things you learn by doing, so.
[00:32:50] Mark: Yeah, yeah, yeah, and so, and I mean that's a good segway into- into where I wanna go next here with the conversation, but I think, you know, just to wrap that up, what I really want people to take away from- from your failure mode doc there, is that, you know, this is just a straight spreadsheet. Like it doesn't have to be complicated, it's the process, it's you walking through this stuff that's really important to map it out. you don't need a fancy database tool, like just writing it down on the whiteboard or on a spreadsheet is good enough, because it's the thought that really does count, [laughs], when it comes to that.
[00:33:19] Patrick: [laughs].
[00:33:19] Mark: you know, but in the good way, not in the like, "Oh, that's nice you failed completely, but the thought counts-
[00:33:23] Patrick: [laughs].
[00:33:23] Mark: ... like you don't wanna fail."
[00:33:24] Patrick: Yeah, we'll see next week Mark, [laughs].
[00:33:25] Mark: Yeah, oh, it's gonna be great. It is absolutely gonna be great, but, you know, the DotOnline thing actually comes out to, what I wanted to talk about, and where we first had our actual first in-person conversation, was, way in back in February, you Tweeted out the, I'm getting some transparency there Pat, so you can see it a little faded on the, on the stream, but basically you'd called out, asking to talk to some CISOs, and red teamers about, security, right?
[00:33:48] Because you- you have a long history in the development side, on Agile and DevOps helping, build the rest of the business and security's always somewhat excluded, mostly of our own doing, but what is y- what... I wanted to kinda, and that was the episode, the title of this episode, you know, Finding Security, I really wanna hear your experience, coming from that, such a strong development side, such a strong business side, starting your first journey in the security, you know, formally kinda thing, and doing that research, what'd you find?
[00:34:18] Patrick: [laughs], I found that the- the problem is new, right? [laughs], [
[00:34:23] Mark: laughs].
[00:34:23] Patrick: ... surprise, surprise. so I guess there's two things. There's the- the people who say, "Why do we need to have that SecOps, because security was always included in- in the discussion, right?" So, for them they, again they might be on a higher maturity level, so for them it's the lines have blurred, so they don't care too much. for others being, you know, if you start out only from the security community, I've found that they have the same failing as Dev and Ops had a while ago, like nobody understands us, and then we keep preaching to everybody, but nobody wants to listen to us, and we want them to care about us.
[00:35:03] So, it is the same kind of [inaudible 00:37:03], that is- is counter. one is less accounted for, and I- I started doing this exercise when people from the security told me, "Oh, so Dev should do this and Ops should do that." And- and- I'm not good, like, "Yeah," and, "Yeah, they should totally do that?" And- and then I asked them, "And- and why would they do that?" "Because they care." No, it just doesn't happen magically, so-
[00:35:32] Mark: Yeah.
[00:35:33] Patrick: ... this- this answer of, "We want somebody else to do something for us, but we haven't listened what they get back from it."
[00:35:42] Mark: Mm-hmm [affirmative].
[00:35:42] Patrick: And that's kind of something I- I missed in- in a lot of the conversations I had, in the, and, you know, er, responding to that Tweet again, somebody said, "Well, security people will never respond to that Tweet, because it's all hush-hush." truth is, kind of several people, responded to it, so that's a good sign-
[00:36:02] Mark: Mm-hmm [affirmative].
[00:36:03] Patrick: ... in like the- the- the one group that I didn't expect to kind of, reply to me, was actually somebody from the Department of Defense, [laughs]-
[00:36:11] Mark: Nice.
[00:36:11] Patrick: ... right? Okay, so I'm not saying I got all the, all the explanations, [laughs], on the Department of Defense, but they were saying, and that was what, that is a- an interesting thing, they said like, "Well, we are actually running Kubernetes on fighter jets, and part of our pipeline is to make things faster and respond-
[00:36:32] Mark: Mm.
[00:36:32] Patrick: ... and making it more resilient." So that's something I- I- I kind of learned, from that discussion. but the- the way I've seen it is that they want somebody else to do something, and, for me that whole discussion, moved towards the discussion of trusts. Do we trust the security person? Do we trust the Dev person? Do we trust the Ops person?
[00:36:54] Mark: Mm-hmm [affirmative].
[00:36:55] Patrick: Like, Devs want to trust the security person-
[00:37:00] Mark: Yeah.
[00:37:00] Patrick: ... but, he wasn't very reliable because he wasn't there at the stand-up. He wasn't really helpful getting it to production. He was saying, "No."
[00:37:10] Mark: Mm-hmm [affirmative].
[00:37:11] Patrick: So, there is a- a dance to be done by if you want people to trust us, we want to become more trustworthy, and that is can be shown by, being a- around more, talking to people, listening, making a good balance, on what's important, what's priority, and not just looking at our own kind of, you know, what we want to do and- and what we need to do, and that- that is, that narrative is kind of changing, so there is a willingness to collaborate, and a good example for, er, was threat modeling.
[00:37:46] They would say, "Threat modeling, the security people have, you know, asked that for the developers," do that in the beginning, you know, of every sprint, and do that all the time.
[00:37:56] Mark: Yeah.
[00:37:56] Patrick: but- but the value, they had a hard time articulating it, right? But, er, for some developers there is a value of learning the system, so-
[00:38:08] Mark: Mm.
[00:38:09] Patrick: ... for them it's a fun exercise. but it- it is also if you say, "At a personal level," become a better developer. But it, these are still kind of fluffy. If you said, "Well, you don't wanna wake up in the middle of the night because of a security breach," and then if you come back to the Devs almost b- being part of the Ops now, and running the show, then they have more ears to that. So, it's kind of finding what the other group is kind of, and I'm- I'm, I wanna stop calling them groups, but, [laughs], but more like, expertise.
[00:38:49] Mark: Yeah.
[00:38:50] Patrick: So, the same expertise can kind of go in one person-
[00:38:54] Mark: Yeah.
[00:38:54] Patrick: ... or in one group, and it doesn't have to be a group separate. It could be a role, somebody's playing the role of security today, the Ops person next day, developer the next day, and it isn't that much of the ac- the- the separation of- of, this knowledge or responsibilities, to go for, so.
[00:39:14] Mark: And it's- it's interesting that you say the, you know, so there's a lot in there to- to unpack, there's a lot of fantastic [00:39:20] stuff as a primarily-
[00:39:21] Patrick: I should pause more, sorry.
[00:39:22] Mark: ... no, no, it's perfect-
[00:39:23] Patrick: [laughs].
[00:39:23] Mark: ... it's great. I love that just stream of thought and, you know, as a security guy, I'd be sitting there going like, "Ugh, ugh," like, you know, because I- I hear it, and I understand. the first thing I wanted to tackle was that idea of groups, because I've done a lot of research over the last few years, specifically around security teams, and I think the fact that they are their own group causes a lot of these problems, because they're constantly firefighting. They don't have time to attend the stand-ups. They don't have time to build those, that trust relationship, and it makes their own job harder, but they don't have enough time to get above water to look and go, "Wait a minute, we're not working towards our own goal here, because we aren't investing in time in the relationships."
[00:40:01] And so hearing that echoed from your side is, you know, it's- it's confirming it's still a massive problem. but the other thing that really stood out for me there, was the explanation of the lack of explanations, you know, so when you said that, "The security person's saying, 'We need you to do this,'" but there's no, there was no support to it as to why- why was it a good thing, and I find that a lot, purely in the security world as well, where people they're, recommending things, or requiring things by [ROTE 00:42:39], without understanding what the trade-offs are.
[00:40:29] Right, so you absolutely have to encrypt everything all the time, while in an ideal world it would be nice, there are trade-offs there. There are, you know, there's performance, there's complexity, there's potentially cost, but not being able to articulate that is really difficult to get people onboard when you think you have some sort of trump card that just says, "Well, you need to do what I said." and did you see that, you know, so can you elaborate a little more on what you found, what you got the impression of sort of the personality profile was from the security relationship?
[00:41:00] Patrick: Well there this-
[00:41:01] Mark: Like just as far as the attitude's kind of thing.
[00:41:04] Patrick: ... Yeah, the attitude is n- actually again, no different from all the others, like, I know my domain best, right?
[00:41:12] Mark: Yeah.
[00:41:12] Patrick: Which is logical, but it- it- it kind of makes us, almost like that where you say, "Well, we're better than the others," right?
[00:41:23] Mark: Mm-hmm [affirmative].
[00:41:23] Patrick: Because we know this better. We're- we're better educated.
[00:41:27] Mark: Yeah.
[00:41:27] Patrick: But guess what, the- the developers are better at coding, [laughs], and the Ops's are better at running stuff, so, eh, this ego has to kind of go away, in- in- in a, in the aspect, and the egos go away if you start collaborating, and I- I wanted to add to the point of, "Yes, there are expertise, and maybe more of a role or a hat that people are wearing," but one of the- the- I think is- is a- an error people are making is that it has to be this, this poor full stack secure developer, right, [laughs], that has to know everything-
[00:42:05] Mark: Yeah.
[00:42:05] Patrick: ... right? And that is, that is closely impossible, and- and tying back to you, all the things that happened in your- your organization, like we discussed, before, like the discoverability.
[00:42:16] Mark: Mm-hmm [affirmative].
[00:42:17] Patrick: There is no way that you can know all the domains well.
[00:42:23] Mark: Yeah.
[00:42:23] Patrick: So the only way of approaching it, is that, you understand enough when to ask for help, [laughs], right?
[00:42:30] Mark: Yeah, because the counter to that is if there is somebody who understands everything about all the systems, I guarantee you have found the number one bottleneck to your velocity. Right-
[00:42:41] Patrick: [laughs].
[00:42:41] Mark: ... because everything has to go through that person to make it work, and that doesn't fly and, you know, it may have worked in '80s when we were building software, but it doesn't-
[00:42:49] Patrick: [crosstalk 00:45:07].
[00:42:49] Mark: ... anymore, right, and I- I mean, I think it's a good thing to not know everything, because it forces that collaboration as long as you accept that you don't know everything, and I think that's what you're getting at is that that's one of the hardest things, right is to, from the engineering pride perspective, to be like, "I- I don't know, I'll figure it out, or we'll find somebody who knows?"
[00:43:08] Patrick: Mm-hmm [affirmative].
[00:43:08] Mark: so-
[00:43:08] Patrick: Yeah, and I think that ev- even in hiring sometimes they say, "A good hiring strategy, is to hire people that know different or more things than you,"-
[00:43:20] Mark: Yeah.
[00:43:21] Patrick: ... because they take away worries.
[00:43:23] Mark: Yeah. So-
[00:43:23] Patrick: Right? And that's kind of, you know, you look at a, your- your whole team... don't hire the same people with the same background, with the same knowledge, with the same attitudes, like we talk a lot about diversity, but it's in that domain as well-
[00:43:39] Mark: Yeah.
[00:43:39] Patrick: ... applicable I think.
[00:43:40] Mark: Right, absolutely, you need diversity, mentally, right in that thought process. I remember, a long time ago, like 20-years ago, [laughs], I was working for the Canadian federal government, and the hiring manager, that I was talking to was like, "Yeah, I always hire people from this college program, who've taken this, who get above this grade," and, you know, we posed the question to him like, "Okay, well aren't you hiring a- all the people who think the same way?"
[00:44:03] Just because you've had success with one of them, that's great, and maybe a couple more, fine, but if you have an entire team of the same person, erm, you know, in an, like in a cookie cutter, you- you don't have any, you're very fragile, you don't have any resiliency, right, because it's, if something-
[00:44:17] Patrick: Yeah.
[00:44:17] Mark: ... happens outside of that person's scope, you're done.
[00:44:21] Patrick: Yeah, and they, I think it's one of the, so there's a, an upcoming book called Agile Conversations-
[00:44:27] Mark: Okay.
[00:44:28] Patrick: ... and, the nice thing about the book, and it's the only book I know is actually addressing the person-to-person communication issues that we have, within a business context. and they're saying, "Well, you know, I- I want to get, explain something to person B, but, yeah, I already have my opinion." No, so it's like, "How do I listen to the other person-
[00:44:52] Mark: Yeah.
[00:44:52] Patrick: ... and get better at, you know, pushing my things maybe forward, but listening and the- that feedback." And that whole dance is... like a lot of people talk about DevOps as, "It has an impact on the organization, the team level." but I also think there's a, on the one-on-one, you know, connection between people, and that's, you know, it's the people that build the trust. It's, er, and that's kind of where it becomes important that we have the honest conversations about what we're really saying, what we really want, what we really need to do, and not just leave that in the open and say, "Well, you know, we're gonna do it somewhere else. We're gonna go in the cloud, or-
[00:45:32] Mark: Mm-hmm [affirmative].
[00:45:32] Patrick: ... we're gonna g- solve this with this service, because the others aren't responding." And that- that is, that listening to that feedback is again a, a sign of, not being, overconfident, like-
[00:45:45] Mark: Yeah.
[00:45:46] Patrick: ... "Help me understand, help me," this- this vulner- making ourselves vulnerable to feedback is, is again, er, important. But I know for a lot of people it sounds like kumbaya, and I, and it's, [laughs], so yeah it's, there's a, definitely something to be-
[00:46:01] Mark: Yeah, but it's-
[00:46:01] Patrick: ... said, but I-
[00:46:02] Mark: ... it's true, right? I mean it's, the technology, you can get an answer on the technology, "This will work," or "This will not work," right, or-
[00:46:08] Patrick: ... Yeah.
[00:46:08] Mark: ... "It'll work under these circumstances," but the vast majority of this hard work, you know, really what you, what you're talking about it is- is listening with empathy, and communicating with empathy, to understand that, you know, I- I have yet to hit an organization with, well with very few exceptions where people are not trying to achieve the same goal, right?
[00:46:25] Patrick: Mm-hmm [affirmative].
[00:46:25] Mark: They're- they're not trying to actively work against each other, but because they're not listening, because they're not communicating in each other's languages, and, or in terms of the other person, you know, can understand, they end up in this combative situation, and you're like, "You're trying to do the same thing guys," like it's, it, er, you know, maybe [kumbayaie 00:49:09], but it's, [laughs], really all about that empathy, right?
[00:46:44] Patrick: Yeah, and I think a lot of the debate has been, within the DevOps community, maybe specific is about, it's not about the tools-
[00:46:52] Mark: Mm-hmm [affirmative].
[00:46:52] Patrick: ... right, they- they- they kind of say, "It's all about the culture." I'm somewhere, but again I'm- I'm more of a consensus figure, you know, being from Belgium, but, [laughs]. it's, like I think the tools influence the people, and the people influence the tools, so I- I don't think you can see them separate from each other.
[00:47:14] Mark: Yeah.
[00:47:14] Patrick: I think introducing a new tool can actually lead to a new mindset. It's no g- not a guarantee, and that's- that- that is what people mistake for, but the fact that you dr- introduces change, kind of, maybe requires you to change the process, you are thinking about the problem, and that kind of makes a good relationship, I- I saw, like j- John Allspaw made a, a re- a question to the audience at one of the conferences, he said, "What if you don't touch your systems for a day, will they keep running," right?
[00:47:48] Mark: Yeah.
[00:47:49] Patrick: There was like, "Okay, yeah, they, "How about a week?" And you see the au- audience getting nervous and they're like-
[00:47:55] Mark: [laughs].
[00:47:55] Patrick: ... "Hmm." Okay.
[00:47:56] Mark: [laughs].
[00:47:56] Patrick: "What about a month," right? And the- so that's the way he has proven-
[00:48:01] Mark: Mm-hmm [affirmative].
[00:48:01] Patrick: ... that we are part of the system.
[00:48:03] Mark: Yeah.
[00:48:04] Patrick: We are part of making it work, and it, not just the tools that are running, and I- I find that like a powerful analogy of, you know, understanding that, that's there's some truth, and interaction going on between both so.
[00:48:17] Mark: Yeah and that- that ties to a really good comment we just had on YouTube around, burnout, right? If you don't have that empathy component, people will burnout really, really quickly because the pressure just keeps mounting, especially with that idea of, "You need to do everything," right, "You need to be completely full stack." Erm, and, you know, it's- as much as it is clich脙漏, it's really is about the people, you know, so I wanna just shift gears a little bit, because this has been fantastic, you know, but we're- we're coming close to some time here, and I know you at some point are legally required to sleep-
[00:48:45] Patrick: [laughs].
[00:48:45] Mark: ... before this conference, next week. but we'd like to do a little section, just rapid fire questions. You gotta pick one or the other. No explanations, we'll circle back. little bit putting you on the spot for some stuff, but nothing- nothing career-harming or dramatic.
[00:48:57] Patrick: All right.
[00:48:58] Mark: ... yeah, okay. So, who do you think's harder to work with, finance or security folks?
[00:49:06] Patrick: I think security folks actually.
[00:49:09] Mark: Yeah, [laughs].
[00:49:11] Patrick: I'm sorry, but-
[00:49:11] Mark: ... no, it's, I- I get it, I- I sit here and I take it because I- I a hundred percent agree. okay if you could only pick one, so you can only pick one of these, integration testing or blue-green deployments?
[00:49:23] Patrick: Blue-green deployments.
[00:49:24] Mark: Okay. and we'll circle back to that in a sec. What's harder, starting a movement that's, er, transformed how hundreds of thousands of people work, a.k.a. DevOps, or organizing a 24-hour, three track online conference?
[00:49:39] Patrick: Definitely the conference.
[00:49:40] Mark: [laughs], that's insane, that is, [laughs], absolutely insane. All right, a little bit on the spot, especially if, the, other authors are, listening, best book in the series, Phoenix Project, DevOps Handbook, Accelerate or The Unicorn Project?
[00:49:57] Patrick: I would say The Phoenix Project.
[00:49:58] Mark: Hmm, okay, interesting. and because I saw you put an entire track in all the talks, DotOnline conference for Java, I'm gonna ask you this one, what's the best candidate to displace Java, Go or Python?
[00:50:17] Patrick: I would go for Python.
[00:50:19] Mark: Interesting, interesting. Okay, I gotta ask, why, why Python?
[00:50:27] Patrick: Oh, because Python is, a f- well, my understanding is that a tooling around Python currently is in a, a higher evolved state than the Go s-,
[00:50:41] Mark: Yeah.
[00:50:41] Patrick: ... well language. I don't mean that it's, Go isn't a, er, isn't a good language-
[00:50:46] Mark: Well, no-
[00:50:46] Patrick: ... I mean, I love it-
[00:50:47] Mark: ... yeah.
[00:50:47] Patrick: ... but it's- it's like, Java is Enterprise, so it needs a little bit of maturity level, and I think Python gives that more than Go-
[00:50:54] Mark: Yeah.
[00:50:54] Patrick: ... that's my reasoning.
[00:50:55] Mark: Hundred percent fair, hundred percent fair. Phoenix Project for your book selection, I assume because it kicked it all off?
[00:51:02] Patrick: I think Phoenix Project, explains the, like, first of all, I liked the narrative of the story, that Gene has done there-
[00:51:12] Mark: Yeah.
[00:51:12] Patrick: ... but I- I think it- it's shown the- the seeing the system, better than The DevOps Handbook, which was kind of a little bit, a lot more evolved, and, er, I think the other one was, everybody could read The Phoenix Project-
[00:51:26] Mark: Yeah.
[00:51:27] Patrick: ... without, you know, doing that. So that's why I liked it better.
[00:51:29] Mark: Yeah, and that lines up with my experience where I highly recommend everyone in the technical side buy the book, and read the book. in fact at Trend we did that for our entire, our engineering organization, we got them all the book, just to get them on the, on the same page for The DevOps Handbook. but The Phoenix Project is the one that I recommend to anyone in the company. So it's like, "Oh you're-
[00:51:48] Patrick: And there is a-
[00:51:48] Mark: ... Sorry.
[00:51:49] Patrick: ... there is a graphic novel of that.
[00:51:51] Mark: Yes.
[00:51:51] Patrick: Which is also cool.
[00:51:52] Mark: Yeah, and the audio series after and the conversations do, but yeah, I like that accessibility, I think that really, you know, it explains what, because for the longest time, people who think as IT as cost sync, and it's something that, you know, they have to put up with and The Phoenix Project really explains that like, "Hey, we're trying to move things forward, here's the challenges, here's where we're going in the future and," I really like that accessibility.
[00:52:13]so last question for yah, a easy one hopefully, because this has been fantastic. I very much appreciate you taking the time, anytime, let alone in the midst of organizing-
[00:52:21] Patrick: You're welcome.
[00:52:22] Mark: ... all the talks. picture yourself two weeks after, the conference. So the conference is April 15th. again the link is in the show notes. sign up. it is free to attend, but a di- a donation is highly recommended, and again, the donations are going to the WHO, right?
[00:52:36] Patrick: Yes, correctly, yeah.
[00:52:37] Mark: Perfect.
[00:52:38] Patrick: And sponsors also still welcome, so.
[00:52:40] Mark: Yeah, absolutely, and so, you know, I, full disclaimer, Trend Micro's one of the sponsors, but all that means is that we get our logo and we're donating money to the WHO as well, and everybody absolutely should come together in this difficult time. but personally, for you, you've been going crazy organizing this. The community appreciates it for sure. The event is gonna be amazing. Two weeks after, so end of April, looking back at the conference, what would be the biggest metric of success for you personally?
[00:53:09] Patrick: And this might sound a little bit strange, but, er, I- I think a lot of the talks people kil- w- will probably be able to pick them up later-
[00:53:18] Mark: Mm-hmm [affirmative].
[00:53:18] Patrick: ... so for me the personal goal has been, the more money we raise, the better. we- we kind of have a goal, but, [laughs], and then we have a stretch goal, so it's gonna be interesting if we can get l- you know, somewhere close to that, [laughs].
[00:53:35] Mark: Well, that's good, because that-
[00:53:35] ... I mean that for me-
[00:53:36] Patrick: ... yeah-
[00:53:36] Mark: ... that's a, that's a metric that reflects the community side of it, right? Like of people coming together-
[00:53:41] Patrick: ... yeah-
[00:53:41] Mark: ... and realizing that we can do something positive, er, as a community, and to support our larger community, right? So that- that's a fantastic way to look at it.
[00:53:49] Patrick: ... yeah, and I think obviously the, you know, the number of people that will come and watch, that's- that's cool and- and- and- but, to be, that is probably like a vanity metric, what- what really counts is that we can kind of donate, and kind of help the people in need, so that's- that's what got me onboard on doing this as well, so.
[00:54:09] Mark: Well, I think given the all-star roster you've got lined up for speakers, the fact that people are gonna come and consume the content is just a given, so, you know, it's nice to have that- that human side as the metric, so with that Patrick, thank you for taking the time, this has been an amazing, amazing, discussion for me. Hopefully the audience has enjoyed it. again for everybody, watching at home, follow Patrick on social... that'll be in the show notes as well.
[00:54:30]but please support all the talks, a conference on April 15th, we've got that link. obviously it's all the talks at DotOnline, assuming that works for you, and, thank you Patrick, we really appreciate it.
[00:54:42] Patrick: Well, thanks Mark for having me, it was a, a fun, way to, you know, end my day, so I appreciate that, [laughs].
[00:54:47] Mark: Perfect, thank you.
[00:54:48] Patrick: [crosstalk 00:57:48].
[00:54:48] Mark: [crosstalk 00:57:48].
