Operations new customers: developers

Episode 235 · Mon, 29 Aug 2022 18:14:17 +0200 · 42:56 · SRT · archive.org · all Tanzu Talk

Hello, everyone. This is Coté. This episode, I've got a discussion that my friend Barton George and I had after I gave a keynote at DevOps Days Dallas, the new role that operations has in supporting application developers, you know, building a platform on top of Kubernetes. But before we get to that, I want you to go to spring.io and check out the conference that we have coming up December 6th to 8th, 2022. In case you're listening to this in the future, I hope it's turned out well for my sake and yours as well. Anyhow, if you go to spring1.io, you can check out the talks we have there from application development in the Java, .NET, and other world doing things like DevOps and SRE operation stuff, and then agile software development and case studies of how large organizations have succeeded at it, maybe even some of how they failed. You know, there's plenty of Kubernetes stuff if you're into that area. Anyhow, go to spring1.io and check it out. And when you register, you can use the code KOTE200, that's C-O-T-E-2-0-0, to get, you guessed it, $200 off registration. Back to the discussion. So Barton and I, had just started talking about a summary of the talk that I have. And as you'll see, we move into kind of thinking about what it means as operation staff to support application developers and how they can start thinking about their new customers and working best for them. Developers. I was going over a talk about how when it comes to the stacks of the platforms that we use to run the software that organizations build and run, their software, that we tend to sort of like rebuild the stack every five to ten years or so. And the premise was that we're at the beginning of rebuilding the stack with Kubernetes and things like that. And that it was kind of going over like, so we're going to be rebuilding our stack. What can we learn from the past times that we have rebuilt it? Ways that, kind of like the way that you develop that stack out, the way that you run it, kind of the frame of mind that you have so that we don't have to like reinvent everything. And the reinventing everything is not so bad. It's more, we don't have to lose time and make the mistakes. We can kind of, instead of just completely getting rid of everything and starting afresh, we can

incrementally improve from where we are and help things out. And I'm remembering that part that I left off. How did I skip this slide? I wasn't taking it out. I had a whole jag about buy mobile IT in there. I mean, that was Gardner. I need to see that. That was Gardner. Okay. Now I forget. I wonder what happened to that slide. I better go look. And because I might have left it in Detroit. But then, but basically the idea that you had the fast part of the company, you also had the Right, right, right. The lagging part of the company. Right. And neither the twine shall meet. Yeah. And that, that was, I mean, this is a very niche thing that doesn't exist to go into right away here. But that was the point that I was trying to make is that, uh, uh, you know, it's, it's very easy as, as technology people, especially ones at a conference to like, be focused on this interesting new thing. That's great. And just sort of like neglect all the stuff that exists and, and, uh, and not really like try to bring everyone, uh, alone necessarily. And also like any chance I get to point out the madness several years ago, that was this whole bimodal, like scruffle. Like I'm pretty sure most of the people complaining about it, you know, to spend the $3,000 to read the garden PDFs. And, uh, I don't know, it's one of those typical things of like, no one did the news story a year later. Well, Matt, let's, let's, let's move on to it. If you had some advice to give folks who were now trying to make this transition in this new space, that you say, we've got the Kubernetes, uh, that for some people, uh, they have started implementing some people, of course, like Google, they, they've been implementing it. Um, what would you, how would you tell people to look at it? And what should they be thinking about? Well, I think, I think that the primary thing, especially if you're used to like, uh, traditional is the wrong word, the current dominant way of thinking about operations and infrastructure, sysadmitting, whatever you want to call it. Um, you don't, when you're doing that, you're not really thinking so much about the, the developers, right? And, and so if you're building

this stack out, it's, I think the first thing that is easy to overlook, just because you're not kind of used to thinking about this, you're doing, you're building infrastructure stuff, is that you're building this for developers, like they're your customer, because the reason you're building this Kubernetes stuff, more or less, is to run that those custom written applications that your organization, uh, uses. And so as you're building up this stack, you should find some of these developers because they are the people who are, that you're supporting and that you're, as they say, enabling. Right. And so I think traditionally, if you look at like, um, if you're like a virtualization administrator or you're a storage administrator, like you're all these operations things, like you're a little too far removed from the developer side of things. Like you may not even be building infrastructure to run custom written software. You might be running some off the shelf thing or a cons, as they used to say, you might be doing all this administrative stuff. And so you, you can't really take that attitude because then you, you don't have a customer that you're building this stuff. And that's, I think that's the important thing to realize is that you are building a platform, right? And like, you're not going to know what to build unless you know the customer that you're building it for. And you'll just end up building stuff you think is useful and cool and have no validation, uh, if it's useful or not. And then you'll have a very well architected city that no one wants to live in. Good analogy. Well, so the other thing too, is you also become a customer. Wouldn't you say in this new model, because you're not just building it and giving it then to you, you're going to be part of that same product team with the developer. Right. And that you have to be, you have to implement what you, you built in support of the developers. Yeah. That's interesting point is that when you are building up this new platform, you're going to have to live with it. Right. And, and so like, you're not going to have like, you know, in contrast,

if you're using just, you know, VMware virtualization stuff, or you're using, uh, the services that you get in a cloud, a public cloud, like you don't really have a lot of choice in what the thing is. You're more learning how to use something. Whereas a lot of the people I talk with who are building up this platform, they're spending a lot more time customizing it to how they want to run. Right. So it's something they're going to have to live with afterwards. So yeah, it is important to think about as I'm building up this stack, how am I going to build something I want to use for the next three years, if not more, or how am I going to improve my resume so I can get out of here. Exactly. It's a bimodal thing again. There you go. That's actually what it was about. Yes. Um, so then you're going to then also without, besides building infrastructure that's going to satisfy your customers, which are the developers, and then also making it something that will be usable for you because you're going to have to support it. Right. You're not, you yourselves also have to transition to be this new, to build this new skillset to support those developers. Right. So is that going on in parallel? Would you need to do, would you need to transition before you, you started designing based on the developers needs? I think what I would say, I'm still formulating the question in my mind for your question is what you should start with is by creating the role of a product manager, which I don't, I don't think a lot of organizations have at all. Like, like in, in, in the IT world, right? Like you more have architects, project managers, and think people who like specify what software is supposed to blend. Right. And then the operations layer, like, you know, we have the, what you do is someone specifies, tell me what you, the performance characteristics you need for this

infrastructure, for this platform. And then tell me on the security requirements that you have. And then I will put together, or I lend a term, like we will put together a stack of infrastructure and the software above it that provide those capabilities. Right. Um, but that's not really how you product manage something like based on what me, someone had, well, based on the capabilities that they need. Instead, what you do is you talk directly with your customers, your developers, and you help them discover like what problems they have and the best ways to solve those problems. So for example, like it would be easy to say, and, and not wholly incorrect, but, um, you would say like, oh, so we're building this platform based on Kubernetes. So we're going to build on all the storage and networking and the compute. And then we're going to get the clusters up and running. And it's really easy to stand up a cluster and put that in, put down and, and like, you know, shut down a cluster and it's secure and all that stuff. And then, you know, what's going to happen is that you're going to go to the developers, you probably haven't really talked with yet. And they're just going to be like, that's great. I spun up a cluster. And now I don't know if you know how software development works, but I got a bunch of other stuff I'm going to do. Right. And so instead, if you start with the developers, you'll find that they do need, uh, a place to run their stuff, you know, Kubernetes, uh, cursor, but they also need to be able to do, uh, they need to build, right. And they need to, to, to something you alluded to is the developers are going to need to know like, so if you want, if you, the operations people are going to support this in production, like, what do you want me to put in the code so you can monitor it? Like what do you, how do you want me to package up the software so that it's easy to diagnose? And what way should I architect things so that it's easy to, uh, deploy this stuff like to various data centers, whatever, like all these sorts of things. So the infinite loop starts in the beginning. Right. All right. And so that's why I was saying like, you should start talking with developers and realize that they're your customers, right?

You're not just building infrastructure and capabilities that kind of map. Like we need this capability that matches these numbers. Like you're going to be co-developing this with, with developers, product managing it. You all go out and talk to a lot of customers. And so when, with ones you're talking to, you've got the, so we're talking about the operations, you're talking about the app developers, but then there's the common end user custom. Right. And so how, and obviously the developers hopefully are, are thinking directly of what they need to deliver to support the business. Right. What about operations? How, how should they be learning about the end customer? Should they be doing that directly? Because otherwise, if it goes too many layers back, it becomes a game of telephone. Right. And then it gets all, it gets distorted. So to what extent does operations need to directly understand the end user needs and wants? Well, I think that, well, I'll, I'll, I'll do it in reverse order of whenever, but like, so I think it's what operations to think about more is the application development organization is their customer, right? So they should spend most of their time working directly with the, I'll just say developers. But when I say developers, I mean, application developers, they, they, they should spend most of their time working with and talking with the developers, because that is very directly their customer. Now there are, aside from themselves, as you pointed out, there are, there are at least two other constituencies they need to talk with constituency customers, and that is the security people and the compliance people, right? So these are also going to be customers of theirs that they need to start consulting with. But that's, we're trying to keep things brief. Right. So those will be internal customers. Right, right, right. And so I would, I, I think this is true. I mean, I would say that for the most part, that's two operations to talk with. Now that said, probably, especially when you're starting, you

should have a good idea of who the, how, who your, your organization's end users, customers are. Right. And I would even say that maybe, like, as you have a new operations person come on, what they should probably do is go to those development teams and be like, Hey, whatever you're doing to talk to our businesses, customers, I want to do that for like a few weeks too, or like whatever. Right. And so like, I mean, I think, I think somehow you need to figure out like your operations people should kind of know what the customers do. Right. And people who work in retail and banking, well, at least retail banking, not to choose what we put, but like banking that you and I would use. Right. Like they're kind of lucky because they understand what the customers do. Right. But as you get into more and more exotic things and also internally facing things like, yeah, you should probably make sure that at least on a quarterly basis, like you check in and you understand what the customers are doing, but it's better to spend all your time focusing on the developers, the security, the compliance people. And so when you do talk to customers to add yet another constituency, you've got the business itself, right, is how do you see people organizing the business with the app developers with operations? Because in theory, business and application developers should be in lockstep. Lockstep. Yes. And then the operations should be supporting them. But so how do you, how do you see your, the customers you've talked to organizing and how would you, how would you advise them to organize? So I, I mean, I think there's, I don't know, over the years, there's never like a great helpful answer to that. Right. And, and, because I think you just go through cycles of like, uh, the, the chain of people and organizations responsible for the application that the business is using either internally facing or externally facing

is like an external entity to the business or it's part of the business. Right. And I think, I mean, I don't know, this is like part of the art of product management. And I think that kind of, sort of like the operations people, again, that's sort of not their concern. Right. Like it's more of like the develop, the application team should be the one that's figuring out how to work with the business side. Right. Cause like, you don't, in the same way that like, I mean, let's reverse it. Right. Like, so let's say, uh, you know, I mean, I know a lot of it nerdy people who probably would enjoy this anything, but like, let's say we're in a retail environment and the business comes over to the operations people. Like you're not going to talk to them about like, you know, trucking logistics or like, you know, how do I select which stuff to put on the in cat on Tuesdays? Right. It's just like, we don't really need it to give input on that. Right. And similarly, like when it gets down to the operations level, like the business side doesn't really need to say like, I don't know, have you considered SSD drives or like, you know, how's our gigadoodles doing? Right. Like there's not really a lot that needs to interface in there. And instead, again, it's like the product development people are more of the ones who, which should be working very closely with the business. And I would, I mean, it feels like what ends up happening in that area is you have, I mean, there's always a weird phrase, the business, but you have people who are largely non-technical people who understand how the business operates. Right. And they end up working sometimes daily, but very closely with those product managers on the application side. And until you really have those people working that weekly basis together, like you don't really have the good, uh, synergizing, uh, between the two. But again, like, I mean, I don't know, this is always not, I don't know if this is the answer that people like, but like, I don't know, when it comes to operations, people worry about the developers. Okay. Well, that's, that's, uh, that's good advice. So if we do with end with the lightning round, I'll just, I'll, I'll give you some things that you just

say the first thing that comes into your mind, but, um, Ice cream. Yes. Thank you. And you win. Thank you everyone. Um, no. Okay. Who were that? Uh, huh? I don't know. What's going to happen to it? What should we keep? Oh, I thought this is the first thing that comes into my head. Well, yeah, it changed rules, but. I, I was thinking koala for some reason. Exactly. Probably because they both start with K. Yeah. Yeah. Like every, every kiss begins with K. Yes. Okay. Um, so I, I think, yeah, I mean, I think after a long time of, of all of us in the industry trying to figure it out, like, yeah, that, that seems to be what people want to run. Like, I think, I think the most interesting thing with Kubernetes, like I was realizing this on stage today is I should stop saying public cloud and I should just say cloud. Cause like there used to be, there still is a distinction of public versus private cloud, things like that. But like, I think increasingly, like, you know, when people say cloud, they just mean like the big public clouds done. Right. And so what I'm curious with Kubernetes is like, like if you're just using public cloud, cloud stuff, like, do you need that? Like, and like, I guess another way of putting it is like, is all this interest in Kubernetes, is that a private cloud thing or, or a multi-cloud thing? But if you just wanted to use just one of the, the big public clouds, like does Kubernetes, is it really necessary? And I don't know. I mean, I think, I think you could equivocate. At least forget if equivocate means what I think it does, but you could, you could, you know, either answer, I could totally see that, you know, it goes either way, but I think that, that would be the, uh, I think that's what's at store in the future. It's figuring out like, do we need this thing? Uh, if we're not doing our own, building our own, like data centers and private clouds or edge, right? Well, yes, exactly. So that brings up the, and this isn't very late now, the longer answers, but it's more like a rolling with

thunder. Well, I like that. Um, the multi-cloud, when you hear multi-cloud, because you just started talking about distinctions, delineations that you see going away, do you see multi-cloud as a, uh, a, as a helpful term? And B, do you see it as a reality in that? Like, would you say that would become the reality that it's just this pastiche of, uh, public cloud, private cloud, and, and then a mixture where you're, you're first thing over, uh, and a bunch of different configurations? So mostly the second, like whenever, nowadays, whenever I see the phrase or hear the phrase multi-cloud, I, I try to substitute in the word computers. And, and what I mean by that is, uh, like we used to have this phrase heterogeneous IT, which just meant like, uh, Windows, Linux, Unix, mainframes. And from an IT person, from the IT department's perspective, it's like, oh yeah, we got all of that. Right. And so what we need to be able to do is we need to be able to support and manage everything. Right. Like we don't only have windows, we, whatever. And so like, when I hear the phrase multi-cloud and what it's come to be to me is like, oh yeah, we're going to be running stuff in the public cloud. We got some stuff over here. We got edge. Right. And like, and then we've got this thing. And again, in the scope of all of the stuff that I care about is scope to like an organization that is writing and running their own software that helps run their business. Right. I think that an organization of any size that I end up talking with, which is large, right. They just like, uh, you know, they got a lot of different stuff. And so they would like to have as few tools and as few things to manage all of that as possible. So in that sense, like, and so I kind of go over that because I think when a lot of people say multi-cloud, the feeling that I get is they're talking about, we're going to build a system and an architecture of a new thing that involves multiple clouds, which sounds cool. Right. Like you said, the word bursting, which is awesome. Right.

Like such a, such a fun word. Right. Uh, but like, really what I think it means is just like, yeah, we've got a whole bunch of different stuff that like is not really compatible with each other, but we need to have a bunch of tools and ways of thinking that allow us to like manage all of it. Right. So it's something that happens more organically than something that, that you plan. And it's more from the outside, inside out, goes the outside in. Sure. At least in my head, I'm guessing. Some people like to go both ways. Exactly. Here, there and everywhere. So so if we talk about DevOps, cause that's what you go out and talk about, how are you positioning that now? This is not letting me run anymore. We're getting back into some topics, but how are you positioning that to people? Are you, to customers, are you saying really you should be focusing on this instead? Are you saying DevOps is going to transition to that for you? Are you still pretty much using that as the framing for your discussions? Yeah. I mean, I think to answer your question in a circuitous way, for once, I think what I try to emphasize is a lot of what we were just talking about. There's two things I try to emphasize. One, I try to figure out if I'm talking to developers or operations people, right? When I'm talking to developers, I have a different sort of like prattle. And once again, you said app developers. Yeah. Yeah. I'm sophisticated enough to know there's like many types of developers. Yes. That's good. But I believe that when most people say developers, they mean application developers. So I shorten it that way because I look. Right. And so I think that, so if I'm talking with operations people, the conversation I try to have with them is what we've been talking about is like, so you're going to be building and supporting a platform, right? I try to use this word platform instead of DevOps. Okay. What comes with that is like, sure,

DevOps, right? But like that's, it's not a bad way to, it's just, it's too much of a term. And so I try to narrow it down to like, what you need to do is you're building a platform. And then we've all, we've discussed that already, right? But I try to steer this conversation towards like, so if there were operations people who are now building a platform that's going to run the software, multi-cloud environment or whatever, like here is generally the way people go about doing that, what the platform looks like, and all of that sort of stuff. Instead of kind of like going through the more traditional, like, well, DevOps, you've got to automate this thing and DevOps. Culture automation, which is all great, but I think, like, I think, I think we're all cool with that, right? Well, either that or it's something that confuses people. I think either way, I like the idea of focusing on platform because it becomes something that's tangible. I think since day one, the thing that is like the DevOps is the multitude of meanings and the sort of the fuzziness around it. We all have sort of the same idea, but particularly people coming new to the, to the concept or for trying to get to a second level of understanding platform is, is very helpful and easier to wrap your head around. Right. And if I may, I made a comment on myself further. Like, I feel like I always want to tell people something they can do, not like some state they should be in, right? Like, and so like, there's a great place for, in the computer world, the DevOps world, the product management world, all worlds of kind of saying like, wouldn't it be better if things were like this and sort of pointing out like, you know, we, you know, this, this culture over here is horrible and this culture is better. Right. And like, I've read all of that stuff and listen to it. But I, I always ask, like the frame that I have in my mind is like, all right, so this conference was fun. And, uh, then I'm going to come back on Monday

and like, I got to do something. Right. So like, what am I going to do? Right. And so like, you know, I haven't mentioned a lot of concrete things that you can do, but that's what I always want to drive towards. And like, even if it's small, like what's something you could actually start doing. So for example, had to talk with developers recently, why don't you hire a product? Why don't you create a product manager role and go talk with the application developers, find out what they need. Right. Like never, you know, like you're going to end up building a platform. Like I, we, you know, most of us who are on the outside, we can tell you what you're going to end up doing. Right. But you're going to end up doing it in a slightly different way. And all those little edge cases, slightly different things are going to be what matters. So like, we know what you're going to end up doing, but first just call up developers, find out your VP of applications or whatever nonsense is, and just talk with them and ask them what their deal is, what, how you can tell them what they need and start there. Because you already know you're going to build Kubernetes thing. What else are you going to do? Exactly. Platform to manage platforms. Yes. But you need some guidance or you're just going to end up with like something that people don't want to, don't want to, it was too strong. Just like something that doesn't apply, like that is a mismatch for what people actually need. Yeah. And just thinking more as you're talking about platform, I like it because you don't necessarily have to be talking about a specific platform like a Tanzu or an OpenShip. Well, you always have to talk about it, Tom. Yes, exactly. I forget who you work for. But the, it's just the concept of whatever it is that's going to support application development and that's going to be supported by operations. That is what you can call a platform. Right, right, right. With a pre-packaged bundle that you get, whether it's your own, well, your own platform that you built. Right. I think that. And then the other, the other tangible thing, right, is that like, and this is why it's important to go start talking to developers, is like, from a operation standpoint, you focus on running the application, right? I mean,

I mean, if you think about the process, it's sort of like someone gives me an application. I mean, configure it and set it up, and now it's running in production. And then something goes wrong, and I figure out what's wrong with it. And those, I mean, ludicrously, whatever, but like, that's kind of what's going on there. But if your customer is a developer, there's a lot more that's going on. So for example, your developers have, will have like a pipeline, like a whole process of how they ingest what the software needs to do, how they build it out, how they test it, how they automate things, like all sorts of things, right? And as you build out your platform, you're going to find that like, oh, I guess you've been ashamed left. Like, I should get involved in those tools more and more. And that's, I think, what a lot of DevOps groups do nowadays, is they build these developer tools. But that also becomes part of this orbit of the platform that is something different than operations people do. Yeah. And I should also, once again, thank you while you're talking. I should do more thinking. Well, I don't. Exactly. That's something I could do as well. But it doesn't mean, well, again, back to the side of platform and you focus on, doesn't mean that you be dope, that DevOps is not helpful. As I thought about it, DevOps is the methodology that underpins modern IT. And modern IT is characterized by a platform model. I mean, if you think about it at the beginning, like DevOps, like Puppet and Chef and Oblutatory, three other companies you always have to mention, right? But basically DevOps was, we don't like the way that automation is currently done. We want to make automation more programmable, right? In fact, depending on which way you went, like it was just a programming language, or it was a DSL or whatever you want to call it. But we want to start having infrastructure as code, right? And so it wasn't a platform. The whole thing of DevOps was that we are going to program our infrastructure, right? It's going to be more programmatic versus whatever else was before then, right? And so like floppy disks that you walked around and that's right. That's right. And then as

DevOps has progressed, like it always sways back and forth between like the technology and the culture, the technology and the culture, right? One thing that I liked that Patrick Dubois said was he called it technical gravity, gravity and technology, basically that you try to pull it more to culture, et cetera, and you always get set back to the two. I mean, it always goes back, right? Because the two things enable each other, right? Like you get a new sort of technology, like when the automation people came along, that freed up a lot of time, and you had a new approach to doing it, which means, I mean, Joven's paradox, that's where it is. Yeah, that's right. Which means you could focus on changing culture. And then you change the culture around long enough and you haven't been focusing on the technology. And then the culture is in a good state. And you've got to go back and like there's new technology. Now all of a sudden, you've got containers that you can work with. And that changes the stack. And so you've got to spend some time with technology. And then you go back up to the culture. So, right. So you go from Puppet and Chef to Docker. Right, right. And then so forth and so on. And now, now, like a lot of us in the industry, we're just sort of farting around trying to figure out what we're going to do with Kubernetes or not do with Kubernetes. Finally, that's more or less resolved. And so now it's back to like, we, the people who are doing DevOps or whatever, like now, it's sort of like, hey, here's the new box of stuff you need to do. So like, I think things hopefully are swaying back towards technology where just like now we need to get Kubernetes up and running, which is why going back to what you're saying, like the important thing there is that like, what you're building is a platform, right? Like you're not, you're not just, it's not like the good, good times of the early days of DevOps, where like, you know, really all you need to do is writing a bunch of Puppet and Chef scripts, you get an A plus, right? You've done the DevOps. Whereas now, it's more of like, you need to build a platform that your organization is going to use to make application development better, right? And that's like the technological focus that you have. So do that platform stuff. It's interesting because there are so many more dependencies and

Kubernetes is so much more involved and intricate to set up and maintain. It is a bit of a black box compared and I made your own, but Puppet and Chef, they seem to come, come out from the beginning, be more fully formed, that there was less sort of set up you have to do. So while we talked about, traditionally with, with DevOps, as we talked about this culture, it's the most important thing, because if your culture doesn't change, then it doesn't matter how many great tools you have, because they're going to languish, because people won't, won't matter. But to your point, okay, so you know all these people who are raring to go and they, they understand the new way and they're looking forward to working together. But if they can't take Kubernetes work, they're out there and it will hurt. So it is, it is that balancing act. Yeah. No, you need both of them, right? Like, like to, to repeat what you're saying is you have, uh, I don't know, you're like in whatever the right column of the West, Westeros corporate, Westeros or Rorschach thing is, you know, like you've got the bureaucratic, like, and then you've got like whatever one's in the middle of the, just a 1984 reference. Yeah. It's, it's the, the Westeros thing. That's all the big DevOps rewards. Okay. So let's say you've got the good generative culture. Okay. And then let's say your tools are crap. Like it doesn't matter, right? Like you've got this generative culture that everything, they're, they're all pulling the right way. They've got all the characteristics. And then it's like, all right, now let's do this stuff. And like, well, we've got to go to the train and tell us how to fill out the tickets correctly to get a server. Right. So that's my point is that like, you can't dismiss culture and you can't dismiss technology. Like you need both of them. And if one of them is bad, including the technology, then the other one is irrelevant. Right. Like, like you could have, for example, I mean, my little joke is always like, you get a great technology and all that gets you is this blinking cursor. Right. He's still needing to do something with it. So anyhow, that's, that's why it's good to like, figure out, like, don't get over fixated on just one of those other things of the

continuously, uh, the swing thing. Cool. Like this. Right. Does that work? Yeah. No, I think that makes sense. You can't have one without the other. And I think, yeah, I don't know, back to that technical gravity. If that tends to be the natural, uh, pull of, of, of, or snap the swing of, of, uh, culture versus technology that tends to be the, the 60 to the 40 or the 70 to the 30, but whatever it is, you still can't have it without the, the other component. Yeah. Yeah. Yeah. And it maybe attached to that is like, it's really easy to stop talking with your customer. Right. And like, like whether you're an application developer or operations person or, or whatever layer, like, that's why I try to always emphasize, like, like what is your business? Like, what is it that your organization does? Who is the customer that you work indirectly and directly with? How do you make things better for them? Right. And like every single, like, at least in the area that we're talking about, every single, like, I don't know if the person who like, you know, orders the Xerox paper, you know, well, I don't know, they can do whatever they like. Right. But like, you know, you always have to know, like, I don't, I don't like that whole, like, you have to know your why sort of like, also, I need to breathe regularly and like, you know, but like, you need to know why you're doing this. Like, who is the customer for it? And like, I think what happens a lot is, is whether you're building a technology or you're perfecting the culture, like it's easy to kind of lose track of the customer or the outcome. And so you always got to go check back on them and be like, so we made this generative culture. Uh, is it like selling more stuff? Right. Like, is it working? And like, is it, is it making it easier for, uh, Bart to file their, his taxes, right? Like, you know, you've always got to go back and make sure that whoever your customer is, that like,

you're actually making things better for them, regardless of how great you're doing. Right. Yeah. And that's the, that's the whole idea of this being an infinite loop. There is no stasis. You can't say we got the requirements there. We're done. We'll talk to you another 10 years because things happen to. Right. This is this continuous feedback loop that is so important. Whether you do the full blown DevOps model or not, that in itself is, is a something simple, but something very important to realize that things are always moving. You want to be, as you say, checking back with your customers, checking back and seeing what they're needing. And that's say, in a simple example, uh, consumer goods, you're obviously always taking track of what kind of scents are important for, uh, shampoos or what kind of, what they're dentifrice, as they say, toothpaste, how those are trending. Uh, one of the things that toothbrushes, man, they have so many different bells and whistles, they keep coming up with. You would never think of not continuously checking with those customers. Right, right, right. But maybe say on the, within it, you say, hey, God, I know what the developers want. I'm good. But that changes. And you also need their learning as you go as well. Yeah. Yeah. No, I mean, toothbrushes are, uh, a fun analogy, right? Because it, it, it, it, uh, it almost seems like, you know, capitalism gone muck. It's like, how many types of toothbrushes do we really need? It was like $9 for toothbrush. I mean, it's just, I mean, it's crazy. I was in, uh, oral care at Johnson and Johnson. I did, uh, uh, dental floss. You don't have to floss them all just the ones you want to keep. A hundred million dollar brand. And this was like 20 years ago. Um, it's crazy. So yes, but you always do have to stay up with it. Right, right. Capitalism run amok, as you say, because people, whether people lead it or not, there's always this differentiation that they seem to be seeking. Some of which is warranted. Some of which is just let's throw something out there and maybe people will buy toothbrushes that have three pads

that, you know, that spin. Exactly. And you know, you want to experiment, try new things out and explore it and get feedback. And if it works, do more of it. That's always a good idea if something works in your business. And if like, it doesn't work, then like stop doing it. Right. And so, but it is getting that loop in place where you, uh, you're making sure all the way down to the infrastructure and operations stuff like it, is it still working out? Is it good? And in order to answer that question, you've got to know who the customer is with like, is it making the application developers jobs better? And then when you make their jobs better, the actual in the customer of the business, the end user, as you say there, that they should be improving as well. And I think that part of the actual manifesto and then part of the DevOps ethos is the quick feedback loops, right? So that you're, you're not putting out big, uh, deployments, but you have things in bits so you can do quick rollbacks. So I think that would be one of the big differences between that. The toothbrush market is to get the toothbrush out there to get it in place at Walmart, et cetera. That's a lot trickier because you have it all the way out there and you, you're pretty far instead and make pretty big investment. And in the past, people have done that with workflow deployments or things where you had to spend two years on it to get it anywhere. But with the idea of, with DevOps and with Agile, it's let's get, let's get this loop quicker so that we don't, A, we don't make any mistakes. We can't pull back and B, we're, we're able to match the needs of the customers. Yeah. Yeah. Go on. Well, let's see if I can make this statement without having it be like, just like, uh, useless. But like, I think the traditional way, which is to say the current way of thinking about operation stuff is that you build what you can, right? Like, like you have, you have this stuff and you build up what, what is possible. Right. Whereas like what you were just describing there is like, instead you should build like, kind of like what you need in the sense of like, what we want to be

able to do is we want to be able to deploy our software every week. So let's work back from there. That's the goal that we have. Right. And so like, I, you know, I know that sounds ludicrous, but like, tell me, and I don't, this is someone talking to the operations people, right? Like, what is it that you would need to support that? Right. And like, I know with our current way of thinking about stuff and the infrastructure we do, it just seems ludicrous kind of like installing some big package application, but like, there are many companies and organizations that manage to do this. So I know it's possible. Right. And so like, what do we need to do to get to the point where we can safely deploy and run our software like every week and like, let's start from there. Right. Like, nevermind all this nonsense, like not nonsense, but like all the constraints and the problems that we have over here, like, and, but that's what it is. I think to build a platform, like start with that goal in mind, not with, not with like, well, we have all this stuff and we can build stuff with it. Right. Like maybe that stuff you've had like is useful. Right. And so you need to come up. That's why you're building a new platform instead of just like, you know, like, for example, you could be like, ah, we got all these computers and we're just going to install Kubernetes on them. And then we're going to have a Kubernetes cluster up and running. And it's going to be great. And then we'll have that. So we built this thing. And then, and then a good test is to be like, all right, so how, how would a developer get a cluster? And then sometimes the answer is like, oh, well, they need to file a ticket. And you need to be like, no, no, no, no, no, no, no. Hold on, hold on, hold on. I think we've lost track of what's going on here. Right. So, and again, I think it's good to start with that angle of like, start way up here. We want to deploy our software every week. What does that imply and work back from there? Is that working up? Right. And then, and then work forward in incremental ways because you're not going to say, this is where we want to be. So let's throw everything out that we have and let's buy new everything. Right. To get it going is that you say, once again, you've got your roadmap. This is where we need to be. This is what we've got. Let's slowly start replacing things. Let's figure out how we can use what we have

modified versions of that to support the new system. Because otherwise, it's, it's, it's a loss in expenditure, capital expenditure. And also, you're, you don't quite know how to use the new things. And I think it would be, it would be bad. Yeah. Yeah. So start small on some projects, find your customer. Yep. Just experiment, try things out. And, uh, you know, I'll, I'll always, uh, consult with the, the customers that you have, see how that's working out, uh, do stuff to help them. And I should say for both our respective companies, if you want to buy everything brand new, that is totally cool too. Yes, exactly. In fact, I'll put a link in here that, uh, direct use of sales for us and yeah, sales ticket that you can form and, and file a ticket. Yes, exactly. So, well, with that, Michael Coté, it's been a pleasure as always. I think, uh, I've learned something from here. I hope our, our viewers, I've learned a lesson from YouTube. Oh, stop it some more. Uh, and on that note, uh, signing out from DevOps days, Dallas Fort Worth number five. Thank you. Bye. Well, I hope you enjoyed that episode. What I want you to do now is go to SpringOne.io and check out the conference we have coming up December 6th and 8th. I've got a discount code. When you register, you can use Coté 200 to get yes, $200 off. Now at that conference, we're going to be going over software development, agile software development practices and culture, case studies of organizations that are getting better at software and all that operation stuff, devopsy things, SRE, whatever, all the stuff that comes with operating and providing stacks you've built on top of Kubernetes platform as a service like the Tanzu application service, stuff like that. Overall, it's focused on how organizations are getting better at software. Just kind of fun stuff like that. If you're into that kind of thing. Anyhow, when you go to SpringOne.io and you register, you can use the discount code Coté 200 to get $200 off. Hopefully I'll see you there. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.