ICYMI: DevOps with Mitch Ashley, CTO of Techstrong Group (DevOps.com)

Lee: 00:00:00

DevOps is now mainstream. If you and your organization, aren't using DevOps principles, you are at a distinct disadvantage compared to your competition. And doing DevOps does not mean simply hiring a DevOps team. There's more to it than that, much more. My guest today is Mitch Ashley, the CTO of Techstrong group. Techstrong is the publishers of devops.com and other publications. In this episode of Modern Digital Business, Mitch and I talk about the value of DevOps and how it fits into the structure of a modern digital application. Are you ready? Let's go. So Mitch, DevOps started to appear in mainstream, it seems about about 2007 or 2008. I started using some DevOps types principles when I started at Amazon in 2005, but places at about 15 or 15 to 18 years old is what it, what it sounds like yet. It's still an essential skill that I find, you know, many organizations that are trying to modernize still struggle Um, you know, they're, know, they want to move to the cloud. They want to move to microservices. They wanna move to cloud native, but yet they still struggle with the basics of DevOps. What advice can you give to companies trying to modernize? yet they don't follow DevOps processes and systems,

Mitch Ashley: 00:01:58

They don't live and breathe it every day yet. Right. So.

Lee: 00:02:01

right.

Mitch Ashley: 00:02:02

Well, you know, it's, you know, we've gone through successive transformations or generations of SDLC and different, different, I would call them almost project management, life cycles for software engineering, um, and up and into including Agile and things like that. And I think what's different about DevOps and maybe why folks struggle with that a little bit more is it's not a structure for project management. It's not a structure just for managing work across functioning across the organization. Yeah. Those things happen. It's, it's also about how you, how you create software and the way you create it. And what I think is a little bit mystifying at first is a lot of the things share similarities or comes out of, you know, agile. Some past past efforts, but it brings a lot from total quality management, you know, the Deming era and from, uh, Toyota manufacturing and things like Kanban boards and things that have shown up in agile, et cetera. But. What, what it's about. I think it's a really convergence of multiple things. So let me, let me describe it this way. It's about how we create software in an era where we changed from being resource limited in our data centers, to being virtually unlimited in our resources, through cloud and through our laptops and develop anywhere strategies. We have git show showing up distributed source code management. You know, I can sit on the plane and develop on any part of the source tree that you can. And, um, at the same time, introducing some new evolution of architectures into cloud, native microservices, et cetera. And so why I mentioned all of those together with DevOps is because dev ops now thinks of things in much smaller pieces of work, much smaller cycles, much more concurrency of all those things happening at once. We can develop much more quickly in much, much smaller increments, and we can deliver those things more quickly. So that's very different than we're going to go... we're going to take a product release and divided into sprints and do six sprints, and then we'll have a release. Then we'll push out.

Lee: 00:04:13

Right.

Mitch Ashley: 00:04:14

Six two weeks sprints or whatever our metrics are. It is literally getting to the point where you can, if we had a security emergency this afternoon, you potentially could issue a patch today, tomorrow within hours within days, you know, very quickly because the software smaller, the process is smaller and faster and it's all, or a lot of it is automated. So I think that. You're there isn't a manifesto to follow it. Isn't like the agile manifesto. Right. Um, there were just some principles that were kind of set about at the beginning and I think it's evolving. Wow. It's while we're, while we're implementing. So, you know, we are building the plane while we're flying it, you know, the old analogy does that help Lee? I know it's a bit, it's a big answer to a core question, but I think it is really a little bit of all of those things happening.

Lee: 00:05:08

It absolutely does help. I, you know, I certainly, when I talk to people about dev ops, um, I talked to them much that it's a cultural transformation as it is a specific set of processes and procedures. And it's more. Maybe it's an umbrella that covers lots of different things. You know, one of the questions I comes up and matter of fact, I did want to ask you about that is what's the difference between agile and dev ops. And just like you can ask the question, what's the difference between microservices and dev ops and microservices and agile and these different technologies there's they solve part of the overall problem, but DevOps kind of feels like. The umbrella that encompasses a lot of these things together, like cloud native is an umbrella term dev ops very much as is an umbrella term as well.

Mitch Ashley: 00:05:56

Yeah. I very much agree. I think of agile. Bringing in one really big thing to the table and that's resource constraining by time. I mean, I figured out earlier on in my career, any, any software project longer than three months was always going to be delayed. Matter probably longer than a month that I was always going to be late. So agile because of my learning, but some of the very smart people said, look, let's restart those top resource by time bounding it. And that's the main core principle is you build it around those, those cycles where DevOps is it isn't time bounded, but it's holding time as a critical resource to do things very quickly. And, you know, as quickly as possible, that makes sense. Of course, but it doesn't, you know, we're in a continuous integration, so we can always do testing we're in a continuous testing cycle. So we can test multiple environments because we're automating, not just the testing and integration, but the creation of environments, test environments. You've lived in product environments where you may have three, four gens of your product that you need to test at once. So it is a convergence of a lot of those things and an umbrella term, like you say.

Lee: 00:07:14

Yeah. When I started at, uh, I mentioned when I started at Amazon in 2005, we were doing what I call DevOps principles, basic ideas we were doing. Uh, th the concept of the single ownership, right? Ownership of both the development side and the operation side being single organization. So you didn't have an operations group, you had to be service owner. Um, and, but, but yet we still had the monolithic application. And so we still had, you know, two week release cycles and everyone had three days to test their part of the monolith before the release went out. And if somebody didn't get the testing done, The release didn't go out. So One the things that I found that I spent a lot of my time as, as a manager in that group was spending time getting other teams motivated to do what they needed to do in order to click the yes, I approve of this release. So we get the green light for everyone before the whole thing went out. So it was DevOps types ideas. But forgetting the agile aspect of it. And, you know, one of the first things we were doing was trying to move to a service architecture to get rid of that monolithic problem. And that's really was the, the move of Amazon into more what I would call more agile principles. And now companies like Amazon they'll release you know, Thousands and thousands and thousands of times a day, or in many cases an hour. Um, and they're very, very agile, very nimble as an organization. And that's quite a transformation over just 15 years and really it's DevOps along with agile, that's really has led to that sort of transformation A company like Amazon could not have existed without the principles of DevOps. I wonder if you've seen similar stories in other companies.

Mitch Ashley: 00:09:04

I do remember there are things you remember in your career. You're like I went to this conference, I went to the first re:Invent. And I had been working in Amazon for awhile and it, and it appeared to be like, okay, so it's a cloud-based data center environment. I can spin up S2 for storage and EC2, et cetera. Um, the S3, sorry. And, and I went to this session where an Amazon person talked about how they change the deployments, you know, from the rolling deployments, kind of where you used to, or the big weekend deployment, right? The two, every two weeks, you kind of freeze everything and everybody shows up for the weekend for pizza. And he talked about how, no, we don't do that anymore. We take where you spin up some more servers. We put the new version on there on a few servers and a segment of region of the globe or whatever it might be. We point some traffic there with the new version of things running on it. We expand that pretty soon we expand it to be large enough to cover the. Well, all of our production, then we start winding down the servers, running new version. Okay. There, that's how the clouds are different. That it's not just your data center. Right. And the same thing can happen with me with DevOps because I was running a, an it organization that supported a lot of other development organizations when we were first moving to the cloud and we were doing like early OpenStack stuff and using Amazon and some things like that. So as in this kind of automating the infrastructure part of it. And then once I started to see. Teams did more and more development on GIT and started doing smaller and smaller releases, like, okay, there's something there. And then a friend of mine, Alan Schimmel, who is CEO editor in chief, chief editor of devops.com a Techstrong group, he said, I've got this new domain, devops.com. You need to go read about it, right? Like, what is this? So I wrote my first about. Sort of the, more of a open kimono. Here's what I'm trying to figure out what this is, what exactly it is. And that started my journey onto it. And we, transformed the organizations to a dev ops organization. I later did another cloud migration or took a big model with a DotNet application, move to Amazon rearchitected, a portion of it into microservices because no one would touch 90% of the code. Those kinds of things, but you go through those, those experiences where you go. Ah, okay. That makes sense. I understand why this is useful and important. It's not, um, uh, you know, we have used to have the methodology debates, right? It's not a methodology debate. There's some real, real value and some real benefits you can get. And when you see that you go, that I'm going to do that more of that.

Lee: 00:11:53

So one other thing I see is I go and work with clients as I see the, the company that says, yes, we do DevOps, see over there, that's the dev ops team. And that it's a, it's a, the definition of dev ops is they have a group that's responsible for dev ops and

Mitch Ashley: 00:12:10

I have one. I have a dev

Lee: 00:12:12

they, set it aside. Yeah. Right. Exactly. I bought one. There we go. It's right over there Yeah So what, what's wrong with our model? What are they missing? What, what are they realizing when they do that model?

Mitch Ashley: 00:12:26

Well, DevOps, isn't a thing. It isn't a person. It's a how right. So you can hire yes. You need people and you benefit by bringing in people who've done some or all of it before. Right? Sure. It's ultimately all about people, but it's what I would ask is great. Tell me about the work that your dev ops team is doing and. How's that gone? Are you, are you like, this is great. We're kind of leaving it where it is. It's kind of keeping it happy where we are. Are you expanding it into your organization? How's that going? Cause that's a whole nother set of challenges, transforming an organization to do work that way. Um, so I mean, that's, my response is, you know, that's some managers on their resume. I implemented dev ops at our company. I have one.

Lee: 00:13:17

Yeah

Mitch Ashley: 00:13:19

Wrong answer.

Lee: 00:13:21

Yep. Yeah. I know what you mean. I've I have seen me the center of excellence model

Mitch Ashley: 00:13:27

Well, that's different

Lee: 00:13:29

That's different, right? Where they have a dev ops team. That's is to, uh, spread the word of dev ops and spread the, the process and to train the organization into the, and help with the cultural transformation. But more often than not, that's, you know, maybe they think that's what they want to do. But the end up with you have an ops team. I have a development team and here's the dev ops team. So therefore we're all set and that's the

Mitch Ashley: 00:13:52

At pizza together every day. So we

Lee: 00:13:54

Have pizza. Exactly. Yeah. They, they meet for pizza once a week, so they you know?

Mitch Ashley: 00:13:59

you know, the, the center of excellent idea and dojo's and things like that. Dev ops dojo's. Yup. I think there's the control way. We used to do things to the approved product list. Here's the approved architectures. You can, Josh, I'll do this way, software this way. And then there's the more the Switzerland approach we're trying to, um, collect knowledge and share knowledge and increase everyone's experience. And then. Uh, create some things that make, make it easier. Like here's the environment, you can spin it automatically. You don't have to go through that learning curve. Uh, several of them, depending on what you're trying to do or in the environment, here's the tool chain or set of tool chains that we've developed. And we maintain for you. Um, that's constantly changing. It's not a fixed thing, right? It's not an approved product list. I mean, you can't just go buy that off the shelf, even with the ones that have it off the shelf. Right. Um, but th those kinds of ideas of let's enable and empower and equip people for a center of excellence or a dojo or whatever it might be called that. Is is super effective because then it's non-threatening cause most people going through a transformation, a big change, the first question they don't say, but they ask is what does this mean for me in my job? I going to have a job, right. And when we started dev ops this, oh, we don't need the ops people anymore. Guess what? We have SREs

Lee: 00:15:25

a more than never.

Mitch Ashley: 00:15:26

in platform engineering and we need more people in ops doing, doing what we might have thought of as ops things. So. It's I think there's threatening ways and there are embracing ways that will bring people into the process.

Lee: 00:15:40

That makes sense. That makes sense. I, I, another model that I've seen companies use that, uh, I think it's, it's well-meaning, but doesn't quite get the job done either. It's the, I call the center practice versus a center of excellence and the, the difference, I, I think there is a, you think of a center of practice, you, you think about a multidisciplinary. Team that gets together and negotiates and figures out, if we do all of this, then this is all good stuff. And so it's more of a democratic way of coming up with the process of what we're going to do. So you get everyone together. It's much more of a, mind is much more of a kumbaya sort of experience. Right? You get everyone together. Good things will happen, which is, which is fine. That concept. But what it seems to miss is. Directed energy that a center of excellence does center of excellence will, you know, it's more of a outward knowledge transfer versus a let's collect what we can find and put it together, and maybe something good will come out of the soup that we're mixing. I don't know if you end up seeing things like that, but it's, it's much more of a law or it's much less of a directed approach to, move into that. I see this with cloud migrations to, much less of a direction and much more of a feel, good experience for the people involved than it. Is. Yes, let's focus and direct ourselves and migrating to this direction.

Mitch Ashley: 00:17:11

I think what you're saying, I don't have that exact experience what you're talking about, but I think what you might be hitting on something super important is, the worst problem to have is to not have a big problem that you're, uh, that you're rallied around going after and challenge to fix or to address or to achieve. It's, you know, we're, we're here to create standards for the organization by the standards were meant to be broken. Yeah, it does very much in our culture today, even more so with developers and dev ops and open source, I think what, what you might really be getting to the heart of it, something really important is when you have a rallying event, cry, purpose, objective goal, that helps bring people together to say, you know, we, we, the corporation. Really faced with some tough times here, economically our supply chains have been decimated and we've got to rebuild them, but we're going to rebuild them differently. We, you know, have to figure out to really create not just online systems, but digital experiences that differentiate us from the competition because they're doing it. And we're seeing the effect of it. Not so good on our side, whatever that is. That, especially if you can link it to something that's customer effecting or business affecting, not just, we want fewer bugs or something, that's very internally driven. Um, that helps say, okay, well then let's work on this, right. We're going to work together and we're going to share what we learn on the parts that we work on. And. We ha we can't do it alone. We, we can do it together. And that forces you to share and not create new silos. You know, you're wiping out old ones. Um, I was on a, uh, recording earlier today. We're talking about, we're going to start naming them, um, game of Thrones houses instead of silos, right? There's some, there's some fitting analogies there. I think

Lee: 00:19:15

Actually, absolutely. Yes. Yes.

Mitch Ashley: 00:19:18

that was the inside out now. And, uh, but anyway, the point being, I think grid you're getting after is when you have something that you're driving towards that has a purpose behind it that helps everybody know why we're doing this. Why are we doing this too? Shall pass. It's the latest, bad dev ops. What do we know? Something will be next in a year and we'll move on to that, but we'll never do it. Well, when you have a purpose and something, that's going to pull people together, then you really focus on how to achieve something.

Lee: 00:19:52

Yes. That advice. That that is fantastic. Oh the

Mitch Ashley: 00:19:58

Worth what you paid for it it's free. So that

Lee: 00:20:01

Absolutely. Absolutely. So actually read an article. it was this last week, that came out, in InfoWorld and the title of the article was devs don't want to do ops in the premise of the article was, was engineers don't want to do opposite of. And that companies need more control over their ops. And so therefore dev ops is losing favor and there articles premises at what has been replaced by is platform engineering and SRAs and that model, dev ops is going away. I figured you might have some thoughts on this article and I'd love to hear what you, what you think about this.

Mitch Ashley: 00:20:44

But I don't want to offend the author. They may be somebody really important. Um, it sounds like a real, those are really good trees article. And by the way, we live in a forest, there's a thing by, I would argue that dev ops is one of the things that helps create this other things, platform engineering, where you go, go read the Phoenix book. If you haven't. What's the first thing they do is automate setting up environments, right? That's platform engineering in a cloud environment in a, in a simplistic comparison, but it is an SRE. Uh, we do a whole show and at tech strong called the show and we were just having a fantastic debate the other day about, about the role of SRE and observability. And how much is the SRE is driving the need or do they manage observability? How it's configured or does that eventually evolve back into development? And the reason why I bring that up. Again, it's not silos, right? It's those are all part of one continuous. Um, Ecosystem of creating software that has continuity between why do we have SRE? Because we have automation and because we have more complexity than we had 10 years ago, and we have the ability now to equip people and skills people with the skills to go automate performance engineering, automate how to. Uh, be more resilient in our software and best guess what they call, they can't implement all that stuff. They're going to work with developers to, to do a lot of those things. And when, when they learn from that and it's going to help developers with understanding what is happening inside of our software, right. It developers, we think we understand it because we created it. We created it. How much of the stack we're running on, maybe a third of it. If we're lucky, right? The rest of it is all open source and third-party services and SAS, and no one person understands it. So I would argue dev ops help create it, create the need, both the need and the opportunity for those other disciplines and that they are part of one continuous thing. It kind of fall reminds me of back to the, oh, we won't need ops people anymore where we won't need dev people more. Here's the other argument I would make. I would agree with the article developers. Don't like doing ops, guess what? They're going to automate it because they don't like doing it. They don't want to at 3:00 AM calling another developer saying, I don't know what you're going doing, dude, but it's, you know, it sucks. You need to get in there and fix it and then won't do that either. So that's, that's the whole idea of. Bringing disciplines together is we're going to bring automation to the things that can help us bring, do automation. We're going to bring more data engineering into observability and do understand how to use and implement tracing better going back into our hands so we can architect it in, you know, this is your world, right? Architecting it in traceability into our code based on what we learned on the last time when we didn't have it, when we started and we had added later. So anyway, long, long, long answer to the article that you're referencing. Those are also, I wrote an article like that once, by the way, I wrote an article when I was blogging for network world, when, uh, there was a document leak by Microsoft about their new, new Microsoft phone OS and I said, yeah, the death of the iPhone. Cause I was mad at apple about something and I got. The highest hit volume hit. I also got fireball for it. Um, and then I got fireball again, three years when someone back and said he was wrong, then he's wrong now. But those are the agitator articles. So maybe

Lee: 00:24:28

it. Yep.

Mitch Ashley: 00:24:29

clickbait.

Lee: 00:24:30

Yeah. no, I know what you mean. I I've, I ran a number of articles and certainly one of the best articles. They're the ones where you can say, yeah, this person was wrong here's why, those get those digging a lot of

Mitch Ashley: 00:24:42

We call that trolling now, but yes,

Lee: 00:24:44

Yeah. That's true. That's true. try and do it in a positive way, but it's uh, it's. It's good. Yeah. Yeah.

Mitch Ashley: 00:24:51

You have the discipline to do that. Some of us don't have that, but

Lee: 00:24:57

on certain topics. So I don't think we all sometimes do and sometimes doubt it on the topic that true.

Mitch Ashley: 00:25:03

very true.

Lee: 00:25:05

So, you know the name of this podcast is modern digital business. And, you know, when I, I use words, modern applications, modern businesses, and a lot of the writing that I do. And, usually this means some combination of cloud cloud native dev ops agile is, you know, certainly SRE, um, you know, microservices, scalable architecture is high availability. All those. But when you hear the term modern application or modern business, what specifically comes to mind to you?

Mitch Ashley: 00:25:38

I think there's, there's two sides of the coin there's modernization, right. Which is kind of catching up. Right. And there are people who were in that world. Who maybe haven't invested as much in going digital or were kept up or need to, you know, rip and replace in some cases. And then I think there is contemporary modern, which is there are technologies and approaches and things that we have that are closer to, to state-of-the-art and not necessarily bleeding edge. Uh, can enable us to do things that we couldn't do three, five years ago, et cetera. So I think when I read what you write, I'm a fan boy and enjoy what you do. So thanks. Thanks for contributing the way you do when it re and I listened to your podcast. And I think, I think what you've created with this podcast is fantastic because. Our role as technologists in that side of our role is not just being technical technologist. It's bridging the gap, it's connecting and collaborating between the business, with the business and with technology teams, right? We're not doing this for something other than technology sake. You know, if your startup it's going to fail. If you're a project it's going to fail, you know, all that kind of stuff, but that's why that's why businesses are looking at technology differently. Like I don't call my team it in my company. I re I, I, I do not like to call it that because that hearkens of the day of the land of no, and kind of, we put a ball, those people in one place so they can talk stuff. So we don't have to talk to them. We're in a world today where. Businesses. See other companies do this, they, and we need to be able to do it in our business if we aren't already. And that is every executive has to be a little bit of a technology executive. It doesn't matter if you are CEO CFO chief strategy, officer, product, officer, whatever. They have their, their job is to figure out also how to leverage technology to their benefit defensively. You know, I was an offensive strategy go after new markets, increasing competitiveness, customer acquisition, whatever it is in a modern business environment. as you talk about it, I automatically think about how can these things advantage us in our company, our business, our team, our product, what we're part of, and that's the connection we have to make. That's how we can best serve all of us and our customers, our individual careers by figuring out what can we do that? we Couldn't do six months ago, or if we do get our release cycle from a week down to twice a week, what would that do? How would that change? How we work or how we deliver for our customer? And what happens is, as we do things like cloud-native and DevOps and other things is the business is Now looking at technology organizations differently, they're looking at as, as an organization, I can trust. instead of Distrust to deliver if you can deliver, not only does that mean I can go after this, I can introduce a new product. I can introduce a product in this part of the world, in this market, on this level, as an experiment, as a, you know, to test things in market. I couldn't do that before. It was always a three-year effort to get something rolled out. Right? If you sarcastic about it, but really probably happens a lot. So now businesses not only trust. To deliver, but also react when something happens that's bad. Maybe it really messed up. Maybe we guessed way off. We got to course correct fast. I think that's, what's, that's, what's important about modern business from a technology perspective.

Lee: 00:29:38

Yep. I couldn't have said it better and I much appreciate that response. Yeah. And my mind, The ability to make mistakes and missed and correct from and respond to them and, um, and, and recover from them quickly one of the biggest aspects. And that's exactly, I think, at the heart of what you were trying to say there. So

Mitch Ashley: 00:29:59

Yeah, I think there's a, we should, we should do, we should do a podcast on the side called, um, you know, what's the, you know, you can't fail over expression from the NASA era. Um, too big to fail. It's not too big to fail. Expression from that from the Apollo

Lee: 00:30:16

Oh, um

Mitch Ashley: 00:30:18

blank.

Lee: 00:30:20

I was, it, was it, um, Gene, what's his name? I

Mitch Ashley: 00:30:23

Yeah. Gene um, having a blank, which was ironic.

Lee: 00:30:28

Failure's not an option

Mitch Ashley: 00:30:29

are not option. Okay.

Lee: 00:30:31

Yeah. Gene Kranz,

Mitch Ashley: 00:30:32

Yes, Gene Kranz. So, which is actually totally wrong. It's a thousand percent. It's not enough when he has an option to fail, it's required to failure. What, what couldn't happen is people can't die. That's what couldn't happen in the Apollo 13 mission, right? It wasn't that they couldn't fail because if you think about Apollo 13, how many ideas did they try? The round versus the square scrubber and the duct tape and the hose and all the mishmash of parts. And they failed the hundreds of times to get to something that would finally work that would work in, in that environment and with the people they were in. But they same with pairing up the limb. Right. You know, I had 10, 10 apps and couldn't go above that. And what was the sequence and all that stuff. They failed

Lee: 00:31:21

many times they try and fail?

Mitch Ashley: 00:31:23

Exactly. So that, to your point, it's about. Experimenting trying, learning, you know, and applying all that and just not repeating the failures right. When, when you've already made them. But that's the environment

Lee: 00:31:37

it matters the size of the failure, right? I mean, when you're talking about, you know, a, failure, meaning the ship will die is, is one thing that is a failure because this one test didn't quite go right. And we have to do another test five minutes from now that's a, that's a whole different thing. And I think one of the whole basic concepts of agile and dev ops would be part of that is make your failures as tiny as possible. And quick as. You want more failures, but make them smaller and quicker and faster so you can recover from them quickly.

Mitch Ashley: 00:32:10

Exactly. So that, that, that attitude and you, and talking about cultural transformation, that's a huge one. That's a lot realizations point failures, not, you don't want to tell anybody about it. Failure that would career limiting move, right?

Lee: 00:32:26

Yeah, I, I went to a client once they had a huge QA department. And they said one of the biggest problems is that we spend all this time building something and then it takes six months to go through QA before we release. And I said, okay, we'll just get rid of that. Stop. Well, it can't not past, is that why? Why not? Yeah. Well, why do you need to test them the whole concept of without testing? It was foreign to them and, you know, yes, no, I'm not suggesting that everybody could not test their code before they release it. It's not at all what I'm suggesting, but the fact is you move to a model where mistake in code creates a tiny problem, that you can correct. Then testing becomes irrelevant and because you can correct refine and refresh very, very quickly. And the problem that you had up the scope of the problem ends up being insignificant. And that's really The goal isn't to not test the goal is to make it so that failures are so small that you can deal with them and handle them. And they don't ruin the entire project. They just ruined one tiny aspect of that. It's very simple and easy to recover from.

Mitch Ashley: 00:33:40

And think I totally agree and think, think about this is another thing that's changed, but we don't talk about it is we live in a world where. Massive amounts of telemetry about what our applications are doing, what our users are doing, all of that. So the real, the real answers we're actually all just testing each other's software. We don't call it that we call it. But really, I mean, seriously, because problems can be narrowed down. It can be much smaller in size and scope and we have not real time, but near real time data about what's happening. We can validate things. We can see things happening. Um, we just went through a release, a pretty big upgrade of, uh, techstrong.tv or video platform. And we moved from a different way of doing our video player and all that kind of stuff. And. We had this meeting. I'm like, are we ready? Okay. We said, we're going to do it. We did sort of a modified DevOps sprint. Here's all the stuff we're going to do in this sprint. We'll do an ad a couple of weeks and we'll release it as a recovery. We got to the point where we said this one thing, do we cut it over? Cause that's a bigger thing to cut over and did involve, did we test enough? Well, you know, no, cause I know we're not going to test everything everybody's ever going to do on our site. There is a lot more people will do. We never expected someone to do. Can we re can we react in. Information to know when something's happening. Um, at least in enough cases, we're comfortable that we can respond. That's what I want to know.

Lee: 00:35:14

That's a much more important question.

Mitch Ashley: 00:35:16

If we feel good about that, then I feel good because if we, if we're trying to achieve perfect software or, you know, bug free or whatever, there's no more Sev ones, you know, whatever kind of language. But it is a different way of thinking and I've had to change my thinking about it. I'm like, yeah, I'll really code with a lot less testing than I used to. Hopefully not to the detriment of any, of any of my users of my products. Like the way.

Lee: 00:35:44

that's great. That's great. Yeah. So, um, I want to give a plug to you if I, if I can. You're the CTO Techstrong. And you know what I know about Techstrong, you know, you've got 433,000 subscribers, I believe, according to your website, 13 million page views, a live video, stream video, conferences, et cetera. Tell me a little bit about what you think is the most important thing that Techstrong does and what you'd like to tell people about Techstrong.

Mitch Ashley: 00:36:14

Well, so Techstrong group is a combination of some media learning events. Its for an audience of people who are in software and cloud and security, some at the very senior level, a lot at a practitioner, both vendor and non. And, you know, when you fill out the thing that says, what is your work industry is your company. And we would fall into a media company. I think what, what I view it. And when I coach all of our folks of what we're doing is we're helping people advance in their. People come to fertility event in person event to a webinar, to an article, to a video show on women in technology, or, um, CSO talk for security people, whatever it might be, um, because they want to not only. The learning, they want to be informed and they want to hear from other people. They don't want to just read about it. They do want to read about it. They don't know what, just watch videos about it. They do wanna watch videos, but they, they want to consume information. Both. But people themselves offered through themselves and people offered through the medium of articles and videos and things like that. So kind of a long answer, but really what we are. People come to sites and events and shows like we have, uh, Staying, up-to-date wanting to know what's so what is going on or what is test op? I read that I read about that three, three years ago. What's happening with it today. What's happening with, uh, I heard it, the CIC D is the place to start for, for Dunlops Y Y. And tell me how that works and what I should do. Um, or the role of a CSO has changed. Right. It's not just a technologist role there in the boardroom. Must have to speak business language and understand. And how do you implement a continuous. Instant and response instead of a single incident and responding to all these things that are happening while we're doing our jobs. That's what Textron group is about, is creating a forum and bringing in experts like yourself and practitioners, um, vendors. Uh, people who can speak to that audience that needs to know we both what I need to know now and maybe where things are heading. So hopefully that helps explains that the websites are dev ops.com security boulevard.com container journal.com. Uh, the names are pretty obvious what they cover. We have a site called digital CXO for senior level for, you know, everybody's a digital executive, right. That thought. And then tech strong TV, which I mentioned earlier is our kind of Netflix like platform. That we host, uh, interviews. We do a daily TV show, um, about two and a half to three, sometimes four hours of interviews like this, you know, conversation, sometime panel conversations. We also go to events like CubeCon cloud native con Valencia. We'll be in Detroit live streaming interviews with thought leaders, practitioners there. We, um, you know, we'll be at, uh, other vendor conferences. We host vendor conferences, virtual, uh, and some in-person. So it's, it's where it kind of people meet to talk about technology.

Lee: 00:39:40

I'll put it in my plug too. I've uh, I obviously have spent a lot of time on devops.com. Uh, um, haven't done as much with container journal, which I know is one of yours that I want to pay some attention to. And, uh, the virtual conferences are great. And, and you have a ton of it, just a ton of fantastic content. So want to thank you very much Mitch, for coming on modern digital business. And this is Mitch Ashley, CTO of Techstrong, and thank you very much.

Mitch Ashley: 00:40:10

And I wish you all the best. I'm honored to be here and to look forward to other great podcasts.