DOP 100: Course Correcting DevOps

Show Notes

#100: In our 100th episode, we bring back Patrick Debois, the GodFather of DevOps (at least we think so), as our “divide by 50” guest. In very Patrick fashion, he turns the tables on us and we go down a number of paths that we didn’t see coming.

Guests

Hosts

Links

• DevOps20 Slack Workspace

Rate, Review, & Subscribe on Apple Podcasts

If you like our podcast, please consider rating and reviewing our show! Click here, scroll to the bottom, tap to rate with five stars, and select “Write a Review.” Then be sure to let us know what you liked most about the episode!

Also, if you haven’t done so already, subscribe to the podcast. We're adding a bunch of bonus episodes to the feed and, if you’re not subscribed, there’s a good chance you’ll miss out. Subscribe now!

Transcript

Patrick: [00:00:00]
That's why I think before somebody asks you how should I start my DevOps transformation? Okay. What's your mental model? Is it are you still in the castle or you're in the factory and no surprise the factory and the metrics are where a lot of the transformations get stuck.

Darin:
This is DevOps Paradox episode number 100. Course Correcting DevOps

Darin:
Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darin and Viktor, pretend we know what we're talking about. Most of the time, we mask our ignorance by putting the word DevOps everywhere we can, and mix it with random buzzwords like Kubernetes, serverless, CI/CD, team productivity, islands of happiness, and other fancy expressions that make it sound like we know what we're doing. Occasionally, we invite guests who do know something, but we do not do that often, since they might make us look incompetent. The truth is out there, and there is no way we are going to find it. PS: it's Darin reading this text and feeling embarrassed that Viktor made me do it. Here are your hosts, Darin Pope and Viktor Farcic.

Darin: [00:01:18]
Episode 100, Viktor.

Viktor: [00:01:20]
Does it mean that we are old or what?

Darin: [00:01:23]
Well, we always talk about you're old, but I'm ancient, right? That's ongoing joke.

Viktor: [00:01:27]
You're beyond old.

Darin: [00:01:29]
Yeah, but episode hundred. Did you think we would ever get to 100?

Viktor: [00:01:34]
That question would assume that I actually plan for the future and think about what's going to happen next. I don't. So.

Darin: [00:01:40]
Of course and as we've talked about in a number of places, we were trying to get Patrick back to be our divide by 50 guest and he thankfully said, yes, Patrick, welcome back.

Patrick: [00:01:55]
so Darin, if you're old, I'm the dinosaur, right?

Darin: [00:02:00]
I'm older than you.

Patrick: [00:02:03]
Well, you know, we could be dinosaurs together

Darin: [00:02:07]
At least we haven't turned into oil yet. So we're still on this side of dinosaur.

Patrick: [00:02:12]
Sounds good to me. By the way congratulations A hundred. That is amazing. Well done.

Darin: [00:02:17]
Shocking and you'll be back in another 50

Patrick: [00:02:19]
Or did you start at zero?

Darin: [00:02:21]
We actually do have a zero but that we

Patrick: [00:02:23]
Oh

Darin: [00:02:23]
We don't count that for Look do that's like saying did the decade start in 2021 or 2020. With an episode zero, it was 30 seconds long. Yeah It doesn't really count

Patrick: [00:02:35]
You started in Java right Viktor?

Darin: [00:02:39]
In Java

Viktor: [00:02:41]
Hey I haven't seen Java for quite some time now, so don't jinx it.

Darin: [00:02:46]
Kotlin

Patrick: [00:02:46]
well done by the way

Darin: [00:02:49]
Okay So in case people Patrick do not know who you are, introduce yourself and then if you want to go back and listen to Patrick's old one, divide 100 by two and that's his first episode. I guess technically you should have been the zero one too, if you're really the divide by 50.

Patrick: [00:03:05]
Maybe I was. I dunno.

Darin: [00:03:08]
All right. Anyway, who are you Patrick?

Patrick: [00:03:10]
I'm Patrick. I think over the years I've done many roles. Developer, ops, manager, no manager, and while looking for a better way of collaboration people know me from starting devopsdays which is also like 10 years ago, 10 plus one year ago and then since then I did a few things. I start my own company totally unrelated in live streaming and now these days I work as an advisor for Snyk. I'm trying to figure out what DevSecOps could be in these days.

Darin: [00:03:46]
Just in case you don't know what Snyk is say it and say okay. Pronounce it for me correctly at least from your perspective. Is it Snyk like Snickers a Snickers bar or sneak like I'm sneaking around?

Patrick: [00:04:00]
So it's actually a marketing stunt. Nobody knows and then because of that, we say it five times.

Darin: [00:04:08]
And you say it five times differently each time

Patrick: [00:04:10]
Yes because that gets more promotion. So I say Snyk. Snyk.

Darin: [00:04:16]
You say Snyk. Okay. In case you don't know what that is S N Y K or if you didn't know how to spell it it's S N Y K and then you can go off and go do that yourself. We may talk about it a little bit more but we're not here to talk about that for the real reason we're here and you said you've got a live streaming side business. I want to get there while we're talking about this as well because we actually play one on YouTube. Live streamers or we attempt to. But let's talk what you're doing right now. If you haven't followed Patrick on Twitter, you should. Number one. Number two what he's been posting about recently at least from my perspective has been interesting. He's been doing a lot of reading and scarily enough, it's not fiction, or is it?

Patrick: [00:05:02]
No, well you know, I have a weakness for books because they get me up to speed much faster than reading blogs and searching the internet. So I tend to just buy lots of books and I think what I'm interested in while researching the books and funny enough I didn't have a plan like Viktor I didn't before I started reading books. I just have you know this will look interesting. It's only after reading some of the books that they started to fall in place, was like how do you make sense how people are starting let's say DevSecOps transformations. What do they go through and what happens all the time and that went in all directions from Hey what is a strategy to Hey we kind of measure things. Why are we so bad at measuring things over to why do we hate when we measure things and then it became things like what if we changed the whole control system of management like what blocks us from self-managing teams and I just kept reading and reading and then I came into resilience engineering then back to SRE and so it just kept going and now it kind of have a better or let's say a different mental model than I had before where it was just like people do a bunch of stuff and now I think there is a logical progression in why people are doing stuff. For those who like reading, it is a book by Frederic Laloux which is called Reinventing Organizations. That was the book that made it all click for me. Not surprisingly it just tells you that part of your transformation the success is how you structure your organization and that's the cliffhanger. I dunno if you've went or heard about any transformation what sticks out for you mostly in their journey. MarkerDarin: [00:07:01] What you just said is a variant of the teams will organize to the structure of the company which seems obvious but it goes much deeper than just an org chart. Systems will start aligning to the structures of the company whether that's good or bad. We've been talking a lot about event-based systems and I can think of near zero companies that are structured in an event based way. It's still very much command and control in most places.

Patrick: [00:07:30]
Yeah. There are some more organic structures for companies that are emerging a little bit where I guess part of the event driven it's not my area of expertise but I would assume part of it is like the loosely coupling of push and pull. Right? That sense there. So Viktor why don't you enlighten us? You're the expert.

Viktor: [00:07:54]
I mean from technology perspective it's all about announcing something. Hey, I just did this. I don't know whether you want to do something with that, whether Darin wants to do something with that or nobody wants to do something with that. My job is to announce Hey I just finished this. Make an announcement and I'm really using non-technical terms. Then somebody might listen to me or not. To me that somehow also is very linked in how companies operate or not operate. We are somehow on an organizational level, on a human level, we are trying to always design that sequential set of steps. Hey it needs to be first that Joe comes and writes a document about this and then comes Mike and he does this and then comes Peter. We are very much focused I don't know whether that's the software industry or everywhere on trying to organize things in a very command and control sequential type of organizational structure and to me what is surprising both on human level and on technology level is that outside of our professions we do not work like that. You send a email to somebody and you forget about it. I mean sometimes you don't but most of the time you do. Then you might receive a reply or you might not. It's very decoupled. It's very desynchronized. How we operate in real life. You go to restaurant and say Hey I would like a burger and you don't follow a guy to the kitchen and breathe behind his back. But then when we organize companies somehow that doesn't work anymore for us. We need to have that Hey I need to know who is the person A ,who is the person B and who comes after person B.

Patrick: [00:09:35]
It reminds me, so you know me reading the books, it reminds me of this phase if you have something like self servicing, that is different from a driven pipeline you have to accept, like somebody's pushing it through your throat. Here's a self servicing platform. You can take it or not. The problem is I think in a lot of the companies it is you have to take the pipeline. It's like there's there's no kind of like freedom to do something next to it because you might not agree or you do something different. So I think self servicing in a way could be using good. Hey you could do this or you have to do this and that seems to be the struggle you're mentioning as well with the event streams.

Viktor: [00:10:20]
Yeah. I have a real problem with you have to do this because usually it is followed and you're responsible for it. To me, those two things are very much clashing. You can say that I'm responsible for something but you cannot tell me that I need to do it in this way because then you're taking away that responsibility from me. You can also say Hey you need to use that pipeline or whatever you mentioned but you cannot then have me accountable for that. Accountability, responsibility for something needs to be followed by freedom to do it the best way I can or want to, which does not exclude that I shouldn't use your expertise and your services or whatever that is but that type of command and control and also holding somebody responsible to me is very problematic. Now I don't know whether that's me and my character and way of thinking but to me that makes no sense in a way.

Patrick: [00:11:15]
Yeah. So coming back to the book that made me click they say the first step is we're right in the middle ages. We're building fortresses and we're trying to protect everything. This is the thing we do. Then they said well maybe we need to do a little bit of this automation stuff and we are building factories to make weapons or things for good. Then came the moment that we're going to measure and you have to fill the metric and deal with the metric. But after that, the self-servicing came as a model. People can use our services, can use the platform, but the next step is what you see in the company structures is they say you have to solicit everybody that you interact with and you should ask them all for advice but ultimately it's you who decides. So that is a totally different way as you saying because the control is so hard in this hierarchy model that we've been using so long in a company that flipping that control to the one who's doing the work, it's like contradictory for many companies worldview. That's why I think before somebody asks you how should I start my DevOps transformation? Okay. What's your mental model? Is it are you still in the castle or you're in the factory and no surprise the factory and the metrics are where a lot of the transformations get stuck and then the self service thing, they sometimes get it through the services or the SaaS platforms but the last mile is hardly ever done. Make the team decide for themselves but make it mandatory for them to ask for advice. What I also see, the little that I know from the event streaming or the queues and SOA that I've used, the one thing we're really bad at is the dead letter queue where all the exceptions that happen that. What do we do with that and that sounds to me a little bit what resilience engineering is doing. What if we don't know what to do with it? How do we deal with this? I read a few books on eventing but this is something that is left in the open for an exercise for the users to solve. How do you think about that?

Viktor: [00:13:36]
I'm not sure. I think it's even a broader problem than really eventing. It's simply that we are having those maybe on a surface opposing things that at one hand we are trying to enable teams to be self-sufficient. I think smaller teams. You're in charge of this application but on the other hand, systems are getting more complicated, more complex. At the same time, impossible for any single person or a team to comprehend even what's going on. Honestly, I don't have the answer because I do want to be self-sufficient. I do want to have certain responsibility and autonomy to do things but on the other hand I'm aware that there is no way on earth that I will ever understand more than a percent of a serious system. I don't have the answer but the only thing can be that at least the high-level direction is that me being responsible for something whatever that something is does not mean that I'm alone. There is a whole company. There are different expertise in a company and I don't have to know Kubernetes to deploy to Kubernetes or I don't have to understand intricacies of networking to use networking in my application. I just need that to be part of my responsibility and I can find the person who knows. I can use somebody's service. There are many many things that I can do without really even going deep and understanding everything because nobody does. It's almost the same thing to me as voting. We all go I mean not all but many of us go and we vote for certain party. None of us really not none 99% of us do not really know the whole program and everything that they stand for and that they will do and stuff like that. It's more about gut feeling and then correct as you go. Kick them out after four years or whatever the rules are. Now I'm rambling. I don't even know what I started talking about.

Patrick: [00:15:22]
I think what you're saying is you can't oversee the full system. You want to do your best at the part that you are taking responsibility of. It's not somebody who pushed the responsibility. You want to take the ownership of this but then what do you do? I'm guessing you're going to reach out to the people who depend on you and the people you depend on start having a conversation right?

Viktor: [00:15:48]
Exactly. Exactly. That's the only thing that comes to my mind. That's not even for events or even for software systems. It's even for a company as a whole. CEO, CTO, they don't know everything going on in a company. They can never know. They're still responsible for the future of that company but when they're doing their job well, they know whom to call. They know whom to ask for help when part of the company is misbehaving not doing whatever they should do. I feel that it's kind of hard for us as people that that act of asking for help. I don't know maybe it's some pride you know kind of like I don't want to admit that I don't really know what the heck is going on. What is that Kubernetes thingy or VPCs?

Patrick: [00:16:30]
Could it be the fact that we've always been rewarded when we did know and punished when we didn't know so that like we're like having that behavior and we can't just say I don't know. Is that part of the problem do you think?

Viktor: [00:16:46]
That's definitely not necessarily everywhere but that's definitely part of the problem. I wouldn't say that we are rewarded. I would invert it. I would say that we are punished for mistakes and not sufficiently awarded for successes. We are trying never to show the weakness and never to make a decision that might result in a failure, even though the decision might propel the company to be from 10 million to 100 or whatever. But fear of punishment rather than looking for a reward I would guess.

Patrick: [00:17:18]
I must say for me, it gets better when I get older. I'm like whatever. I'm gonna do my best and I'm going to speak as it is and probably that's a luxury position because I earned my living already alive and can make and feel that I can speak more openly about things that I see, that I want. Personally I don't need to level up to high level management so I can just speak freely my mind, but it's nice to obviously have an environment where that's appreciated otherwise you're like shutting down quite fast I guess.

Viktor: [00:17:53]
When you do those things you produced, I mean assuming that you know what you're doing, you produce value, so that is usually appreciated. It requires a certain level of confidence in yourself and especially in your value in the market. I'm speaking now for myself. I have no problem saying exactly what I think, no matter who that somebody is in company, among many other reasons because okay so what's the worst thing that can happen? There is a higher demand and offer in our industry. You can fire me and then two weeks later, I will have a new job. It's not that I'm looking for a job. It's not I want that to happen, but when you have that security that you know that I can do what I think is right I can say what I think and there are no repercussions that can be done to me.

Patrick: [00:18:39]
So what would help you or what has helped you in the past to have that security besides you yourself having a splendid reputation for swearing and

Viktor: [00:18:53]
Honestly I don't know. It just happened or it was always there. I dunno. I think that my problem might be overconfidence but I don't think actually that that's only me. When I look at generally the working conditions and the salaries and the many different aspects of our industry, software industry, they tend to be much higher than most other industries. In which other industry you can work by using skateboard to move around the office and having a ping pong table on which you spend 50% of your time. I mean I'm exaggerating a bit, but those are all the conditions that I think were silently requested by people because maybe a bit more confident in our industry than in others that that demand and offer working in our favor in a way?

Patrick: [00:19:42]
So can we make our event queue more confident? What would that take

Viktor: [00:19:50]
What would that be?

Patrick: [00:19:52]
The signaling from others I guess. It's like you said. The signaling is probably important.

Viktor: [00:19:58]
It's more about the whole thing about Hey waiter give me a burger and then it happens. It needs to be that tiny tiny level of synchronicity that eventually you might time out after half an hour and say okay so he didn't hear me. Something went bad there. I don't know. Kitchen burned down or something Right Uh

Patrick: [00:20:20]
Feedback

Viktor: [00:20:20]
ed.

Patrick: [00:20:21]
Sounds like feedback. Timely feedback.

Viktor: [00:20:24]
Exactly. It's again that individual responsibility or process level responsibility or team level responsibility that Hey even though I announced my intentions or what I did and what so not, it's still my responsibility to make sure that something happens. You cannot just simply blindly pass that responsibility to others and say be completely event driven right? Kind of now I forget Right

Patrick: [00:20:50]
So this brings me to something. We demand a lot of things from others. If you're on the queue and you're accepting you want others to do stuff but what do you think we should do ourselves to others? How do we become more susceptible for others or how we can we help the others in that? Maybe Darin you have some ideas on that.

Viktor: [00:21:12]
Yeah I'm going to pass the ball to him because I'm the person who tends to work best alone. 10% of my time I take my head above kind of like okay okay and come back to my cave.

Patrick: [00:21:25]
Well you know you can flip the chart and just say what you expect from others but then you have to do it yourself as well and why is it so hard then?

Darin: [00:21:31]
For me the hard thing is I'm used to working by myself Every role I've for the past 25 years I've pretty much been by myself and not in a big team. So how do you get other people to work without telling them what to do? This is the thing that I don't like. I've seen these goings arounds of this is how I work. I'm publishing how I work and how you best interact with me. That's no different than telling people what to do. In fact it is telling people what to do. You want to work with me? This is how you have to be. I don't think that's effective even though I'm not used to working in I say I've never worked in teams I have but usually two or three people. It's not like large teams.

Patrick: [00:22:17]
You did a hundred episodes with Viktor. That's that's tough right

Darin: [00:22:22]
All I have to do is it's actually very simple. It's. All I have to do is I start it off and then he talks for 35 minutes then I say okay thanks

Patrick: [00:22:32]
sorry for turning this into an interview of both Right like hijacking the

Darin: [00:22:37]
this is what you did to us on episode 50 as

Patrick: [00:22:40]
sorry So

Darin: [00:22:41]
should have thought about it Yeah It's a pattern in I should have caught it before now

Viktor: [00:22:46]
But it is a hard one because it's similar like even whole societies. Most of us are striving to be individualists. We want to be able to do what we want. You can walk naked if you want or vote for whomever you want. We want that level of individualism but we also know that that individualism works only until it starts clashing with social norms, whatever those norms are. It's the same thing in a company. I think that everybody should work in a best way that fits them personally but that does not mean that you should start throwing people out of the window. I mean I'm exaggerating. It's very hard to find that balance especially and this is the part where I have real trouble especially when those social norms or company norms happen not to fit me. I honestly don't know where is that balance where how much you should be you and how much you should comply with norms of the environment where you are.

Darin: [00:23:44]
Let me take it somewhere right now and I'll throw myself under the bus. It's not a secret that I don't drink. Right? That's just not something that I do. Let's just say in college I did one time and I woke up the next day having no idea where I was. That was very unsettling to me. So at that point, it was all over. It's also not surprising in the time to where we could travel or we would have company gatherings and everybody go to the bar. I can't go hang out in the bar. Just because I. It's not even a temptation for me to drink but I just can't be around it. It takes me back to a place where I can never go again and that's sort of probably a very dark place. Most people haven't heard that dark place of me. That's a line I can't cross. So how does that fit back into an organization? Some people may not be comfortable working in a 50,000 person company because they have been used to working in the less than a thousand or the less than 500 or the less than 50 company and all of a sudden they get into this larger organization whatever larger means to them and they're completely dysfunctional because they don't know how to deal with what a social norm is in that case. In my case, the social norm is Hey we've got a big sales thing going on. Let's go to the bar afterwards. Yeah I'll drop by. I'll get a club soda but I'm out in like 10 minutes. I just can't hang out. I think the social norms thing is a very interesting angle on this because for some people it's just I don't get this or especially in the States and I'm sure it's the same way in EMEA. I'm from the South. I don't relate with people that are from the far Northeast or the far West coast because culturally everything's very different. Same way. People come here. What is this NASCAR thing where people race around in circles for hours on end?

Viktor: [00:25:49]
Yeah What is it

Darin: [00:25:52]
Look this podcast is not long enough for me to get into because I could tell you that because even even at this point my mom she's 85 now. She doesn't watch NASCAR but she lives in a town to where the 80 I think it's 85% of all NASCAR team shops are in that city So she can name off a lot of the drivers and the teams. Like Oh yeah I drive by that shop when I go to the grocery store. I drive by that shop when I'm going to get my hair done because it's just cultural in that area. It's I don't know you. Talk about going off the rails right now I've taken us way off the

Viktor: [00:26:34]
I have a question that goes in a completely unrelated with all this but something you said at the very beginning Patrick. You mentioned DevSecOps. Okay. Is there a maximum number of words we will put in there? DevTestSecOps?

Darin: [00:26:51]
Is it is it just as Dev*Ops now? Is it a wild card?

Patrick: [00:26:55]
Well I'm guessing the Well I was going to say the limit is the tweet but it's probably if you can point a URL to it, there's no limit. The other day I got this was let's say I would say bashing buzzwords and in a way we like to bash the buzzwords and say DevOps, that ship has sailed. Agile that ship has sailed. Now it's like DevSecOps, DataOps, AIOps, FrontEndOps. I learned TestOps exists. Whatever that number and I understand that people are really fed up with like come on like GitOps? Is this the new next DevOps thing? Every time that happens and my answer there was they're all interesting ideas and we shouldn't confuse ideas with implementations and marketing abuse. I'm not saying marketing is bad but sometimes it is used in a way that they don't really understand the value of the idea they're bringing. They're just trying to get everybody this is the next thing. We're cool by proxy. If you look at a lot of these ideas they do make value of and the way is that they're a different lens to look at the problem. You could say DevOps and DevSecOps, they're the same. Then StarStarOps and WildcardOps and even wildcard in general, but I think when people say BizDevSecOpsTest, that's also even value because there's an integration with the business. It will just keep on happening because they are useful but I guess my advocacy is just that we should look behind and see the real idea and look at that value. It's been helpful and I think DevSecOps the same ideas but DevOps was agile and agile was something else and we can go back in time and say this is a similar idea but the fact that these things got that label because I always said like DevOps was a good label because a lot of the stories were surfaced for that idea and that lens. The same is happening with DevSecOps. We get lot more noise as a word gets more used but that label is the value that like Oh there's people doing this. This is what happened. We can relate to this. GitOps is good in a way that it's structured the Kubernetes flow. It's a flow. It's not the flow. A lot of people see it as the flow but it's a flow that is at least documented and could be standardized, used by others. I would personally have seen it more integrated with the human level and the psychology of all the discussions happening at the git merge but it has been a useful lens, like what if we can cut out and do everything automatically. It's the same idea as continuous deployment but it's kind of putting this lens on well if you use Kubernetes, what can you do to get this thing done? I don't know if that makes sense Viktor to answer

Viktor: [00:30:01]
And in my case I think so now there is a marketing element of inventing random stuff that just you know because it's popular. I'm going to ignore that for a moment. To me what is very useful with new terms and I. Don't get offended but I don't see DevOps being much different than Agile. Me .That's me and DevSecOps much different than DevOps and GitOps different than continuous something. What I think it is the part that I think is different and that is resetting the expectations in a way I think that the terms become polluted over time. If I go back long time ago when we had SOA, to me microservices and SOA is conceptually very similar, if not the same thing. We needed the term microservices because over time, SOA became something else. Sometimes that's something else is better. Sometimes that something else ends up going down a wrong path. So I see those new terms that are iterative improvements on one hand but also putting back people on a right path at the same time because to me after let's say five years almost every term in industry gets as much negative practices as positive and then we come up with a new name. That's the positive part I see in that. Not as if new name is exactly the same. When I said DevOps, I'm a fully aware it's not exactly the same as Agile, but to me that's all evolution of something. We are evolving and we need a name to call that some evolution somehow because nobody said in my head nobody ever said those 17 or whatever number of people that met at the mountain to come up with manifest, they never said and you should never include operators in your stories. That was never said but that's how it was understood in a way. So I see it as resets. Positive resets in a way and iterative improvements. I don't know whether that makes sense. I'm not trying to offend now.

Patrick: [00:32:11]
I think what you mean is it it resets a little bit of your lens or your view on the problem?

Viktor: [00:32:16]
Yeah my view but also that marketing pollution that is happening around good stuff. We get something good. Good idea. Whatever that idea is and then over time, that idea evolves in both positive and negative directions. To me, those new terms are resets of those negative implementations or a

Patrick: [00:32:37]
like

Viktor: [00:32:37]
correction and I was looking for a word. Course correction. Exactly

Patrick: [00:32:42]
Hmm but it depends on whether you believe in the new course, yes or no, of course.

Viktor: [00:32:47]
But that's why we have 17 new terms every every two months. Two of them survive. 15 don't and one of those two end up living longer than a year Right

Darin: [00:33:00]
Well at least that's a number that's lower than the number of JavaScript frameworks day.

Viktor: [00:33:05]
It's similar like when I hear continuous testing. A lot of people were speaking still speak about continuous testing. On one hand, I like it because I understand what you mean by that. So I like that you're saying continuous testing because I can get immediately a picture in my head of what you're thinking. On the other hand then I get disappointed. Are you saying that continuous integration didn't include tests, so now we need something else? I don't know. I get mixed feelings. One day, I'm mad and the next day, I'm a very positive person.

Patrick: [00:33:35]
Imagine we would not have any new buzzwords or new ideas. That would be the worst. I'd rather live with new ideas that after a while turn a little bit more polluted than having none and and I think being able to read from the original intent and understand the original intent in the original setting does make sense. Context is not only the thing but it's also the time. The ideas that live in a certain time whether they make sense yes or no. Coming back maybe to the factories. The factory was a different time than we're living now and now people want to have a meaning where they work. It's changing. The industrializations of the Googles and so on now they have to be conscious of energy, diversity. We're putting more meaning in the way we think about these companies. Remember the ICE thing with the Chefs pulling the library away because it was used by ICE. So people are getting into a different mode of this but this couldn't have happened years ago. It was not done.

Viktor: [00:34:39]
But my issue with that is let's say if I go back 20 years when they came up with agile manifesto I had the feeling that for first five years when somebody says agile I understood what it is. As the time passes I think it becomes so much more encompassing of basically almost every term becomes over time it can be anything. The core value I think between catchy names like GitOps, DevOps, Agile, whatever, is that I can say a word or two words and we already exchanged 15 minutes worth of explaining what I really wanted to say. It's a very good way to communicate because it allows us to speak faster. Hey I said GitOps. You know what I mean. It would take me 20 minutes to explain what it is.

Patrick: [00:35:28]
So I feel guilty in a way. People from the first devopsdays have asked me to write a DevOps manifesto and I said Agile has written manifesto. After five years people misunderstood it in several ways. ITIL has written 12 books and even that wasn't helpful at a time because everybody thought it was about ticketing systems and change advisory boards where it was way more and well-intended as well. So DevOps wasn't written and I can't speak for DevOps as a whole but in the devopsdays, we always said we're going to expand the idea so we don't want to hear the same thing over and over again and let it expand. But then in a way you could say that also polluted because everybody could bring their own stuff to the table and now we're back to you can't organize or orchestrate this thing because it's a community. I might not agree when people say DevOps is equated to only deployment and cloud native but somebody else thinks and the majority is agrees that it's cloud native and deployment but what are you going to do? I'm glad I don't have to do anything because it doesn't make sense. This is what we all want to build up, like a meme. You learn it and then the next meme comes in.

Viktor: [00:36:43]
But that's also related with that typically people who are closer to the edge and let's say that edge now is cloud. Not that not cloud is bad but they tend to adopt something traditionally faster than others. You just said something that I initially didn't want to comment. GitOps. Kubernetes. No. Heck no. It's absolutely not. Now 99% of implementations are Kubernetes based something something, but the whole idea about GitOps is not really I mean it could just as well be called VersionControlOps, it's just that we have no other version control than Git. It can just as well be done in VMs or on-prem or whatever you want. Doesn't matter.

Patrick: [00:37:25]
Well, yes and no. It does need to have branches because it is in a way that I think the merging model of Git represents the idea of fork, work on you, and come back, which is harder in other older models I think on the version control.

Viktor: [00:37:45]
Yes. Now we're going over time. It really depends whether GitOps is the definition that we can say Hey everything is stored in Git. Whatever is in Git is the desired state and then the actual state and I don't need branches. There is nothing that I need branches or pull requests to do GitOps. I can be trunk based development GitOps and then you say no whomever doesn't create pull request is a horrible person. Should burn on a stake or something like that. Those are the types of conversations that are frustrating on one hand but on the other hand those conversations are what creates those iterative

Patrick: [00:38:24]
So good practices versus common practices? Good ideas versus common ideas?

Viktor: [00:38:29]
Oh best practice. I I lose a bit of hair whenever somebody says best practice because you know, I fall into similar generation as you guys. My brain has associated best practice means that something needs to be done this way for the next 50 years. That's how we were taught about best practices. That's why, whenever I hear it, I go wild. Today, that's the best practice and we've got TikTok tomorrow.

Darin: [00:38:55]
Best is completely environmental. Okay, just with these couple of minutes because I know we're almost out of time. Patrick, you said you had a livestream thing going on. This whole past year when we talked last it was probably February of 2020 or it was March something like that. In other words, the time that we do not speak of had just started.

Patrick: [00:39:21]
Yes but I actually meant something different. Before the beginning of last year I actually had a company for four years with that live interactivity and live streaming. So that's what I wanted to mention but I did learn some things like run an internal conference versus a community conference.

Darin: [00:39:39]
Yeah so that was interesting because you did all the talks online last year and that was done I believe you did it right after we spoke last year and you did at ground up two to three weeks total right?

Patrick: [00:39:58]
Four weeks or something from Hey how about this and then the whole company got behind it So that was

Darin: [00:40:03]
Yeah and then it was done Right and it actually worked

Patrick: [00:40:08]
Strangely

Darin: [00:40:09]
and you didn't need a lot of money to pull it off

Patrick: [00:40:12]
No that's true. That's true. A part of it was the know-how and pulling things together. You also giving me some hints on things like StreamYard and past kind of experiences with easy life and things but I think if I look at it I I didn't go for a platform because a lot of the platforms are just they do one thing and they try to be average on all the things and the approach I took is I want to take a little bit of the best of breed of each of the parts and then maybe I still had to cobble a little pieces together and that's a different approach I took there. I'm not sure whether that works because I was there but it might not work for everybody in that

Darin: [00:40:56]
for everybody else because you had the other knowledge to pull it off. So, okay. So we're at time, I apologize to cut this off, but we all have lives that we need to continue on with. So, Patrick, thanks for joining us on this 100th episode. We'll see you again in about 50 weeks and, uh, we'll get back to it. So if you want to check out what Patrick's doing, all of his contact information is down in the show notes, Patrick. Thanks for joining us today.

Patrick: [00:41:30]
well, thanks for having me. Good luck with the next 50 Viktor and Darin.

Darin:
We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us. Our contact information and the link to the Slack workspace are at https://www.devopsparadox.com/contact. If you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover this podcast. Go sign up right now at https://www.devopsparadox.com/ to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.