DOP 51: Is Shifting Left All It Is Cracked Up To Be?

Transcript

Darin Pope 0:00
This is episode number 51 of DevOps Paradox with Darin Pope and Viktor Farcic. I am Darin.

Viktor Farcic 0:06
And I am Viktor.

Darin Pope 0:08
I'm going to try to talk a little bit slower. I've been listening to myself when I've been editing. It's been bad.

Viktor Farcic 0:15
And I am

Darin Pope 0:19
Yeah, okay, it's not that bad. Well, maybe I do need to think maybe I've need to talk that way so it sounds normal. I don't know. Anyway, that's not why we're here today. Today, we're here talking with a guest. Viktor, would you like to introduce our guest, please.

Viktor Farcic 0:37
Yeah, our guest is Adam from Container Solutions, which I happen to meet in random places on random conferences in random countries. Every once in a while.

Darin Pope 0:48
Not right now you're not.

Viktor Farcic 0:51
Yeah, now nobody's meeting anybody face to face.

Ádám Sándor 0:54
Yeah, now we have to do podcasts.

Viktor Farcic 0:58
podcasts, virtual conferences. Makes me sad at night why I didn't buy stock options from Zoom before this outbreak and stuff like that.

Darin Pope 1:10
This too shall pass. This is releasing on April 15. So hopefully it's already passed, or at least we're on the very long tail of it. So, but today we're talking Kubernetes. Now there was a Twitter back and forth between Viktor and Adam. So let's let's actually, let's set it up two different ways. Viktor, you you go at it from your perspective. And then Adam, you can tell the same story from your perspective.

Ádám Sándor 1:35
Sure.

Viktor Farcic 1:36
It's a single sentence. Kubernetes is too complicated for 95% of people.

Ádám Sándor 1:41
Yes, and I don't completely disagree with it. But there are a few comments I would like to make on that statement. And I would really like to hear what what then your comments on those comments are because the Yeah, this should be way better than Twitter. I don't really like Twitter arguments. They suck. So when I was listening to your, your episode about the about how Kubernetes is too complicated for everybody, one thought that was constantly going through my mind was that I'm working as a consultant basically. So I work with see quite a lot of companies same like you do, Viktor. And my experience is not really that people would be hating Kubernetes for the for the complexity. And I'm only talking about about developers point of view and the API, like nothing about managing Kubernetes because I think that's not really relevant for this discussion. It doesn't change how a developer interacts with it. And yeah, that's one thing that that I don't see that much hate out there for it like as if like that people not really don't seem to be screaming for a for a simpler way of deploying things. But of course, this also might be caused by the big hype around it. And people are not really questioning something yet, that everybody seems to be praising so much. And that seems to be changing so much of the IT landscape. And then what I think could be a very interesting discussion could be like, what to replace it with or what to build on top of it. Because what I also see is that there is no successful PaaS built on top of Kubernetes yet, and I'm suspecting there are reasons for that. And that might be a very interesting discussion of what are those those reasons? Practically what's happening everybody is building their own internal PaaS, usually a thin layer on top of Kubernetes made out of Helm charts or whatever. And, and that's also in my mind whether it's like a good thing to do, or, or maybe maybe it's enough for now or maybe we just haven't found the right level of abstraction and maybe whenever we try to raise the level of abstraction, we just get into a place where we have made something very specific for some use case. And it just doesn't work in a generic sense again.

Viktor Farcic 4:10
I guess it takes time. You know, we just started with Kubernetes. You know, it's been around for three years that it sounds like Kubernetes has been around for whole life, but that's not really true. It just started, right. And it's and it's normal that we are kind of all lost. I mean, the time lost, okay, I'm not gonna say all lost, but I'd kind of because and it takes time until you build a real kind of mature ecosystem, I would say. Now, the what I was saying, let me clarify, so what I was saying is that probably didn't explain it well. I have always that idea that things should be shifting left for big part, and I'm big on power to the developers, right. So when I say and I honestly don't think that developers hate Kubernetes. What I do think is that so let's put this scenario. How likely is for an average developer, let's say Python, NodeJS, whatever doesn't matter, right? To define, not use something defined by others to define what they need for their application. Right? And then when I say define, I mean kind of so what do we need? Deployment, HPA, metrics that they're gonna watch through that HPA service. Ingress, and then you say, yeah, maybe virtual service from Istio, maybe gateway from Istio, maybe. And then kind of so how likely is for a developer not to use what you create for him? That's easy, kind of like because everybody likes to look now I have some YAML files that I can just say kubectl apply and then that that's perfect. Everybody loves it, but how likely is for them to be in control. Just like they're in control of their Gradle build.gradle. Right. And that's that's the worry I have right kind of, because I have impression that Kubernetes right now. And I'm not saying that that's necessarily bad, but it's it's mostly in the hands of a special department who really knows what's going on? And I'm referring now to definitions of applications. Let's ignore completely infrastructure and stuff like that.

Ádám Sándor 6:28
Yeah. So how likely would it be for a developer to be able to write all that? Well, if we go over, maybe, maybe let's take a look quickly at the different parts you need to define right? So there there would be a deployment, which is your basically I want to run these containers. And yes, the deployment will have like, there are some there is some weird stuff in there. Like, you have to define the label, which then you also put on the pod. So the Deployment actually manages those pods which happen to have the label that you're defining the same YAML file twice. That's that's pretty horrible. But But yeah, besides this kind of like over configurability the deployment is kind of pretty straightforward what it does. You also define like how your application gets upgraded, and, and so on. So, and readiness liveness probes really important. Again, it's very developer concern, right. So it's, I think, as long as as the stuff that they have to define kind of makes sense for them, developers are okay with learning how to do it. They understand that liveness probes just need to be defined. Again, a bit too complicated, should be simplified sensible defaults and stuff like that. But generally, the concept of a deployment is not a bad level of abstraction for developers. Then you need to define a service for routing the traffic. That's more questionable part whether that's good to detach from the deployment, right because usually the deployments need a service and maybe you could just have like a flag that says, Yes, service, please. And then there is the Ingress, which I actually kind of compared to the Heroku model where by default you like get a public address to your to your service. I kinda like that in Kubernetes is kind of the other way around, that shows that it's geared towards microservices more that many services will not be exposed to the internet. So you have to explicitly say, exposing this service to the internet. So that part is also not that, like, not something developers don't need to care about. Then the whole like Istio stuff, which you mentioned. Yeah, that's that's, that's really low level. That's that's like, except maybe the part where you have where you want to define which services talk to which other services, which is again, a developer concern. So it's, for me, it's pretty hard to pinpoint those places where there could be like, major improvements made without significantly losing the flexibility that people actually need.

Viktor Farcic 9:06
Yeah, I mean, but you know, wouldn't be, let's say, kind of Wonderland, right? Kind of like it, let's imagine wouldn't be great. I mean, if we could get rid of if you could stay up if we would have only deployment resource and say, and just that, yes, and the domain will be this one. And so don't bother me with service. Don't bother me with ingress. We know that it's there. Kind of like, the only thing I really I would, I would, I would actually be happy if we could just remove those from YAML and say, realistically, I just need the domain. I'm not talking about Istio now, just a domain. That's what I need. Everything else is kind of noise. So it's not that it's overly complicated. It's just a lot of noise, I believe. Same thing like with labels. Yeah, great. I understand the concept of labels and all those things, but yeah, it's a deployment. You figure out. I when I say you, I mean Kubernetes you figure out that you put some automatically generated labels that are unique for me, you know that I am me kind of like, so it's a lot of noise. That's, that's, that's my issue. It reminds me of getter setters in Java that everybody's writing getter setters for absolutely no good reason. I mean, I know the reasons but those reasons are not used in vast majority of cases. So it's instead, when I say complexity, or more mean, the sheer volume of stuff, you easily end up with hundreds of lines of some YAMLs, right?

Ádám Sándor 10:42
Yeah, so so maybe sensible defaults, but also like, customized templating and stuff like that can get rid of that for you. Practically building a thin layer of like your own internal PaaS basically, right? You you set your own default and every company has to do it now. The Yeah, nobody figure seems to have figured out the generic enough way to do this that would just work for everybody that could be released as a framework and actually gain adoption. But I do like the idea that maybe deployment would be a thing that the deployment controller could just create everything for a service, and you could just have a few flags in there and have the whole configuration simplified a lot. That's actually might be a good idea,

Viktor Farcic 11:29
My kind of the the one I like the most when applicable, and it is not applicable aways, is Flagger. I don't know if you played with it, right? So if Flagger is you define a single resource canary resource, right? And you put the information that you really need kind of like those will be the metrics that I care about those are options, the domain blah, blah, blah, stuff that you really care about. And then Flagger creates the virtual service which is to me kind of a layer of abstraction that most people don't care. It creates destination routes, again, the level of abstraction that most people don't care, it creates secondary deployment, which again, most people don't care, right, because you need to have two deployments for canary releases, but realistically, I just care about mine. Right? So it's kind of Flagger is that abstraction level layer that I don't think it's the best possible thing that we can have. It has many faults, but it's that one that creates things that are noise.

Ádám Sándor 12:38
Yeah, well, that's, that is that is Yeah, yeah. very reasonable level of abstraction. So when Kubernetes came out, I remember before Kubernetes we were actually having like, just before it became really popular. We were having discussions at Container Solutions about like what would be like a cloud native language to describe applications. We didn't really come up with like a anything that would that we would have felt happy with. But at the same time Kubernetes came out and the Kubernetes language became the de facto cloud native language to describe applications. And yeah, it has done really well in terms of adoption. But yeah, but when you go into the more fine grained services like Istio, you really need to need to hide it. And and there is the another thing that you you said that from a good platform what you would expect is that just you just throw your NodeJS application at it, right, and it just just runs it. You don't, you don't really have to care about all these YAMLs and whatever reduce it to just like a few configuration values that you can change. And there, my thought was that to do this, basically you start working not from the level of a generic Docker container, but from a like, whole technology stack, like you need to care about whether it's Java or NodeJS, or, or Go or whatever other technology. So when you want to do something like this, which is what we usually call PaaS, that's why OpenShift calls itself a PaaS because it kinda has this functionality, even though not in a very good way. Yeah, suddenly, you need to care about those technology stacks. So that's, that's also a huge challenge, I think to like, yeah, that that's something that would make developer's life much, much easier that they don't, that their applications are just treated as generic Docker containers. But to achieve that, I'm not really sure if there are like reasonable ways without limiting your organization to very specific ways of building building images. Or maybe that's the right thing to do. Maybe we should just embrace it.

Viktor Farcic 15:00
I guess what I'm looking into is that kind of separation between, you know, people or departments or groups or teams that are that are make them think about how the system should work as a system. And then other side of that story would be people responsible for a single application, right? So somebody should mean, I cannot expect from a NodeJS developer to think whether should be Istio or Linkerd. That's just simply too much out of the scope of his work. So somebody needs to think about that, right. So and make a decision, like kind of, Okay, so we're, we're going to use service mesh, and it's going to be Linkerd or whatever, whichever it is, right. And then as a developer, then just kind of like whatever is required for Linkerd that just kind of somehow happens, except that I need to, I need to specify something I need to specify lets say domain of my application something right? But again, it's not just application. Assuming that somebody knows, I'm talking about the magical platform that doesn't exist just to clarify, but if somebody made all those hard choices, then I should just say, this is NodeJS, this is the domain, minimum maximum number of replicas, you know, 10 different things, whatever those things are, but things that really matter. So, I would like to see us get to the point where I as a person who is not in charge of the whole system, make decisions that matter.

Ádám Sándor 16:33
If we look at this kind of approach in like larger organizations, which basically every organization is trying, every company is trying to achieve something like this, right? Because it's efficient. Once you figure out how to build your application, then you can just give that as a service to all your development teams and they don't have to be messing around with like huge Gradle builds and whatever anymore. That's that's just great. But somehow, in reality, I guess you also see that that's somehow not happening that much. That that there that this this golden way of building things would just emerge especially not like cross companies, right? So I'm not sure if this is because of the fact of like, Oh, we just like to do things our way, just because or are there like, genuine reasons for for differing between companies on even how do we build Java applications let's say. Because there is like a lot of ways to get the Java application into a Docker image, that's for sure. So it's difficult to standardize.

Viktor Farcic 17:33
It's not. The kind of the this is this is where we may disagree. I don't for any given thing whatever the thing is, let's say building Java application, there isn't 1000 different ways to build Java applications. Companies make sure that there is 1000 different ways because everybody thinks that we are clever, but in reality, only a small number of people in this industry small percentage, really figures out new ways to do things and most of us are following those ways. And there is a limited number of ways how to do specific things right. Kind of, yes. There are three different ways to build application, Java application that matter. Now, if you figure it out in your company, because you have some silly reasons based on historical nonsense, that Yeah, none of those ways to build Java application work for you, you're gonna figure out your own stuff. I mean, that's your problem. That's just you being silly.

Ádám Sándor 18:27
If you have those three ways, there's already a platform that is just supposed to build your application now need to suppose support three ways for it. Or you have to tell all developers that we have found the golden way and this is it. Shut up. Don't try that new framework that is not doesn't work with this way. This is how we are going to build it.

Viktor Farcic 18:46
No, but what you just said I think was a key kind of like, just paraphrasing what you said and you correct me if I'm wrong, kind of like you cannot really stop those same teams from figuring out new and better ways to do stuff.

Darin Pope 19:03
Okay, so we had a an abrupt stop during recording. So when we left off, Viktor was talking about teams coming up with ways to do things. Okay boys back at it.

Ádám Sándor 19:17
Yeah, teams basically shifting left means that teams have more responsibility, which means they can innovate and come up with new ways. But it also means the platform they are using needs to be more flexible, which means more YAML files. Right? So this is the, the area where where you can play with. You can't have both high level of abstraction and like innovation on like ways of building applications and stuff. And actually, a lot of companies going to extremes on this, right? They go into like saying developers should not even write all the Java code, let's say but they should just plug in some Java code into this huge framework that there is because we will just want to keep them productive on the on the very specific business logic that they are supposed to be implementing. And it's not a bad argument.

Viktor Farcic 20:09
I mean, it kind of is, I think. So if you try to keep people productive by focusing only exclusively on a tiny fraction of the whole story, then they don't know the story. And that then the fraction that they're working on, will not take into account the big picture. That's why I do believe that actually, it is very important that the teams in charge of a product developers or whatever they are, do have a say, or a control of how it will be deployed, how it will be tested, without understanding those things and without having a say in those things. Whatever is their real focus, which is let's say writing NodeJS code will not be done in a way that is appropriate for that whole picture. So I want to shift left. It's just that. And I want that flexibility. And I completely agree that the more you abstract from people less flexible they are. And that's now a chicken and egg problem. But on the other hand, if you don't abstract some things, then we're running a risk of them. of, of the, the level of knowledge required is so overwhelming. And I'm talking now in general, not even for Kubernetes it's so overwhelming that they say, Yeah, okay, look, I'm not gonna spend half a year learning this. This is just kind of like this is out of my reach. But if I can spend a couple of days, then that might be a good option. Again, talking in a very general terms, but if I can learn what I need to know about, let's say service mesh, I'm inventing that does whatever it is

Ádám Sándor 21:55
always comes back to service mesh.

Viktor Farcic 21:57
Yeah. Okay, let's, let's change up About, I don't know, like, HPA horizontal pod autoscaler right? Kind of if I can, if I can figure it out in a day, then maybe I would like to, to take that under my wing and put it into into a bigger picture that we're developing here.

Ádám Sándor 22:17
Right? Yeah. Also, it's a bit related to like to the whole how you implement DevOps, which was also something I was, I don't know if it was mentioned in this podcast or another one that I listened to, was that, that to basically this there is this kind of, I would say, naive idea of DevOps, which sometimes sounds like you're also talking about, but maybe that's just because of like, the episode is not specifically about that. But the naive idea of DevOps is you put together developers and operations people right, and now they work together and everything is better. Well, I think that the, but that means when you put together developers and operations people in the same team, it means that that team has like a huge amount of competency suddenly, which they probably also have to use. Because they are, let's say, in charge of their whole infrastructure. That's why you need the ops people in the team. And that means that your teams are suddenly huge and have very wide ranging responsibilities that are really hard to, which is good for like in an experimentation phase when you're like adopting Kubernetes, maybe. But it's definitely not the state, what you are trying to aim for. You are trying to aim for having a platform team that is just supporting the development teams and the development teams don't have to have all those platform competencies inside the team. So that's why I think that's like an early stage maybe not even naive, but like an early stage DevOps versus a more mature DevOps model in a company.

Viktor Farcic 23:53
So let's say as example right that I have operations or infrastructure team and I have a development team in charge of a product right. Now, I don't think that operation teams should be, can be removed, and everything goes to developers. Absolutely not. However, what I do think is that operations should, should be similar to let's say that my operations team is actually AWS. Right? They're thinking about low level stuff that I will never understand. But I'm not opening. I'm not asking them to do the work for me in I'm asking them to provide the service that I can consume. So I as a developer, I am going to create virtual machines, I am going to create a load balancer if I need it and a few other things, because they made it easy for me. It's a service so I am becoming Ops, but ops that is operating on a on a on a, on a higher level, meaning that consuming services created by others. Now that AWS team theoretical, that can be operations team in a company, it can be AWS, really it can be both. So that level, we will never get away from the idea that some people needs to be highly specialized, because we can never know everything. But on the other hand, I do believe that development teams need to have high more wider knowledge, and wider responsibilities than they traditionally have. I don't want ever again to see a JIRA ticket saying, I need three virtual machines. That should be illegal.

Ádám Sándor 25:39
Even better is a JIRA ticket that says I need to restart this server. Right?

Viktor Farcic 25:44
Exactly. Exactly. So I probably I mean, those a short episodes and I tend to express radical opinions, but that's what I mean by DevOps, ops moving towards dev, that the developer should be in charge of operations. But on those operations should be more consuming services than creating them.

Ádám Sándor 26:08
I think an important point to make here is that you actually don't just have one layer of platform under developers. Let's say if you are you say your ops team is AWS, and everything above that is development teams. That means those development teams will have really wide responsibilities still, because they will have to manage servers or use a managed Kubernetes service, whatever, they will still be writing Terraform or CloudFormation code, and probably have special cloud specialists inside the development team. Now you can put another layer of platform team on top of AWS, who builds a more specific PaaS on top of whatever AWS provides. And now suddenly, the development teams all development teams responsibilities have shrunk to using that platform that you have provided to them. For example, at my my last client, it was we, we formed the CICD team. So the CICD team was building basically like delivery pipelines and stuff. But practically it ended up being a PaaS on top of the underlying platform, which was a bunch of OpenShift clusters. So it can and then you can put another layer of platform on top of that, which gets like harder and harder to manage. And actually, the challenge building these platforms is really getting the abstraction level right. Until you don't want to go as high as possible, without like stifling innovation without forcing developers into some very narrow process that that might even be good for a year but will not last and then it's very hard to move away from. I think that comes back to the whole Kubernetes API. Is this the right level of abstraction or do we need something on top of this?

Viktor Farcic 27:55
And I agree really completely. The only thing that is missing I think is and still maintaining freedom. So you create some levels of abstraction. But they should never be done in a way that you must use it. It must be that kind of it's in your benefit to use it. If you figure it out that actually did this level of abstraction that my team created for you to consume is not what you need. Yeah, kind of, let's say, my team creates Flagger as being a level of abstraction. I inventing, not promoting Flagger. Yeah. And you use it because it's beneficial for you. But if you don't want to use it, it's up to you. You're still responsible for your application. I'm not.

Ádám Sándor 28:40
That you could like advertise these things as services, right, that might or might not get used. And if they don't get used, and probably they're shit.

Viktor Farcic 28:47
Exactly. What I'm seeing all over, over and over again, in companies, especially the bigger ones is that there is a team that creates let's say, you mentioned CICD, right? Create sets of let say Jenkins or Bamboo or whatever and create pipelines to say, now you must use those pipelines. You have absolutely. You must use them. And that creates problems because then they're a bottleneck, then I start sending requests to them. Yeah, if I have to use it, then you need to do this and you need to do that. And I don't care really that's useless to others because I need it and all those things. Having creating a service, but still providing freedom and making it transparent in the sense that hey look, if you think that Mesos I'm going to give you a Kubernetes as a service if you think that Mesos will work better for you be my guest. I'm not going to help you with that, but be my guest. It's yours. Do it. I'm exaggerating. It's now maybe too bad of example.

Ádám Sándor 29:39
No, no, it's I think it's very good like that. What what came to my mind now, I totally agree with what you say. But there has to be some layer when the buck stops, right. There has to be some layer beyond below which nobody is in a development team is allowed to go. And what I see with Kubernetes I think why I do like the Kubernetes API a lot is I have never seen a request to go below the Kubernetes API. Like I've never seen that the development team would have felt that. Oh, yeah, we we now want to replace Kubernetes with Mesos. So the Kubernetes API is like is is the level of abstraction there is really hitting a sweet spot, I would say where where it's so flexible that nobody really dreams up any use cases for for going below that. But at the same time, it's way more high level than let's say virtual machines on AWS.

Viktor Farcic 30:35
But that's the thing. I think it's more like a conceptual difference. So nobody is going to going to go now from Kubernetes to Mesos, but that does not mean that people should be used. So it should be that yes, you want to be including use Kube API because you want to not because I say so. So yeah. If you want to play stupid, go somewhere else. That's okay. Kind of I'm against forcing because then you have that you have silos that are not really don't have incentives to innovate and to make something better because everybody must use it as is. And that's the real issue. Then those departments became become stale kind of like No why I mean, mainframe works bad for us because we force everybody to use mainframe. So what's wrong with mainframe? Nothing? Nobody complains because that you're not allowed to complain, right? So yeah, make it so good that nobody wants not to use it not not that everybody is forced to use it.

Ádám Sándor 31:40
And if you if you think in terms of I recently read this book called Team Topologies. Have you heard about it? It's like two guys. I can't remember the names right now who wrote it, I would say it's kind of on the level of like the the DevOps book And like this kind of like, specific, like really writing down how teams interact in a company in a very, very generic and really good way, I really recommend it. He just came out last year, it's pretty new. I bet that in a year, everybody will have read it. They talk about very specific team types and how they should always interact. And one team type is like they call it the stream-aligned team, which is basically the product team who delivers like the actual business value. And then there is a platform team who delivers the platform on top of that takes away the complexity from these teams. And this is nothing revolutionary, right? Just the way they've like really specify how these teams exactly should interact and stuff is like really just just nails it down in a really nice way. And that was kind of an eye opener for me because a lot of times we confuse these platform teams for like a platform team could work really like like providing a product internally in the company that might or might not adopt. And you could totally have this like marketplace style adoption where the platform team has to advertise has to educate the same way as if you are pushing a product to the external world. That's that's a really good way of interacting between teams without blocking those teams, but at the same time do providing services so they don't need to take up the complexity. Because what happens in many companies is they confuse these terms and then they assign platform responsibilities to development teams to make up for the deficiencies of the platform. But then the platform team is just trying to force everything on top of everybody because they're not even a platform team. They are kind of this DevOps team that is supposed to help developers but build kind of a platform. They have like way too many responsibilities all over the place around this. And if they would just behave like a proper platform team, then you can achieve much better results because they are focused on providing the service to developers and then developers having the option to not adopt the platform is actually a really greater force a good evolution of the platform.

Viktor Farcic 34:05
I think that may be what is missing in many cases is that some teams do not understand fully who are their customers. So if I'm a platform team, developers are my customers, I will do whatever I need to do to make it a success on the market. And there is a market. Developers are my customers, that's the market. Maybe we should have two teams that do the same thing in every company so that there is some kind of competition even. But I think that Darin is giving a sign that we need to stop, we've been over over our limits.

Ádám Sándor 34:43
I didn't even know how long we have just kept talking.

Darin Pope 34:49
Well, technically, you could have unlimited time, but I have to edit it and I don't have unlimited time to edit.

Ádám Sándor 34:54
Yeah, sure.

Darin Pope 34:57
The the book you were referencing was Team Topologies by I'm gonna mess up one of these persons named Matthew Skelton and Manuel Pais

Ádám Sándor 35:06
Pais. Yes,

Darin Pope 35:07
Yeah, P A I S. Yeah, it's through IT Revolution, which is the same company that does all the Gene Kim books. It was released September 17 2019. Available on Amazon and probably every one of your favorite bookstores. Team Topologies Organizing Business and Technology teams for Fast Flow. So yeah, that's it looks pretty interesting. I hadn't heard of it. So it's great yet another book to read. Well, hey, you're sitting around right now. You have time to read a book now.

Viktor Farcic 35:40
You'll put it in the comment section. Right? I want to read it.

Darin Pope 35:44
Yeah, I'll do that. Yeah, you have to wait until April 15 to actually get the link to that. So no, you can't read it. Um, yeah, great conversation. What made it even better is me not talking. I was getting other work done. Sorry. That's fourth wall stuff right there. Yeah, well, I was I was editing another podcast while you guys were talking like I was listening, making sure everything was okay, but it was fun.

Ádám Sándor 36:10
Thank you for having me guys. This was I really enjoyed this.

Viktor Farcic 36:13
This will continue. I'm I'm not finished with you. This will continue, right?

Darin Pope 36:19
Yeah, I'm smelling. I'm smelling a part two on this.

Viktor Farcic 36:22
Yeah, I think so.

Darin Pope 36:24
Because I heard some stuff in there and let me go and I'll put in my jab and then I'm going to do the close. I don't think it's bad to force to force people to do certain things. I'm going the exact opposite of both of you.

Ádám Sándor 36:37
Oh, that would be great to continue with that actually. Because yes. Oh, yeah.

Viktor Farcic 36:41
That is Don't go Don't go. Darin, Stop, stop. Stop. Don't say anything else. This is a next episode. I mean, one of the episodes.

Darin Pope 36:50
Yeah. But that's, that's I, because of what I do on a day to day basis and the people that I see nothing against the people that I see if you if you're listening to me, please don't read too much into this. But there's a reason why. I can talk about my reason why later.

Viktor Farcic 37:07
So if you're one of the people that Darin visited, it's everybody else except you. You're fine.

Darin Pope 37:14
No more than likely if I visited you, I told you. so it's

Ádám Sándor 37:22
okay. Yeah, I get it. Okay.

Darin Pope 37:24
I told you as politely as I could. Yeah, it's not directed at you Adam. Okay, so anyway, if you're listening right now via Apple podcasts, thank you for hanging out this long. Please subscribe and leave a rating and review. All of our contact information including Twitter and LinkedIn can be found at https://www.devopsparadox.com/contact. If you'd like to be notified by email when a new episode is released, you can sign up at https://www.devopsparadox.com/. The signup forms at the top of every page. There are links to the Slack workspace, the Voxer account, and how to leave a review in the description of this episode. And we'll also have Adam's contact information so you can tell him he was wrong in a lot of things.

Ádám Sándor 38:09
Oh sure go ahead.

Darin Pope 38:10
Not true.

Ádám Sándor 38:11
I'd like to hear that.

Darin Pope 38:13
No, I I, I'm on. I'm on both sides, but I have very strong opinion for the other side too. And we'll save that for later. Viktor, do you have anything else? No,

Viktor Farcic 38:23
no. I already forgot what we spoke about.

Darin Pope 38:27
Yeah, that's fine. No, you're not. You're a kid. That's another conversation. Adam, thanks again for hanging out today.

Ádám Sándor 38:37
Yeah, thanks for having me, guys.

Darin Pope 38:39
Yeah, hopefully the corona thing is sort of tailing off by now by the time you're listening to this releasing on April 15, or anytime after so hopefully it's an on a non thing and people are people's lives are starting to get back to normal or as much normal as they can be. So thanks again for listening to episode number 51 of DevOps Paradox.

DOP 51: Is Shifting Left All It Is Cracked Up to Be?

Show Notes

Guests

Ádám Sándor

Hosts

Darin Pope

Viktor Farcic

Links

Rate, Review, & Subscribe on Apple Podcasts

Signup to receive an email when new content is released

Transcript