Techstrong TV – April 9, 2024

Hey, live on the gang today. We've got three big topics we're gonna cover. One is about what is the end goal of DevOps here, should it have an end goal?

Second, we're gonna talk about anti-patterns in DevSecOps. And then third, we're gonna have a deep philosophical discussion about what's best for society, working from home, working in the office, some combination. Who knows?

We've got that and more live today on the Textron Gang. Hi. Good morning everyone.

Alan Shimel here for Textron Group on the Textron Gang. I'm joined by our usual gang members and a very special guest who's a longtime Textron, uh, family friend member. But first, let me introduce our chief content officer sitting here to my left or right, depending on if this is mirrored or not.

Mike Ard. Mike, welcome. Thank you.

Good to be here. Yep. Joining Mike and I at, we're at Techstrong Headquarters joining us from there, a bodes on the road and who says we don't allow remote working is our CTO and Chief, uh, research analyst at Techstrong Research.

Mitchell Mitchell. Ashley Mitchell. Welcome.

Good morning. Great to be here. Welcome everybody.

Yep. com. Amanda Reini.

Hi, Amanda. How are you? Good, Amanda.

Just check you're not on mute. com and been part of the family here for probably 9, 8, 9 years now. One and only Bob Ruman joining us very early in the morning out in la Hey, Bob, it's great to have you here.

Uh, great to be here. Thanks. Good morning.

Yeah, good morning. Yeah. Um, alright, so I, I said in the preamble, we got three main, uh, blocks we want to hit on today.

Mike, do you wanna kick it off? I do. 'cause it's gonna be a very philosophical show I see that I start to finish.

com talking about, well, what are the implications of AI for our fellow DevOps professionals? Because the goal has always been to quote unquote ruthlessly automate. But if we automate to the point now where we, what are we, are we pushing ourselves out of existence here?

Who will do what, what? Because as he points out, if the machines are writing all the code, well then what do we need all the folks for to manage this process? 'cause the whole thing will become highly automated.

I know this is top of mind for you as of late, but lots of DevOps folks are wanting to know, where's my cheese going? So first of all, I would say that automation has not always been the chief goal of DevOps. I think the chief goal of DevOps has been to break down silos and cultural among people, not process, not tools among people so that they work better together and in working better together.

We can have higher quality and go faster if higher quality going faster entails automation, that's good too. But don't, don't underestimate the power of people and of culture in DevOps. But I think we're mischaracterizing Don's article in, in all due respect, I think the point of Don's article is what is the end goal for DevOps, right?

Because if, if the initial goal was to make people work together better break down silos, okay, we've achieved some modicum of success in that, right? Uh, we've added automation to the mix. We've done a lot of that platform engineering check.

SRE check, you know, DevOps seems to be this ever growing AME ebra umbrella that encompasses many things. When is it finished? What does success look like?

What when's, when's it, when can we shut the oven off? And AI is just the latest check on, on this whole DevOps, uh, you know, uh, ones it done. And, and it promises in many ways, as you said, Mike, to be the most, uh, impactful.

But I, I think the point of Don's article is you have business people, right? The business team, dev BizOps, who's ruthlessly moving forward, let's do more faster, better, cheaper, right? Automate, automate what have you.

And then you have an IT team who says, you know, I'm just following orders here. Tell me what your priorities are and we'll make it happen. I don't think the world's that clean cut.

The other thing is, look, DevOps never had a definition. It never had a manifesto. It never had, it was always amorphous by design.

Why should that stop now? I'll leave it right there. All right, Mr.

Reman, since you are new to our show and a guest, do you wanna weigh in here because you are, after all, one of the more deeper thinkers in the land of it, A Deeper thinker. There's another T-shirt. Um, well, let's remember the days before DevOps.

I was, I was actually working production at that time, and everybody get together and we'd have a major deployment and we'd all sit in a war room and they'd put in, you know, the potato chips and the soda and the ice cream and the coffee and all that stuff. And there would be the zip files. We'd be passing zip files between servers all over the place.

That's what it was like. And then everything would go wrong. And then people be there for the weekend and get really mad and do all that stuff.

And one day somebody woke up and said, you know, there has to be a better way. There just has to be a better way because we can't afford it. And my thinking is that the foundation of DevOps is, was, is and was, uh, financial efficiency.

We just can't afford to keep doing this. And we, when we looked at it, we said, okay, well what's one of the big problems we have? Well, we have dev developers in one pot making the zip files, and we have ops in the other part, deploying the zip files, right?

And that's just not working. And maybe if we got them together, that would work out. That's the good news.

The bad news. The bad news is, is that people can only identify that, which we know what to look for. So what do I mean?

If you've never, if you've never seen a giraffe, how can you go looking for a giraffe? Right? And, and the reason I'm saying this is that what's happened in DevOps, it's almost become somewhat analogous to systems administration.

When we start looking at what people are saying, well, you know, systems, you know, make the machines do system administration. The spirit of being able to, whereas Allen pointed out of being able to talk to one another and being able to do away with this whole insanity of developers giving stuff to systems set admins and making sure it gets out the door goes away. So what's the end game?

There is no end game. I mean, that's what people want their software and they want their software as fast as possible. So there you have it.

I Don't, Mitch, I'm gonna weigh in on that too. Yeah, no, I I, you, you got my punchline too, which is, I don't think it's a sensical question. It's like, what's the end?

What's the end game of waterfall or agile or weather? It's, there isn't an end go end game. It's about adapting this approach to what's important in your business, right?

If we are like in dire straits for getting software out, 'cause we really suck at it, and it takes nine months to get a, a release out, which is kind of the days Bob was talking about, which mean, back in those days too, by the way, you had your backout plan. 'cause about half the time you had to back it all out and go re re upgrade again. But it's about, you know, what's important to the business, right?

Do we want to implement ai? Well, that doesn't mean no DevOps or DevOps. It means that's just a way of doing software.

So to me, to me it's not, I, I understand there are business goals and measurements for success. Those are all great. That's not an end goal.

I will argue something. I wanna Oh, go ahead. Sorry.

Oh, well, I just wanna jump in on what Bob said about the deep thinkers and, um, and also what you just said, Mitch. So, what spoke to me most in that article was if there was some sort of end goal, and the end goal was use AI to automate everything and remove it roles, then the question is going to be where are the deep thinkers, the philosophers, that question situations that could come up in the future, or problems that don't exist yet. If there's nobody writing code and there's nobody able to do those things, then AI is gonna come to a point where it can't solve issues in the future.

And that would be concerning. So that was interesting and made me think that we need to keep the human element, the philosophers and the deep thinking about the future. I would argue there is indeed a goal, and I'm gonna disagree with you.

And the goal is to make this stuff as transparent as possible. I think, um, we had John Willis on the show. He is a big fan of, uh, touring, I think it is.

Who said Deming? Deming. Deming, sorry.

Deming, who I think said something to the degree that any process that you can see is broken. It's pretty clear to me that we see DevOps all the time and there's tons of bottlenecks. So therefore it is broken.

AI may move it along to, from where it is today. But I think the ultimate goal is to make it so transparent is that you don't see it, you don't experience doesn't mean it goes away, but today there's too much, um, noise in the system that results in rollbacks to Mitch's point or results in vulnerabilities that aren't addressed. I think we got a long way to go here and maybe AI's a step in the direction.

I gotta call BS on you, man. All right. Because I'm gonna tell you something.

If you don't, I will. Exactly. And Mitch is ready to jump through the screen because guys, I gotta tell you, we have less rollbacks today than we ever did.

That's damn short. Right before DevOps, you know, upgrading to a new version was hit or miss at best. You know, that 12 inch stick in my eye is so much worse than the six inch stick in my eye, so it doesn't really matter.

Okay. And that, but the, but secondly, secondly, not, not just the rollbacks, but vulnerabilities. S**t.

Excuse my language. Oh God, at least we scanned for vulnerabilities before we deploy code now. And that's actually part of the process.

We never did that. I wish we did scan, but it's pretty clear we do from every guy article that we write on Security Boulevard that we are not scanning. No, no, we are scanning.

There is an article today, in fact from em did their research showed that hardly anybody scans any of the packages they download from the JavaScript files. And so it's just kind of, It's, so you're talking about SCA, right? Software code analysis is those things.

So we scan more those than we ever did before. Now do we need, can we be better? Yes, but let's, let's be clear, software coming outta the shoot today is many, many times more secure than when Mitchell and I and Bob were were what, you know, they were referencing sitting around with the potato chips and ice cream unzipping zip files.

Oh. And we had to get it done. And I, I got my kid's birthday this weekend.

I can't be here all weekend. Screw the scanning. I'll do it later.

We've automated scanning. Could scanning be better? Could scanning find more vulnerabilities?

Yeah. Yes. And it is, it's getting better.

But make no mistake, you know, it's very easy to put the, the rose colored glasses on a wax nostalgic about the old days. The old days weren't the good old days. Hardly at all.

I don't think anybody's saying that. I'm arguing That we make tremendous progress. You Were describing the Stanley Steamer age of software development, and the rest of us are going, where's my flying car?

So, exactly. I did read that article and I was a little surprised of, of the, the vast percentage of incidents they did find. I think it was like 47% of malicious code in the software, which seems kind of high to me.

So it's Mitch, what do you say? Well, um, sorry, not to gloss over what you said, Amanda. 'cause I'm thinking about that.

I go back and re reread that part of the article. Um, I think so I'm just gonna pick on you a little bit. Not as much as, as Alan did, Mike, the flaw in what you said was DevOps is not a process, right?

It's a, it's a method, it's a, uh, an approach to developing software. So it can't be invisible because you're continuously improving all different aspects of it. And that's why rise of DevSecOps and platform engine, all these different things come about.

Or you can localize it just about CICD, which I think we're gonna talk about in a bit. So that, that's my argument about it shouldn't be invisible. It should have low friction and it should facilitate getting software out the, the right software out the door at the right time.

But, but yet, I'm sorry. Yeah, Bob. Oh.

And, and yet we have the corporate paradox of the title called the DevOps engineer. If DevOps is a way of life, then what does a DevOps engineer do? Engineer my life, right?

But there are people out there lined up around the corner trying to hire DevOps engineers, right? So that's sort of, that just sort of strange to me, which is, again, going back to my argument that this notion of DevOps can only be interpreted in the language you have, which is, if I'm a system admin, guess what DevOps is? Systems administration.

Right? Or if I'm not so much a system admin, if I'm a corporation or an I or a CFO or an A CFO, more likely I can only imagine my organization to have, um, s system administrators, people that run, you know, turn the dials, people that, you know, uh, um, tighten the bolts. And for that, I need an engineer.

I need a DevOps engineer, which, you know, meet, meet the old CIS admin and new is Nuys admins did DevOps. Well, He makes 2 cents job. But Bob, he makes more money as a DevOps engineer.

Yeah, that's true. That's true. Okay.

Or he is actually, he's gonna make a lot more money being a platform engineer. Engineer. Exactly.

There you go. But, but let's talk about bottlenecks for a second, right? You know, again, I'll go back to, to, uh, Phoenix Project, which is based on the goal, right?

The very nature of, of business in the goal it was manufacturing in, in, uh, Phoenix project, its software manufacturing is, there's always bottlenecks. You're never gonna be done with bottlenecks. You're never gonna reach nirvana by definition.

It's almost unknowable and reachable. You can know, you know, it's like knowing God. You can't really know it's something on faith and you don't know the essence of, of, of the deity.

Um, but the very nature of this process is as soon as you solve one bottleneck, it now gives you vision and to the next bottleneck and so on and so on. And you, and, and to a certain extent, that's the way of DevOps the same way. It was the way in the goal is trying to get to those bottlenecks and solve them as quickly as possible so we can get to the next one.

And that's the whole right to Don's full circle to Don's article. If the goal is to remove bottlenecks, you're never gonna reach your goal. And maybe DevOps was set up that way to begin with, never to have an end goal.

Have we, have we exhausted this? We have not. Okay.

Mike's ready to, To go. I'm gonna, I'm gonna come back on it and say DevOps is a means to an end. It is not the end in itself.

And therefore, what is the end? And the end is to make the business more efficient, more effective. I would argue the DevOps tail is wagging the business dog.

Because now the business is having a hard time keeping up with the pace of change from DevOps. There's still work to be done on the DevOps side, but the business side of the house is sitting there going, I'm not sure we can absorb the frequency of updates and changes. We see it in the digital transformation conversation all the time.

But DevOps is itself, is not the goal. It is something else. It empowers mm-Hmm.

I don't know. I'm talked out on it. Mitch, Amanda, Bob, anything else?

I'll throw one more thing in is that I think what's changed with DevOps is that the frequency of change is much greater, but the degree of change is much smaller. You know, the days of Bob and I sitting in the conference room, you know, why didn't the, the implementation, what happened with the installer, the database conversion script, you know, those, those days are over. So we all live in the, in this world where we're in our software's in constant change, how often does Zoom and Chrome and everything else we use update itself every day?

Now getting a an enterprise system to working in that kind of fashion is no small feat. But I think the change can be smaller Mike, than what the business is used to saying, I, I just changed our process to match the new version of software. Don't change it again.

That, that's kind of the old days. At least to me it is. Fair enough.

Alright. You know what, let's take a quick break. And by the way, excellent article to our by our friend Don McVety.

But let's take a quick break. We'll be back here in a second with more text on gang. All right folks, welcome back.

We are now gonna talk about our second favorite most contentious philosophical topic. DevSecOps, our friends at Techstrong Research have a new report out about anti-patterns as it applies to CICD and security. And I'm gonna let Mitch explain what's in there.

But it seems like to me, just to get the argument started, you know, we're saying you should take your vitamins, but I don't know, what do you, what's in there, Mitch? Yeah. Every day.

But, but you know, we don't always do that, right? Well, so, so what this was about is actually is a collaboration with Red Hat, looking at, uh, supply chain security, a software supply chain security, and thinking about the DevOps pipeline in particular around the CICD process. But you can think about it more broadly than that.

And an anti, the definition of an anti pattern, at least for the purposes of this report, is a pattern or, or practice that kind of gives you a false sense of security. Like doing these things. I'm good, I don't have to do more.

That's, that's, you know, that's fine. I'm secure. So scanning images that I put into my software supply chain, uh, getting them from a reliable source, uh, scanning for vulnerability, those are all good things.

Nothing wrong with that. But is that enough? If, if it was enough, we wouldn't have supply chain attacks.

So we, we talked to people about what are they doing to secure in the inside of the, the workflow pipeline, the DevOps tool chain, and how software and, and workflows through that. And sort of the, one of the interesting conclusions was one approach that's being used is using kind of a cloud native, some aspects of it where you containerize and compartmentalize different parts of the, the CICD process of the supply chain and secure it at a more granular level. And people were using kind of that approach, barring some ideas from Cloud native and things we've had before, cloud native.

But that, that was really interesting to me and how many people were either considering or doing that. The other is, you know, there were substantial number of people that reported they'd had, uh, some kind of a breach or some security incident in their supply chain, uh, in their own software development process. So, pretty fascinating work.

I thought it was great to work on it. Bob, what's your take on this? And I'm gonna ask you this question in this context.

Um, we hear the phrase sh shift left all the time. So who should be in charge of this security? 'cause some people would say, pardon my French, that shift left equals s**t left.

And people are complaining about that. The developers are saying, I can't handle a cognitive load. I can barely do what I'm currently doing.

So where does this DevSecOps security function belong in your mind? It, it's a good question. 'cause this is, you know, one aspect of it, this is about securing how the pipeline of where we create software versus the security of the software we're creating in that, that flows through that pipeline, if that makes sense.

And, and it's pretty clear that, you know, you, Bob was talking about, you know, the cis admin, you know, new boss, the same as the old boss, right? The DevOps engineers doing this work. Those are the people who are really probably gonna have to do most of this heavy lifting.

'cause the security engineers gonna go in and configure Jenkins and configure, put it into containers and do all those things, right? Maybe some platform engineering might help if, if they need that. But it's really a system administration function for the development tool chain.

So I think in that aspect, it lives more in the people who support the underlying tools and how they integrate and how they're secured in a software development process. Bob, appreciate your perspective on this. Yeah.

Question and feel for you to disagree if you don't think this Is a or not. No. I have a question for you, Mitch.

In your research, were, were the companies looking at the artifacts or were they looking at the, uh, the, the, the artifact deployment process? Um, 'cause I, and I'm, I'm asking you that was it for more, okay. We're just, we're just gonna take the code, we're gonna stick scan the artifact, we're gonna send it out, or were they, were they actually looking at the process of which inspection happened?

That's my question to you. Yeah, It is a great question. It kind of goes at the heart of what the research about.

Yeah. Looking at the artifact, most people are doing that, the scanning and making sure what you're producing is secure. What you're consuming is secure.

But there, what we're starting to do more work on is securing the process of how that art artifact flows and then gets out the door to the, to your ladder example. So that's, yeah. And then that was the real kind of aha in It for me, right?

And then it goes to architecture. So I remember when, when I was at one company, one of the big battles was whether to have your own private repository. And this was back n not, not, it was back in the middle days of, of Docker.

So are we gonna go out to Docker? Are we gonna trust that you know, the, uh, the images out there or secure? Or are we gonna say, no, we're ne we're never gonna do that.

We're gonna create our own repository. We're going to use images that are only ours, even if it's a well-known, uh, image, we're still gonna bring down those docker files in that source and do it ourselves. And that was a huge fight.

That was a huge fight. Mm-Hmm. And that was a fight that actually the company I was at at the time got lost.

They went right to, they, they relied upon Docker. So now the question, is it also in saying the CIS admins also is, well, what is the, what are the role of these, you know, enterprise level repositories? And I, I'm seeing that.

I mean, honestly, I get caught in, um, when, when I, when I run an NPM install, uh, I get caught a lot. I get caught a lot. You, dude, you got a lot of high vulnerabilities in there.

So it's showing up in my work, but the honest, if I'm doing just a demo, I check it in. Mm-Hmm. And so now who's insured there?

You know, Bob did a badie, right? And so what, in, what in the development pro in the deployment process is one, where's the security check happening? And I defer that to you, Mitch.

And the other one is where, what is the se security architecture again? Local repos, global repos. And you got me, I'm, I'm interested to learn.

Yeah. Uh, it's, I think that debate is still going on very much. Um, Rob, uh, Bob, sorry.

Uh, but I think the thing that's shifted is we're not gonna just rely on a, uh, you know, some external repository where it's docker or it's anything else. Um, where are we getting that stuff from? And then let's bring that into our own environment and make sure it is what we think it is, and that we consistently use that from our repository and flow it that way.

Now, every, is everybody doing that? I don't think it is. So, and I promise I won't call you Rob again, so That's cool.

Why not? This is, yeah. His name is Robert, but, um, It is Robert.

Yeah. Before a judge. Yes.

Yes. But to me, not trouble. So we don't use that name.

But to me, here's, here's an issue though. It, it's more of a, who's watching the watcher issue? Yes.

Yeah, I agree. Right? So we, we have, we've, we've put in these processors that theoretically not processors, processes that theoretically are checking the software that we're getting from repos, whether they be public, private, local, global, whatever.

However, we're relying on the software that's checking those artifacts or repo items to in fact, be themselves not corrupted. Right? And who's watching that?

Who's checking that? Who's checking the tools we're using on the factory floor to, to assemble the software, right? And so it's not the classic DevSecOps conundrum of, let's throw another straw on the developer's back.

It's more of a, who's watching the watchers? Can, can these tools be self run, self checks? Do you trust them to run self checks?

You know, um, should there be a, an integrity check of the tools as part of your SBO or something like that to make sure you know, nothing got introduced after you downloaded it from whatever repo you are using. There's, you know, again, as soon as you solve one bottleneck, we find the next bottleneck. As soon as we solve the problem of scanning software coming from repos, we, we worry about is the scan, are the scanners corrupted?

And, and I'm sure once we fix or solve that, there'll be another bottleneck issue we need to hit on. And I, but you know what? That's, that's why this tiger has stripes.

Maybe Mitch, do you think maybe it's a hollow debate, right? We see it in the industry all the time, but the more I think about it, I'm kind of like, trust nobody, the developer, don't trust them. But there's gonna be stuff thrown into the build.

Don't trust those people. 'cause they can make mistakes as well. And then by the time the whole thing gets deployed in production, somebody's gonna do an update anyway.

So you gotta check it on the far right side of the equation. So maybe we should just be, you know, I, we throw around the phrase zero trust, but I'm more of the presume everybody's guilty till otherwise proven innocent. That, and that is zero trust.

Mm-Hmm. That is zero trust. Well, you hang around with security people long enough and your, you know, software folks will become that way as well.

I, I think it's, I I think it's more taking out the, well, I personally trust them, and I think that's a good source. And I'll use that and I'll download my code from there, which you can do on your own or smaller development team. But it's more formalizing where are we getting our code?

How do we know we're getting it in a way that it's secure? And how are we know that we consistently use that as opposed to something that might have been ingested or added to it. It's almost like, as you were talking down, I was thinking about, it's like the movie inception.

How many le how many layers deep do you have to go to plant that seed, right? That's gonna change an outcome. Um, and that's kind of what what we're describing is do I have to go look in every piece of open source software that I deploy in my code?

Well, maybe my scanner's doing that, but it's probably not doing all that either. So at some point, you know, there's the diminishing returns, right? We will never stop scanning.

Yep. So the, the, the other point about it though is, you know, philosophically zero trust sounds great, right? What could be wrong with that?

But then it runs headlong or head first right into the wall of I gotta do more, faster and zero. You know, the old saying about your civil rights end at the tip of my nose, zero trust is fine until it runs into the tip of my, I want to go faster debate. And that's what happens is zero trust can wind up slowing things down.

And and when they do, people scream. When it does people scream. I'll throw this out to any one of you three remote folks, but, um, there was a book a long time ago, Ralph Nader wrote it, said, unsafe in any speed describing cars, are we unsafe at any speed with software development these days?

Well, I think there's always gonna be a safety issue, but it just requires constant vigilance and good communication. And maybe as the article said, some frown work, some groundwork, uh, that, uh, needs to be put into place. And, um, just having a good plan of action, um, for defense.

All right. I think we can end it there. But to Amanda's point, I think the saying goes something like, um, freedom requires eternal vigilance.

Is that where we are? I've heard that before. It does.

You know, I'll also put in that democracy is the worst form or the best of the worst, right? And, and that's kinda what we've got. All right.

We're gonna take a break on Text Trunk Gang. We'll be back here in a second. All right.

We are back with our third philosophical argument of the day. And we're talking about this whole push to get everybody back into the office. There's, uh, an interview that we did with, uh, Tite Patal, who's over at Cisco.

He is one of the senior vice presidents. And he has some things to say about, well, why you may not wanna have people come back to the office. Let's run that clip for a second.

The future of work, in my opinion, I very strongly believe in this is gonna be hybrid, where people are gonna work in mixed mode. There'll be times that they go into the office that there'll be times they wanna work from home. There'll be times somewhere in the middle.

I actually think it would be like very regressive for society if we required everyone to be back in the office five days a week. Because what that does is makes geography such a disproportionate, um, you know, prerequisite for economic participation and economic success. So I actually don't think it's a healthy thing to go back to pre covid days.

And everyone worked from the office five days a week. I think the next generation of leaders need to figure out a way that they can build strong bonds and relationships and serendipity while being, uh, while never having met someone in person. All right?

So he is saying that having everybody move to New York or San Francisco, or Chicago, wherever it may be, is bad for society. It's bad for the economy. It, uh, reduces the ability to have jobs that they can have well paying for and live in nice little towns somewhere that would in turn drive their local economy.

I know we have talked about the merits of working in the office versus remote. What's your take? So I have an opinion or two on this.

So keep in mind myself, I and Mitchell knows this. When, when we co-founded Still secure, I worked remotely for the most part for 10 years, 13 years. Not true.

When we first started the company, I actually lived local in the Boulder area for three or four days a week and then commuted back and forth. Um, I've been through CO as we all have, and I'm talking as a CEO now as well. There are layers and layers to this discussion.

The first discussion I'm gonna answer strictly as a CEO, I don't care what you tell me. Doing this on Zoom is not the same as having Mitchell, Amanda and Bob sitting around this table with us. There would be more interaction, there would be more productivity.

There would be a warmer feeling of togetherness than than doing it like this. If I had my druthers, I'd fly them all to Florida and do it here, right? And that is equally as true with people working in office.

Yes, there are certain disciplines, certain, uh, job functions that it's not maybe quite as important to, but overall from a societal impact, it, it, it works better when people are together, no doubt about it in the same place. And, and back to your society point, You got this finger weighing at me, I'm Sorry. Um, to your society point, you know, I'll take, San Francisco is the perfect example, right?

San Francisco in many ways a ghost town today. 'cause it's not just the people aren't in the office as much, but you need a critical mass of people in the office so that the breakfast restaurant has enough customers to serve breakfast to so that the lunch places and the bars after work and restaurants have places so that the dry cleaner can drop people, drop their stuff off and do their thing so that the print shop down the block and think about all of, and if I want to go retail shopping during my lunch, not on Amazon, I want to feel a shirt, right? You need, I mean, this goes to fundamentally, you know, society.

You need critical mass of people. It would be nice if Mitchell was out on some big cloud ranch in Montana, and Bob was on some seaside villa in Baja California, and Amanda's out on St. Pedro Island, and, and you are up in Galloway, Ireland, and I'm sitting here, right?

And you all would be really happy, but we wouldn't really, it's hard to do a business like that. Are the tools better? Yeah, but I I I think they're a, a pale in comparison of working together.

All Right. Any of your remote folks have something to say about this? Well, I will say, um, while I see so much value of coming together in person, and I hear everything you're saying and do agree to some level, I think what outweighs all of that is comfort of working from home.

Um, in, in the environment that you enjoy. You can be in your pajamas if you want to, you can work. But that's exactly my point.

If you're in your pajamas, go get a different job. I don't want people in their pajamas. I want people dressed for work.

Because how you dress has a lot to do with how you look at what you're doing. If you're in your pajamas, you're sitting around having fudge brownies. I beg to disagree.

I think the research and the studies are showing that people, when they're working at their comfort level, maybe it's morning, maybe they're morning people, maybe they're night people, or maybe they're midday people. I need work done when work needs to get done. Not when you feel comfortable.

I'm, I, my world works on nine to five. The fact that you got something done at 10 o'clock, God bless you, but I needed it at five o'clock. How?

Wait, Alan, how do you really feel about this? I'm telling you, I have strong feelings on this subject. I don't need people dressed in their pajamas.

I don't dress in my pajamas. Right? So l well, let me, let me tell them.

Okay. So yes, at one, I admit at one time I'm Bob and I, I'm a recovery executive. Um, and, uh, yeah, one time in, in my, my my, my long and stellar career, I, I was CTO of a of a, of a emerging trading company on Wall Street.

And, um, I worked in New York during the week and I went home into the Midwest on the weekends. And I found, and my flight time was, uh, my flight day was Monday. And I found, I was, found myself getting paranoid.

'cause I couldn't watch what people were doing. I really couldn't watch what people were doing. What are they doing?

They're probably smoking cigarettes and having a party when I'm not there. So I would start, then I changed my schedule to go every other weekend so I could watch them on Monday. Right?

And so that was more my, my paranoia. I, I, and then, so if they all went remote, I wouldn't know what they're doing anyway. 'cause the paranoia is mine.

So go, go. Going back to your, your point, Alan, as much as we'd like to have people in front of us, the, the trend, the heuristic trend I'm seeing is those days are gone. Uh, I buy a lot more from Amazon today than I do from Ralph's down the street.

As a matter of fact, the only re deal there, there are three retailers I go to now. I go to Ralph's down the street to get, get stuff that's not a Trader Joe's down the street, and then there's a guy, uh, that I go to get to get a haircut. That's it.

Everything else is pretty much done online. So the notion we're, we're all online now, but we're not all online because the, the stuff that this remote stuff applies to is knowledge workers. The guy, you know, the, the, the, the 30 the 30 construction workers building this building down the street from me, they're not online.

And it's interesting, they are remote because in a sense their, their managing office is about 10 miles away. So the point I'm trying to make here is, as much as we'd like to, you know, have people in front of us and enjoy that productivity and that intimacy, yeah, we're all shopping on Amazon now. And that, that's our future.

So let me, let me run with that a second. I shop on Amazon too. Whole Foods, right?

And I have Instacart and all that. Amanda, do you do shopping in person or online? It's a food shopping's a good mix of both.

For me, I, I'm more of a, I would call it hybrid Mike. Yeah, I think everybody's mostly a hybrid. So I will tell you yes, for packaged goods that you would get on Amazon, but I still, for, when it comes to supermarket shopping, I like to pick out the specific fruit that I want.

This is a good apple. This isn't a good apple. When you order apples from Amazon online, you, you don't get the good apples.

They take whatever the first three apples are and throw 'em in there, or the kinds of fish. And I don't necessarily know what they got fresh local in the market that day. So to me, there is no comparison of supermarket shopping in person versus doing that online.

Um, and it's the same thing with buying clothes. Yeah, I could buy my clothes online now that I've lost some weight and I, I could fit into better clothes. But until you touch it, you don't know.

Mitch, is this a, a technology challenge that we're trying to solve here, ultimately? Because theoretically, at least I could have an algorithm that might tell me how fresh that Apple is before it was thrown into a package and shipped to me. Are we just on a journey here and we kind of rushed it because of Covid, but ultimately, you know, there are gonna be technology innovations, there's gonna be better video, more ai.

Are we on just on a path? Well, I, I don't know. To, to me, we're on an evolution of doing more and more online and the shop, the grocery shopping example is a good, a good one of it ain't there yet.

The bane of grocery shopping is substitutions. I don't want that brand of peanut butter. That's not what I asked for.

And I told you not to substitute. You know, there, there are still issues to work out with it. You know, I, that fish doesn't look fresh like what I like to buy.

So there, there are things that aren't there yet, you know, and they're evolving. Maybe they won't get there in, in the world. That, and, and I'd be interested in Bob's opinion, the world that Bob and I live in of software creation, you kind of go with where the talent is.

And I can't get everybody into Denver, Colorado, or Boca or LA or what, or just hire people that are local because the talent that might be available, the person that's really one on the team is in Austin. You know? Yeah.

Come join the team. Or, or in Bangkok, right? Or Bangkok.

Yeah. Right. Exactly.

Exactly. Then we get in, you know, the whole wage compression stuff, which is, you know, and another, in another story, what will be, what will become interesting if, is if we watch the e the elu, there's two parts here. The, the evolution of the online experience in this remote work.

I'm still, of the opinion that remote work is, is is that is affected, or I'm losing my words here, but it's affected to knowledge workers. And that's only a section of the economy or everybody else. They're, they're still real time.

They're still real time. But if we look at the, the evolution of the online experience, remember, you know, Amazon started with books and now if I get a, um, if I get a thumb drive that doesn't work, which is a non-perishable commodity, if I get a thumb drive that doesn't work, I just take it down the whole foods and I'm credited within, you know, Seconds, Uh, min seconds. And so my whole shocking experience is no worse than going down to Best Buy, bringing a thumb drive home down the street, putting it in my computer.

It doesn't work. And I go back to Best Buy. The, the reason is, is that the evolution of, of the business process is such that they, it's almost immediate.

So going back, so what's the next one, Alan? You're talking about high perishables. So what happens if Amazon says, okay, first of all, we're gonna guarantee the quality.

And they have, you know, their AI looking saying, oh no, Alan and Bob and Mitch returned all these apples. 'cause they weren't any good. We've gotta to implo improve our QA around our fresh produce.

And eventually all the Apple starts showing up. Cool. Mm-Hmm.

That's where it'll be going. All right. So let me take what they're saying.

And with all due respect, you're Doing a lot of this today. Basically, Basically, basically Bob and Mitch said, Hey, boomer to you. Mm-Hmm.

And, you know, do you need to learn how to manage in a new world and a new reality? And we can long for the days when we all hung out at a table. And there is much to be, uh, benefit there, but it's never gonna happen.

Yeah. So when, and, and when it does happen, gimme a call. But until then, I'm telling you that people are not as productive working remotely because, and, and Amanda, I'm not picking on you.

I love you, but Amanda hit it right on the head. If she wants to dress in pajamas today, she'll dress in pajamas. If she's having a nighttime workday, she'll work at night.

I can't run a business like that. I really, I can't. And I think it does come down to if it's project driven work with deadlines, or if it's, you know, truly hourly, you know, you're needed during certain hours.

So it depends on the work itself. And, um, like Bob said, it's only a certain type of knowledge work that can be done Online that that works like this. Yeah.

But I'll give you another example. To Bob's point about Bangkok, look what, where's the biggest outsource for, for software development? India, Bangalore, or other cities in, in India or Pune and so forth.

There's a good chunk of Bangalore that works our North American time. These people get up and they work on our time because that's where their work is. Right?

I think that's kind of the way, and, and I'm, and I'm not, you guys can make me feel bad all you want. I'm not alone in this. I've got some pretty smart people who are saying the same thing.

Well, we can just say to people, don't put your PJs on from nine to five, regardless of where you are, because you are working with people. To Bob's point, I'm not paranoid where I don't, I gotta see people to know they're working. I know Amanda works, I see her output.

I see how many articles we publish. Yep. The the point is, how much more productive could she be if she was sitting in the same office as you?

Right. Right. Because she uses Slack.

Right. Part of this remote working thing is you gotta use the tools, gotta use the Job. A that's Our Slack anti-pattern.

That said, we cannot find people as smart as Mitch and Amanda here in Florida. So no, We can't. And maybe that's the reason why we shouldn't be in Florida.

Yes. That's what I was gonna, it brings us okay to the fact that we're casting a wide Net to find we don't need measles vaccines All the full of talent. Yes, you do.

And, and so look, I I think there's a pendulum that swings here, right? Mm-Hmm. Um, even prior to Covid, when we were seeing the boom times in tech, you hired an a software coder.

If he was in Timbuktu, you would hire him because you need as many software coders as you can get. Now, as we're seeing these layoffs and we're seeing the job market tighten up, now employers are getting a little more picky saying, I don't want that guy in Tim book too. I want the guy down the block.

You know, Alan, one thing I would say, I I do agree. When you're face to face, I mean, when we want or like have an important meeting or a, a whatever working session, we all get together wherever it is, bo on our case. Um, there's a lot to say to that.

I think one of the dynamics we don't talk about is a lot of what you're saying is ex very true for smaller, medium sized teams, right? When we're working on projects, we're working on something, we're solving a problem getting together. When you get into larger organizations, you still tend to hang out in your area.

My floor of the building, I don't go to the other floors that often, unless I got a meeting up there. And it's not that frequent. I definitely don't go to the other building, uh, unless I really have to go.

So in, in larger corporations, the, the idea of bumping into together in the serendipitous, you know, innovation stuff happens, but not, not to the same level that it does at smaller teams. Yeah. So I think that's where, where the everybody's gotta be in one building is b******t, because those people are not gonna run into each other.

They're gonna see each other maybe when they walk into the building, and they're gonna work with the people that they work with. So, but when you need people to work together on something, the best way is to get 'em face to face. I agree with that.

Fair enough. It's Kind of like when you're texting somebody over and over again and you're con continuously going back and forth, texting, texting, texting, texting, and finally you just pick up the phone or a phone call and you get everything taken care of right away. So I think most of the time, working remotely is great and, um, everything's spinning along, but then when you just really need a lot of things to come together, being able to meet in person at least once a year, twice a year is so effective.

So with all due respect to my colleague who calls me a boomer, when he's a boomer as well, this is a big issue I have with my kids. Mm-Hmm. My kids refuse to pick up a phone and actually talk.

Everything is text. Mm-Hmm. And, and again, being remote and texting, you lose a certain intimacy, you lose context, you lose.

It's not the same as even talking on a phone, let alone being in person. And you know, and you know, are we destined to live in a world of Wally where we're all gonna be fat blobs sitting on a chair at home, ordering our Amazon, slacking our coworkers, and having AI write our stuff for us? And, and you know what, what's the meaning of life?

Yes. The answer's yes. That's, that is the end state.

That is the future. Ha Mitch, uh, that doesn't sound too appealing at the end of the day. No, no, that does not.

At the end of the day, the human element and, and, you know, the relationships are so important. Safe San Francisco. Well, you know, yeah.

And, and then, you know, back in, you know, back for cars, you know, hay was important because the horses needed them. Um, and so, you know, the, the, the, the point that I'm making about that is that the experience will change. And the notion of what it means to be engaged is going to change.

The more, the thing I, the thing I worry about is that we just become so removed from this thing called reality. So for example, we, you know, at the old days when you used to get fired, at least you got called into a room. You got called into a room, and there are three other people in the room, and you had to sign some papers, and then you're given your severance check.

You know, now you get an email. Yeah, That's true too. And what does that mean?

Well, what's that? What, what? And for us, you know, we are, we are, many of us here are boomers.

So it's like, it's like an amusement to us. Okay. Okay.

That's cool. Isn't that cute? He just got fired by email.

But what happens when that, for a majority of the workforce that does work online, that's their experience of being hired, working and being fired. What does that do to one's perception of reality? I don't know.

But we saw that poor woman who was fired and she recorded it on video. And I think they, in hindsight, they'd rather have sent an email. Well, the email is a aesthetically clean, um, maybe impersonable depending on the content.

Impersonable, because I mean, to this's a great point. Look, getting fired is a traumatic experience for anyone, even if you want to get fired, right? And, you know, the fact that we do it sort of surgically veer an email or, or in the case of, uh, X Twitter, whatever they call it today, right?

They didn't even send the email first. First they cut you off from all of your e from your email and your, you know, resources and stuff. And then you had to kind of figure out, this means I'm fired.

Right? That, that's not, that's not human. That's not the kind of company as a founder of a company that that's not the kind of company I wanna run.

And, and I unfortunately, we like everyone else in tech, we've had our share of layoffs. And you know what, it's not a happy thing to do, but it's something as the CEOI feel very responsible that I have to do. It.

It, it's not my favorite thing for sure, but I do it because the people who were having the off or let go deserve it. Mm-Hmm. And that's why, um, Mike, if you could see in Your video game, Alan, right?

They don't Deserve to be laid off. They deserve your attention. They're Different.

They do. Exactly. They deserve.

They deserve, right? They do. And I feel like it's my responsibility to do that because they deserve better.

And, um, anyway, I think there's two things that we should address when it comes to this topic, which is number one, while the majority love working remotely, and that is the way, and that is the future, we do need to think about the, the mental health of those who are struggling with working remotely. Um, and the isolation. So I think we should talk about that, but also about the technology that does exist and how we harness that technology to make the remote work environment feel as human and close, um, as possible.

Like removing the distance and making it feel as personal as possible. And there's a lot of technology out there to do those things. Absolutely.

But those are for a future version of tech, uh, future episode of te uh, Textron Gang. We've gone over our time today. Hey, we hope you enjoyed it.

Bob Ruman, it's so, I appreciate you getting up so damn early in the morning out there. Um, see if you didn't work remotely, you'd be right here with us. But, um, thank you very much.

We'll have you back on soon. Keep doing what you're doing. Roll Bob cartoons, occasional essays.

Bob, just give him a Google if you're interested in seeing some of the great stuff he's doing. Mitchell, Amanda, we'll speak to you soon. Mike is always great show.

Thank you. Alright, this is Alan Shimel, Mike Ard, Amanda Rini, Mitchell Ashley and Bob Ruman. For Text Drug Gang, we're outta here.

com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery, and more. com has the largest collection of original DevOps content, featuring breaking news, blog posts, podcasts, and more.

com to learn more. com where the world meets DevOps. Hey everyone, I hope you enjoyed today's Textron gang.

It was a little hot and heated there with a couple of contentious subjects. Um, if you couldn't tell, I am a big fan of working in the office, but it was a great show. We hope you're enjoying Text Drunk Gang.

Let's get onto the rest of our text Drunk TV today. First up, it's me talking with my good friend Joe Duffy, Joe of course's co-founder CEO of Lummi. And they recently announced some new infrastructure libraries, uh, me, uh, allowing you to use a Gen AI or abstract it with the Gen AI stack.

Joe tells us all about it. Here it is. This is Textron tv.

Hey everyone, welcome back here to techron TV and welcome to our next segment. Uh, our guest for this segment is fellow who's been, uh, he's, I, I can't tell you how many of these he is done. He's been on with us many times, almost I think from the beginning of Tech Drunk tv.

It's my friend Joe Duffy. Joe is the co-founder and CEO of pmi. Joe, welcome back to Tech Drunk tv.

It's great to see you, man. Thanks for having me, Alan. Great to see you again.

Pleasure. Uh, so Joe, as I said, you've been on a long time. We, we've probably asked you this before, but I'm gonna assume a lot of people out here and a, they don't know who you are and b, they may not know Lummi either, or maybe they, maybe they think they know Lummi, but who really knows Lummi.

Joe, why don't we give us a little bit of, of the background here on both you and Lummi? Yeah, for sure. So my name's Joe Duffy, founder, CEO of Lummi.

Uh, started the company actually about seven years ago, believe it or not. We're coming up on our seventh anniversary next month, um, which is kind of crazy. Uh, before that I spent, you know, over a decade at Microsoft, uh, working on developer platforms and developer tools like T Net, uh, was leading developer tool strategy before, before leaving to start Lummi.

And the thing that struck us when we started Lummi was the cloud really changes everything about how we develop software, uh, from the design and architecture to the, you know, the implementation, uh, and of course how you run and operate it. And yet, you know, developers out there weren't thinking of it the same way. They still thought of it as, you know, the world of two virtual machines and a database.

Uh, and meanwhile, infrastructure teams were, were, you know, dealing with a lot of tools that paled in comparison to what we had built for developers over many decades with great languages and IDs and test frameworks. So we sort of thought to take a step back and, you know, we're sort of in the era of distributed computing and let's reimagine what that would look like in a modern way. So that's what plume is best known for our infrastructure as code technology, which is open source.

Uh, and we've since expanded into a broader cloud management platform with secrets management, configuration management, uh, search analytics, insights, and what we'll talk about more today, uh, AI for infrastructure. Absolutely. And, and Joe, you know, chicken and the egg question.

I think part of what has made Lummi successful is the overall success and acceptance of open source software, right? You couldn't have Lummi without open source in some, in some ways. I mean, you could theoretically, right?

But, but really, it's, it's a big piece of that puzzle. A big piece of the equation. Absolutely.

And, um, so it, it, it's an interesting thing. com or do ai, I always forget, Uh, dot com. Uh, and yeah, just click one of the blue buttons.

Get started. It is, as you say, open source in our DA super important to us. com/lummi as well, if you wanna check out the repo.

com. Very cool. All right, so let's jump into this.

You guys have some new infrastructure libraries, uh, and they involve JI Why, if you can explain it a little better than I can to our audience. Yeah. I think of, you know, we've been involved in AI in two ways.

Uh, one, using AI for DevOps automation and workflows. Uh, so we have, you know, uh, Lummi Co-pilot, which is a chat bot that can generate your infrastructure's code for you. And increasingly over time, it's just getting better.

And we're, we're able to apply that to your unique, uh, organization's challenges. But the second pillar is actually using PMI for AI workloads. Uh, when I think about AI workloads, I think of infinite compute, infinite data.

Um, and, and Plum is really good at provisioning and managing infrastructure at that scale. But the thing that we find is, you know, a lot of AI teams are not cloud infrastructure experts. So they, they have a, a thing running on their local laptop.

Maybe it's a lang chain or some AI application, but when it comes to running in production, a lot of folks aren't sure exactly how to go about that. And it turns out, when you talk to folks, a lot of the architectures are very similar. You know, there's kind of two classic patterns.

We see. There's, there's training the models and serving the models. Those are heavily GPU based architectures, uh, very gnarly stuff.

Often a lot of folks using Kubernetes for those. Um, but the second, which is what these new libraries are more about, is the application. You know, there's usually a front end, you know, whether it's a chat component or an integration into an existing app.

Uh, and then there's, you know, um, resource augmented generation rag, which is, you know, Lang Lang chain is one way of stitching together a workflow of ai. But the thing is, running this in AWS or Azure or Kubernetes, it's tough, right? And everybody's recreating the wheel.

And so these libraries are meant to make those, you know, super seamless and easy. I love it. Um, I wanted to go back to this chat bot that you have built in here.

Is that running off of, uh, your own, like custom, uh, LLM or SLM? Yeah, we've, we've built it to be agnostic to the LLM, so we can run it on, you know, uh, open AI or Azure open AI or anthropic, but we've extended it with knowledge of cloud infrastructure, uh, which is what we're good at. And, um, and so it's very good at generating cloud infrastructure or infrastructure's code to, to create that, that cloud infrastructure.

And over time it just gets better. I mean, we've, we've worked on correctness and continuing to refine the models, uh, but it is, yeah, that, that's sort of our secret sauce. Very cool.

Um, let's talk about end users out here. People, I'm sure there are people on here right now who are Lummi users, right? Customers, how do they engage this?

How, you know, how do they make it happen? Yeah, I think, you know, I'm increasingly telling people to start with the ai, um, because the thing that's really tough is, you know, you think of, we have over 150 clouds supported AWS Azure, Google Cloud, Kubernetes Snowflake, CloudFlare Datadog, and then each one of those has hundreds, if not thousands of services with different ways of configuring them. I, it's very daunting to get started.

And so I often suggest people to get started with that and just describe in natural language what you're trying to do. You know, Hey, I'm trying to build a microservice on AWS or, you know, I want a static website on Azure, and that's gonna guide you down, you know, the path that you need to go down. Um, if you know what you're gonna build, like, for example, one of the libraries we worked with, pine Cone, who's a vector database company doing amazing things.

A lot of people using vector databases. In fact, we use it for our chat bot for, uh, effectively, you know, compressing a lot of knowledge that we can then use to make the AI better. Uh, and so if you're trying to run Pine Cone in production, we now have a reference architecture for that.

Uh, similarly, another library is Lang Chain. Uh, so if you want to run Lang Chain, you've, maybe you've got it running locally on your desktop, but now you want to run it in AWS uh, our reference architecture that we worked with Lang Chain on is super easy to get up and running. So if you know that's what you want to do, just go straight to those reference architectures.

Uh, they're up on our website. Excellent. org, some other folks too.

Really, really good time. Um, and it, it, I really learned about how to train your AI and how to inject, whether you want to call it small language module or, or what have you. Mm-Hmm.

Um, but my biggest takeaway from it, Joe, was it's real. Right Now. Anyone who tells you it's not real, doesn't know what they're talking about, but the promise of what it could do, as we continue refining this and getting better at it, is crazy.

I mean, I will tell you since August, I've learned really how to do prompts, which is a nothing thing, right? Just how to write a good prompt it, and it blows me away. I, I can't, you know, as you sit here, so this is your first release with the, with these libraries, how fast, how far do you think we're gonna be going here?

Very fast, very far Short answer. You know, Honestly, things that typically take years are taking, you know, one year takes one month, uh, to make that amount of progress. So it's very hard to predict.

And, you know, that's one of the things that we face is, yeah, we can go spend a lot of time training and refining our own models, and yet GPT five is gonna come out, you know, sometime in the next few months, and it's just gonna eclipse everything we could have even imagined doing ourselves. And so figuring out where to spend the energy and the effort is, it's definitely challenging. But I think a lot of people using AI to apply it to problem domains.

You know, we talk to customers all the time. Everybody has an AI slush fund, even, you know, fortune five hundreds. It's, you know, finance, you know, healthcare, like literally every industry management is saying, run fast.

Just build value using ai. And that's very exciting. But if you're an engineer in such an organization, like it's, it's pretty hard to know how to get started.

Agreed, agreed. Um, the other thing though, and it's funny that I told you, I was on a webinar, uh, round table before I came on here, the proliferation of, well, there's the proliferation of ais, but look, you could just make sort of a generic that plugs in, you know, different ais on, on the, on the go, but the proliferation, proliferation of tools that are then AI enabled. Mm-hmm.

Right? It, because it's also speeding that up. It's speeding up a new generation of tools by leveraging this AI that I, I, at some level, I guess it's confusing for developers because, you know, they have a wealth of choices that maybe they didn't have before.

But on the other hand, it's gotta benefit them at, because, you know, we've been through the technology game before, Joe. The, the cream kind of rises to the top and the crap settles to the bottom right. The market is ruthless like that.

Yep. And, um, you know, the, the tools that are gonna rise to the top here are just phenomenal for not, I mean, the things that they could do is gonna be crazy. How do you, how do you keep Lummi have its edge?

Is open source a secret source for it? Is there something else? What do you, as the co-founder, CEO, I'm sure there's something you think about all the time.

Yeah, I think the, one of the best bets we ever made was to bet on programming languages. You know, that that was our unique angle on infrastructure's code, is we're gonna stand on the shoulders of giants. And every benefit in the domain of programming languages now accrues to plum me as well.

And that was true of, you know, test frameworks and ides and refactoring and libraries and package managers and, you know, secure supply chain. And, and now it's true of ai. You know, instantly GitHub copilot was good at writing PMI code, uh, for example.

And, you know, as the industry continues to evolve and make those things better, we, we benefit from that. I would say we also have our secret sauce, you know, our understanding of cloud infrastructure, all the metadata, the semantic understanding of the cloud, and we can use that to develop better models. And so that's where we've been focusing energy.

But my feedback to the team, there's a lot of people, I call it AI cookie licking. Everybody wants to lick the cookie so nobody can eat it. Um, everybody's, everybody's doing that.

But my feedback to the team was, sorry, that's kind of gross. But, uh, No, no, I like it. It's a great analogy.

Yeah. We used to use that phrase at Microsoft quite a bit, uh, but Uhhuh, but my feedback to the team was, let's use ai, but, but let's not do it just for AI's sake. For every problem you're facing, take a step back and say, how would I solve this in an AI first way?

And if that genuinely leads to a better user experience or a better solution, let's do it. Uh, if it doesn't, that's okay too. Um, but that's been, that's to your point on the cream rising to the top, that that's been my philosophy and how to tell the team to make sure to focus on the cream versus the crap that's gonna ultimately fall to the bottom.

Absolutely. Absolutely. Joe, we're about outta time here, but you know what, I'm glad to see Lummi is riding the wave as, as you have.

I mean, you know, I'm probably working with you now, I you only four or five years, maybe more. Yep. Um, and you've, you know, you've always kept Lummi on the edge, so I'm not surprised to see you out in front on this one as well.

You need to go have, you're gonna have to come back though and tell us how things are going. Absolutely. I'd be more than happy to, and thanks for having me.

All right. Joe Duffy, co-founder, CEO of Lummi, go check out their new infrastructure libraries that allow you to, uh, work in Gen AI here with all of the great languages and, and infrastructure that Lummi helps you with. We're gonna take a break on Tech Drunk tv.

We're gonna be back in a moment. Next up on Text Drunk TV today is another good friend of mine, Mike Nelson, who, uh, who is over at DigiCert, and he's gonna talk about DigiCert's 2024 State of Digital Trust Survey. Uh, Mike is, I believe VP of Dig Trust at DigiCert, and there's a lot of good information here.

This is Textron tv. Hey, everyone, welcome back here to techron tv. I'm so happy to welcome back to our screens today, my friend Mike Nelson.

Mike is the global Vice President of Digital Trust over DigiCert, and has been for a long time. Mike, how long have you been a DigiCert Man? Coming on nine years.

Can you believe that? Yeah. I, well, I feel, look, I know I was talking to you before Covid, so it's gotta be at least five years that you and I are talking probably more.

Yeah. I mean, Alan, it feels like our friendship goes back. You're just too, you're such a friendly guy.

It's easy, you know, it just feels like it goes way back. But I think it was, I think our first interview was right before, uh, COVID, Maybe the year before. I said, yeah, it's five years easily.

Anyway, Mike, let's start a little bit, you know, global Vice President of Digital Trust. Digital Trust, of course, is something that's near and dear and to the core of DigiCert. Um, let's talk a little bit about you though, and kinda your history and, you know, background and, and why you're kind of the perfect guy for this role.

Well, I love trust. I think trust is very important. And as our world has become more connected, we talk about, I mean, um, you look at, uh, connectivity has exploded within enterprises, um, as employees have moved home.

And, uh, COVID was a forcing function of that. As we're introducing more connected devices into our life, software is, everything is everywhere. Um, I mean, the world is more connected and trust becomes absolutely critical in connected world, and that's really the mission of DigiCert.

And, you know, I, you and I have talked about my, you know, I'm a type one diabetic. I use connected technology to kind of keep myself alive, and I've got a 9-year-old daughter who does the same. And trust of those systems is really important.

So at a personal level, I really get it as well. And I'm a huge advocate and passionate about it because I really believe that, um, I love technology, but I believe technology needs to be trusted. And so I have a lot of fun talking with people like you and evangelizing and talking about the things that we can do to make sure that as we engage in that connectivity, that we can do so in trusted ways.

Love it. I love it. Mike, I don't want to take up too much time, but I, I think most of our audience, you know, they're a technical audience.

They've heard of DigiCert. I don't know if they realize just how dominant DigiCert is in, in the space that you guys play in. Um, you know, we all, I think the first thing people think of of is SSL certificates when they hear DigiCert certificates.

And yes, that's a big part of your business, but digital certificates today are a big part of our life. Whether we're talking about our smart home equipment or our, you know, or the containers that our, our, you know, multi-threaded application, uh, applications run on, you know, whether we're talking about verifying identities of humans, machines Yep. Software.

I mean, in all, you know, the, the underlying basis for what makes the internet work is, is the ability to have faith that you are who you say you are. And it is what it says it is, and, you know, yeah. And that it's pretty much accomplished via, via digital certificates.

Yeah. Did I get that right? Yeah, you're right.

And, and, um, yeah, I mean, certificates and, and DigiCert's role with certificates has predominantly in the past been around public SSL certificates. But to your point, the use of certificates has exploded in other ways besides just for web servers. You know, today they're securing endpoints, laptops, uh, desktops.

They're securing connected devices, critical, um, you know, devices, performing surgeries and things like, uh, glucose monitors and insulin pumps. And, uh, the vehicles that you're driving, certificates are used on most of the, um, operating systems and the control units within those. And so, you know, certificates are, um, and, and most consumers don't know that, right?

When you're technical and you understand how to authenticate and how encryption is done, then you get a better understanding of where and how certificates can be deployed. But really, they're the fabric of security under most of the digital connectivity that we have. You look at software, how do you secure software?

You do it with a signed digital certificate, right? And so, um, there's, there's so many ways that certificates can be deployed, um, in this ever expanding connected world. And, um, you know, DigiCert is, to your point, as a global leader, um, we define digital trust really in a handful of different buckets.

Like enterprise, it's important that enterprise have it. Software needs digital trust, connected devices need digital trust. More and more, we're seeing digital content.

So you think videos, you think documents, all of that stuff needs trust. And so we, we pro we play in all of those different spaces and, and we're, you know, promoting trust and security best practices and all of those. You know what we're gonna talk about the, the 2024 stated digital trust report from DigiCert this year study.

But before we do, on in that vein, you're talking about, Mike, there's two, two areas I want to bring up. One is AI and deep fakes, right? How do we know, how do we know?

This is really Mike talking to us right now. And I, I mean, we actually ran a story in security Bo by a couple weeks ago. Some poor bank manager had a Zoom with some, was supposed to be the CFO of a company asking him to do a little bit of an unusual transfer of $20 million or something.

And the guy, it was him, it, you know, the bank manager had him on the video, and he knew the guy, and that was him, and it was his voice, and he was surrounded by other people that he knew. Well, it was a, it was a deep fake, yeah. It was all AI generated.

Yeah. This is something DigiCert wants to help with, right? Yeah.

Yeah, absolutely. I mean, I believe that in the content trust space, Alan, we're on the brink of some big, um, the world needs trust. Um, you think about the inability to trust content and videos.

Uh, we have elections coming up. Can you trust elections? There is so much trust that is needed, um, in the content space, and it's lacking right now.

I think people are searching for truth. And it's, it's hard to find sources of truth because content is just hard to trust. And we need the ability to know where it came from, know who the authors were, know if that person in the video is right, and to have integrity.

Even photos, we're doing a lot in the photo space right now, um, with, with some standards there. How do you know that photos that you're looking at are actually the people that are, are in it and have been fabricated? And there can be a lot of bad outcomes when if people can't trust those.

And so we need, the world needs that, and that's a, that's a critical mission at DigiCert, and we're trying to promote that. Absolutely. And, and for those who are interested in this kind of thing, you know, we were, tech Trunk TV was at the DigiCert user conference.

I was it last October? Yeah, maybe early November. Yeah.

Uh, and we had a chance to sit down and talk to a bunch of DigiCert, like some of the really smart, not that you're not smart Mike, but to some of the really smart people at DigiCert working who are working on these initiatives, as well as some large organizations that you're working with. And, and, uh, if you go over to the digis, actually it's on Textron TV too. If you look up under event events, I think the whole collection is there.

You can go and watch it. Mike, one other area around trust and around security that I, uh, I wanted to just quickly ask your opinion on. Yeah.

I did an interview a couple weeks ago and someone gave me the number that, uh, I think it was 54% of internet traffic now is API to API. Right? It's APIs Yeah.

Communicating and, you know, shuttling data back and forth. So we, you know, we, we look to test identify identities of people. We, we verify identities of devices, we identify identities of containers.

What are we doing to identify or, or trust API calls? Is that something you know about or what do you think? Yeah, I mean, APIs are a big part, um, of, of the technology that we, we deploy.

And, and there certainly needs to be trust and identity, um, with those. Um, and yeah, I think you're right. I, we, we see that the security of API, uh, connections, um, is, is paramount and having authenticity and, um, knowledge that, um, what you're connecting to is can be trusted.

And so, um, you know, that, um, we, you know, the APIs that we deploy many of our customers use, use those, and they're good security approaches that, uh, we take to make sure that those can be trusted. So I, I think those same approaches need to be, uh, employed, uh, with that. And so, um, you know, I, I haven't seen that study, but I, I do agree with your, um, approach that as those things, as we see more and more API to API connections that you still, you need trust between those If you, if you're interested, I be, um, and I hope I get this right, but I think that study came at CloudFlare.

Okay. I was talking to their cso. Yeah, I'll go check that out.

That's Interest about it. And yeah, they had a whole study on API security, and I remember thinking back then, I wonder if this is something DigiCert could help with. Right.

And I don't even know how you would go about issuing a certificate to an API, but you, you guys would know if anyone knows, you'd know. Yeah. Um, Mike, let's turn over to DigiCert's 2024, state of Digital Trust.

Awesome. Lay it out for us. Give us a little background and, and what we can expect to see here.

Yeah, I mean, I think it's, it's important to note that, uh, you know, at DigiCert we're, we're constantly monitoring, um, the evolution, uh, and, and state of, of digital trust. And I think that, um, you know, it's, it's been, it's been interesting to see the progression where we're still, where we see the world still lagging, uh, where improvement needs to be made. Uh, but we recently conduct, we recently concluded, um, our 2024 survey on, on digital trust, and I think we had some compelling findings.

I'm excited to talk to you about some of those. Cool. Let, let's hear.

Well, let's dive right into it. Um, yeah, so I mean, I think, uh, the, the first thing, just to note, you know, I think we, um, we surveyed wide and, and far, uh, it was a global survey, um, that spanned all regions, uh, of the globe. We interviewed, um, over 300 senior decision makers, uh, in the trust space from small to large enterprises.

So we, I think we had a good range of, of coverage, various industries, um, mostly targeted at critical infrastructure, uh, just to kind of set the, the groundwork for that. But, um, you know, I think that the findings, um, well, well, some of them may not shock, uh, may not be shocking, I think are leading to help us see that we are seeing some maturing in the digital trust space. Um, but I think, uh, for me, um, we're seeing more, um, we're, we're seeing it's a, a divide between the leaders and the laggards.

I think we're seeing the leaders are actually doing really good things and are employing trust practices that are protecting their infrastructure. Um, and you know, I, I think we broke our survey down into, um, you know, the leaders and the laggards, and then the, the middle group. And really most are leaders, or most are laggards.

We don't find a ton in the middle. Um, and, and I think that that leads us that organizations are either in or they're not right now. And, um, and once they get in, I think, you know, we're, we're seeing healthy engagement in the right type of activities, and we can talk about some of that.

But, um, but you know, I, I think it, it also emphasizes that, um, that getting on board with digital trust practices can be hard for organizations. But once you get the organizational commitment, the executive, uh, the executive commitment to say, look, this is an important priority for us. We, we see organizations starting to see the benefits of doing trust right away.

And, and I think that, that, I think that becomes compelling, but I think that there still is a growing divide between the leaders and the laggards. Um, it's interesting. Think some, yeah.

So, um, you know, I think that there's, um, a handful of, um, compelling things. From my standpoint, I think the leaders, one of the characteristics that we see that I think is really interesting is a centralized approach to security. Um, we see the leaders that are actually, they're doing a better job at defining policies for cyber and trust and enforcing those policies.

Instead of saying, Hey, we've got a burning fire over here. Go put it out. They're looking at it more at a strategic level and saying, what are the things that we need to do to protect our organization?

Let's create policies and enforce those policies. Um, and then once they do that, they actually bring security to the business as a centralized approach saying, look, this is not an option anymore. We need to enforce this through policy.

And that was a common characteristic we see amongst the leaders is that centralization of policy and enforcement, but then also of security solutions we see in the crypto space, um, the elimination of kind of siloed certificate management saying, look, we need to do this from a central position so that we can have control, we can have visibility, we can have, um, the ability to mitigate if something goes wrong. And so centralization is something that, to me, stood out quite a bit because, um, I think it's a mature practice. It's something that organizations should be doing from setting policies and enforcing those policies.

I Love it. Um, it's interesting, you know, so I've always followed, I, I forgot who the author is, but crossing the chasm model where it's the middle, where the meat is, right? But you seem to have almost, I call it a dumbbell, right?

It's heavy on the, on the bo on the front and the back. And people, as you say, people are either all in or they're not. And I, I can't imagine, you know, but usually when you look at a large market like this, we're not all all in, and we're not all laggards.

The middle is usually the fat part, right. People that are in various stages of, of getting there. So it, it, yeah, it's an interesting, Yeah.

And, and I look at that and I think that's right, but is security is not as efficient until it's properly managed. And once you get proper management of it, it puts you in the top group. And so, as long as you're dealing with security from a chaotic lack of management standpoint, when you're responding to a survey, I think people think it's still chaotic and they're not doing well.

So they qual they identify more with the, the lower tier, right? Mm-Hmm. Um, it's hard to say you're doing security.

Well, when you're 50% secure, if you're 50% secure or 50% in your practices, you're like, I'm not doing very well. Right? Yeah.

You don't get that confidence until you have higher levels of trust and you're doing things that are actually giving you more of a enterprise wide confidence that you have the right things in place. Yep. Does that make sense?

I Think Yeah. No, it absolutely does. And I, but I think you also hit on, you know, I've been security 25 years.

You also hit on one of the soft white underbellies of security, which is most organizations don't have the wherewithal to get there, right? Yeah. They don't have the budget, they don't have the manpower, the skillset to get there.

And, and so you can't be a little bit pregnant here. Either you're doing it or you're not. Yeah.

And that was one of, one of the findings is as we look at, um, as we look at the challenges, I think, um, you know, the increased complexity of connectivity, um, is one, you know, I think organizations are saying complexity is, we talked about at the beginning today, is like the complexity of connectivity is just skyrocketing, uh, with remote workers. Networks are becoming more complex. The applications that are connecting are, are more challenging devices, remote workers, all that stuff.

Um, but a skillset is still listed as a top reason for why people are struggling is not being able to find the right resources. So I think that still is, is a significant challenge for organizations. And an interesting thing, the number one thing, you know, when I came outta school, we didn't have cybersecurity in school.

We, you know, you didn't have a cybersecurity degree, you had computer science, but really nothing on security. Now you've got kids coming outta kids, you have people coming outta school with cybersecurity concentrations and degrees, and they can't get jobs. Right?

The number one thing we hear from those people is, how do I break into this industry? Yeah. And I can't get a job.

Every job wants three to five years. I'm just coming outta school. Yeah.

Um, so, you know, we, we've created this to conundrum of we can't get people to fill these skilled jobs 'cause they don't have skills, but we won't give people a chance to get those skills, even though they may have education behind it and everything. It, it, you know, it's a, it's a catch 20 classic, a catch 22, and, um, is what it is. Let's return back to our, our, uh, report, though.

What else is, is, you know, in the top highlights here. You know, I, I think just, uh, a compelling outcome for the leaders is the benefits that they achieve from having those in place. So you look at, um, significantly less, uh, exposure to data breaches, significantly less disruption to their business because of outages.

Um, those, you know, outages and data breaches can be catastrophic for organizations. And, um, there was dramatic variation in the leaders and the laggards with the impact of the business on those. And so as you're looking at compelling reasons to engage in that, I would say that that is certainly compelling elimination of data breaches.

Um, and, and also compliance. So a lot of organizations, uh, operate in critical infrastructure where they have regulations that they have to be compliant with. Um, the leaders, um, report a much high, it's, uh, it, uh, much higher compliance with regular regulation, um, and less impact based on, um, non-compliance to regulation.

And I think that that, um, is another, you look at healthcare or automotive safety critical systems, uh, you know, you need to have compliance and you need to have solutions that allow you to do that. And a lot of those regulations now are starting to talk about protection of data, the protection of the critical systems, and the security of those. And so having the ability to confidently say we've got the right stuff in place, um, uh, to be compliant with those, uh, is, is really important.

And so I think that there's, the takeaway from what I'm saying here is that there is business impact, uh, reputation, you know, I mean, preservation of, of income and earnings by not having to spend money on recovering from data breach or outages. There's tremendous, uh, benefit to the organizations that are engaging in digital trust. Um, and, and I think that's, that's a compelling driver, uh, to say to those that are in the laggards, you gotta get on board.

Absolutely. You know, um, it kind of reminds me of when you look at the DORA metrics and the DORA surveys and DevOps on high performing IT teams and how having a high performing IT team smooths so many bumps and, and allows you to accelerate so much faster than not having a high performing team. Yeah.

It's the same thing here with security. Mike, I, I'd love to jump more into this to you, but we're, we're at the end of our time. We got people in the waiting room.

I think we might have to do a part two on this one, that it happens every time you and I talk we wanna done. Yeah. We'd just love to chat.

Yeah. Um, before we go though, for people who maybe don't wanna wait till the next segment, we record to find out more, where can they go get this report study? com.

They can go and there will be a link where they, they can find it. And if, if you'd allow me, I mean, I, I think the, I I would love to end on this, if I could just say, sure. You know, did we have some recommendations that we're making for organizations based on the findings of the study?

And I think your listeners will find this study compelling. So I do encourage you to go, we've touched on some of it, but there's a lot more. But, um, we have four recommendations.

One is organizations need to take inventory. Um, they need to really have an inventory and understanding of the crypto assets, the security approaches that they're deploying, really understand where you are and take inventory, uh, around crypto assets. Inventory is so critical.

Um, but then the second one, and we've talked about this, is define policies. Get your corporate policies in place that govern how security is to be deployed so that you can ensure trust is there. And then enforce that policy.

Centralization of security approaches, especially around certificates, is absolutely critical, is the use of them grows. One of the biggest challenges they reported was centralized management of security. And so get centralized approaches, figure out how to do that, and then prioritize your approaches based on your business and the risks of your business.

Prioritize what you're doing and your roadmap based on the risks to your business. And, you know, I think, uh, there's a lot of compelling data in this survey. Really appreciate being able to dive in with you, Alan, on this.

And I hope you, I hope you and your, your readers can go and find some more insights from the survey. Absolutely. Well, I'm serious.

Let's have you back on to jump in. We'll peel the layer back a couple onion, a couple of layers of the onion. Mike, it's great seeing you again.

Great work as usual on the state of Digital trust report. And, um, keep doing what you're doing, man. We'll be in touch, Alan, always fun to chat with you.

Thanks for having me on. All Right. Mike Nelson, global Vice President of Digital Trust here on Digi DigiCert.

We're gonna, uh, here on text Drunk tv. He's from DigiCert. Uh, we're gonna take a break right now.

We'll be back in just a minute. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of Security Bloggers Network. Next up is our own Amanda Rini, uh, in a digital CXO leadership insight interview. And Amanda speaks with Dr.

Vic Brou about the ways in which the medical industry can embrace digital transformation to help underserved communities. Hello, I'm Amanda Ani with digital CXO, and I'm excited to be here today with Dr. Vic B Group.

He has a lot of information about the health industry and how they can digitize. How are you doing today? I'm doing well.

Thank you so much for asking. And more importantly, thank you for having me here. I really appreciate the opportunity to speak with your listeners.

Yes, thank you for coming on the show. So tell me, you've worked with a lot of underserved communities, um, and you're really passionate about bringing digital transformation to the medical industry. Um, what have you done?

Can you share a little bit about that? Yeah, absolutely. Happy to do so.

You know, uh, for me, a lot of it started when I was in medical school and I, uh, worked on a nonprofit, uh, that builds clinics, uh, specifically pediatric clinics in the developing world. Um, and so we ended up, uh, building facilities that would care for kids and their families, um, in communities in Uganda, in Central America, in Asia, quite literally in about 10 countries. Um, and that formed, I think, a lot of the base for me in understanding how best to serve and how to scale, you know, what are always limited resources because the need is that great.

Um, so digital transformation became a real, you know, key part of my learning journey, um, in terms of how to reach more individuals and how to make your services more accessible. And technology ends up being a core part of that answer in many cases. So can you tell me, how do you reach these individuals?

How are you utilizing technology? Can you give a few examples? Yeah, absolutely.

You know, across a number of different operating environments, different companies I've worked with, um, you know, you can never replace the human. In fact, you shouldn't. You should really try to maintain that human touch and feel, uh, throughout whatever services you're delivering, especially in healthcare, it's so incredibly important to establish a human connection and make that last.

But the backend technology can often be quite transformative. So if you think about, um, the connection we may feel through texting and through messaging, um, you can have a clinician. In one example, in one company I worked with, we built technology that allowed us to engage with patients in a very personalized way.

Meaning we could message back and forth together, and on the backend, the technology supported a doctor or a nurse having conversations with 10 people at the same time. Now, it's hard to keep track of that, which is why the technology was so important to be able to tee up when someone had replied how much time had passed since they were, you know, since they had messaged you and you needed to get them at least some kind of response. A lot of people ask the same questions, and so you can draft a lot of the answers that are very customized to the need of the moment.

Um, but you can do it in a way that feels very personalized. And so in that case, technology was a key part of the service delivery experience. Instead of having each letter typed anew, there were some quick shortcuts that our clinicians were able to use on the backend to still deliver a very personalized interaction with great information.

So that's just one example, but a lot of it tends to be how do you support the caregiver? How do you support the clinician? How does your technology enable scalability of what you bring to the table?

Because there's really only one of you, and there are many patients that you may need to serve. That's a very clinical context, right? So happy to share other examples about different environments, but each environment carries with it the potential for digital transformation.

I think that's what's important to keep top of mind. It's a commitment to technology and to digitizing the experience Absolutely. And getting that medical help around the world.

So in regard to that, you mentioned a few countries when a country doesn't have a lot of access to technology in the first place, how do you bring digital transformation to those countries? Um, how do you utilize technology when there isn't a lot of technology There? You know, the first thing that you know, we do, um, whenever we're operating in a new environment is to do an assessment.

You gotta survey and see what are the tools and resources when we walk in with a lot of assumptions, unfortunately, we fall behind on our ability to build correctly for the community we're trying to serve. So the first step is really assess and understand what are the tools and resources that are available. You'd be surprised in, in countries that you would, um, maybe not see the same level of infrastructure in front of you in terms of roads and bridges and so forth.

Um, you actually have some of the latest and greatest cellular technology infrastructure that's available on the market today because it's new, it's more recent. Um, so it just depends on, you know, what exact, uh, need is in the community and how you're trying to serve it with what level of technology deployment. Um, so transformation, I think is it's important to take a step back before you, um, you know, charge in, if you will, and, and, and just assess and see what the needs are before you, before you start deploying, um, some of the tools you have available to you.

That makes complete sense. So what about here, I hear more and more about Teladoc as a way to get medical help. Um, what do you have to say about Teladoc and where that's going?

And then also, um, I'm seeing more and more robots being used in the medical industry, even for, um, diagnosis, uh, at ERs they're talking to a robot, um, and the physician is at home. So, uh, and that all is of course part of digital transformation as well. So can you share a little bit about those technologies?

Yeah, there is. So there are so many exciting things happening in healthcare when it comes to new ways to deliver care, to deliver support, to be able to help understand what people need in their home environments and, and how they live their daily lives. Um, especially when we're talking about, uh, communities in need.

And so whether it's Teladoc or American well, or any other number of telemedicine companies, there quite literally are a lot on the market today that are doing some important cutting edge work on rethinking the care pathways and being able to augment our ability to understand from the patients we're trying to serve, from the people we're trying to serve, what the need is. You know, one of the things that I think is, um, it's, it's, it's very interesting to me that if you're talking about someone who has high blood pressure, the current standard of care might be seeing your physician or your nurse practitioner in an office setting once or twice a year, maybe three or four times a year. That's it.

And you might be given a blood pressure cuff or asked to buy one, and you might be tasked with writing down those numbers and bringing them in with you. But more often than not, we forget the notebook at home or we don't actually record it, um, as consistently. I did have a patient, uh, once, um, who recorded their heart rate, um, as one of the numbers instead of the systolic and the diastolic blood pressure, the top number and the bottom number that we typically associate with the blood pressure.

And it was an innocent, normal, um, thing that someone who's non-medical may not know how to do. But to me it stuck out like a sore thumb. And I was very curious why these were the numbers and why they were recorded in a certain way.

I hadn't done my job to explain properly how to record this information. And so I think we have oppor as we think about the role that digital transformation can play using telemedicine, we can connect with our patients and the communities we're serving more frequently. We can do it with digital templates that allow us to automatically collect the information and put it into our electronic record, our medical record, where we can access it and react to it.

And there's so much more that we can do that we're not doing. And if we were appropriately managing blood pressure for every single person, then we wouldn't need this technology. But the truth is, we're not, as a healthcare system, we have a long way to go to serve those people who suffer, um, high blood pressure or low blood pressure or blood pressure issues in general.

Um, you know, I don't know if you deal with blood pressure issues or diabetes or any other number of, of medical concerns, but I can tell you that if you did, I would want more for you than a once or twice visit a year to a doctor's office that may not fully allow the level of behavior change that is needed to compliment whatever medications you might be eligible to receive and so on and so forth. So the role that telemedicine and companies like the one you mentioned, as well as many others that are out there, the role is to introduce that technology to help people adopt it and learn how to adopt it, and then ultimately to access the level of support that you need. And I do think that digital health right this moment is perfectly poised to make some of these advancements in the outcomes that we drive for the communities we're serving, especially when you live a very difficult life and it's hard to go to the doctor because you may work an hourly job, you may not be given the time off that you need.

You may have other barriers to care, such as a lack of transportation and the, I could go on and on on this, right? But health equity and the ability to achieve equivalent outcomes for the people we're serving actually starts with digital transformation and a recognition of what tools we can bring to meet people where they're at. Absolutely.

And something you said there, I've actually had conversations with people who didn't have, um, easy methods of transportation and they took time off, or they scheduled the taxi to get to the doctor and the appointment was canceled or rescheduled. And, and this happens on numerous occasions to most anyone, even myself. And so especially in the underserved communities, when that's difficult to get there in the first place, that's very frustrating.

And so utilizing these technologies would be very helpful. Um, and then another thing you said, um, just, uh, in general using digital transformation as a way to track data, more track medical data of individuals, um, uh, to get a better medical diagnosis for them. Absolutely.

You know, I mean, I think that when you properly house the data and you leverage it for, uh, the outcomes that you're trying to achieve for the people you're serving, that is the full end-to-end solution. You know, you can't just do the assessment and wish that, or hope that after they leave your office, that they're gonna be perfectly empowered and comfortable and knowledgeable about what they need to do to improve their health. You've gotta provide a support network along the way.

I need that in my, uh, with my health issues. And, and I think everyone deserves that ability to receive the level of support that they need. And, and different people need different levels of support.

My parents need a little bit of help using their phone and understanding how a continuous glucose monitor can actually be, uh, applied to the skin and then connected to the app. And there are a few steps there that are not just, you know, easy for everyone to do. So in their case they need a little bit of extra support.

Um, someone else may be perfectly fine opening a box, reading a, you know, know pictorial diagram of how to do the different steps and, and be off to the races. So we've really just gotta make sure that as we do digital transformation, as we commit to it, we're building in the right, uh, user journeys and right pathways, uh, that accommodate different levels of need, different levels of support. Absolutely.

Well, thank you so much for coming on the show today and talking about digital transformation in the medical industry. I appreciate your insight. Oh, my pleasure.

Thanks so much for having me. Thank you. I'm Bonnie Schneider, sustainability contributor to the Techstrong Group.

I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter. The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry. Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong Research.

Next on the agenda, we have a Cloud Native Now podcast featuring our own Sharon Florentina, Mike Ard, and they're gonna talk about the issue of Kubernetes management, who's managing it, uh, you know, when you're building out your Kubernetes team, should you develop in-house talent, freelance contractors, what about the role of MSPs? Uh, Mike and Sharon dive into this subject, which I think is an important one for all folks as we move to this new stack. And here it is.

Welcome back to the Cloud Native Now podcast. I am Sharon Florentine, once again, I am here with Mike Vard, and we have some awesome, awesome issues to get into with you this week. Uh, the first one being as an organization, when you're putting together your Kubernetes team, how do you go about doing that?

What is the best way to staff those folks? Do you want to start building and upskilling in-house? Do you wanna bring in freelancers?

What are the pros and cons of these two approaches? Yeah, or sometimes not just freelancers, but actual professionals with skills, because there's a whole class of folks who are managed service providers who you and I are both pretty familiar with and have a lot of expertise in this space, and Yep. So I, I think the debate though is, uh, do I go hire folks or try to hire folks and retain them when they are hard to find and in high demand or, And very expensive, Right?

Or do I go with contractors that are available be, but you know, they come and go and they may not be around when I need them versus, you know, you're starting to see some managed services from outfits like Fairwinds and others. But, um, yeah, they've developed a team, they have a framework, they manage these Kubernetes clusters, and that becomes a bigger issue as you start dealing with fleets of clusters versus onesies, twosies. And I think we're gonna see, you know, everybody using a mix of all of those things, but maybe more reliance on managed services.

Because if I look in the cloud, most of what people are using from AWS and Google and Microsoft and the like, is the managed services version of Kubernetes. They're not provisioning it there. So it's not clear to me they want to provision it in a local data center at the edge themselves either.

But what's your sense? No, I agree. And I think that's, that's where the success of, um, so like you mentioned the, the AWS managed Kubernetes, uh, service is, you know, that's, that's kind of what's driving that is folks are looking at this and saying, this is, as you say, many times, Mike, this is one of the most powerful but one of the most complex technologies to ever hit it.

And people are looking at that and going, you know what? If I can find someone that I can pay to do this for me and make sure that everything works together correctly and runs smoothly and achieves the outcomes that I wanna achieve, I am just gonna offload that and, you know, be, be happy with it. Um, And there are a lot of places where they have platform engineering teams with that level of expertise, but the closer you get down to the mid-market and SMB, the less expertise there is.

So the tendency to rely more on managed services, I think edge computing all will force this issue because, um, if I start having clusters that are distributed at the network edge, they're physically in places that I don't have an IT team to get to anyway, right? So I'm kind of have to find some way to essentially manage all that. And sometimes it's just easier to hire somebody to do that than to do that myself.

Especially when, um, my internal IT team probably has a handle on my virtual machines and my monolithic applications. But do they know Kubernetes and client Right Systems attached to that and, and cloud native applications that are built on top of the clusters themselves? Um, I'm wondering, I've got my doubts.

Yep, yep. And I think people make a lot of, of, uh, noise about the cultural aspects in a previous life. One of my coverage areas was hiring and upskilling and uh, and all that, that good fuzzy stuff.

And uh, you know, there, I think there's something to be said for that team cohesion aspect that you work with these folks every day, you have a shared goal within the business that you're all working for full time. But I think there's also a place for bringing in external folks, whether that's via managed service or a, a freelance or, or a contract worker because you get a fresh perspective. Maybe they use different tools, maybe they have different approaches or ways to look at a problem that you don't.

And, uh, so I think they're, it's once again, it's unique to the organization and everybody's gotta do what is best for them and what's gonna get them to the outcome that they wanna achieve. I think there's kind of three yardsticks to look at. I mean, the first one is, yeah, how much do I need to continue to do this every day?

Do I need my team to do that every day? Or is this a task that we need to do one time only? It's kind of the reason why you see so many organizations rely on contractors to build applications for 'em.

'cause they're basically like, well, once we get the application up and running, we can take care of that part, but we don't really wanna hire a full-time developer just to write the code for us. We can get that from somebody who's a contractor. And then I think the third leg then becomes, what, what level of scale am I gonna deploy and do I have the skills and expertise to do that?

And if I don't, but my scale is gonna be large, like, I don't know, I'm gonna be using Kubernetes in, in, you know, a thousand retail stores. Maybe I am gonna look towards a managed service. So it all comes down to that.

But you and I know that historically there's always been a bias against managed service providers. Internal IT team is always a little wiggy about the fact that somebody's coming for their jobs. And, um, a lot of times the MSPs are, uh, inconsistent, shall we say, in their, uh, their flexibility and their even desire to, you know, they'll say all the right things, but in reality they got a hundred customers and they're trying to manage this thing in some way that scales and is centrally, uh, consistent.

So their tolerance for exceptions is small. Yeah. Yeah, that is an excellent point as well.

All right. Very true. Let's move On.

Let's move on to this next topic, which is kind of related, but there's a post up there on the site and talking about automation and Kubernetes, and if ever there was a need for automation Kubernetes, is it, there's more knobs and things to turn that can go wrong on Kubernetes and Misconfigurations? And I think it's part of the problem is that, you know, it's the most powerful yet complex platform to come down the enterprise. IT pike in a long time.

So we need automation. We need to find some level of abstraction up here that allows us to manage this at scale. And I think, uh, part of the reason it's holding Kubernetes back somewhat is that there isn't enough automation framework in the IT environment in the first place.

So it's not clear to me where's the, who's the chicken and who's the egg here? Is the automation the thing I need first before I get Kubernetes? Or do I bring Kubernetes in and figure out I need automation?

Either way, I gotta get there. Yeah. And it, it seems like from my perspective, a lot of folks take, take the second route where they get Kubernetes into their environments and then go, oh my God, we gotta automate this somehow because this is way, way too much.

Um, you know, and as the article talks about Kubernetes operators as a way within Kubernetes itself to do that, um, I don't know, not being a Kubernetes specialist myself, how effective that actually is. Um, tends to be, Let's talk about operators and helm charts and all this other fun stuff that's out there. So we kind of helm charts and, and other tools to help provision the infrastructure and Kubernetes, and then we have operators for deploying the software on top of that platform.

It's kind of a loose way of thinking about that. The challenge is, uh, you know, so let's say I have six things running on Kubernetes, well, that's six operators now. So, you know, that's, you know, too much of a good thing.

And if you get into some of these areas, some software, you know, open source, there's seven operators that exist that somebody built because they didn't like somebody else's operator. So now I got seven choices for that, and I gotta figure out which one to standardize on that. And hopefully sometimes the vendor or the community drives that conversation and sometimes not.

Um, I think that there's a, a big opportunity to create custom operators for organizations where, so I have a stack of software. I've got six things that I deploy, rather than having six operators, maybe I'll have my one operator that I created that will span all six elements of my stack. And I'll just provision that with a single operator.

If you look at some of the, uh, global system integrators, that's clearly what they're doing. And, you know, it's an, it is a good way to think about how to do something at scale. So, uh, don't be afraid to, you know, go in there and build your own operator.

'cause at least that one, you know, and you know, you won't be trying to figure out how to make operator A, B, C, and D actually maybe talk to each other someday. Yeah, indeed. And it seems there's also built-in tools with a lot of the common CICD, uh, tools, as I use that word again, um, you know, Jenkins, GitLab, GitHub actions, all of those seem to have added ways for folks to, to include automation as they're trying to get these tools to work together.

So it seems like, you know, there's, there's lots of options out there to be able to do that. The other thing about automation is automation for who, so is it world, the difference between a DevOps team that has programming expertise and knows how to work with APIs and can, uh, do things that, you know, your average IT administrator cannot do. They are, um, not trained the program.

Remember having this conversation one fellow about all this stuff about how, uh, he may have to learn programming skills to, uh, continue in his line of work. And he looked at me and laughed. He said, brother, if I could program, I wouldn't be in my line of work.

Right? Yep, exactly. So, um, I think we do need to have more of these graphical type of automation tools that are made for mere mortals than the average IT administrator so they can manage Kubernetes clusters at scale.

And let's be honest, even the DevOps folks don't always want to write code to go do something if they can push a button. So, um, we need to find a way to strike a balance between, you know, the classic IT service management mentality and the DevOps mentality about what to manage when using code and what can just be done with a button. Yeah, good point.

Good point. Um, I want to move on to something that always confuses me a little bit, and, uh, I'm sure there are folks out there who are a lot smarter than I am, but, uh, we had an article this week talking about the maintainers of cross plane have added Python support to their control plane. Mm-Hmm.

And, uh, first can we get into what is a control plane? What does it do? And you know how this ties into our kind of management discussion, All right.

In the beginning of time. No, I'm just kidding. Uh, but, you know, for the most part, with DevOps, we rely heavily on APIs and scripts to automate various things.

A controlled plane essentially pushed that up a level of abstraction and, and really was driven by the cloud service providers. If you look at, um, how they manage their environments, they have a control plane through which they enable their teams to. And it's a mix of folks with different levels of expertise to manage things at higher levels of scale.

Cross plane is trying to take that notion and make it more applicable a outside of the cloud and for, you know, to apply it to whether it's the edge or local data centers, but also to have ultimately one control plane to rule them all. Because part of the problem you run into in this multi-cloud universe is that now, uh, you know, I got an AWS environment, I got a Google environment, and I got a Microsoft environment. Every time I add a new environment, I gotta add more people, right?

To go manage that. And that's where the total cost of it starts to increase. So a control point provides the mechanism in Crosspoint specifically for unifying the management of these hybrid cloud computing environments and beyond just having multiple clouds, right?

And kind of, we throw around these terms all the time, right? Like somehow or other multi-cloud equals hybrid cloud. Well, in my mind, multi-cloud is just a bunch of clouds and it's a mess.

Hybrid cloud is, you know, I'm bringing some adult supervision of this thing and I'm unifying the management thereof, and I am reducing the total cost of it, which as far as I can tell in this current economic climate is an issue, Seems to be Okay. Well, that, that helps. That helps a lot.

And you know, going back to what we were talking about before, you don't, you don't necessarily wanna have six different control planes, right? Because if your, if your goal is to reduce the complexity by adding that level of abstraction or unifying something, then why would you need to do that six times? I mean, the issue with cross plane though, it's like I have to first figure out that I need Kubernetes, and then I need to figure out how Kubernetes works, and then I've got this thing cross plane as an extension of the Kubernetes API.

So there's a significant bar of skill to get to before I realize that there's this thing out there that can make my life a whole lot simpler. But, um, I think what will happen is as you start to see more Kubernetes clusters starting to show up in the enterprise, people will start saying, uh, well, how can we centralize the management of that? And then they'll get to control planes, and then they'll be like, well, can I apply this to our legacy stuff?

And people will go, yeah. And then we'll get to some rational behavior. Versus I think trying to, you know, take a legacy monitoring platform and trying to turn it into something that manages both, uh, monolithic apps and Kubernetes environments might be a bridge too far as they say.

Yeah. Um, so you had an interesting conversation too earlier this week that, uh, I think we, we wanna wrap up with. Yeah.

We were having a chat with, uh, Marcus Elli from, uh, red Hat about internal developer portals. And, you know, in the context of Red Hat, that's always a conversation about, um, using their OpenShift platform, which is a flavor of Kubernetes. You could argue it's a highly extended version of Kubernetes.

But, um, we were talking about the notion of internal developer portals, and there's a lot of interest in this idea as it applies to platform engineering, which is kind of a methodology for managing DevOps at scale. That's starting to catch on with folks. And a lot of the times it starts with, the first thing that these teams do is they go, well, let's build an IDP, which is hardly a new idea.

IDPs been since time began, but it feels like we're trying to find some way to build these things. The uh, red Hat platform is based on the IDP that, uh, Spotify originally built, which is what a lot of people are doing using Right Backstage, right? Yeah.

Truth of the matter is backstage is almost as a complicated as Kubernetes to deploy. So indeed, um, red Hat is basically saying, we will curate that process for you and streamline it, and, uh, it's part of the great subscription service that they provide. Um, some folks may look for something that's a little simpler, uh, depends on, you know, what your, uh, favorite approach may be and how complicated your development efforts are.

But it seems to me at least that a lot of this platform engineering and IDP conversation is starting with Cloud Native because it's only then that I have enough moving parts and microservices and complexity that makes this a real issue That I am I am seeing that too. And it, it definitely, that seems to be true to me as well. On the DevOps side, I would say it's, it's taking hold.

But in much, much larger organizations, which again speaks to, we have too many moving parts. Everybody's trying to use different tools and different things to reach the same goal. We need to standardize, we need to get everybody on the same page.

How do we do that? And seems to be the way. Well, here's the paradox, right?

So we embrace DevOps to get out from underneath centralized it Yeah. So that individual groups and departments can enjoy more flexibility and develop software faster, fast forward to today, and it's like platform engineering is back with a hard centralization flavor to it, and it kind of feels like sometimes we're talking about the revenge of it. Yep.

The balance is how do you do that in a way that enables scale but is not so heavy handed? And by that we mean it enables developers to kinda bring in new tools when they feel like it, or, um, is flexible enough to enable different teams that wanna work at slightly different way to do that way versus, you know, saying thou shout all the time. And, you know, there's a big difference between, I guess, uh, guardrails and fences.

And I think if you're on guardrails, you're okay. And if you're building fences that force everybody down a path, I can almost guarantee that the rebellion is not far away. Indeed.

And it will be fierce and swift. There you go. Well, I think that's all we got for this week, right?

I believe so folks, thank you so much for tuning in and listening to us chat. If there's, uh, anything you want us to talk about, please feel free to reach out and let us know. Uh, if you are an IT cloud native professional who wants to come on and have this conversation with us, we would love to have you shoot us an email.

We'll put our contact info in the show notes, and, uh, we'll get you here on camera. We'll pepper you with questions. And of course, if you're happen to be going to CubeCon in Paris in March, by all means stop by by the booth.

Indeed, indeed. And, uh, in the meantime, check out we've got some great content coming in from some of the folks who are also going to be at, uh, at coupon. com.

You can check it out there. All right folks, well thank you again. We will talk to you next week.

Next up is a, uh, session out of our predict, uh, uh, virtual event back in January 18th. And in this one, Ben debell, founder and CEO of Fortify Fortified, he explores the ongoing strategic shift towards cloud computing and addresses key factors that are gonna shape the future of cloud success. Well, welcome.

I'm gonna be talking about strategic cloud adoption and, uh, balancing innovation, legacy systems and the financial realities of technology organizations. First, a little bit about myself, um, been in the industry for, uh, last 30 years. And one of the great things I got to do over Covid was, uh, write a book around some of the things that I've seen in technology over the last 30 years.

Today we're gonna be talking about how and what some of that stuff I think is gonna be happening and influencing us for in 2024. But my book End of Abundance talks about some of these concepts that are gonna be talked about today, but there's a lot more out there as well. Um, here's how you can also reach out to me, um, if there is additional information that you would like, um, both from the podcast and the different articles that I'm writing out there.

One of the things that many of us have been doing over the last, realistically 10, 12 years, is moving to the cloud and leveraging different cloud resources in different ways. And I always like to understand, you know, sort of how did you get to the cloud? Um, many times.

I also think sometimes it's driven by, you know, I call a boardroom member driving down the highway, seeing that new technology and saying, Hey, I want to go there. Um, you know, that that definitely helps organizations get there, but was it for the right reasons? Um, when you think about your cloud choice, which cloud provider are you, uh, in?

Is that the best choice for the applications? How did you guys migrate up there? These were all the different things that sort of are impacting us today, um, both from a technology challenges perspective and a technology opportunities perspective.

So what I'm gonna be talking about today is many of the technology challenges that we have today. Um, and it's sort of coming to a point where we are having restricted and tighter budgets to support essentially 30 to 40 years of technology that we already have built. Same time as data is growing at 23% compounded annual growth rates.

At the same time, the business is actually growing at increased paces as well. And even if your top line of the business is not growing, its use of technology is growing because businesses are realizing that technology and technology services are just as important in getting their job done as it is potentially inventing and creating that new next service that you guys offer out to the market with the business, bringing more applications online, leveraging technology more. The other byproduct does transactions, our transactions and everything that we are doing and processing within technology is also increasing at the same time.

But is your budget growing at the same pace? Many of our budgets are now frozen. Prior to two years ago, many of us had these great technology budgets that we could spend, but as money has become expensive, as there has been some inflation pressures, et cetera, now we are having to deal with increased technology requests, still supporting all the leg legacy technology, but our budgets are frozen.

So how are we going to still innovate? Because many of us are talking about AI today and it's gonna create grant, great, great new opportunities, but how are we going to continue to invest and innovate without spending a huge amount of our budget? One of the other challenges that we have is, I started an insurance about 30 years ago when I started in insurance 30 years ago.

There was large amounts of technology that already existed. Now think about 30 years later, that same insurance company, all the other different technology systems that they brought online. And by the way, some of those same systems that we, that I personally worked on are still there.

Those big mainframes, those big IMS systems, they're still there. But now one of the biggest challenges for many organizations is how do we continue to invest and innovate in the new technologies while supporting the legacy technologies? And things are not getting less complex.

They're even getting more complex. So where we used to have two tier three tier, now we have interior microservices, data is everywhere. You have a hundred different SaaS platforms where all your data is across all those different SaaS for, uh, platforms, potentially having to anchor the gate that back into a central location.

These are all the different things that we have to think about as we are technologists or business individuals trying to understand how do we continue to leverage technology going forward? Businesses want more. Um, one of the, the challenges that we've had in the past is early in the day, the business didn't understand what technology did.

They thought we just maintained their email, their file systems. If something broke, my phone broke, my computer broke, I called 'em. But one of the great things that we wanted to happen, and it has happened, and it is happening, is the business understands the value of technology.

But the challenge with that, and the byproduct of that is they're asking more of us. They want us to continue to build more applications for them quicker, faster. They wanna be able to invest in the newest things that are coming around the, the, the corner.

And those are creating unique pressures on the technology groups to be able to satisfy those needs. And this is some of the things that we need to change our mindset and sort of how we approach us both in a service model, technology services, but also what we leverage in both in cloud, the cloud services and the SaaS services. But how do we balance all these different areas and aspects so that we can give the business and meet their demands and needs as well?

The other challenge that we've had is things are changing. So prior to Amazon and Microsoft really gaining traction in the cloud, it's everybody had a data center or a colo where we would buy our RAA servers, we deploy applications. Whether or not I ran them hot or hold meaning high utilization or whatever, I was not charged realistically a different amount of money to be able to support those servers at one, my one capital cost.

My CFO loved that as a very predictable expense. But now we're changing into a usage based technology model. So all this legacy technology that we're slowly migrating up to the cloud, it's the pricing of that is changing.

Now we're going to a usage based. Think about those apps, SaaS subscriptions, how many of them have some usage components in there, whether it's consumption based, user based, server based, et cetera. So as we create more technology, one is the numbers of units that are gonna go up and that's gonna increase our cost of technology.

But also, what about all that code that you wrote over the last 30 or 40 years, those processes, those systems you designed, were those designed for usage-based model? The majority of them were not. I do remember back when I started coding, we had very, uh, tight parameters on both the time we could run processes, the amount of resources we could use.

Um, you know, we had the three 80 sixes, four 80 sixes, the mainframe. We had to be very careful and co uh, cognizant around what we coded and what number of resources it took up. Today, everybody is coding and building processes on these eight VCPO boxes with 16 gigs a m.

That's what we buy our, our team. But is that creating a great outcome to go into a model just like this? It's similar to me looking at maps, right?

So how do we understand the cost of our decision to take the scenic route or the direct route? Uh, you know, this is very similar to code. So if I take a scenic route to get to my data, to get to my answer, to process a request versus the direct route to get to my destination, in this scenario, I'm gonna use potentially a lot more gas, two hours or more time.

The same stuff is happening within technology as well. 'cause everything has a cost. And one of the things that we need to change as a organization, as an individual, as a team going forward, is the way we think we need to think about efficiency and change our mindset.

And there's a great quote by Wayne Dyer says, if you change the way you look at things, the things you look at change. And when we think about, we are changing many variables both in how we deliver services, where we processes, process our services and technology at the rates at which we're investing in technology. And unless we start to change, um, our mindset around how we build those fundamental systems, we will write big checks and we'll even impact the environment as well.

And those are the things that we need to start to think about when we look at our applications, at our technology, at our implementations of our business services. One of the areas I think that needs to change is our acceptance criteria. Whenever we build technology solutions, whether it's applications, uh, database schemas, um, technology services, we all accept based upon the functionality of those systems.

So when you think about those deployment processes and making sure that that brand new feature that is being built in that sprint, what do we do at the very end? We check to make sure that it is functionally correct and then we promote it up. If we ever have issues within production within that system, what do we usually do?

Infrastructure usually adds more resources. Well, when I use to host that in the data center, adding more VVC PS or memory within VMware or virtualization, a virtualized environment didn't cost me any additional cost in a cloud environment. If I add and change the service size, the container size of that solution because I am having performance problems and I want to add more resources to power my way through that, guess what I just did?

I just increased the cost. But it all goes back down to why am I having issues? How much am I using?

And it goes back down to how did I design that process? How did I build that process? Meaning when I start to decode that process or design that data model, what are the data types I selected?

How am I storing that data? How am I accessing that data via the code? Is it procedural or set based?

Those design choices have financial impacts, resource impacts. One of the things that I see us needing to do as we move to this usage based model is start to change. How do we look at our application deployment, uh, life cycles and really step back and say, all these other variables have changed.

What else needs to change within my ecosystem? I think in the future that we need to start to look at the efficiency of code, not necessarily getting into the code parsing to determine whether or not it's efficient. Look at the runtime, the output.

Did this code run and return a certain amount of value or records per the resources? Ultimately, what's the cost of that code today? finops is a very large important aspect within environments.

How do we impact finops upstream? 'cause today, finops is focused on downstream. Once you've already built, designed, engineered, and deployed that feature, and you get that bill from Amazon, Google, Microsoft, that is after you've already realized that cost.

We need to go upstream to understand the cost of our design upstream, not after we deployed it, because it's a lot harder for us to fix it after we've already deployed and committed that to production. This is where we want to go migrate to, but it's gonna take a large amount of time hardly because we are not thinking about the cost of our design decisions. When you go and build that application today, usually you get a budget for that project team.

You get a budget for building that application. You go and design the application. People start coding, whether it's onshore, offshore, a hybrid.

And then once you've built it, tested it, you feel great about that decision, you go and deploy that to production. Then you ask your infrastructure team, well, what would be the best servers to deploy this to? Now think about this.

This is without really understanding the volume metrics of that application, the usage me metrics, the data growth, the transactional growth metrics of that application. I'm deploying it to production on servers that I'm gonna potentially guess what size on code that may be efficient, not efficient, a hybrid. And only then do I ever know the cost of supporting that app.

And that is today. And how often and how long do apps run within production? 10 years, 15 years, 20 years.

We're working with an app that's been running 23 years. Very large system. Do we think part of the the app could have been more efficient early on?

Yes, but we never know the cost of that design until the end, which is one of the challenges. And that's why we need to move upstream as well. Another area is data.

So my passion is data. Um, build a company around data. 20 years ago when I said, Hey, I'm focused on data, didn't have the same meaning as it does today.

When I talk about data, we think data analytics, we think of value. We think you know, a lot of storage. Usually people think storage.

What's the byproduct that we all have? You know, I love the HGTD show porters. I actually think most organizations, when we look at 'em and work with 'em, most of us are hoarding data.

Why? There's potential value in this data. I believe it, there's gold out there, but how much gold is in that data?

And which data actually is gold versus which one is just copper or which one is actually just byproduct? So the cost of my data is something that we're focused on because it's not just the cost of storage. Every time you have data and access it, guess what?

There's a memory cost to compute cost. But this all goes back down to really having a solid enterprise data strategy. So you're bringing all these new technologies, online line, iot, that generates huge amounts of volumes of data.

You have all your SaaS applications, you're pulling all that back, all the key data from all the SaaS PLA platforms back into a larger data lake or data warehouse, whatever. You wanna determine it. And then you start to analyze that.

But then you also have all your non-production environments that have, again, copies of the data potentially. Then you have HA and dr, which have additional copies of the data. Then you have your backup strategy, which has additional copies of data, maybe back seven years.

What about if you just added a dollar sign next to that and then told that story to the business and said, this data, do we need it? It's costing us a hundred thousand dollars a year. So this is where we want to really also start to merge financials over technology as well.

But at a greater level of detail. I just talked about code, talk about data, talk about the design decisions, which it's interesting to think what happens when I start to tell a story via financials. And by the way, what language does the business speak?

We all speak financials. No matter who is on this presentation today, I could have one conversation around financials, we'll all be able to communicate. net, we all of a sudden we are in a subset of audience that we could speak to.

It's the same thing within technology. The biggest challenge is data and code. It doesn't just execute one time.

Data doesn't just exist today. Think about what I said at the very beginning. 23% compounded annual growth rates.

I wish my bank account had that growth rate. Um, it's almost like my insurance bill does have that growth rate, which I do not want. But this is what we have today.

And if you start to look at your data footprint today, the cost of supporting all your apps today, then start to factor in growth and look at what is that three year cost? What is that five year cost of your technology? Forecast it out.

And then an interesting statistic that we have. So we've been focused on identifying efficiency of code for a while and also the cost of code. And when we think about migrating to that usage-based model and what big challenge it might have with that legacy apps, a lot of times we think we don't have time to rewrite my whole app, let's just do a lift and shift and then we're gonna fix it later on.

That has that large cost impact. But the one statistic I do wanna share with you is this 1% of your workload usually equals 50% or so of the cost or resource footprint. Again, 1%.

So if I'm migrating up, if I identify the top 1%, and a lot of times it's a lot less than that, those cause those pieces of data, those transactions, if I optimize this, that very small subset, I could potential have 30 or 40% gains or cost reductions. And that gives you back a large amount of capacity to be able to understand and process your, your uh, transactions going forward. One of the things that I think we need going forward is better financial transparency of technology.

I have a ba a financial background and a technology background, and it's, it's amazing what clarity I have within accounting at any point in time within a business, the clarity I could have. But once you jump over the technology, you start to look at what clarity do I have around the cost of technology? This server's running hot in this Amazon bill or this Azure bill.

What can I do to reduce that cost? By the way, you've already right sized it. So already in the best server size, what other options do you have?

Unless we start to have better financial transparency down the stack, the storage level, the code level, the process level, we are not able to solve the root cause of the problem and start to actually take out cost gain margin back in the business and become more profitable. Or another way to look at it is as that business is asking more of us to build more technology over time, how can we use this fine out budget, even if it's frozen or only growing one to 5% year over year as far as the technology budget? How do we continue to support more technology and organic data and transactional growth within the same technology budget?

We need to find those inefficiencies within our technology implementations today, and that's gonna give us that 30% pop that will enable us to continue to invest in innovation of technology to drive the business. Here's my contact information that you have. Um, if you wanna reach out to me, feel free to shoot me an email.

As well as there's a lot of other, um, information out there around, uh, me talking to different thought leaders out there as well as, uh, sharing some of these other ideas in more depth. And I thank you for your time. Discover the cutting edge insights of our new show, AI Times a series that explores the limitless potential of artificial intelligence sponsored by the AI Infrastructure Alliance.

The AI Times is at the forefront of the AI revolution, tackling the crucial questions of how we can leverage AI for the betterment of humanity. Stay ahead of the curve as this show delves into all things surrounding ai, including trends, pressing concerns, and the positive impact AI is making around the globe AI times. This is Textron tv.

Mike speaks with Mike Moper, who's a senior VP for product and pro product marketing at virtue or VER virtue. And they explain why a data-centric approach, a data-centric approach to cybersecurity has become an absolute necessity. Uh, as cyber attacks continue to increase in sophistication, data is where it's at.

Check it out. Hey guys, thanks for the throw. We're here with Mike er, who's senior vice president for virtru, and they are a provider of a platform that specializes in data security.

And we're gonna be talking about, well, why is data security suddenly all the rage? Hey Mike, welcome to the show. Hey, I'm glad to be here.

Thanks For so long. We invested heavily in firewalls and the perimeters and we had this whole castle and moat kind of mentality to security. And suddenly we woke up one morning and we discovered that, um, the good guys were basically flying over the castle wall and stealing all our stuff.

And it was like we had no roof. So why now are we shifting towards this data centric approach? And does that mean we spent less on the perimeter and more on the data security?

What's going on here and what's the right balance of things? Yeah, that's a, that's A great point. I think, uh, there's a few things that are, is driving this change.

Uh, it probably all started as more and more SaaS-based applications started to be the tools that organizations were using. Uh, shortly thereafter, we had that, that thing that, uh, we all lived through the pandemic where we had, uh, remote workforces. When you reflect on those remote work floor forces, uh, applications that are up in a cloud, uh, not back in a a rack, you know, in the organization, in the building where you used to work, you realize now that there is a need to be able to, uh, protect this data wherever it exists because it is now no longer just on the bare metal that is sitting at the end of the hallway in each of these organizations.

So as a result of this, uh, organizations started, um, evolving their, uh, their posture. We had gone from a perimeter centric, uh, uh, methodology. And, and by the way, about 98% of cybersecurity's investment, according to Gartner, is still rooted in this perimeter centric, um, uh, motivation.

But what we're now starting to see is, um, more and more collaboration is absolutely required with this data. So we like to think of this as, um, there's the data you store, but there's also that data that you need to share. And there's really a distinction there.

And I think that is where we start recognizing that there is a, a need to be able to have a comprehensive set of zero trust controls, not only to prevent data theft, but to also be able to promote the sharing of that data itself. So we think of this as, you know, playing both offense and defense. So defense is really equated to that perimeter centric security that we're all familiar with the, the moats and the walls and probably pouring tar over the side of the, the, the wall itself.

But playing offense is how do I encourage the sharing of this data and to be able to still ensure its governance? Uh, I want to be able to get it to you because our two organizations are trying to, uh, conduct business together. Maybe there's merger and acquisition, or you're just trying to buy some software from us.

So we wanna be able to encourage that offensive posture, uh, associated with, uh, data-centric security. And it's the culmination of these things that we're absolutely seeing more and more interest around a data-centric security posture, uh, becoming a larger and larger share of wallet, uh, when one thinks of a comprehensive zero trust investment for their organization. How do I know what data requires?

What level of security and what level of policies? Because not all data is created equal, but too often the IT and the security people have no idea. It's just all data to them.

So, um, how do I kind of go in and figure out what data represents my actual level of risk? Yeah, that's a great point. Uh, we absolutely should not be depending upon, uh, the IT staff for figuring that out.

It is the subject matter experts that really need to be responsible for that. In fact, the matter is, it's those data owners themselves that know more about that information than anybody else in that organization. So a best practice is to start tagging or classifying this content.

So, um, you know, from from hashtags on Twitter, that's probably the place that the vast majority of, of consumers or frankly the, the larger population of those that work in commercial organizations are familiar with this concept of, of tagging content. So you can find it. Um, you're now starting to see these capabilities manifest themselves in the applications that we use today.

And, and I'll give you a a great example. Um, Google Workspace now has a label capability that is, uh, pervasive across their applications, whether it's docs, whether it's slides, et cetera, by applying a label. This is confidential.

Uh, this is internal only. This can be shared with external parties. Taking advantage of that attribute that simply describes the intention or the sensitivity of that information is a fantastic first step.

Can we do that given the volume of data that we're looking at? It seems like every time I turn around and somebody's reporting that the amount of data that they're trying to manage has exponentially increased yet again, and or we're just getting overwhelmed. Yeah, that's a, that's a great point.

Uh, here's how I like to think about this. Um, if I'm creating a new document, again, as that subject matter expert, uh, it should be my responsibility to my organization to go ahead and label that document. You know, this is for internal audiences, external, et cetera.

And that's pretty easy to do. Uh, in fact, even tools like, uh, Microsoft Office 365 can prompt for that. You know, you can't save the document until you put a a label on it.

Google's workspace does the, does the same thing pretty easy to do. However, to your point, there is that fire hose of content that's being produced every single day. And it's not reasonable for us mere mortals to be able to keep up with that.

That's where I do believe, uh, machine learning is going to play more and more of a vital role in the way we classify and label content. Um, the proliferation of LLMs is a very natural place for us to be able to accelerate that. So while DLP does a great job today, uh, I do believe we're going to see a next generation of data-centric labeling that is going to take place by having, uh, an LLM that has been trained on your corpus, your information to not only go through your data at rest and give recommendation for labeling back to the subject matter experts anytime it's it's open or attempting to be shared.

Uh, but to be able to also further evaluate, uh, any inbound messages as well to potentially, uh, give recommendation to that, that control plane as well. Do we need to converge data management and data security management? 'cause it seems like, uh, many of the principles we're applying here are concepts that might have been first used in the space of data management.

I mean, what's the relationship between these two motions? I, I do think we're going to see a logical convergence. Again, if you think about a control plane from identities through, uh, the devices that individuals use, the networks themselves to the applications and to the data that control plane is going to be, um, collapsed and there's going to be, uh, uh, best of breed applications that are used for governance across that continuum.

So I think it's very reasonable to expect to see that evolve. Absolutely. In effect, are we not deputizing other arms of the enterprise team to help manage security because, well, we're shorthanded on the security side.

So do we need more IT operations people and database people and developers to all pitch in here? That's a good question. The way I like to think about this is, uh, this is a natural evolution of, uh, intellectual property and governance.

And as a result of that, each of us, uh, whether you are a DBA, uh, whether you are in finance, each has an obligation to ensuring the integrity of our most precious asset. And that, and that's the data that our organizations possess. So, um, you can, you know, if we had this conversation 10 years ago, we would've not been talking about LLMs and how ML would be playing a role in our businesses.

Look where we are today, uh, we are still going to absolutely need to have, um, CISOs that are, uh, making policy decisions across the integrity of this data. We're gonna still have SMEs that understand this data, um, most intimately. But Eva, each of us played a critical role in ensuring that we can store this data safely, we can share this data safely, and that we can go ahead and accelerate the outcomes for our organizations by getting this data exchanged with whatever that other party is that's, uh, needing to help be able to conduct that, that particular role or business.

You mentioned LLMs. Um, can we use AI to save us from ourselves here and apply that to data security? Um, like everything, um, AI is absolutely not a, uh, a crutch.

It's just a tool. And it is a tool that, um, much like, you know, maybe RegX, you know, what, 30, 40 years ago started to become some, uh, uh, uh, a, a tool in the, uh, toolbox. Uh, LLMs are gonna absolutely become another one of those tools in the toolbox.

What we absolutely expect to see very, very soon is organizations, um, developing their own, um, corpus of data and then training it against, uh, an LLM an open source model, et cetera, but keeping that running only within their perimeter so that they have no leakage outside the perimeter itself. By building that model, training it on your own corpus, you can start to do some really, really powerful things. Uh, as I had mentioned previously, the idea that you could use it to intelligently start identifying content and giving recommendation to that SME, here's how this should be labeled.

So go ahead and proactively label it. Uh, we're gonna be seeing, uh, LLMs used for that purpose very, very soon. But again, like so many things, it is a tool, not a crutch, uh, crawl, walk, run and implementation.

Learn how your end users within your organization are taking advantage of it, and then find those next logical spots to be able to, um, address more productivity and efficiency gains that will be absolutely recognized, um, by tools such as that. Alright, on the face of it, data security seems like, you know, intuitively obvious thing to do. So what's the issue that holds people up when making this transition?

Yeah, that's a great question. I, you know what it is. Uh, I think the transition is largely rooted in, um, making sure that you've got internal stakeholders that are convicted to moving this forward.

Obviously, if you're in a regulat uh, a regulatory regulated industry, uh, uh, whether it's, uh, CMMC or IAR or you know, HIPAA data that you're managing, uh, the, the stick that you get hit with, um, can really hurt. So by ensuring that your policy folks, um, are constantly working with line of business and there is collaboration there, but most importantly you make it easy for the users, the moment there is a high degree of friction for those end users, that's when mistakes happen. Uh, we saw this back in the, you know, early ts with, um, um, rogue IT where, uh, individuals started going out and, you know, getting licenses to SaaS applications that it knew nothing about.

It's because they had friction in the process. You wanna make sure that there is not friction in that process. You wanna make sure that data-centric security is, uh, complimentary to the existing business processes in the tools that your, uh, end users are using.

Don't force them into another tool. Uh, this should be as transparent as possible to them. Maybe a little popup to say, Hey, this is, you know, a confidential document and that's it.

Let 'em get back to their day job. Let 'em be able to hit send as quickly as possible. It's probably one of the most important things you can do.

Well, you mentioned the word conviction, so, um, I think if we have broken this up over the years, we always assume that highly regulated industries will have more, uh, robust security policies and tools like these to go enforce that. But it seems like lately, if I watch how regulations are evolving, especially say data privacy, isn't every organization kind of now in a highly regulated industry, I mean, won't this just become a pervasive requirement? Data security is everyone's responsibility.

Uh, even in our personal lives. Uh, I personally, uh, I am and I I'm in this industry. I am numb to the number of massive exploits we hear about day in and day out, whether it's in our own government or in the private sector itself.

This is not going away. Um, things such as, um, um, two FA, uh, is not even enough anymore. We need to be able to use other tools to, again, make it as easy as possible for PB people to be able to adopt and to be comfortable with being able to secure their own information.

Um, pass phrases, um, pass keys, et cetera. Um, continue to help advance this, but it is everyone's responsibility to make sure that that precious jewel, uh, the crown jewels that are inside that castle that are are being protected, um, are so, and um, and still yet at the same time being able to ensure that that information can be shared with the right people at the right time, yet be able to pull that data back at any point in time as well. All right, folks.

You heard your data is the asset. So you start there from security and work your way out. 'cause I think historically we've been working from the outside in, in a way that maybe, uh, makes it too easy for the bad guys to do whatever they need to do whenever they wanna do it.

Hey Mike, thanks for being on the show. Appreciate it. Thanks a lot.

All right, and back to you guys in the studio In our second view with ard. Mike speaks to ASI lab's, CEO Neil Sahota, and they dive into why cybersecurity is evolving into an AI arms race that requires eternal vigilance. I think it's always been an arms race, now it's just ai.

Enjoy this interview with Mike. This is Textron tv. Hey guys, thanks for the throw.

We're here with Neil Sahota, who's CEO for ASCI Labs. And we're talking about the AI arms race as it applies to cybersecurity because, well, everybody seems to be delving in, but it's not quite clear who's ahead, who's behind, or for that matter if they're actually doing anything. Neil, welcome to the show.

Hey, thanks for having me along, Michael, excited to be here. So what exactly are the bad guys up to? Because on the one hand we hear about the potential to use AI to drive cybersecurity attacks in volume and increasing sophistication, and then the rest of us kind of sometimes look at that a little bit and we say, geez, you know, it's already so easy to launch these attacks.

Why would they bother? Because why do they, why do all the extra heavy lift? Well, it's either, uh, obviously they're looking to, to score a big heist or they're looking to inflict damage or sometimes both.

And bad actors, uh, unfortunately have gotten the jumpstart in this whole arms race on cybersecurity versus kind of cyber threats. How do you know what they're doing? I mean, do you, have you seen any examples of them using AI and what does it look like?

Yeah, it started with, you know, more traditional attacks like denial of service and stuff. But with AI they could do it at a speed and volume that was just overwhelming for most systems. So no good guys.

We, you know, started combating that with our own like kind of AI cyber warriors and started using AI to figure out other types of attacks and bad actors got more creative. And so, you know, they're using AI to figure out new types of attacks, which is not just cyber. They're actually using AI to probe like physical weakness.

And even, um, perhaps the linchpin, the whole model is people weakness. 'cause it's a lot easier to hack a person, like as an individual than it is to hack a system. So does that mean they're kinda using some form of AI to monitor people's behaviors and figure out who's maybe most likely to click on a, on, on a malicious link or something?

I mean, how sophisticated does that get? Yeah, that, that's actually one thing they're looking at. They, they're AI systems that learn like psychology and neurolinguistics.

So the AI can really get to know a person just like a best friend does. So they, they understand kind of your, your language, the way you speak, interact. They understand the best channels to, to hit you at.

They know kind of the right triggers to get you to take action. And, you know, we're seeing more and more of this getting prevalent, unfortunately with the rise of deep fakes. You know, there was a financial se uh, services company recently that was just hit.

They were literally on a Zoom meeting. They thought it was a CFO and the CFO's, I think core team seemed, acted just like the CFO said, you know, we have an emergency situation, we're gonna wire this money to, you know, cover, you know, whatever cogs cost sold were or something like that. And I think they wired it like $12 million right away, not realizing they were talking to a deepfake.

As we go along, it seems like, are they inserting themselves into our workflows to monitor that behavior and collect our processes and figure out what we're doing? Or can they do this from afar? I mean, you hear the phrase living off the land all the time, but how much access do they need for how long before they can start using AI to kind of create that deep fake that sits in the middle of a workflow?

They not, not, they don't need much data at all. I mean, there are tools out there that you, you pull some, you know, video or audio or even pictures off the internet and that's all you really take. I mean, last year there was a crime ring that, you know, would call parents and tell 'em they had kidnap their child and they called when the child was in school, knowing that most schools don't allow them to have their phones on at the time.

And you know, the parent would be like, oh, we'll prove it. I wanna talk to my child. And they would quote unquote, put the child on.

It was really an AI deep fake audio made from their social media and it sounded like they did talk like they did. You know, parents are freaking out, you can't confirm because the kid's phone cell phone is off. And I think they, they, they did it, I think it was almost a dozen times and they were getting paid like 50, 60 grand a ransom before I think, uh, the FBI Interpol really started trying to track them down.

But that's the level it takes. You, you, you really like two minutes of data now, especially audio or video to create a deep fake. Yikes.

What can the good guys do with AI to help thwart these attacks? 'cause it, uh, hopefully it is an arms race and there is things that, you know, the good guys are doing. We're trying our best one.

One thing that we are doing right now is what we've learned that, you know, DeepFakes, like a lot of things have almost like a unique pattern or fingerprint to them, but the way that that AI is trained, there are some things that kinda reveal themselves as much. Like, you know, how, how do people know if you wrote something or Chad GPT wrote it, it's the same thing we could try and look for in deep fakes, whether videos, audios, images are a little bit tougher. Listen area, we're trying to also figure out.

But, uh, we know that if we don't provide this level of protection, it's, it's one thing like when it happens to a famous person like Taylor Swift or President Biden, but for the average person, like those parents that thought their kids were kidnapped, they don't have a whole lot of recourse. So we're trying to build those counter tools right now to give people that, that protection and that that option of verification. Do you think, um, we're gonna have to wait for some massive reach for everybody to kinda wake up to this whole thing?

And I'm asking the question. 'cause historically we've always chased after emerging technologies after the fact. And of course, you know, we're told all about it for months and months and months and, but it seems like it's not until there's something catastrophic that everybody goes, all right, we gotta get serious.

Michael, unfortunately, that that's the, the attitude that, you know, we've always been like a reactive society or you know, something bad happens, but we're at a point where AI can do things with such volume, such speed, such large impact that if we're not proactively thinking about it and trying to, you know, protect against some of these threats we're it's gonna be too late. That's the honest truth. Primary activism is gonna be too late.

I I seem to be using this quote a lot from Plato. I I do like it, but we learn from pain. We have to break that kinda mold because we can't wait for like, oh well 50 million people just got impacted.

There's real no way to recover for those people. They still are suffering and feeling real pain. Don't jump ahead of these things.

What are we gonna do? And, and in my work with the United Nations, that's one of the things we're actually trying to do with the global regulators. It's kinda shift that mindset away from reaction to being proactive, which means we have to get good at scenario planning.

We have to get good at thinking about, you know, these are just tools. How would people use and misuse them? And that's just something we, a skillset.

We, we just pulling the beginning of trying to develop, Are we suffering from cybersecurity fatigue? And I asked the question because a lot of the boards are asking questions now, like, well, we invested all this money and are we any more or less secure than we were before? And I might argue that that might be the wrong question to ask in the first place just because, well, it's not like the bad guys don't change their tactics and techniques So is this just a continuing, evolving gamer?

I don't know if I'd call it a game, Michael, but it's a, it's a nonstop race, that's for sure. There's, there's no finish line. We know that bad actors figure something out.

We find countermeasures, but protections, they find either a different path or different way, you know, d better tools to, to break what we've done. And we then elevate our game. They elevate their game.

It's, it's nonstop. And I get where the boards are coming from. Infrastructure projects are, are the hardest things to rationalize.

There's really no ROI either you kind of do it or, you know, what's the cost of not doing business. But the truth is, is look, there's not that many bad actors out there as a percentage of the population, but especially with emerging technology like ai, that can cause a horrific amount of damage. That's the reason we make the investment.

So I wish I had better use for everybody, but it's, it's one of those things that it's just never gonna be ending. It's, you know, what's, what's the old cliche, and sorry to be using the cliche here is the price of freedom is, uh, ever constant vigilance. And that's very true when it comes to cybersecurity.

Well, speaking of that vigilance, do you think AI will make it easier for, uh, nation states and companies in general to collaborate with you, with each other to thwart these threats? 'cause I think one of the issues we've had so far is everybody kind of functions in isolation and, um, the bad guys are just going to town because we don't communicate with each other. Yeah, that's unfortunately true.

And AI has been a boost in sharing some information and different types of attacks. I know that Interpol, my work with them has been a lead on that. There's still a hesitancy to, to share some of these things.

We, we know that, you know, some of these big institutions, whether their companies or universities, for example, they get bombarded every day by attacks, and they don't want to quite reveal that or what kind of attacks are happening. 'cause one, they don't want, you know, their employees, customers, students, faculty to freak out. But two, they don't wanna know just how much at risk they are, make themselves a bigger target.

So it's, it's kind of unfortunately, a, a weird balance trying to figure out here is how much to share without trying to increase your risk factor. Our, the folks at Interpol and other law enforcement agencies getting more proactive. And, um, I asked the question because the honest truth of the matter is cybersecurity always felt like, well, we know there are bad guys out there, but until they rob the bank, we can't do anything about it.

So then we go chase after them. But we knew we could see them walking down the street and they were about to rob the bank, but we had 'em wait for them to actually rob the bank before we could do something about it. Can we change that?

We, we could, right? We just, we just need 194 member nations to agree to it. Michael, that's one, that's one of the big challenges that, that's why everyone talks about building a better fence, so to speak, better safeguards.

Because it's, it's almost like the whole minority report movie, right? Is it really a crime of, someone thinks about it, but hasn't done it yet? That's, I think, a challenge for the legal system.

So, you know, is it enough to say that someone's trying to probe the defenses or trying to do something? I mean, that's gonna be a debate for the legislatures. I, I fear.

But that's why the focus for a lot of the cybersecurity organizations and law enforcement has just been around trying to create safeguards and protectors. Can we get better offensive capabilities? I know there are diplomatic niceties involved when we kind of hack into servers that exist in other countries, but it seems like people are starting to say, Hey, we're not gonna take it anymore.

So are we gonna get a little more aggressive? I, I think some of that is happening, whether it's sanctioned or unsanctioned. I, I really couldn't tell you how much of which of each of is, but you know, you probably heard it more about Michael, the black hat versus the white hat type of hacking.

You know, I, I think, again, there's no way to effectively regulate that at the moment. And, you know, I'm sure a lot of people saying like, well, why would you wanna stop white hackers? It's not necessarily stopping them, but it's, I think, I think the real or underlying threat here is that, you know, everyone talks about the next war is gonna be in cyberspace, and we're building a lot of tools that we're reaching a point where's, you know, even some of the developers don't fully understand how they work.

We could leash something that's very cataclysmic, unintentionally. And I think that's the biggest concern when it comes to white hats, black hats. Well, to that point, you know, if I went back in time, uh, there were bank robbers holding up stage coaches and, uh, railroads and those guys got together and put out little bounties for capturing these people.

And it was, um, you know, the niceties of the court thing were kind of, you know, if they were captured great, they would go on trial, but sometimes it never quite got that far. Um, our company's gonna get more aggressive about this because they have so much at risk and, um, they can't wait for the government to actually respond after there's been an incident. It's a, it's an interesting question, Michael, 'cause there's a debate about that.

And the debate is, should they have like their own kind of counter team? And I know that they are using AI for scenario planning predictions to say, you know, probing for their own weaknesses, trying to figure out, you know, new, new types of attacks and they can then create safeguards against. But there's a growing consensus that the biggest challenge to solve is the people, right?

At the end of the day, hackers know it's a lot easier to get the information you need through a person clicking on a phishing link or something else than trying to really break down encryption or cybersecurity systems. The question really becomes is how do we do that? We, we would, you know, try an education, try some of these other things.

You know, there's talk about now could we put people into like a metaverse simulation run by an AI where they actually, they do one of these things. They actually see what the overall impact is, would that make them think twice? So I think right now, still a lot of the root solution is, can we better educate people?

Because that's really the first line of attack for a lot of hackers, right? But bad guys only need to be right once, so even the smartest person gets tired, they will accidentally click on something. And, um, it's just kind of the nature of the human condition.

And frankly, you know, 20% of the population probably isn't that smart to begin with. So, um, I don't know. People is, you know, a good place to start, but I gotta feel like there's gotta be some other ways to augment this because, well, those people are humans.

It's very true. And there's, there's talk of leveraging what we call hybrid intelligence that, you know, people are good at things like, you know, first of a kind creativity, something that requires a lot of like, you know, instinctual type of thinking. Machines are really good at processing lots of data and so forth.

And so it's the meld between the two that augmenting our human capabilities with machine capabilities is hybrid intelligence. And can we exploit that in terms of cyber protection? Could it not just be educating the person, but could we have like a little ai, you know, security guard as your, your buddy helping to review your emails and some of these other things and say, Hey, whoa, whoa, before you click that link, let's just double check that, you know?

And, you know, there, there's some merit to the idea. The challenge is twofold to try to do it. One that the more variability the system, the more data AI needs to be trained properly.

And thinking about how much variability there is in a cyber attack. And two, are you training one weakness for another? And that, well, if, if, great, I have the buddy system, but if I could figure out how to hack the AI security buddy, does that solve my problem?

Right? Can I then just incentivize the security buddy to have the person do wrong things? Uh, maybe, right?

We, we could debate this to we're blue in the face because there's never gonna be a perfect solution. And I, and I think that's what we unfortunately have to accept. That's why it's a never ending race, right?

Given the imperfect nature of cybersecurity, then what's your best advice to folks about how to get to where they need to be versus where they are today? 'cause I think a lot of folks are like, they understand that AI exists, but I think they're a little overwhelmed. Again, it it's the see old adage though, trust but verify, right?

They're one, one thing we've noticed is that, uh, you know, AI tends to be too perfect, like with deep fakes or, you know, some of these things that either they try and create very obvious flaws that seem weird to us, or we don't see the flaws at all. So subconsciously it feels weird to us. So if you're feeling weird about something or you gain something that is a lot of money, or there's a link here or something that seems sort of right, still just check it out, right?

Do, do the virus scan, hover over the link, all those things we're, we're taught to do. And, you know, if you're worried about being deep fake, you gotta, you gotta confirm somehow there, there's really nothing that urgent that can't wait for, you know, an extra few minutes for that kind of verification. So just trust but verify.

Be a little guarded. All right, folks, you heard it here. I'm not so sure about the trust part, but to verify absolutely.

I would more maybe argue don't trust anybody and think twice about it and go from there. Hey Neil, thanks for being on the show. Yeah, my pleasure, Michael.

Thanks for having me. All right. And back to you guys in the studio.

Cloud Native now is the web's leading resource for the growing cloud native ecosystem. com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more. Stay on the cutting edge of modern application development at Cloud Native.

Now, Well that's gonna wrap up another great action packed fun-filled, uh, text drug TV day. We hope you enjoyed everything. We'll be back, uh, on Monday with another Fresh Tech strong TV show.

Until then, this is Alan Shimmel. Be safe. Be well, be strong tech, strong.

We're out. Hey, live on the Gang. Today we've got three big topics we're gonna cover.

One is about what is the end goal of DevOps here, should it have an end goal? Second, we're gonna talk about anti-patterns in DevSecOps. And then third, we're gonna have a deep philosophical discussion about what's best for society, working from home, working in the office, some combination.

Who knows? We've got that and more live today on the Textron Gang. Hi, good morning everyone.

Alan Shimmel here for Textron Group on the Textron Gang. I'm joined by our usual gang members and a very special guest who's a longtime Techron, uh, family friend member. But first, let me introduce our chief content officer sitting here to my left or right, depending on if this is mirrored or not.

Mike Ard. Mike, welcome. Thank you.

Good to be Here. Yep. Joining Mike and I at, we're at Techstrong Headquarters, Dr.

Joining us from there, ABOs on the road, and who says we don't allow remote working is our CTO and Chief, uh, research analyst at Techstrong Research. Mitchell Mitchell. Ashley Mitchell, welcome.

Good morning. Great to be here. Welcome everybody.

Yep. com. Amanda Reini.

Hi, Amanda, how are you? Good, Amanda. Just check you're not on mute.

com and been part of the family here for probably 9, 8, 9 years now. One and only Bob Ruman joining us very early in the morning out in la Hey Bob, it's great to have you here. Great to be here.

Thanks. Good morning. Yes, good morning.

Um, alright, so I, I said in the preamble, we got three main, uh, blocks we want to hit on today. Mike, do you wanna kick it off? I do.

'cause it's gonna be a very philosophical show I start to finish. com talking about, well, what are the implications of AI for our fellow DevOps professionals? Because the goal has always been to quote unquote ruthlessly automate.

But if we automate to the point now where we, what are we, are we pushing ourselves out of existence here? Who will do what? Because as he points out, if the machines are writing all the code, well then what do we need all the folks for to manage this process?

'cause the whole thing will become highly automated. I know this is top of mind for you as of late, but lots of DevOps folks are wanting to know, where's my cheese going? So first of all, I would say that automation has not always been the chief goal of DevOps.

I think the chief goal at DevOps has been to break down silos and cultural among people, not process, not tools among people so that they work better together and in working better together. We can have higher quality and go faster if higher quality going faster entails automation, that's good too. But don't, don't underestimate the power of people and of culture in DevOps.

But I think we're mischaracterizing Don's article in, in all due respect, I think the point of Don's article is what is the end goal for DevOps, right? Because if, if the initial goal was to make people work together better break down silos, okay, we've achieved some modicum of success in that, right? Uh, we've added automation to the mix.

We've done a lot of that platform engineering check. SRE check, you know, DevOps seems to be this ever growing amoeba umbrella that encompasses many things. When is it finished?

What does success look like? When's, when's it, when can we shut the oven off? And AI is just the latest check on on this whole DevOps, uh, you know, uh, ones it done.

And, and it promises in many ways, as you said, Mike, to be the most, uh, impactful. But I, I think the point of Don's article is you have business people, right? The business team, dev BizOps, who's ruthlessly moving forward, let's do more faster, better, cheaper, right?

Automate, automate what have you. And then you have an IT team who says, you know, I'm just following orders here. Tell me what your priorities are and we'll make it happen.

I don't think the world's that clean cut. The other thing is, look, DevOps never had a definition. It never had a manifesto.

It never had, it was always amorphous by design. Why should that stop now? I'll leave it right there.

All right, Mr. Ruman, since you are new to our show and a guest, do you wanna weigh in here because you are, after all one of the more deeper thinkers in the land of it, A deeper thinker. There's another T-shirt.

Um, well, let's remember the days before DevOps. I was, I was actually working production at that time, and everybody get together and we'd have a major deployment and we'd all sit in a war room and they'd put in, you know, the potato chips and the soda and the ice cream and coffee and all that stuff. And there would be the zip files.

We'd be passing zip files between servers all over the place. That's what it was like. And then everything would go wrong.

And then people be there for the weekend and get really mad and do all that stuff. And one day somebody woke up and said, you know, there has to be a better way. There just has to be a better way because we can't afford it.

And my thinking is that the foundation of DevOps is, was, is and was, uh, financial efficiency. We just can't afford to keep doing this. And we, when we looked at it, we said, okay, well what's one of the big problems we have?

Well, we have dev developers in one pod making the zip files, and we have ops in the other part deploying the zip files, right? And that's just not working. And maybe if we got them together, that would work out.

That's the good news, the bad news. The bad news is, is that people can only identify that, which we know what to look for. So what do I mean?

If you've never, if you've never seen a giraffe, how can you go looking for a giraffe? Right? And, and the reason I'm saying this is that what's happened in DevOps, it's almost become somewhat analogous to systems administration when we start looking at what people are saying, saying, well, you know, systems, you know, make the machines do system administration.

The spirit of being able to, whereas Allen pointed out of being able to talk to one another and being able to do away with this whole insanity of developers giving stuff to systems that admins and making sure it gets out the door goes away. So what's the end game? There is no end game.

I mean, that's what people want their software and they want their software as fast as possible. So there you have it. I Don't, Mitch, I'm gonna weigh in on that too.

Yeah, no, I I, you, you got my punchline too, which is, I don't think it's a sensical question. It's like, what's the end? What's the end game of waterfall or agile or weather?

It's, there isn't an end go end game. It's about adapting this approach to what's important in your business, right? If we are like in dire straits for getting software out, 'cause we really suck at it and it takes nine months to get a, a release out, which is kind of the days Bob was talking about, which mean, back in those days too, by the way, you had your backout plan.

'cause about half the time you had to back it all out and go re re upgrade again. But it's about, you know, what's important to the business, right? Do we want to implement ai?

Well, that doesn't mean no DevOps or DevOps. It means that's just a way of doing software. So to me, to me it's not, I, I understand there are business goals and measurements for success.

Those are all great. That's not an end goal. I will argue something.

I wanna Oh, go ahead. Sorry. Oh, well I just wanna jump in on what Bob said about the deep thinkers and um, and also what you just said, Mitch.

So, what spoke to me most in that article was if there was some sort of end goal, and the end goal was use AI to automate everything and remove it roles, then the question is going to be where are the deep thinkers, the philosophers, that question situations that could come up in the future, or problems that don't exist yet. If there's nobody writing code and there's nobody able to do those things, then AI's gonna come to a point where it can't solve issues in the future. And that would be concerning.

So that was interesting and made me think that we need to keep the human element, the philosophers and the deep thinking about the future. I would argue there is indeed a goal, and I'm gonna disagree with you. And the goal is to make this stuff as transparent as possible.

I think, uh, we had John Willis on the show. He is a big fan of, uh, touring, I think it is. Who said Deming?

Deming. Deming, sorry. Deming who I think said something to the degree that any process that you can see is broken.

It's pretty clear to me that we see DevOps all the time and there's tons of bottlenecks. So therefore it is broken. AI may move it along to, from where it is today.

But I think the ultimate goal is to make it so transparent is that you don't see it, you don't experience doesn't mean it goes away, but today there's too much, um, noise in the system that results in rollbacks to Mitch's point and results in vulnerabilities that aren't addressed. I think we got a long way to go here and maybe AI's a step in the direction. I gotta call BS on you, man.

All right. Because I'm gonna tell you something, you don't. I will.

Exactly. And Mitch is ready to jump through the screen because guys, I gotta tell you, we have less rollbacks today than we ever did. That's damn short, right before DevOps, you know, upgrading to a new version was hit or miss at best.

You know, that 12 inch stick in my eyes, so much more than the six inch stick in my eyes, so it doesn't really matter. Okay? And then, but the, but secondly, secondly, not, not just the rollbacks, but vulnerabilities.

S**t. Excuse my language. God, at least we scanned for vulnerabilities before we deployed code now, and that's actually part of the process.

We never did did that. I wish we did scan, but it's pretty clear we from every guy article that we write on Security Boulevard that we are not scanning No, no, we are scanning. There is an article today, in fact from Lum did their research showed that hardly anybody scans any of the packages they download from the JavaScript files.

And so it's just kind of, it's, So you're talking about SCA, right? Software code analysis is those things. So we scan more of those than we ever did before.

Now do we need, can we be better? Yes, but let's, let's be clear, software coming outta the shoot today is many, many times more secure than when Mitchell and I and Bob were were what, you know, they were referencing sitting around with the potato chips and ice cream unzipping zip files. Oh.

And we had to get it done. And I, I got my kids' birthday this weekend. I can't be here all weekend.

Screw the scanning. I'll do it later. We've automated scanning.

Could scanning be better? Could scanning find more vulnerabilities? Yeah.

Yes. And it is, it's getting better. But make no mistake, you know, it's very easy to put the, the rose ca colored glasses on a wax nostalgic about the old days.

The old days weren't the good old days. Hardly at all. I don't think anybody's saying that.

I'm arguing That you, we've made tremendous progress. You were describing the Stanley Steamer age of software development, and the rest of us are going, where's my flying car? So, Exactly.

I did read that article and I was a little surprised of, of the, the vast percentage of incidents they did find. I think it was like 47% of malicious code in the software, which seems kind of high to me. So Mitch, what do you say?

Well, um, sorry, not to gloss over what you said, Amanda. 'cause I'm thinking about that. I go back and re reread that part of the article.

Um, I think so I'm just gonna pick on you a little bit. Not as much as, as Alan did, Mike, the flaw in, in what you said was DevOps is not a process, right? It's a, it's a method, it's a, uh, an approach to developing software.

So it can't be invisible because you're continuously improving all different aspects of it. And that's why rise of DevSecOps and platform and all these different things come about, or you can localize it just about CICD, which I think we're gonna talk about in a bit. So that, that's my argument about it shouldn't be invisible.

It should have low friction and it should facilitate getting software out the, the right software out the door at the right time. But, but yet, I'm sorry. Yeah, Bob.

Oh. And, and yet we have the corporate paradox of the title called the DevOps engineer. If DevOps is a way of life, then what does a DevOps engineer do?

Engineer my life, right? But there are people out there lined up around the corner trying to hire DevOps engineers, right? So that's sort of, that just sort of strange to me, which is, again, going back to my argument that this notion of DevOps can only be interpreted in the language you have, which is, if I'm a system admin, guess what DevOps is?

Systems administration. Right? Or if I'm not so much a system admin, if I'm a corporation or an I or a CFO or an or a CFO, more likely I can only imagine my organization to have, um, system administrators, people that run, you know, turn the dials, people that, you know, uh, um, tighten the bolts.

And for that, I need an engineer. I need a DevOps engineer, which, you know, meet, meet the old CIS admin and new his Nuis admins did DevOps engineer, He makes, that's cents. But Bob, he makes more money as a DevOps engineer.

Yeah, that's true. That's true. Okay.

Or he is actually, he's gonna make a lot more money being a platform engineer. Engineer. Exactly.

There you go. But, but let's talk about bottlenecks for a second, right? You know, again, I'll go back to, to, uh, Phoenix Project, which is based on the goal, right?

The very nature of, of business in the goal it was manufacturing in, in, uh, Phoenix project, its software manufacturing is, there's always bottlenecks. You're never gonna be done with bottlenecks. You're never gonna reach nirvana by definition.

It's almost unknowable and reachable. You can know, you know, it's like knowing God. You can't really know.

It's something on faith. You don't know the essence of, of, of the deity. Um, but the very nature of this process is as soon as you solve one bottleneck, it now gives you vision into the next bottleneck and so on and so on.

And you, and, and to a certain extent, that's the way of DevOps the same way. It was the way in the goal is trying to get to those bottlenecks and solve them as quickly as possible so we can get to the next one. And that's the whole right to Don's full circle to Don's article.

If the goal is to remove bottlenecks, you're never gonna reach your goal. And maybe DevOps was set up that way to begin with, never to have an end goal. Have we, have we exhausted this?

We Have not. Okay. Mike's ready to go.

I'm gonna, I'm gonna come back on it and say DevOps is a means to an end. It is not the end in itself. And therefore, what is the end?

And the end is to make the business more efficient, more effective. Mm-Hmm. I would argue the DevOps tail is wagging the business dog.

Because now the business is having a hard time keeping up with the pace of change from DevOps. There's still work to be done on the DevOps side, but the business side of the house is sitting there going, I'm not sure we can absorb the frequency of updates and changes. We see it in the digital transformation conversation all the time.

But DevOps is itself, is not the goal. It is something else. It empowers Mm-Hmm.

I don't know. I'm talked out on it. Mitch, Amanda, Bob, anything else?

I'll throw one more thing in is that I think what's changed with DevOps is that the frequency of change is much greater, but the degree of change is much smaller. You know, the days of Bob and I sitting in the conference room, you know, why didn't the, the implementation, what happened with the installer, the database conversion script, you know, those, those days are over. So we all live in the, in this world where we're in our software's in constant change, how often does Zoom and Chrome and everything else we use update itself every day?

Now getting a an enterprise system to working in that kind of fashion is no small feat. But I think the change can be smaller Mike, than what the business is used to saying, I, I just changed our process to match the new version of software. Don't change it again.

That, that's kind of the old days. At least to me it is. Fair enough.

Alright. You know what, let's take a quick break. And by the way, excellent article to our, by our friend Don McVety.

But let's take a quick break. We'll be back here in a second with more text on gang. All right folks, welcome back.

We are now gonna talk about our second favorite most contentious philosophical topic. DevSecOps, our friends at Techstrong Research have a new report out about AntiPatterns as it applies to CICD and security. And I'm gonna let Mitch explain what's in there.

But it seems like to me, just to get the argument started, you know, we're saying you should take your vitamins, but I don't know, what do you, what's in there, Mitch? Yeah. Every day.

But, but you know, we don't always do that, right? Well, so, so what this was about is actually is a collaboration with Red Hat, looking at, uh, supply chain security, a software supply chain security, and thinking about the DevOps pipeline in particular around the CICD process. But you can think about it more broadly than that.

And an anti, the definition of an anti pattern, at least for the purposes of this report, is a pattern or, or practice that kind of gives you a false sense of security. Like doing these things. I'm good, I don't have to do more.

That's, that's, you know, that's fine. I'm secure. So scanning images that I put into my software supply chain, uh, getting them from a reliable source, uh, scanning for vulnerability, those are all good things.

Nothing wrong with that. But is that enough? If it was enough, we wouldn't have supply chain attacks.

So we, we talk to people about what are they doing to secure in the inside of the, the workflow pipeline, the DevOps tool chain, and how software and, and workflows through that. And sort of the, one of the interesting conclusions was one approach that's being used is using kind of a cloud native, some aspects of it where you containerize and compartmentalize different parts of the, the CICD process of the supply chain and secure it at a more granular level. And people were using kind of that approach, barring some ideas from Cloud native and things we've had before, cloud native.

But that, that was really interesting to me and how many people were either considering or doing that. The other is, you know, there were substantial number of people that reported they'd had, uh, some kind of a breach or some security incident in their supply chain, uh, in their own software development process. So, pretty fascinating work.

I thought it was great to work on it. Bob, what's your take on this? And I'm gonna ask you this question in this context.

Um, we hear the phrase shift left all the time. So who should be in charge of this security? 'cause some people would say, pardon my French, that shift left equals s**t left.

And people are complaining about that. The developers are saying, I can't handle a cognitive load. I can barely do what I'm currently doing.

So where does this DevSecOps security function belong in your mind? It, it's a good question. 'cause this is, you know, one aspect of it, this is about securing how the pipeline of where we create software versus the security of the software we're creating in that, that flows through that pipeline, if that makes sense.

And, and, and it's pretty clear that, you know, you're, Bob was talking about, you know, the cis admin, you know, new boss, the same as the old boss, right? The DevOps engineers doing this work. Those are the people who are really probably gonna have to do most of this heavy lifting.

'cause the security engineer is gonna go in and configure Jenkins and configure, put it into containers and do all those things, right? Maybe some platform engineering might help if, if they need that. But it's really a system administration function for the development tool chain.

So I think in that aspect, it lives more in the people who support the underlying tools and how, how they integrate and how they're secured in a software development process. Bob, appreciate your perspective on this. Yeah.

Question. It's question for you to disagree. If you don't, This is a question or not.

No, I have a question. Uh, for you Mitch w in your research, were, were the companies looking at the artifacts or were they looking at the, uh, the, the, the artifact deployment process? Um, 'cause I, and I'm, I'm asking you that was it for more, okay.

We're just, we're just gonna take the code, we're gonna scan the artifact, we're gonna send it out, or were they, were they actually looking at the process of which inspection happened? That's my question to you. Yeah, it is a great question.

It kind of goes at the heart of what the research about. Yeah. Looking at the artifact, most people are doing that, the scanning and making sure what you're producing is secure.

What you're consuming is secure. But there, what we're starting to do more work on is securing the process of how that auto artifact flows and then gets out the door to the, to your ladder example. So that's, yeah.

And then that was the real kind of aha in it for Me, right? And then it goes to architecture. So I remember when, when I was at one company, one of the big battles was whether to have your own private repository.

And this was back, not, not, it was back in the middle days of, of Docker. So are we gonna go out to Docker? Are we going to trust that, you know, the, uh, the images out there are secure?

Or are we gonna say, no, we're ne we're never gonna do that. We're gonna create our own repository. We're going to use images that are only ours, even if it's a well-known, uh, image, we're still gonna bring down those docker files in that source and do it ourselves.

And that was a huge fight. That was a huge fight. Mm-Hmm.

And that was a fight that actually the company I was at at the time got lost. They went right to, they, they relied upon Docker. So now the question, is it also in saying the CIS admins also is, well, what is the, what are the role of these, you know, enterprise level repositories?

And I, I'm seeing that. I mean, honestly, I get caught in, um, when, when I, when I run an NPM install, uh, I get caught a lot. I get caught a lot.

You do. You got a lot of high vulnerabilities in there. So it's showing up in my work, but the honest, if I'm doing just a demo, I check it in.

Mm-Hmm. And so now who's insured there? You know, Bob did a badie, right?

And so what, in, what in the development pro in the deployment process is one, where's the security check happening? And I defer that to you, Mitch. And the other one is where, what is the se security architecture again?

Local repos, global repos. And you got me, I'm, I'm interested to learn. Yeah.

Uh, it's, thank you. That debate is still going on very much. Um, Rob, uh, Bob, sorry.

Uh, but I think the thing that's shifted is we're not gonna just rely on a, uh, you know, some external repository where it's docker or it's anything else. Um, where are we getting that stuff from? And then let's bring that into our own environment and make sure it is what we think it is, and that we consistently use that from our repository and flow it that way.

Now, is everybody doing that? I don't think it is. So, and I promise I won't call you Rob again, so That's cool.

Why not? This is, yeah. His name is Robert, but, um, It is Robert.

Yeah. Before a judge. Yes.

Yes. But to me, not trouble. So we don't use that name.

But to me, here's, here's an issue though. It, it's more of a, who's watching the watcher issue. Yes.

Yeah, I agree. Right? So we, we have, we've, we've put in these processors that theoretically not processors, processes that theoretically you're checking the software that we're getting from repos, whether they be public, private, local, global, whatever.

However, we're relying on the software that's checking those artifacts or repo items to in fact be themselves not corrupted. Right? And who's watching that?

Who's checking that? Who's checking the tools we're using on the factory floor to, to assemble the software, right? And so it's not the classic DevSecOps conundrum of, let's throw another straw on the developer's back.

It's more of a, who's watching the watchers? Can, can these tools be self run, self checks? Do you trust them to run self checks?

You know, um, should there be a, an integrity check of the tools as part of your SBO or something like that to make sure you know, nothing got introduced after you downloaded it from whatever repo you are using. There's, you know, again, as soon as you solve one bottleneck, we find the next bottleneck. As soon as we solve the problem of scanning software coming from repos, we, we worry about is the scan, are the scanners corrupted?

And, and I'm sure once we fixed or solve that, there'll be another bottleneck issue we need to hit on. And I, but you know what? That's, that's why this tiger has stripes.

Maybe Mitch, do you think maybe it's a hollow debate, right? We see it in the industry all the time, but the more I think about it, I'm kind of like, trust nobody, the developer don't trust them. But there's gonna be stuff thrown into the build.

Don't trust those people. 'cause they can make mistakes as well. And then by the time the whole thing gets deployed in production, somebody's gonna do an update anyway.

So you gotta check it on the far right side of the equation. So maybe we should just be, you know, I, we throw around the phrase zero trust, but I'm more of the presume everybody's guilty till otherwise proven innocent That, and that is zero trust. Mm-Hmm.

And that is zero trust. Well, you hang around with security people long enough and your, you know, software folks will become that way as well. I, I think it's, I I think, think it's more taking out the, well, I personally trust them and I think that's a good source.

And I'll use that and I'll download my code from there, which you can do on your own or smaller development team. But it's more formalizing where are we getting our code? How do we know we're getting it in a way that it's secure?

And how are we know that we consistently use that as opposed to something that might have been ingested or added to it. It's almost like, as you were talking down, I was thinking about, it's like the movie inception. How many le how many layers deep do you have to go to plant that seed, right?

That's gonna change an outcome. Um, and that's kind of what what we're describing is do I have to go look in every piece of open source software that I deploy in my code? Well, maybe my scanner's doing that, but it's probably not doing all that either.

So at some point, you know, there's a diminishing returns, right? We will never stop scanning. Yeah.

So the, the, the other point about it though is, you know, philosophically zero trust sounds great, right? What could be wrong with that? But then it runs headlong or head first right into the wall of I gotta do more, faster and zero.

You know, the old saying about your civil rights end at the tip of my nose. Mm-hmm, zero trust is fine until it runs into the tip of my, I want to go faster debate. And that's what happens is zero trust can wind up slowing things down.

And, and when they do, people scream. When it does people scream. I'll throw this out to one of you three remote folks, but, um, there was a book a long time ago, Ralph Nader wrote it, it said, unsafe at any speed describing cars.

Are we unsafe at any speed with software development these days? Well, I think there's always gonna be a safety issue, but it just requires constant vigilance and good communication. And maybe as the article said, some frown work, some groundwork, uh, that, uh, needs to be put into place.

And, um, just having a good plan of action, um, for defense. All right. I think we can end it there.

But to Amanda's point, I think the saying goes something like, um, freedom requires eternal vigilance. Is that where we are? I've heard that before.

It does. You know, I'll also put in that democracy is the worst form or the best of the worst, right? And, and that's kinda what we've got.

All right. We're gonna take a break on text Trunk Gang. We'll be back here in a second.

All right. We are back with our third philosophical argument of the day. And we're talking about this whole push to get everybody back into the office.

There's, uh, an interview that we did with, uh, Tite Patal who's over at Cisco. He is one of the senior vice presidents. And he has some things to say about, well, why you may not wanna have people come back to the office.

Let's run that clip for a second. The future of work, in my opinion, I very strongly believe in this is gonna be hybrid, where people are gonna work in mixed mode. There'll be times that they go into the office that there'll be times they wanna work from home.

There'll be times somewhere in the middle. I actually think it would be like very regressive for society if we required everyone to be back in the office five days a week. Because what that does is makes geography such a disproportionate, um, you know, prerequisite for economic participation and economic success.

So I actually don't think it's a healthy thing to go back to pre covid days. And everyone worked from the office five days a week. I think the next generation of leaders need to figure out a way that they can build strong bonds and relationships and serendipity while being, uh, while never having met someone in person.

All right? So he is saying that having everybody move to New York or San Francisco, or Chicago, wherever it may be, is bad for society. It's bad for the economy.

It, uh, reduces the ability to have jobs that they can have well paying for and live in nice little towns somewhere that would in turn drive their local economy. I know we have talked about the merits of working in the office versus remote. What's your take?

So I have an opinion or two on this. So keep in mind myself, I and Mitchell knows this. When we co-founded Still Secure, I worked remotely for the most part for 10 years, 13 years.

Not true. When we first started the company, I actually lived local in the Boulder area for three or four days a week and then commuted back and forth. Um, I've been through Covid as we all have, and I'm talking as a CEO now as well.

There are layers and layers to this discussion. The first discussion I'm gonna answer strictly as a CEO, I don't care what you tell me. Doing this on Zoom is not the same as having Mitchell, Amanda and Bob sitting around this table with us.

There would be more interaction, there would be more productivity. There would be a warmer feeling of togetherness than than doing it like this. If I had my druthers, I'd fly them all to Florida and do it here, right?

And that is equally as true with people working in office. Yes, there are certain disciplines, certain, uh, job functions that it's not maybe quite as important to, but overall from a societal impact, it, it, it works better when people are together, no doubt about it in the same place. And, and back to your society point, You got this finger weighing at me, I'm Sorry.

Um, to your society point, you know, I'll take, San Francisco is the perfect example, right? San Francisco in many ways a ghost town today. 'cause it's not just the people aren't in the office as much, but you need a critical mass of people in the office so that the breakfast restaurant has enough customers to serve breakfast to so that the lunch places and the bars after work and restaurants have places so that the dry cleaner can drop people, drop their stuff off and do their thing so that the print shop down the block and think about all of, and if I want to go retail shopping during my lunch, not on Amazon, I want to feel a shirt, right?

You need, I mean, this goes to fundamentally, you know, society. You need critical mass of people. It would be nice if Mitchell was out on some big cloud ranch in Montana, and Bob was on some seaside villa in Baja California, and Amanda's out on St.

Pedro Island and, and you are up in Galloway, Ireland, and I'm sitting here, right? And you all would be really happy, but we wouldn't really, it's hard to do a business like that. Are the tools better?

Yeah, but I I I think they're a pale in comparison of working together. All right. Any of your remote folks have something to say about this?

Well, I will say, um, while I see so much value of coming together in person, and I hear everything you're saying and do agree to some level, I think what outweighs all of that is comfort of working from home. Um, in, in the environment that you enjoy. You can be in your pajamas if you want to, you can work.

But That's exactly my point. If you're in your pajamas, go get a different job. I don't want people in their pajamas.

I want people dressed for work. Because how you dress has a lot to do with how you look at what you're doing. If you're in your pajamas, you're sitting around having fudge brownies.

I beg to disagree. I think the research and the studies are showing that people, when they're working at their comfort level, maybe it's morning, maybe they're morning people, maybe they're night people, or maybe they're midday people. I need work done when work needs to get done.

Not when you feel comfortable. I'm, I, my world works on nine to five. The fact that you got something done at 10 o'clock, God bless you, but I needed it at five o'clock.

And how, oh wait, Alan, how do you really feel about this? I'm telling you, I have strong feelings on this subject. I don't need people dressed in their pajamas.

I don't dress in my pajamas. Right? So l well, let me, let me tell them.

Okay. So yes, at one, I admit at one time I'm Bob and I, I'm a recovery executive. Um, and, uh, yeah, one time in, in my, my my, my long and stellar career, I, I was CTO of a of a, of a emerging trading company on Wall Street.

And, um, I worked in New York during the week and I went home into the Midwest on the weekends. And I found, and my flight time was, uh, my flight day was Monday. And I found, I was, found myself getting paranoid.

'cause I couldn't watch what people were doing. I really couldn't watch what people were doing then. What are they doing?

They're probably smoking cigarettes and having a party when I'm not there. So I would start, then I changed my schedule to go every other weekend so I could watch them on Monday. Right?

And so that was more my, my paranoia. I, I, and then, so if they all went remote, I wouldn't know what they're doing anyway. 'cause the paranoia is mine.

So go, go. Going back to your, your point, Alan, as much as we'd like to have people in front of us, the, the trend, the heuristic trend I'm seeing is those days are gone. Uh, I buy a lot more from Amazon today than I do from Ralph's down the street.

As a matter of fact, the only deal there are, there are three retailers I go to now. I go to Ralph's down the street to get, get stuff that's not a Trader Joe's down the street. And, and then there's a guy, uh, that I go to get to get a haircut.

That's it. Everything else is pretty much done online. So the notion we're, we're all online now, but we're not all online because the, the stuff that this remote stuff applies to is knowledge workers.

The guy, you know, the, the, the, the 30 the 30 construction workers building this building down the street from me, they're not online. And it's interesting, they are remote because in a sense, they're, they're managing office is about 10 miles away. So the point I'm trying to make here is, as much as we'd like to, you know, have people in front of us and enjoy that productivity and that intimacy, yeah, we're all shopping on Amazon now.

And that, that's our future. So let me, let me run with that a second. I shop on Amazon too.

Whole Foods, right? And I have Instacart and all that. Amanda, do you do shopping in person or online?

It's A food shopping. It's A good mix of both. For me, I'm, I'm more of a, I would call it hybrid Mike.

Yeah, mostly a hybrid. So I will tell you yes, for packaged goods that you would get on Amazon, but I still for, when it comes to supermarket shopping, I like to pick out the specific fruit that I want. This is a good apple.

This isn't a good apple. When you order apples from Amazon online, you, you don't get the good apples. They take whatever the first three apples are and throw 'em in there, or the kinds of fish.

And I don't necessarily know what they got fresh local in the market that day. So to me, there is no comparison of supermarket shopping in person versus doing that online. Um, and it's the same thing with buying clothes.

Yeah, I could buy my clothes online now that I've lost some weight and I, I could fit into better clothes. But until you touch it, you don't know. Mitch, is this a technology challenge that we're trying to solve here, ultimately?

Because theoretically, at least I could have an algorithm that might tell me how fresh that Apple is before it was thrown into a package and shipped to me. Are we just on a journey here and we kinda rushed it because of Covid, but ultimately, you know, there are gonna be technology innovations, there's gonna be better video, more ai. Are we on just on a path?

Well, I, I don't know. To, to me, we're on an evolution of doing more and more online and the shop, the grocery shopping example is a good, a good one of it ain't there yet. The bane of grocery shopping is substitutions.

I don't want that brand of peanut butter. That's not what I asked for. And I told you not to substitute.

You know, there, there are still issues to work out with it. You know, I, that fish doesn't look fresh like what I like to buy. So there, there are things that aren't there yet, you know, and they're evolving.

Maybe they won't get there in the world that in, in it shouldn't. Bob's opinion, the world of Bob and I live in of software creation, you kind of go with where the talent is. And I can't get everybody into Denver, Colorado or Boca or LA or what, or just hire people that are local because the talent that might be available, the person that's really one on the team is in Austin.

You know? Yeah. Come join the team.

Or in Bangkok, right? Or Bangkok. Yeah, Exactly.

Exactly. Then we get into, you know, the whole wage compression stuff, which is, you know, and another, in another story, what will be, what will become interesting if is if we watch the e the elu, there's two parts here. The, the evolution of the online experience in this remote work.

I'm still, of the opinion that remote work is, is is that is affected, or I'm losing my words here, but it's affected to knowledge workers. And that's only a section of the economy or everybody else. They're, they're still real time.

They're still real time. But if we look at the, the evolution of the online experience, remember, you know, Amazon started with books and now if I get a, um, if I get a thumb drive that doesn't work, which is a non-perishable commodity. If I get a thumb, if I get a thumb drive that doesn't work, I just take it down the whole foods and I'm credited within, you know, Seconds, uh, Min seconds.

And so my whole shopping experience is no worse than going down the best buy, bringing a thumb drive home down the street, putting it in my computer doesn't work. And I go back to Best Buy. The, the reason is, is that the evolution of, of the business process is such that they, it's almost immediate.

So going back, so what's the next one, Alan? You're talking about high perishables. So what happens if Amazon says, okay, first of all, we're gonna guarantee the quality.

And they have, you know, their AI looking saying, oh no, Alan and Bob and Mitch returned all these apples. 'cause they weren't any good. We've got to implo improve our QA around our fresh produce, and eventually all the apples start showing up.

Cool. Mm-Hmm. That's where it'll be going.

All right. So let me take what they're saying. And with all due respect, you're Doing a lot of this today, basically Basic.

Basically Bob and Mitch said, Hey, boomer to you. Mm-Hmm. And you know, do you need to learn how to manage in a new world and a new reality?

And we can long for the days when we all hung out at a table. And there is much to be, uh, benefit there, but it's never gonna happen. Yeah.

So when, and, and when it does happen, gimme a call. But until then, I'm telling you that people are not as productive working remotely because, and, and Amanda, I'm not picking on you. I love you, but Amanda hit it right on the head.

If she wants to dress in pajamas today, she'll dress in pajamas. If she's having a nighttime work day, she'll work at night. I can't run a business like that.

I really, I can't. And I think it does come down to if it's project driven work with deadlines, or if it's, you know, truly hourly, you know, you're needed during certain hours. So it depends on the work itself.

And, um, like Bob said, it's only a certain type of knowledge work that can be done Online that works like this. But I'll give you another example. To Bob's point about Bangkok, look what, where's the biggest outsource for, for software development?

India, Bangalore, or other cities in India, Pune, and so forth. There's a good chunk of Bangalore that works our North American time. These people get up and they work on our time because that's where their work is.

Yeah. I think that's kind of the way, and, and I'm, and I'm not, you guys can make me feel bad. All you want.

I'm not alone in this. I've got some pretty smart people who are saying the same thing. Well, we can just say to people, don't put your PJs on from nine to five, regardless of where you are, because you are working with people.

Right. But to Bob's point, I'm not paranoid where I don't, I gotta see people to know they're working. I know Amanda works.

I see her output. I see how many articles we publish. The the point is, how much more productive could she be if she was sitting in the same office as you?

Right. Because she uses Slack part of this remote working thing is you gotta use the tools, use the nice job a that's our Slack anti-pattern. That said, we cannot find people as smart as Mitch and Amanda here in Florida.

So no, we can't. And the reason why we need shouldn't be in Florida. Yes.

That's what I was gonna, it brings us, us to the fact that we're casting a wide Net to, we don't need measles vaccines. Find all the full of talent. Yes, you do.

And, and so look, I I think there's a pendulum that swings here, right? Mm-Hmm. Um, even prior to Covid, when we were seeing the boom times in tech, you hired an a software coder.

If he was in Timbuktu, you would hire him because you need as many software coders as you can get. Now, as we're seeing these layoffs and we're seeing the jar market tighten up, now employers are getting a little more picky saying, I don't want that guy in Tim book too. Definitely.

I want the guy down, down the block. De you know, Alan, one thing I would say, I, I do agree. When you're face-to-face, I mean, when we went or like have an important meeting or a, a whatever working session, we all get together wherever it is.

Boca, in our case, um, there's a lot to say to that. I think one of the dynamics we don't talk about is a lot of what you're saying is ex very true for smaller, medium sized teams, right? When we're working on projects, we're working on something, we're solving a problem getting together.

When you get into larger organizations, you still tend to hang out in your area. My floor of the building, I don't go to the other floors that often, unless I got a meeting up there. And it's not that frequent.

I definitely don't go to the other building, uh, unless I really have to go. So, in, in larger corporations, the, the idea of bumping into together in the serendipitous, you know, innovation stuff happens, but not, not to the same level that it does at smaller teams. Yeah.

So I think that's where, where the everybody's gotta be in one building is b******t, because those people are not gonna run into each other. They're gonna see each other maybe when they walk into the building, and they're gonna work with the people that they work with. So, but when you need people to work together on something, the best way is to get 'em face to face.

I agree with that. Fair enough. It's kind of like when you're texting somebody over and over again and you're con continuously going back and forth, texting, texting, texting, texting, and finally you just pick up the phone or a phone call and you get everything taken care of right away.

So I think most of the time, working remotely is great and, um, everything's spinning along, but then when you just really need a lot of things to come together, being able to meet in person at least once a year, twice a year is so effective. So, with all due respect to my colleague who calls me a boomer, when he's a boomer as well, this is a big issue I have with my kids. Mm-Hmm.

My kids a phone and actually talk, everything is text. Mm-Hmm. And, and again, being remote and texting, you lose a certain intimacy, you lose context, you lose.

It's not the same as even talking on a phone, let alone being in person. And, you know, and, you know, are we destined to live in a world of Wally where we're all gonna be fat blobs sitting on a chair at home, ordering our Amazon, slacking our coworkers, and having AI write our stuff for us? And, and you know what, what's the meaning of life?

Yes. The answer's yes. That's, that is the end state.

That is the future, huh, Mitch? Uh, That doesn't sound too appealing at the end of the day. No, no, that does not.

At the end of the day, the human element and inner, you know, the relationships are so important. Safe San Francisco. Well, and Well, you know, yeah.

And, and then, you know, back in, you know, back for cars, you know, hay was important because the horses needed them. Um, and so, you know, the, the, the, the point that I'm making about that is that the experience will change. And the notion of what it means to be engaged is going to change.

The more, the thing I, the thing I worry about is that we just become so removed from this thing called reality. So for example, we, you know, the old days when you used to get fired, at least you got called into a room. You got called into a room, and there were three other people in the room, and you had to sign some papers.

And then you're given your severance check, you know? Now, now you get an email. Yeah, that's true too.

And what does that mean? Well, what's that? What, what?

And for us, you know, we are, we are, many of us here are boomers. So it's like, it's like an amusement to us. Okay.

Okay. That's cool. Isn't that cute?

He just got fired by email. But what happens when that the majority of the workforce that does work online, that's their experience of being hired, working, and being fired. What does that do to one's perception of reality?

I don't know. But we saw that poor woman who was fired and she recorded it on video. And I think they, in hindsight, they'd rather have sent an email.

Well, The email is a aesthetically clean, um, maybe depend impersonable depending on the content. Impersonable, because I mean, this is a great point. Look, getting fired is a traumatic experience for anyone, even if you want to get fired, right?

And, you know, the fact that we do it sort of surgically veer an email or, or in the case of, uh, X Twitter, whatever they call it today, right? They didn't even send the email first. First they cut you off from all of your e from your email and your, you know, resources and stuff.

And then you had to kind of figure out, this means I'm fired. Right? That, that's not, that's not human.

That's not the kind of company as a founder of a company that that's not the kind of company I wanna run. And, and, and, and I, unfortunately, we like everyone else in tech, we've had our share of layoffs. And you know what, it's not a happy thing to do, but it's something as the CEOI feel very responsible that I have to do.

It. It, it's not my favorite thing for sure, but I do it because the people who were having to lay off or let go deserve it. Mm-Hmm.

And that's why, um, Mike, if you could, in your video game, Alan, right, they don't Deserve to be laid off. They deserve your attention. Different.

Exactly. They deserve, they deserve, right? They do.

And I feel like it's my responsibility to do that because they deserve better. And, um, anyway, I think there's two things that we should address when it comes to this topic, which is number one, while the majority love working remotely, and that is the way, and that is the future, we do need to think about the, the mental health of those who are struggling with working remotely, um, and the isolation. So I think we should talk about that, but also about the technology that does exist, and how we harness that technology to make the remote work environment feel as human and close, um, as possible, like removing the distance and making it feel as personal as possible.

And there's a lot of technology out there to do those things. Absolutely. But those are for a future version of tech, uh, future episode of Te uh, Textron Gang.

We've gone over our time today. Hey, we hope you enjoyed it. Bob Ruman, it's so, I appreciate you getting up so damn early in the morning out there.

Um, see if you didn't work remotely, you'd be right here with us. But, um, thank you very much. We'll have you back on soon.

Keep doing what you're doing. Roll Bob cartoons, occasional essays. Bob, just give him a Google if you're interested in seeing some of the great stuff he's doing.

Mitchell, Amanda, we'll speak to you soon. Mike is always great show. Thank you.

All right. This is Alan Shimmel, Mike Ard, Amanda Rini, Mitchell, Ashley and Bob wrestler. For Text and Gang, we're outta here.

com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery, and more. com has the largest collection of original DevOps content, featuring breaking news, blog posts, podcasts, and more.

com to learn more. com, where the world meets DevOps. Hey, everyone, I hope you enjoyed today's text on gang.

It was a little hot and heated there with a couple of contentious subjects. Um, if you couldn't tell, I am a big fan of working in the office, but it was a great show. We hope you're enjoying Text Drunk Gang.

Let's get onto the rest of our text Drunk TV today. First up, it's me talking with my good friend Joe Duffy. Joe, of course, it's co-founder, CEO of Lummi.

And they recently announced some new infrastructure libraries, uh, may allowing you to use a Gen AI or abstract it with the Gen AI stack. Joe tells us all about it. Here it is.

This is Tech tv. Hey, everyone, welcome back here to Tech Drunk tv and welcome to our next segment. Uh, our guest for this segment is fellow who's been, uh, he's, I, I can't tell you how many of these he's done.

He's been on with us many times, almost I think from the beginning of Textron tv. It's my friend Joe Duffy. Joe is the co-founder and CEO of Lummi.

Joe, welcome back to Tech Drunk tv. It's great to see you, man. Thanks for having me, Alan.

Great to see you again. Pleasure. Uh, so Joe, as I said, you've been on a long time.

We, we've probably asked you this before, but I'm gonna assume a lot of people out here are A, they don't know who you are, and B, they may not know Lummi either, or may they, maybe they think they know Lummi, but who really knows Lummi. Joe, why don't we give us a little bit of, of the background here on both you and Lummi? Yeah, for sure.

So, my name's Joe Duffy, founder, CEO of Lummi. Uh, started the company actually about seven years ago, believe it or not. We're coming up on our seventh anniversary next month, um, which is kind of crazy.

Uh, before that, I spent, you know, over a decade at Microsoft, uh, working on developer platforms and developer tools like T Net, uh, was leading developer tool strategy before, before leaving to start Lummi. And the thing that struck us when we started Lummi was the cloud really changes everything about how we develop software, uh, from the design and architecture to the, you know, the implementation, uh, and of course how you run and operate it. And yet, you know, developers out there weren't thinking of it the same way.

They still thought of it as, you know, the world of two virtual machines in a database. Uh, and meanwhile, infrastructure teams were, we're, you know, dealing with a lot of tools that paled in comparison to what we have built for developers over many decades with great languages and ides and test frameworks. So we sort of thought to take a step back and, you know, we're sort of in the era of distributed computing and let's reimagine what that would look like in a modern way.

So that's what plume is best known for our infrastructure as code technology, which is open source. Uh, and we've since expanded into a broader cloud management platform with secrets management, configuration management, uh, search analytics, insights, and what we'll talk about more today, uh, AI for infrastructure. Absolutely.

And, and Joe, you know, chicken and the egg question. I think part of what has made Lummi successful is the success and acceptance of open source software, right? You couldn't have Lummi without open source in some, in some ways.

I mean, you could theoretically, right? But, but really it's, it's a big piece of that puzzle. A big piece of the equation.

Absolutely. And, um, so it, it, it's an interesting thing. ai, I always forget, uh, Dot com.

Uh, and yeah, just click one of the blue buttons, get started. It is, as you say, open source is in our DA super important to us. com/plummy as well, if you wanna check out the repo.

com. Very cool. Alright, so let's jump into this.

You guys have some new infrastructure libraries, uh, and they involved JNI, why, if you can explain it a little better than I can to our audience. Yeah, I think of, you know, we've been involved in AI in two ways. Uh, one, using AI for DevOps automation and workflows.

Uh, so we have, you know, uh, PMI copilot, which is a chat bot that can generate your infrastructure's code for you. And increasingly over time, it's just getting better. And we're, we're able to apply that to your unique, uh, organization's challenges.

But the second pillar is actually using PMI for AI workloads. Uh, when I think about AI workloads, I think of infinite compute, infinite data. Um, and, and Plum is really good at provisioning and managing infrastructure at that scale.

But the thing that we find is, you know, a lot of AI teams are not cloud infrastructure experts. So they, they have a, a thing running on their local laptop. Maybe it's a lang chain or some AI application, but when it comes to running in production, a lot of folks aren't sure exactly how to go about that.

And it turns out, when you talk to folks, a lot of the architectures are very similar. You know, there's kind of two classic patterns we see. There's, there's training the models and serving the models.

Those are heavily GPU based architectures, uh, very gnarly stuff. Often a lot of folks using Kubernetes for those. Um, but the second, which is what these new libraries are more about is the application.

You know, there's usually a front end, you know, whether it's a chat component or an integration into an existing app. Uh, and then there's, you know, um, resource augmented generation rag, which is, you know, Lang Lang chain is one way of stitching together a workflow of ai. But the thing is, running this in AWS or Azure or Kubernetes, it's tough, right?

And everybody's recreating the wheel. And so these libraries are meant to make those, you know, super seamless and easy. I love it.

Um, wanted to go back to this. I wanna go back to this chatbot that you have built in here. Is that running off of, uh, your own, like custom, uh, LLM or SLM?

Yeah, we've, we've built it to be agnostic to the LM so we can run it on, you know, uh, OpenAI or Azure Open AI or anthropic, but we've extended it with knowledge of cloud infrastructure, uh, which is what we're good at. And, um, and so it's very good at generating cloud infrastructure or infrastructure's code to, to create that, that cloud infrastructure. And over time it just gets better.

I mean, we've, we worked on correctness and continuing to refine the models, uh, but it is, yeah, that, that's sort of our secret sauce. Very cool. Um, let's talk about end users out here.

People, I'm sure there are people on here right now who are Lummi users, right? Customers, how do they engage this? How, you know, how do they make it happen?

Yeah, I think, you know, I'm increasingly telling people to start with the ai, um, because the thing that's really tough is, you know, you think of, we have over 150 clouds supported AWS Azure, Google Cloud, Kubernetes, snowflake, CloudFlare Datadog, you. And then each one of those has hundreds, if not thousands of services with different ways of configuring them. I mean, it's very daunting to get started.

And so I often suggest people to get started with that and just describe in natural language what you're trying to do. You know, Hey, I'm trying to build a microservice on AWS or, you know, I want a static website on Azure, and that's gonna guide you down, you know, the path that you need to go down. Um, if you know what you're gonna build, like, for example, one of the libraries we worked with, pine Cone, who's a vector database company doing amazing things.

A lot of people using vector databases. In fact, we use it for our chat bot for, uh, effectively, you know, compressing a lot of knowledge that we can then use to make the AI better. Uh, and so if you're trying to run Pine Cone in production, we now have a reference architecture for that.

Uh, similarly, another library is Lang Chain. Uh, so if you want to run Lang Chain, you maybe you've got it running locally on your desktop, but now you want to run it in AWS uh, our reference architecture that we worked with Lang Chain on is super easy to get up and running. So if you know that's what you want to do, just go straight to those reference architectures.

Uh, they're up on our website. Excellent. org, some other folks too.

Really, really good time. Um, and it, it, I really learned about how to train your AI and how to inject, whether you want to call it a small language module or, or what have you. Mm-Hmm.

Um, but my biggest takeaway from it, Joe, was it's real. Right now. Anyone who tells you it's not real, doesn't know what they're talking about, but the promise of what it could do, as we continue refining this and getting better at it, is crazy.

I mean, I will tell you since August I've learned really how to do prompts, which is a nothing thing, right? Just how to write a good prompt it, and it blows me away. I, I can't, you know, as you sit here, so this is your first release with the, with these libraries, how fast, how far do you think we're gonna be going here?

Very fast, very far. Short answer. Yeah.

Honestly, things that typically take years are taking, you know, one year takes one month, uh, to make that amount of progress. So it's very hard to predict. And, you know, that's one of the things that we face is, yeah, we can go spend a lot of time training and refining our own models, and yet GPT five is gonna come out, you know, sometime in the next few months, and it's just gonna eclipse everything we could have even imagined doing ourselves.

And so figuring out where to spend the energy and the effort is, is definitely challenging. But I think a lot of people using AI to apply it to problem domains. You know, we talk to customers all the time.

Everybody has an AI slush fund, even, you know, fortune five hundreds. It's, you know, finance, you know, healthcare, like literally every industry management is saying, run fast. Just build value using ai.

And that's very exciting. But if you're an engineer in such an organization, like it's, it's pretty hard to know how to get started. Agreed, agreed.

Um, the other thing though, and it's funny that I told you, I was on a webinar, uh, Roundtable before I came on here, the proliferation of, well, there's the proliferation of ais, but look, you could just make sort of a generic that plugs in, you know, different ais on, on the, on the go, but the proliferation, proliferation of tools that are then AI enabled. Mm-hmm. Right?

It, because it's also speeding that up. It's speeding up a new generation of tools by leveraging this AI that I, I, at some level, I guess it's confusing for developers because, you know, they have a wealth of choices that maybe they didn't have before. But on the other hand, it's gotta benefit them at, because, you know, we've been through the technology game before, Joe.

The, the cream kind of rises to the top and the crap settles to the bottom right. The market is ruthless like that. And, um, you know, the, the tools that are gonna rise to the top here are just phenomenal pheno.

I mean, the things that they could do is gonna be crazy. How do you, how do you keep Lummi have its edge? Is open source a secret source for it?

Is there something else? What do you, as the co-founder, CEO, I'm sure there's something you think about all the time. Yeah, I think the, one of the best bets we ever made was to bet on programming languages.

You know, that that was our unique angle on infrastructures code, is we're gonna stand on the shoulders of giants. And every benefit in the domain of programming languages now accrues to Plummy as well. And that was true of, you know, test frameworks and IDs and refactoring and libraries and package managers and, you know, secure supply chain.

And, and now it's true of ai. You know, instantly GitHub copilot was good at writing PMI code, uh, for example. And, you know, as the industry continues to evolve and make those things better, we, we benefit from that.

I would say we also have our secret sauce, you know, our understanding of cloud infrastructure, all the metadata, the semantic understanding of the cloud, and we can use that to develop better models. And so that's where we've been focusing energy. But my feedback to the team, there's a lot of people, I call it AI cookie licking.

Everybody wants to lick the cookies so nobody can eat it. Um, everybody's, everybody's doing that. But my feedback to the team was, sorry, that's kind of gross.

But, uh, No, no, I like it. It's a great analogy. Yeah, We used to use that phrase at Microsoft quite a bit, uh, but Uhhuh, but my feedback to the team was, let's use ai, but, but let's not do it just for AI's sake.

For every problem you're facing, take a step back and say, how would I solve this in an AI first way? And if that genuinely leads to a better user experience or a better solution, let's do it. Uh, if it doesn't, that's okay too.

Um, but that's been, that's to your point on the cream rising to the top, that that's been my philosophy and how to tell the team to make sure to focus on the cream versus the crap that's gonna ultimately fall to the bottom. Absolutely. Absolutely.

Joe, we're about outta time here, but you know what, I'm glad to see Lummi is riding the wave as, as you have. I mean, you know, I'm probably working with you now, I only four or five years, maybe more. Yep.

Um, and you've, you know, you've always kept Lummi on the edge, so I'm not surprised to see you out in front on this one as well. You need to have, you're gonna have to come back though and tell us how things are going. Absolutely.

I'd be more than happy to, and thanks for having me. All right. Joe Duffy, co-founder, CEO of Lummi, go check out their new infrastructure libraries that allow you to, uh, work in gen AI here with all of the great languages and, and infrastructure that Lummi helps you with.

We're gonna take a break on X drunk tv. We're gonna be back in a moment. Next up on Textron tv.

Today is another good friend of mine, Mike Nelson, who, uh, who is over at DigiCert, and he's gonna talk about DigiCert's 2024 State of Digital Trust survey. Uh, Mike is, I believe, VP of Digital Trust at DigiCert. And then there's a lot of good information here.

This is Textron tv. Hey, everyone, welcome back here to techron tv. I'm so happy to welcome back to our screens today, my friend Mike Nelson.

Mike is the global Vice President of Digital Trust over at DigiCert, and has been for a long time. Mike, how long have you been at DigiCert Man? Coming on nine years.

Can you believe that? Yeah. I, well, I feel, look, I know I was talking to you before covid, so it's gotta be at least five years that you, I are talking probably more.

Yeah. I mean, Alan, it feels like our friendship goes back. You're just too, you're such a friendly guy.

It's easy, you know, it just feels like it goes way back, but I think it was, I think our first interview was right before, uh, COVID, Maybe the year before. So yeah, it's five years easily. Anyway, Mike, let's start a little bit, you know, Globes global Vice President of Digital Trust.

Digital Trust, of course, is something that's near and dear and to the core of DigiCert. Um, let's talk a little bit about you though, and kinda your history and, you know, background and, and why you're kind of the perfect guy for this role. For Well, I love trust.

I think trust is very important. And as our world has become more connected, we talk about, I mean, um, you look at, uh, connectivity has exploded within enterprises, um, as employees have moved home. And, uh, COVID was a forcing function of that.

As we're introducing more connected devices into our life, software is, everything is everywhere. Um, I mean, the world is more connected and trust becomes absolutely critical in connected world, and that's really the mission of DigiCert. And, you know, I, you and I have talked about my, you know, I'm a type one diabetic.

I use connected technology to kind of keep myself alive, and I've got a 9-year-old daughter who does the same. And trust of those systems is really important. So at a personal level, I really get it as well.

And I'm a huge advocate and passionate about it because I really believe that, um, I love technology, but I believe technology needs to be trusted. And so I have a lot of fun talking with people like you and evangelizing and talking about the things that we can do to make sure that as we engage in that connectivity, that we can do so in trusted ways. Love it.

I love it. Mike, I don't want to take up too much time, but I, I think most of our audience, you know, they're a technical audience. They've heard of DigiCert.

I don't know if they realize Just how dominant DigiCert is in, in the space that you guys play in. Um, you know, we all, I think the first thing people think of is SSL certificates. When they hear DigiCert certificates.

And yes, that's a big part of your business, but digital certificates today are a big part of our life. Whether we're talking about our smart home equipment or our, you know, or the containers that our, our, you know, multi-threaded application, uh, applications run on, you know, whether we're talking about verifying identities of humans, machines, software, I mean, in all, you know, the, the underlying basis for what makes the internet work is, is the ability to have faith that you are who you say you are, and it is what it says it is, and, you know, yeah. And that it's pretty much accomplished via, via digital certificates.

Yeah. Did I get that right? Yeah, you're right.

And, and, um, yeah, I mean, certificates and, and dig search role with certificates has predominantly in the past been around public SSL certificates. But to your point, the use of certificates has exploded in other ways besides just for web servers. You know, today they're securing endpoints, laptops, uh, desktops.

They're securing connected devices, critical, um, you know, devices, performing surgeries and things like, uh, glucose monitors and insulin pumps. And, uh, the vehicles that you're driving, certificates are used on most of the, um, operating systems and the control units within those. And so, you know, certificates are, um, and, and most consumers don't know that, right?

When you're technical and you understand how to authenticate and how encryption is done, then you get a better understanding of where in house certificates can be deployed. But really, they're the fabric of security under most of the digital connectivity that we have. You look at software, how do you secure software?

You do it with a signed digital certificate, right? And so, um, there's, there's so many ways that certificates can be deployed, um, in this ever expanding connected world. And, um, you know, DigiCert is, to your point, as a global leader, um, we define digital trust really in a handful of different buckets.

Like enterprise, it's important that enterprise have it. Software needs digital trust, connected devices need digital trust. More and more, we're seeing digital content.

So you think videos, you think documents, all of that stuff needs trust. And so we, we pro we play in all of those different spaces and, and we're, you know, promoting trust and security best practices and all of those, You know, what we we're gonna talk about the, the 2024 stated digital DigiCert this year study. But before we do, on in that vein, you're talking about, Mike, there's two, two areas I want to bring up.

One is AI and deep fakes, right? How do we know, how do we know This is really Mike talking to us right now. And I mean, we actually ran a story in security Bill a couple weeks ago.

Some poor bank manager had a Zoom with some, was supposed to be the CFO of a company asking him to do a little bit of an unusual transfer of $20 million or something. And the guy, it was him, it, you know, the bank manager had him on the video and he knew the guy, and that was him, and it was his voice, and he was surrounded by other people that he knew. Well, it was a, it was a deep fake, it was all AI generated.

Yeah. This is something DigiCert wants to help with, right? Yeah, absolutely.

I mean, I believe that in the content trust space, Alan, we're on the brink of some big, um, the world needs trust. Um, you think about the inability to trust content and videos. Uh, we have elections coming up.

Can you trust elections? There is so much trust that is needed, um, in the content space, and it's lacking right now. I think people are searching for truth.

And it's, it's hard to find sources of truth because content is just hard to trust. And we need the ability to know where it came from, know who the authors were, know if that person in the video is right, and to have integrity. Even photos, we're doing a lot in the photo space right now, um, with, with some standards there.

How do you know that photos that you're looking at are actually the people that are, are in it and have been fabricated? And there can be a lot of bad outcomes when if people can't trust those. And so we need, the world needs that, and that's a, that's a critical mission at DigiCert, and we're trying to promote that.

Absolutely. And, and for those who are interested in this kind of thing, you know, we were, tech Trunk TV was at the DigiCert user conference. I I, was it last October?

Yeah, maybe early November. Yep. Uh, and we had a chance to sit down and talk to a bunch of DigiCert, like some of the really smart, not that you're not smart, Mike, but to some of the really smart people at Digi Search that's smarter working on, that's who are working on these initiatives as well as some large organizations that you're working with.

And, and, uh, if you go over to the digis, actually it's on Textron TV too. If you look up under event events, I think the whole collection is there. You can go and watch it.

Mike, one other area around trust and around security that I, uh, I wanted to just quickly ask your opinion on, I did an interview a couple weeks ago and someone gave me the number that, uh, I think it was 54% of, of internet traffic now is API to API. Right? It's APIs Yeah.

Communicating and, you know, shuttling data back and forth. So we, you know, we, we look to test identify identities of people. We, we verify identities of devices, we identify identities of containers.

What are we doing to identify or, or trust API calls? Is that something you know about or what do you think? Yeah, I mean, APIs are a big part, um, of, of the technology that we, we deploy.

And, and there certainly needs to be trust and identity, um, with those. Um, and yeah, I think you're right. I, we, we see that the security of API, uh, connections, um, is, is paramount and having authenticity and, um, knowledge that, um, what you're connecting to is can be trusted.

And so, um, you know, that, um, we, you know, the APIs that we deploy many of our customers use, use those, and they're good security approaches that, uh, we take to make sure that, that those can be trusted. So I, I think those same approaches need to be, uh, employed, uh, with that. And so, um, you know, I, I haven't seen that study, but I, I do agree with your, um, approach that as those things, as we see more and more API to API connections that you still, you need trust between those If you want, if you're interested.

I be, um, and I hope I get this right, but I think that study came at CloudFlare. Okay. I was talking to their C Yeah, yeah, I'll go check that out.

That's Interesting. Grand ous about it. And yeah, they had a whole study on API security, and I remember thinking back then, I wonder if this is something DigiCert could help with.

Right. I don't even know how you would go about issuing a certificate to an API, but you, you guys would know if anyone knows, you'd know. Yeah.

Um, Mike, let's turn over to DigiCert's 2024, state of Digital Trust. Awesome. Lay it out for us.

Give us a little background and, and what we can expect to see here. Yeah, I mean, I think it's, it's important to note that, uh, you know, at DigiCert we're, we're constantly monitoring, um, the evolution, uh, and, and state of, of digital trust. And I think that, um, you know, it's, it's been, it's been interesting to see the progression where we're still, where we see the world still lagging, uh, where improvement needs to be made.

Uh, but we recently conduct, uh, we recently concluded, um, our 2024 survey on, on digital trust, and I think we had some compelling findings, and I'm excited to talk to you about some of those. Cool. Let, let's hear.

Well, let's dive right into it. Into it. Um, yeah, so I mean, I think, uh, the, the first thing, just to note, you know, I think we, um, we surveyed wide and, and far, uh, it was a global survey, um, that spanned all regions, uh, of the globe.

We interviewed, um, over 300 senior decision makers, uh, in the trust space from small to large enterprises. So we, I think we had a good range of, of coverage, various industries, um, mostly targeted at critical infrastructure, uh, just to kind of set the, the groundwork for that. But, um, you know, I think that the findings, um, well, while some of them may not shock, uh, may not be shocking, I think are leading to help us see that we are seeing some maturing in the digital trust space.

Um, but I think, uh, for me, um, we're seeing more, um, we're, we're seeing it's a, a divide between the leaders and the laggards. I think we're seeing the leaders are actually doing really good things and are employing trust practices that are protecting their infrastructure. Um, and you know, I, I think we broke our survey down into, um, you know, the leaders and the laggards and then the, the middle group.

And really most are leaders, or most are laggards. We don't find a ton in the middle. Um, and, and I think that that leads us that organizations are either in or they're not right now.

And, um, and once they get in, I think, you know, we're, we're seeing healthy engagement in the right type of activities, and we can talk about some of that. But, um, but you know, I, I think it, it also emphasizes that, um, that getting on board with digital trust practices can be hard for organizations. But once you get the organizational commitment, the executive, uh, the executive commitment to say, look, this is an important priority for us.

We, we see organizations starting to see the benefits of doing trust right away. And, and I think that, that, I think that becomes compelling, but I think that there still is a growing divide between the leaders and the laggards. Um, it's interesting some, yeah.

So, um, you know, I think that there's, um, a handful of, um, compelling things. From my standpoint, I think the leaders, one of the characteristics that we see that I think is really interesting is a centralized approach to security. Um, we see the leaders that are actually, they're doing a better job at defining policies for cyber and trust and enforcing those policies.

Instead of saying, Hey, we've got a burning fire over here, go put it out. They're looking at it more at a strategic level and saying, what are the things that we need to do to protect, create policies and enforce those policies? Um, and then once they do that, they actually bring security to the business as a centralized approach saying, look, this is not an option anymore.

We need to enforce this through policy. And that was a common characteristic we see amongst the leaders is that centralization of policy and enforcement, but then also of security solutions we see in the crypto space, um, the elimination of kind of siloed certificate management saying, look, we need to do this from a central position so that we can have control, we can have visibility, we can have, um, the ability to mitigate if something goes wrong. And so centralization is something that to me, stood out quite a bit because, um, I think it's a mature practice.

It's something that organizations should be doing from setting policies and enforcing those policies. I love it. Um, it's interesting, you know, so I've always followed, I, I forgot who the author is, but crossing the chasm model where it's the middle, where the meat is, right?

But you seem to have almost, I call it a dumbbell, right? It's heavy on the, on the bo on the front and the back. And people, as you say, people are either all in or they're not.

And I, I can't imagine, you know, but usually when you look at a large market like this, we're not all all in, and we're not all laggards. The middle is usually the fat part, right. People that are in various stages of, of getting there.

So it, it, yeah, it's an interesting, Yeah, and I, and I look at that, Alan, and I think that's right. But I think the challenge with it is security is not as efficient until it's properly managed. And once you get proper management of it, it puts you in the top group.

And so as long as you're dealing with security from a chaotic lack of management standpoint, when you're responding to a survey, I think people think it's still chaotic and they're not doing well. So they qual they identify more with the, the lower tier, right? Mm-Hmm.

Um, it's hard to say you're doing security. Well, when you're 50% secure, if you're 50% secure or 50% in your practices, you're like, I'm not doing very well. Right?

Yeah. You don't get that confidence until you have higher levels of trust and you're doing things that are actually giving you more of a enterprise-wide confidence that you have the right things in place. Yep.

Does that make sense? I think Yeah. No, it absolutely does.

And I, but I think you also hit on, you know, I've been security 25 years. You also hit on one of the soft wide underbellies of security, which is most organizations don't have the wherewithal to get there, right? Yeah.

They don't have the budget, they don't have the manpower, the skills, the skillset to get there. And, and so you can't be a little bit pregnant here. Either you're doing it or you're not.

Yeah. And that was one of, one of the findings is as we look at, um, as we look at the challenges, I think, um, you know, the increased complexity of connectivity, um, is one, you know, I think organizations are saying complexity is, we talked about at the beginning today, is like the complexity of connectivity is just skyrocketing, uh, with remote workers. Networks are becoming more complex.

The applications that are connecting are, are more challenging devices, remote workers, all that stuff. Um, but a skillset is still listed as a top reason for why people are struggling is not being able to find the right resources. So I think that still is, is a significant challenge for organizations.

And an interesting thing, the number one thing, you know, when I came outta school, we didn't have cybersecurity in school. You know, you didn't have a cybersecurity degree, you had computer science, but really nothing on security. Now you've got kids coming outta, you have people coming outta school with cybersecurity concentrations and degrees, and they can't get jobs, right?

The number one thing we hear from those people is, how do I break into this industry? Yeah. And I can't get a job.

Every job wants three to five years. I'm just coming outta school. Yeah.

Um, so, you know, we, we've created this conundrum of we can't get people to fill these skilled jobs 'cause they don't have skills, but we won't give people a chance to get those skills, even though they may have education behind it and everything. It, it, you know, it's a, it's a catch 20 class, a catch 22, and, um, is what it is. Let's return back to our, our, uh, report, though.

What else is, is, you know, in the top highlights here. You know, I, I think just, uh, a compelling outcome for the leaders is the benefits that they achieve from having those in place. So you look at, um, significantly less, uh, exposure to data breaches, significantly less disruption to their business because of outages.

Um, those, you know, outages and data breaches can be catastrophic for organizations. And, um, there was dramatic variation in the leaders and the laggards with the impact of the business on those. And so as you're looking at compelling reasons to engage in that, I would say that that is certainly compelling elimination of data breaches.

Um, and, and also compliance. So a lot of organizations, uh, operate in critical infrastructure where they have regulations that they have to be compliant with. Um, the leaders, um, report a much high, it's, uh, it, uh, much higher compliance with regular regulation, um, and less impact based on, um, non-compliance to regulation.

And I think that that, um, is another, you look at healthcare or automotive safety critical systems, uh, you know, you need to have compliance and you need to have solutions that allow you to do that. And a lot of those regulations now are starting to talk about protection of data, the protection of the critical systems, and the security of those. And so having the ability to confidently say we've got the right stuff in place, um, uh, to be compliant with those, uh, is, is really important.

And so I think that there's, the takeaway from what I'm saying here is that there is business impact, uh, reputation, you know, I mean, preservation of, of income and earnings by not having to spend money on recovering from data breach or outages. There's tremendous, uh, benefit to the organizations that are engaging in digital trust. Um, and, and I think that's, that's a compelling driver, uh, to say to those that are in the laggards, you gotta get on board.

Absolutely. You know, um, it kind of reminds me of when you look at the DORA metrics and the Dora surveys in DevOps on high performing IT teams and how having a high performing IT teams smooth so many bumps and, and allows you to accelerate so much faster than not having a high performing team. Yeah.

It's the same thing here with security. Mike, I, I'd love to jump more into this to you, but we're, we're at the end of our time. We got people in the waiting room.

I think we might have to do a part two on this one, that it happens every time you and I talk we wanna done. Yeah. We'd love to chat.

Yeah. Um, before we go though, for people who maybe don't wanna wait till the next segment, we record to find out more, where can they go get this report study? com.

They can go and there will be a link where they, they can find it. And if, if you'd allow me, I mean, I, I think the, I I would love to end on this, if I could just say, sure. You know, Digi, we have some recommendations that we're making for organizations based on the findings of the study, and I think your listeners will find this study compelling.

So I do encourage you to go, we've touched on some of it, but there's a lot more. But, um, we have four recommendations. One is organizations need to take inventory.

Um, they need to really have an inventory and understanding of the crypto assets, the security approaches that they're deploying, really understand where you are and take inventory a around crypto assets. Inventory is so critical. Um, but then the second one, and we've talked about this, is define policies.

Get your corporate policies in place that govern how security is to be deployed so that you can ensure trust is there. And then enforce that policy centralization of security approaches, especially around certificates, is absolutely of them grows. One of the biggest challenges they reported was centralized management of security.

And so get centralized approaches, figure out how to do that, and then prioritize your approaches based on your business and the risks of your business. Prioritize what you're doing and your roadmap based on the risks to your business. And, you know, I think, uh, there's a lot of compelling data in this survey.

Really appreciate being able to dive in with you, Alan, on this. And I hope you, I hope you and your, your readers can go and find some more insights from the survey. Absolutely.

Well, I'm serious. Let's have you back on, and to jump in, we'll peel the layer back a couple onion, a couple of layers of the onion. Mike, it's great seeing you again.

Great work as usual on the state of Digital trust report. And, um, keep doing what you're doing, man. We'll be in touch, Alan, always fun to chat with you.

Thanks for having me on. All Right. Mike Nelson, global Vice President of Digital Trust here on DigiCert.

We're going to, uh, here on Text Drunk tv. He's from DigiCert. Uh, we're gonna take a break right now.

We'll be back in just a minute. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of Security Bloggers Network. Next up is our own Amanda Rini, uh, in a digital CXO leadership insight interview, and Amanda speaks with Dr. Vic Brou about the ways in which the medical industry can embrace digital transformation to help underserved communities.

Hello, I'm Amanda Ani with Digital CXO, and I'm excited to be here today with Dr. Vic Bock group. He has a lot of information about the health industry and how they can digitize.

How are you doing today? I'm doing well. Thank you so much for asking.

And more importantly, thank you for having me here. I really appreciate the opportunity to speak with your listeners. Yes, thank you for coming on the show.

So tell me, you've worked with a lot of underserved communities, um, and you're really passionate about bringing digital transformation to the medical industry, um, industry. Um, what have you done? Can you share a little bit about that?

Yeah, absolutely. Happy to do so. You know, uh, for me, a lot of it started when I was in medical school and I, uh, worked on a nonprofit, uh, that builds clinics, uh, specifically pediatric clinics in the developing world.

Um, and so we ended up, uh, building facilities that would care for kids and their families, um, in communities in Uganda, in Central America, in Asia, quite literally in about 10 countries. Um, and that formed, I think, a lot of the base for me in understanding how best to serve and how to scale, you know, what are always limited resources because the need is that great. Um, so digital transformation became a real, you know, key part of my learning journey, um, in terms of how to reach more individuals and how to make your services more accessible.

And technology ends up being a core part of that answer in many cases. So can you tell me, how do you reach these individuals? How are you utilizing technology?

Can you give a few examples? Yeah, absolutely. You know, across a number of different operating environments, different companies I've worked with, um, you know, you can never replace the human.

In fact, you shouldn't. You should really try to maintain that human touch and feel, uh, throughout whatever services you're delivering, especially in healthcare, it's so incredibly important to establish a human connection and make that last. But the backend technology can often be quite transformative.

So if you think about, um, the connection we may feel through texting and through messaging, um, you can have a clinician. In one example, in one company I worked with, we built technology that allowed us to engage with patients in a very personalized way. Meaning we could message back and forth together, and on the backend, the technology supported a doctor or a nurse having conversations with 10 people at the same time.

Now it's hard to keep track of that, which is why the technology was so important to be able to tee up when someone had replied how much time had passed since they were, you know, since they had messaged you and you needed to get them at least some kind of response. A lot of people ask the same questions, and so you can draft a lot of the answers that are very customized to the need of the moment. Um, but you can do it in a way that feels very personalized.

And so in that case, technology was a key part of the service delivery experience. Instead of having each letter typed anew, there were some quick shortcuts that our clinicians were able to use on the backend to still deliver a very personalized interaction with great information. So that's just one example, but a lot of it tends to be how do you support the caregiver?

How do you support the clinician? How does your technology enable scalability of what you bring to the table? Because there's really only one of you, and there are many patients that you may need to serve.

That's a very clinical context, right? So happy to share other examples about different environments, but each environment carries with it the potential for digital transformation. I think that's what's important to keep top of mind.

It's a commitment to technology and to digitizing the experience Absolutely. And getting that medical help around the world. So in regard to that, you mentioned a few countries when a country doesn't have a lot of access to technology in the first place, how do you bring digital transformation to those countries?

Um, how do you utilize technology when there isn't a lot of technology there? You know, the first thing that you know, we do, um, whenever we're operating in a new environment is to do an assessment. You gotta survey and see what are the tools and resources when we walk in with a lot of assumptions, unfortunately, we fall behind on our ability to build correctly for the community we're trying to serve.

So the first step is really assess and understand what are the tools and resources that are available. You'd be surprised in, in countries that you would, um, maybe not see the same level of infrastructure in front of you in terms of roads and bridges and so forth. Um, you actually have some of the latest and greatest cellular technology infrastructure that's available on the market today because it's new, it's more recent.

Um, so it just depends on, you know, what exact, uh, need is in the community and how you're trying to serve it with what level of technology deployment. Um, so transformation I think is it's important to take a step back before you, um, you know, charge in, if you will, and, and, and just assess and see what the needs are before you, before you start deploying, um, some of the tools you have available to you. That makes complete sense.

So what about here, I hear more and more about Teladoc as a way to get medical help. Um, what do you have to say about Teladoc and where that's going? And then also, um, I'm seeing more and more robots being used in the medical industry, even for, um, diagnosis, uh, at ERs they're talking to a robot, um, and the physician is at home.

So, uh, and that all is of course part of digital transformation as well. So can you share a little bit about those technologies? Yeah, there is.

So there are so many exciting things happening in healthcare when it comes to new ways to deliver care, to deliver support, to be able to help understand what people need in their home environments and, and how they live their daily lives. Um, especially when we're talking about, uh, communities in need. And so whether it's Teladoc or American well, or any other number of telemedicine companies, there quite literally are a lot on the market today that are doing some important cutting edge work on rethinking the care pathways and being able to augment our ability to understand from the patients we're trying to serve, from the people we're trying to serve, what the need is.

You know, one of the things that I think is, um, it's, it's, it's very interesting to me that if you're talking about someone who has high blood pressure, the current standard of care might be seeing your physician or your nurse practitioner in once or twice a year, maybe three or four times a year. That's it. And you might be given a blood pressure cuff or asked to buy one, and you might be tasked with writing down those numbers and bringing them in with you.

But more often than not, we forget the notebook at home or we don't actually record it, um, as consistently. I did have a patient, uh, once, um, who recorded their heart rate, um, as one of the numbers instead of the systolic and the diastolic blood pressure, the top number and the bottom number that we typically associate with the blood pressure. And it was an innocent, normal, um, thing that someone who's nonmedical may not know how to do.

But to me it stuck out like a sore thumb. And I was very curious why these were the numbers and why they were recorded in a certain way. I hadn't done my job to explain properly how to record this information.

And so I think we have oppor. As we think about the role that digital transformation can play using telemedicine, we can connect with our patients and the communities we're serving more frequently. We can do it with digital templates that allow us to automatically collect the information and put it into our electronic record, our medical record, where we can access it and react to it.

And there's so much more that we can do that we're not doing. And if we were appropriately managing blood pressure for every single person, then we wouldn't need this technology. But the truth is, we're not, as a healthcare system, we have a long way to go to serve those people who suffer, um, high blood pressure or low blood pressure or blood pressure issues in general.

Um, you know, I don't know if you deal with blood pressure issues or diabetes or any other number of, of medical concerns, but I can tell you that if you did, I would want more for you than a once or twice visit a year to a doctor's office that may not fully allow the level of behavior change that is needed to compliment whatever medications you might be eligible to receive and so on and so forth. So the role that telemedicine and companies like the one you mentioned, as well as many others that are out there, the role is to introduce that technology to help people adopt it and learn how to adopt it, and then ultimately to access the level of support that you need. And I do think that digital health right this moment is perfectly poised to make some of these advancements in the outcomes that we drive for the communities we're serving.

Especially when you live a very difficult life and it's hard to go to the doctor because you may work an hourly job, you may not be given the time off that you need. You may have other barriers to care, such as a lack of transportation and the, I could go on and on on this, right? But health equity and the ability to achieve equivalent outcomes for the people we're serving actually starts with digital transformation and a recognition of what tools we can bring to meet people where they're at.

Absolutely. And something you said there, I've actually had conversations with people who didn't have, who didn't have, um, easy methods of transportation and they took time off, or they scheduled the taxi to get to the doctor and the appointment was canceled or rescheduled. And, and this happens on numerous occasions to most anyone, even myself.

And so, especially in the underserved communities, when that's difficult to get there in the first place, that's very frustrating. And so utilizing these technologies would be very helpful. Um, and then another thing you said, um, just, uh, in general using digital transformation as a way to track data, more track medical data of individuals, um, uh, to get a better medical diagnosis for them.

Absolutely. You know, I mean, I think that when you properly house the data and you leverage it for, uh, the outcomes that you're trying to achieve for the people you're serving, that is the full end-to-end solution. You know, you can't just do the assessment and wish that, or hope that after they leave your office, that they're gonna be perfectly empowered and comfortable and knowledgeable about what they need to do to improve their health.

You've gotta provide a support network along the way. I need that in my, uh, with my health issues. And, and I think everyone deserves that ability to receive the level of support that they need.

And, and different people need different levels of support. My parents need a little bit of help using their phone and understanding how a continuous glucose monitor can actually be, uh, applied to the skin and then connected to the app. And there are a few steps there that are not just, you know, easy for everyone to do.

So in their case, they need a little bit of extra support. Um, someone else may be perfectly fine opening a box, reading a, you know, pictorial diagram of how to do the different steps and, and be off to the races. So we've really just gotta make sure that as we do digital transformation, as we commit to it, we're building in the right, uh, user journeys and right pathways, uh, that accommodate different levels of need, different levels of support.

Absolutely. Well, thank you so much for coming on the show today and talking about digital transformation in the medical industry. I appreciate your insight.

Oh, my pleasure. Thanks so much for having me. Thank you.

I'm Bonnie Schneider, sustainability contributor to the Techstrong Group. I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter. The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry.

Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong Research. Next on the agenda, we have a Cloud Native Now podcast featuring our own Sharon Florentina, Mike Ard, and they're gonna talk about the issue of Kubernetes Management, who's managing it, uh, you know, when you're building out your Kubernetes team, should you develop in-house talent, freelance contractors. What about the role of MSPs?

Uh, Mike and Sharon dive into this subject, which I think is an important one for all folks as we move to this new stack. And here it is. Welcome To the Cloud Native Now podcast.

I am Sharon Florentine, once again, I am here with Mike Vard, and we have some awesome, awesome issues to get into with you this week. Uh, the first one being, as an organization, when you're putting together your Kubernetes team, how do you go about doing that? What is the best way to staff those folks?

Do you want to start building an upskilling in-House? Do you wanna bring in freelancers? What are the pros and cons of these two approaches?

Yeah, or sometimes not just freelancers, but actual professionals with skills, because there's a whole class of folks who are managed service providers who you and I are both pretty familiar with and have a lot of expertise in this space, and Yep. So I, I think the debate though is, uh, do I go hire folks or try to hire folks and retain them when they are hard to find and in high demand or, And very expensive, Right? Or do I go with contractors that, or available be, but you know, they come and go and they may not be around when I need them versus, you know, we're starting to see some managed services from outfits like Fairwinds and others.

But, um, you know, they've developed a team. They have a framework, they manage these Kubernetes clusters, and that becomes a bigger issue as you start dealing with fleets of clusters versus onesies, twosies. I think we're gonna see, you know, everybody using a mix of all of those things, but maybe more reliance on managed services.

Because if I look in the cloud, most of what people are using from AWS and Google and Microsoft and the like, is the managed services version of Kubernetes. They're not provisioning it there. So it's not clear to me they want to provision it in a local data center at the edge themselves, either.

But what's your sense? No, I agree. And I think that's, that's where the success of, um, so like you mentioned, the, the AWS managed Kubernetes, uh, service is, you know, that's, that's kind of what's driving that, is folks are looking, this is, as you say, many times, Mike, this is one of the most powerful, but one of the most complex technologies to ever hit it.

And people are looking at that and going, you know what? If I can find someone that I can pay to do this for me and make sure that everything works together correctly and runs smoothly and achieves the outcomes that I wanna achieve, I am just gonna offload that and, you know, be, be happy with it. Um, And there are a lot of places where they have platform engineering teams with that level of expertise, but the closer you get down to the mid-market and SMB, the less expertise there is.

So the tendency to rely more on managed services, I think edge computing all will force this issue because, um, if I start having clusters that are distributed at the network edge, they're physically in places that I don't have an IT team to get to anyway, right? So I'm kind of have to find some way to essentially manage all that. And sometimes it's just easier to hire somebody to do that than to do that myself.

Especially when, um, my internal IT team probably has a handle on my virtual machines and my monolithic applications. But do they know Kubernetes and client Right Systems attached to that and, and cloud native applications that are built on top of the clusters themselves? Um, I'm well wondering.

Got my doubts. Yep. Yep.

And I think people make a lot of, of, uh, noise about the cultural aspects in a previous life. One of my coverage areas was hiring and upskilling and, uh, and all that, that good fuzzy stuff. And, uh, you know, there, I think there's something to be said for that team cohesion aspect that you work with these folks every day, you have a shared goal within the business that you're all working for full time.

But I think there's also a place for bringing in external folks, whether that's via managed service or a, a freelance or, or a contract worker because you get a fresh perspective. Maybe they use different tools, maybe they have different approaches or ways to look at a problem that you don't. And, uh, so I think they're, it's, once again, it's unique to the organization and everybody's gotta do what is best for them and what's gonna get them to the outcome that they wanna achieve.

I think there's kind of three yardstick to look at. I mean, the first one is, yeah, how much do I need to continue to do the, continue to do this every day? Do I need my team to do that every day?

Or is this a task that we need to do one time only? It's kind of the reason why you see so many organizations rely on contractors to build applications for 'em. 'cause they're basically like, but once we get the application up and running, we can take care of that part, but we don't really wanna hire a full-time developer just to write the code for us.

We can get that from somebody who's a contractor. And then I think the third leg then becomes, what, what level of scale am I gonna deploy and do I have the skills and expertise to do that? And if I don't, but my scale is gonna be large, like, I don't know, I'm gonna be using Kubernetes to, in, you know, a thousand retail stores, maybe I am gonna look towards a managed service.

So it all comes down to that. But you and I know that historically there's always been a bias against managed service providers. Internal IT team is always a little wiggy about the fact that somebody's coming for their jobs.

And, um, a lot of times the MSPs are, uh, inconsistent, shall we say, in their, uh, their flexibility. And they're even desire to, you know, they'll say all the right things, but in reality they got a hundred customers and they're trying to manage this thing in some way that scales and is centrally, uh, consistent. So their tolerance for exceptions is small.

Yeah. Yeah, that is an excellent point as well. All right.

Very true. Let's move On. Let's move on to this next topic, which is kind of related, but there's a post up there on the site and talking about automation and Kubernetes.

And if ever there was a need for automation Kubernetes, is it, there's more knobs and things de turn that can go wrong on Kubernetes and misconfigurations? And I think it's part of the problem is that, you know, it's the most powerful yet complex platform to come down the enterprise. IT pike in a long time.

So we need automation. We need to find some level of abstraction up here that allows us to manage this at scale. And I think, uh, part of the reason it's holding Kubernetes back somewhat is that there isn't enough automation framework in the IT environment in the first place.

So it's not clear to me, where's the, who's the chicken and who's the egg here? Is the automation the thing I need first before I get Kubernetes? Or if I bring Kubernetes in and figure out I need automation, either way, I gotta get there.

Yeah. And it, it seems like from my perspective, a lot of folks take, take the second route where they get Kubernetes into their environments and then go, oh my God, we gotta automate this somehow because this is way, way too much. Um, you know, and as the article talks about Kubernetes operators as a way within Kubernetes itself to do that, um, I don't know, not being a Kubernetes specialist myself, how effective that actually is, um, tends to be, Yeah, let's talk about operators and helm charts and all this other fun stuff that's out there.

So, and kind of helm charts and, and other tools to help provision the infrastructure in Kubernetes. And then we have operators for deploying the software on top of that platform. It's kind of a loose way of thinking about that.

The challenge is, uh, you know, so let's say I have six things running on Kubernetes. Well, that's six operators now. So, you know, that's, you know, too much of a good thing.

And if you get into some of these areas, some software, you know, open source, there's seven operators that exist that somebody built because they didn't like somebody else's operators. So now I got seven choices for that, and I gotta figure out which one to standardize on that. And hopefully sometimes the vendor or the community drives that conversation and sometimes not.

Um, I think that there's a, a big opportunity to create custom operators for organizations where, so I have a stack of software. I've got six things that I deploy, rather than having six operators, maybe I'll have my one operator that I created that will span all six elements of my stack. And I'll just provision that with a single operator.

If you look at some of the, uh, global system integrators, that's clearly what they're doing. And, you know, it's an, it is a good way to think about how to do something at scale. So, uh, don't be afraid to, you know, go in there and build your own operator.

'cause at least that one, you know, and you know, you won't be trying to figure out how to make operator A, B, C, and D actually maybe talk to each other someday. Yeah, indeed. And it seems there's also built in tools with a lot of the common CICD, uh, tools, as I use that word again, um, you know, Jenkins, GitLab, GitHub actions, all of those seem to have added ways for folks to, to include automation as they're trying to get these tools to work together.

So it seems like, you know, there's, there's lots of options out there to be able to do that. The other thing about automation is automation for who, so there's a world of difference between a DevOps team that has programming expertise and knows how to work with APIs and can, uh, do things that, you know, your average IT administrator cannot do. They are, um, not trained to program.

Remember having this conversation one fellow about all this stuff about how, uh, he may have to learn programming skills to, uh, continue in his line of work. And he looked at me and laughed. He said, brother, if I could program, I wouldn't be in my line of work.

Right? Yep. So, um, I think we do need to have more of these graphical type of automation tools that are made for mere mortals and the average IT administrator so they can manage Kubernetes clusters at scale.

And let's be honest, even the DevOps folks don't always want to write code to go do something if they can push a button. So, um, we need to find a way to strike a balance between, you know, the classic IT service management mentality and the DevOps mentality about what to manage when using code and what can just be done with a button. Yeah, good point.

Good point. Um, I want to move on to something that always confuses me a little bit, and, uh, I'm sure there are folks out there who are a lot smarter than I am, but, uh, we had an article this week talking about the maintainers of cross plane have added Python support to their control plane. Mm-Hmm.

And, uh, first can we get into what is a control plane? What does it do? And you know how this ties into our kind of management discussion, All right.

In the beginning of time. No, I'm just kidding. Uh, but, you know, for the most part, with DevOps, we rely heavily on APIs and scripts to automate various things.

A control plane essentially pushed that up a level of abstraction and, and really was driven by the cloud service providers. If you look at, um, how they manage their environments, they have a control plane through which they enable their teams to. And it's a mix of folks with different levels of expertise to manage things that higher levels of scale.

Cross plane is trying to take that notion and make it more applicable a outside of the cloud and for, you know, to apply it to whether it's the edge or local data centers, but also to have ultimately one control plane to rule them all. Because part of the problem you run into in this multi-cloud universe is that now, uh, you know, I got an AWS environment, I got a Google environment, and I got a Microsoft environment. Every time I add a new environment, I gotta add more people, right?

To go manage that. And that's where the total cost of it starts to increase. So a control point provides the mechanism in Crosspoint specifically for unifying the management of these hybrid cloud computing environments.

And beyond just having multiple clouds, right? And kind of, we throw around these terms all the time, right? Like somehow or other multi-cloud equals hybrid cloud.

Well, in my mind, multi-cloud is just a bunch of clouds and it's a mess. Hybrid cloud is, you know, I'm bringing some adult supervision to this thing and I'm unifying the management thereof, and I am, and I am reducing the total cost of it, which as far as I can tell in this current economic climate is an issue, Seems to be okay. Well, that, that helps.

That helps a lot. And, you know, going back to what we were talking about before, you don't, you don't necessarily wanna have six different control planes, right? Because if your, if your goal is to reduce the complexity by adding that level of abstraction or unifying something, then why would you need to do that six times?

I mean, the issue with cross plane though, it's like I have to first figure out that I need Kubernetes, and then I need to figure out how Kubernetes works, and then I've got this thing cross plane as an extension of the Kubernetes API. So there's a significant bar of skill to get to before I realize that there's this thing out there that can make my life a whole lot simpler. But, um, I think what will happen is as you start to see more Kubernetes clusters starting to show up in the enterprise, people will start saying, uh, well, how can we centralize the management of that?

And then they'll get to control planes, and then they'll be like, well, can we, I apply this to our legacy stuff? And people will go, yeah, and then we'll get to some rational behavior. Versus I think trying to, you know, take a legacy monitoring platform and trying to turn it into something that manages both, uh, monolithic apps and Kubernetes environments might be a bridge too far as they say.

Yeah. Um, so you had an interesting conversation too earlier this week that, uh, I think we wanna wrap up with. Yeah.

We were having a chat with, uh, Marcus Elli from, uh, red Hat about internal developer portals. And, you know, in the context of Red Hat, that's always a conversation about, um, using their OpenShift platform, which is a flavor of Kubernetes. You could argue it's a highly extended version of Kubernetes.

But, um, we were talking about the notion of internal developer portals, and there's a lot of interest in this idea as it applies to platform engineering, which is kind of a methodology for managing DevOps at scale. That's starting to catch on with folks. And a lot of the times it starts with, the first thing that these teams do is they go, well, let's build an IDP, which is hardly a new idea.

IDP has been around since time began, but it feels like we're trying to find some way to build these things. The uh, red Hat platform is based on the IDP that, uh, Spotify originally built, which is what a lot of people are doing using right Backstage, right? Yeah.

Truth of the matter is backstage is almost as a complicated as Kubernetes to deploy. So indeed, um, red Hat is basically saying, we will curate that process for you and streamline it, and, uh, it's part of the great subscription service that they provide. Um, some folks may look for something that's a little simpler, depends on, you know, what your, uh, favorite approach may be and how complicated your development efforts are.

But it seems to me at least that a lot of this platform engineering and IDP conversation is starting with Cloud Native because it's only then that I have enough moving parts and microservices and complexity that makes this a real issue That I am, I am seeing that too. And it, it definitely, that seems to be true to me as well. On the DevOps side, I would say it's, it's taking hold.

But in much, much larger organizations, which again speaks to, we have too many moving parts. Everybody's trying to use different tools and different things to reach the same goal. We need to standardize, we need to get everybody on the same page.

How do we do that? And seems to be the way, Well, here's the paradox, right? So we embrace DevOps to get out from underneath centralized it so that individual groups and departments can enjoy more flexibility and develop software faster.

Fast forward to today, and it's like platform engineering is back with a hard centralization flavor to it, and it kind of feels like sometimes we're talking about the revenge of it. Yep. The balance is how do you do that in a way that enables scale but is not so heavy handed?

And by that we mean it enables developers to kind bring in new tools when they feel like it, or, um, is flexible enough to enable different teams that wanna work it slightly different way to do that way versus, you know, saying thou sh all the time. And, you know, there's a big difference between, I guess, uh, guardrails and fences. And I think if you're on guardrails, you're okay.

And if you're building fences that force everybody down a path, I can almost guarantee that the rebellion is not far away. Indeed. And it will be fierce and swift.

There you go. Well, I think that's all we got for this week, right? I believe so folks, thank you so much for tuning in and listening to us chat.

If there's, uh, anything you want us to talk about, please feel free to reach out and let us know. Uh, if you are an IT cloud native professional who wants to come on and have this conversation with us, we would love to have you shoot us an email. We'll put our contact info in the show notes, we'll get you here on camera, we'll pepper you with questions.

And of course, if you happen to be going to CubeCon in Paris in March, by all means stop by by the booth. Indeed, indeed. And, uh, in the meantime, check out we've got some great content coming in from some of the folks who are also going to be at, uh, at coupon.

com. You can check it out there. All right folks, well thank you again.

We will talk to you next week. Next up is a, uh, session out of our predict, uh, uh, virtual event back in January 18th. And in this one, Ben debell, founder and CEO of Fortify Fortified, he explores the ongoing strategic shift towards cloud computing and addresses key factors that are gonna shape the future of cloud success.

Well, welcome. I'm gonna be talking about strategic cloud adoption and, uh, balancing innovation, legacy systems and the financial realities of technology organizations. First, a little bit about myself, um, been in the industry for, uh, last 30 years, and one of the great things I got to do over Covid was, uh, write a book around some of the things that I've seen in technology over the last 30 years.

Today we're gonna be talking about how and what some of that stuff I think is gonna be happening and influencing us for in 2024. But my book End of Abundance talks about some of these concepts that are gonna be talked about today, but there's a lot more out there as well. Um, here's how you can also reach out to me, um, if there is additional information that you would like, um, both from the podcast and the different articles that I'm writing out there.

One of the things that many of us have been doing over the last, realistically 10, 12 years, is moving to the cloud and leveraging different cloud resources in different ways. And I always like to understand, you know, sort of how did you get to the cloud? Um, many times.

I also think sometimes it's driven by, you know, I call a boardroom member driving down the highway, seeing that new technology and saying, Hey, I want to go there. Um, you know, that that definitely helps organizations get there, but was it for the right reasons? Um, when you think about your cloud choice, which cloud provider are you, uh, in?

Is that the best choice for the applications? How did you guys migrate up there? These were all the different things that sort of are impacting us today, um, both from a technology challenges perspective and a technology opportunities perspective.

So what I'm gonna be talking about today is many of the technology challenges that we have today, uh, um, and it's sort of coming to a point where we are having restricted and tighter budgets to support essentially 30 to 40 years of technology that we already have built. Same time as data is growing at 23% compounded annual growth rates. At the same time, the business is actually growing at increased paces as well.

And even if your top line of the business is not growing, it's use of technology is growing because businesses are realizing that technology and technology services are just as important in getting their job done as it is potentially inventing and creating that new next service that you guys offer out to the market with the business, bringing more applications online, leveraging technology more. The other byproduct is transactions. Our transactions and everything that we are doing and processing within technology is also increasing at the same time.

But is your budget growing at the same pace? Many of our budgets are now frozen. Prior to two years ago, many of us had these great technology budgets that we could spend, but as money has become expensive, as there has been some inflation pressures, et cetera, now we are having to deal with increased technology requests, still supporting all the leg legacy technology, but our budgets are frozen.

So how are we going to still innovate? Because many of us are talking about AI today and it's gonna create grant, great, great new opportunities, but how are we going to continue to invest in innovate without spending a huge amount of our budget? One of the, the other challenges that we have is, I started insurance about 30 years ago when I started in insurance 30 years ago.

There was large amounts of technology that already existed. Now think about 30 years later, that same insurance company, all the other different technology systems that they brought online. And by the way, some of those same systems that we, that I personally worked on are still there.

Those big mainframes, those big IMS systems, they're still there. But now one of the biggest challenges for many organizations is how do we continue to invest and innovate in the new technologies while supporting the legacy technologies? And things are not getting less complex.

They're even getting more complex. So where we used to have two tier three tier, now we have interior microservices. Data's everywhere.

You have a hundred different SaaS platforms where all your data is across all those different SaaS for, uh, platforms, potentially having to anchor the gate that back into a central location. These are all the different things that we have to think about as we are technologists or business individuals trying to understand how do we continue to leverage technology going forward? Businesses want more.

Um, one of the, the challenges that we've had in the past is early in the day, the business didn't understand what technology did. They thought we just maintained their email, their file systems. If something broke, my phone broke, my computer broke, I caught 'em.

But one of the great things that we wanted to happen, and it has happened, and it is happening, is the business understands the value of technology. But the challenge with that, and the byproduct of that is they're asking more of us. They want us to continue to build more applications for them quicker, faster.

They wanna be able to invest in the newest things that are coming around the, the, the corner. And those are creating unique pressures on the technology groups to be able to satisfy those needs. And this is some of the things that we need to change our mindset in sort of how we approach us both in a service model, technology services, but also what we leverage in both in cloud, the cloud services and the SaaS services.

But how do we balance all these different areas and aspects so that we can give the business and meet their demands and needs as well? The other challenge that we've had is things are changing. So prior to Amazon sort and Microsoft really gaining traction in the cloud, it's everybody had a data center or a colo where we would buy our rack of servers, we'd deploy applications, whether or not I ran them hot or hold meaning high utilization or whatever.

I was not charged realistically a different amount of money to be able to support those servers at one mi, one capital cost. My CFO loved that as a very predictable expense. But now we're changing into a usage based technology model.

So all this legacy technology that we're slowly migrating up to the cloud, it's the pricing of that is changing. Now we're going to a usage based. Think about those SA SaaS subscriptions.

How many of them have some usage components in there, whether it's consumption based, user based, server based, et cetera. So as we create more technology, one is the numbers of units that are gonna go up and that's gonna increase our cost of technology also. What about all that code that you wrote over the last 30 or 40 years, those processes, those systems you designed?

Were those designed for usage-based model? The majority of them were not. I do remember back when I started coding, we had very, uh, tight parameters on both the time we could run processes, the amount of resources we could use.

Um, you know, we had the three 80 sixes, four 80 sixes, the mainframe. We had to be very careful and co uh, cognizant around what we coded and what number of resources it took up. Today, everybody is coding and building processes on these eight VCP boxes with 16 gigs a m.

That's what we buy our, our team. But is that creating a great outcome to go into a model just like this? It's similar to me looking at maps, right?

So how do we understand the cost of our decision to take the scenic route or the direct route? Uh, you know, this is very similar to code. So if I take a scenic route to get to my data, to get to my answer, to process a request versus the direct route to get to my destination, in this scenario, I'm gonna use potentially a lot more gas, two hours or more time.

The same stuff is happening within technology as well. 'cause everything has a cost. And one of the things that we need to change as a organization, as an individual, as a team going forward, is the way we think we need to think about efficiency and change our mindset.

And there's a great quote by Wayne Dyer says, if you change the way you look at things, the things you look at change. And when we think about, we are changing many variables both in how we deliver services, where we processes, process our services and technology at the rates at which we're investing in technology. And unless we start to change, um, our mindset around how we build those fundamental systems, we will write big checks and we'll even impact the environment as well.

And those are the things that we need to start to think about when we look at our applications, at our technology, at our implementations of our business services. One of the areas I think that needs to change is our acceptance criteria. Whenever we build technology solutions, whether it's applications, uh, database schemas, um, technology services, we all accept, accept based upon the functionality of those systems.

So when you think about those deployment processes and making sure that that brand new feature that is being built in that sprint, what do we do at the very end? We check to make sure that it is functionally correct and then we promote it up. If we ever have issues within production within that system, what do we usually do?

Infrastructure usually adds more resources. Well, when I use to host that in the data center, adding more vvc, VCPUs or memory within VMware or virtualization, a virtualized environment didn't cost me any additional cost in a cloud environment. If I add and change the service size, the container size of that solution because I am having performance problems and I want to add more resources to power my way through that, guess what I just did?

I just increased the cost. But it all goes back down to why am I having issues? How much am I using?

And it goes back down to how did I design that process? How did I build that process? Meaning when I start to decode that process or design that data model, what are the data types I selected?

How am I storing that data? How am I accessing that data via the code? Is it procedural or set based?

Those design choices have financial impacts, resource impacts. One of the things that I see us needing to do as we move to this usage based model is start to change. How do we look at our application deployment, uh, life cycles and really step back and say, all these other variables have changed.

What else needs to change within my ecosystem? I think in the future that we need to start to look at the efficiency of code, not necessarily getting into the code parsing to determine whether or not it's efficient. Look at the runtime, the output.

Did this code run and return a certain amount of value or records per the resources? Ultimately, what's the cost of that code today? finops is a very large important aspect within environments.

How do we impact finops upstream? 'cause today, finops is focused on downstream. Once you've already built, designed, engineered, and deployed that feature, and you get that bill from Amazon, Google, Microsoft, that is after you've already realized that cost.

We need to go upstream to understand the cost of our design upstream, not after we deployed it, because it's a lot harder for us to fix it after we've already deployed and committed that to production. This is where we want to go migrate to, but it's gonna take a large amount of time hardly because we are not thinking about the cost of our design decisions. When you go and build that application today, usually you get a budget for that project team.

You get a budget for building that application. You go and design the application, people start coding, whether it's onshore, offshore, a hybrid. And then once you've built it, tested it, you feel great about that decision, you go and deploy that to production.

Then you ask your infrastructure team, well, what would be the best servers to deploy this to? Now think about this. This is without really understanding the volume metrics of that application, the usage me metrics, the data growth, the transactional growth metrics of that application.

I'm deploying it to production on servers that I'm gonna potentially guess what size on code that may be efficient, not efficient, a hybrid. And only then do I ever know the cost of supporting that app. And that is today.

And how often and how long do apps run within production? 10 years, 15 years, 20 years. We're working with an app that's been running 23 years.

Very large system. Do we think part of the the app could have been more efficient early on? Yes, but we never know the cost of that design until the end, which is one of the challenges.

And that's why we need to move upstream as well. Another area is data. So my passion is data.

Um, build a company around data. 20 years ago when I said, Hey, I'm focused on data, didn't have the same meaning as it does today. When I talk about data, we think data analytics, we think of value.

We think you know, a lot of storage. Usually people think storage. What's the byproduct that we all have?

You know, I love the HGTV show hoarders. I actually think most organizations, when we look at 'em and work with 'em, most of us are hoarding data. Why?

There's potential value in this data. I believe it, there's gold out there, but how much gold is in that data and which data actually is gold versus which one is just copper or which one is actually just byproduct? So the cost of my data is something that we're focused on because it's not just the cost of storage.

Every time you have data and access that, guess what? There's a memory cost, a compute cost. But this all goes back down to really having a solid enterprise data strategy.

As you're bringing all these new technologies online, iot, that generates huge amounts of volumes of data, you have all these SaaS applications, you're pulling all that back, all the key data from all the SaaS PLA platforms back into a larger data lake or data warehouse, whatever you wanna determine. And then you start to analyze that. But then you also have all your non-production environments that have, again, copies of the data potentially.

Then you have HA and dr, which have additional copies of the data. Then you have your backup strategy, which has additional copies of data, maybe back seven years. What about if you just added a dollar sign next to that and then told that story to the business and said, this data, do we need it?

It's costing us a hundred thousand dollars a year. So this is where we want to really also start to merge financials over technology as well. But at a greater level of detail.

I just talked about code, talk about data, talk about the design decisions, which it's interesting to think what happens when they start to tell a story via financials. And by the way, what language does the business speak? We all speak financials.

No matter who is on this presentation today, I could have one conversation around financials, we'll all be able to communicate. net, we all of a sudden we are in a subset of audience that we could speak to. It's the same thing within technology.

The biggest challenge is data and code. It doesn't just execute one time. Data doesn't just exist today.

Think about what I said at the very beginning. 23% compounded annual growth rates. I wish my bank account had that growth rate.

Um, it's almost like my insurance bill does have that growth rate, which I do not want. But this is what we have today. And if you start to look at your data footprint today, the cost of supporting all your apps today, then start to factor in growth and look at what is that three year cost?

What is that five year cost of your technology? Forecast it out. And then an interesting statistic that we have.

So we've been focused on identifying efficiency of code for a while and also the cost of code. And when we think about migrating to that usage based model and what big challenge it might have with that legacy apps, a lot of times we think we don't have time to rewrite my whole app, let's just do a lift and shift and then we're gonna fix it later on. That has that large cost impact.

But the one statistic I do wanna share with you, I do wanna share with you is this 1% of your workload usually equals 50% or so of the cost or resource footprint. Again, 1%. So if I'm migrating up, if I identify the top 1%, and a lot of times it's a lot less than that, those calls, those pieces of data, those transactions, if I optimize this, that very small subset, I could potential have 30 or 40% gains or cost reductions.

And that gives you back a large amount of capacity to be able to understand and process your, your uh, transactions going forward. One of the things that I think we need going forward is better financial transparency of technology. I have a ba a financial background and a technology background, and it's, it's amazing what clarity I have within accounting at any point in time within a business, the clarity I could have.

But once you jump over the technology, you start to look at what clarity do I have around the cost of technology? This server's running hot in this Amazon bill or this Azure bill. What can I do to reduce that cost?

By the way, you've already right sized it, it's already in the best server size. What other options do you have? Unless we start to have better financial transparency down the stack, the storage level, the code level, the process level, we are not able to solve the root cause of the problem and start to actually take out costs, gain margin back in the business and become more profitable.

Or another way to look at it is as that business is asking more of us to build more technology over time, how can we use this find out budget, even if it's frozen or only growing one to 5% year over year as far as the technology budget? How do we continue to support more technology and organic data and transactional growth in the same technology budget? We need to find those inefficiencies within our technology implementations today, and that's gonna give us that 30% pop that will enable us to continue to invest in innovation of technology to drive the business.

Here's my contact information that you have. Um, if you wanna reach out to me, feel free to sh shoot me an email as well as there's a lot of other, um, information out there around, uh, me talking to different thought leaders out there as well as, uh, sharing some of these other ideas in more depth. And I thank you for your time.

Discover the cutting edge insights of our new show, AI Times a series that explores the limitless potential of artificial intelligence sponsored by the AI Infrastructure Alliance. The AI Times is at the forefront of the AI revolution, tackling the crucial questions of how we can leverage AI for the betterment of humanity. Stay ahead of the curve as this show delves into all things surrounding ai, including trends, pressing concerns, and the positive impact AI is making around the globe AI times.

This is techron tv. Mike speaks with Mike Moper, who's a senior VP for product and pro product marketing at virtue or VER virtue. And they explain why a data-centric approach, a data-centric approach to cybersecurity has become an absolute necessity.

Uh, as cyber attacks continue to increase in sophistication, data is where it's at. Check it out. Hey guys, thanks for the throw.

We're here with Mike Moper, who's senior vice president for virtru, and they are a provider of a platform that specializes in data security. And we're gonna be talking about, well, why is data security suddenly all the rage? Hey Mike, welcome to the show.

Hey, I'm glad to be here. Thanks For so long. We invested heavily in firewalls and the perimeters and we had this whole castle and moat kind of mentality to security.

And suddenly we woke up one morning and we discovered that, um, the good guys were basically flying over the castle wall and stealing all our stuff. And it was like we had no roof. So why now are we shifting towards this data centric approach?

And does that mean we spent less on the perimeter and more on the data security? What's going on here and what's the right balance of things? Yeah, that's a, that's a great point.

I think, uh, there's a few things that are, is driving this change. Uh, it probably all started as more and more SaaS-based applications started to be the tools that organizations were using. Uh, shortly thereafter, we had that, that thing that, uh, we all lived through the pandemic where we had, uh, remote workforces.

When you reflect on those remote workforce, uh, applications that are up in a cloud, uh, not back in a a rack, you know, in the organization, in the building where you used to work, you realize now that there is a need to be able to, uh, protect this data wherever it exists because it is now no longer just on the bare metal that is sitting at the end of the hallway in each of these organizations. So as a result of this, uh, organizations started, um, evolving their, uh, their posture. We had gone from a perimeter centric, uh, uh, methodology.

And, and by the way, about 98% of cybersecurity's investment, according to Gartner, is still this perimeter centric, um, uh, motivation. But what we're now starting to see is, um, more and more collaboration is absolutely required with this data. So we like to think of this as, um, there's the data you store, but there's also that data that you need to share.

And there's really a distinction there. And I think that is where we start recognizing that there is a, a need to be able to have a comprehensive set of zero trust controls, not only to prevent data theft, but to also be able to promote the sharing of that data itself. So we think of this as, you know, playing both offense and defense.

So defense is really equated to that perimeter centric security that we're all familiar with the, the moats and the walls and probably pouring tar over the side of the, the, the wall itself. But playing offense is how do I encourage the sharing of this data and to be able to still ensure its governance? Uh, I want to be able to get it to you because our two organizations are trying to, uh, conduct business together.

Maybe there's merger and acquisition, or you're just trying to buy some software from us. So we wanna be able to encourage that offensive posture, uh, associated with, uh, data centric security. And it's the culmination of these things that we're absolutely seeing more and more interest around a data-centric security posture, uh, becoming a larger and larger share of wallet, uh, when one thinks of a comprehensive zero trust investment for their organization.

How do I know what data requires? What level of security and what levels of policies? Because not all data is created equal, but they all too often the IT and the security people have no idea.

It's just all data to them. So, um, how do I kind of go in and figure out what data represents my actual level of risk? Yeah, that's a great point.

Uh, we absolutely should not be depending upon, uh, the IT staff for figuring that out. It is the subject matter experts that really need to be responsible for that. In fact of the matter is, it's those data owners themselves that know more about that information than anybody else in that organization.

So a best practice is to start tagging or classifying this content. So, um, you know, from from hashtags on Twitter, that's probably the place that the vast majority of, of consumers or frankly the, the larger population of those that work in commercial organizations are familiar with this concept of, of tagging content. So you can find it.

Um, you're now starting to see these capabilities manifest, manifest themselves in the applications that we use today. And, and I'll give you a a great example. Um, Google Workspace now has a label capability that is, uh, pervasive across their applications, whether it's docs, whether it's slides, et cetera, by applying a label.

This is confidential. Uh, this is internal only. This can be shared with external parties.

Taking advantage of that attribute that simply describes the intention or the sensitivity of that information is a fantastic first Step. Can we do that given the volume of data that we're looking at? It seems like every time I turn around and somebody's reporting that the amount of data that they're trying to manage has exponentially increased yet again, and or we're just getting overwhelmed.

Yeah, that's a, that's a great point. Uh, here's how I like to think about this. Um, if I'm creating a new document, again, as that subject matter expert, uh, it should be my responsibility to my organization to go ahead and label that document.

You know, this is for internal audiences, external, et cetera. And that's pretty easy to do. Uh, in fact, even tools like, uh, Microsoft Office 365 can prompt for that.

You know, you can't save the document until you put a a label on it. Google's workspace does the, does the same thing pretty easy to do. However, to your point, there is that fire hose of content that's being produced every single day.

And it's not reasonable for us mere mortals to be able to keep up with that. That's where I do believe, uh, machine learning is going to play more and more of a vital role in the way we classify and label content. Um, the proliferation of LLMs is a very natural place for us to be able to accelerate that.

So while DLP does a great job today, uh, I do believe we're going to see a next generation of data-centric labeling that is going to take place by having, uh, an LLM that has been trained on your corpus, your information to not only go through your data at rest and give recommendation for labeling back to the subject matter experts anytime it's it's opened or attempting to be shared. Uh, but to be able to also further evaluate, uh, any inbound messages as well to potentially, uh, give recommendation to that, that control plane as well. Do we need to converge data management and data security management?

'cause it seems like, uh, many of the principles we're applying here are concepts that might have been first used in the space of data management. I mean, what's the relationship between these two motions? I, I do think we're going to see a logical convergence.

Again, if you think about a control plane from identities through, uh, the devices that individuals use, the networks themselves to the applications and to the data that control plane is going to be, um, collapsed and there's going to be, uh, uh, best of breed applications that are used for governance across that continuum. So I think it's very reasonable to expect to see that evolve. Absolutely.

In effect, are we not deputizing other arms of the enterprise team to help manage security because, well, we're shorthanded on the security side. So do we need more IT operations people and database people and developers to all pitch in here? That's a good question.

The way I like to think about this is, uh, this is a natural evolution of, uh, intellectual property and governance. And as a result of that, each of us, uh, whether you are a DBA, uh, whether you are in finance, each has an obligation to ensuring the integrity of our most precious asset. And that, and that's the data that our organization possess.

So, so, um, you can, you know, if we had this conversation 10 years ago, we would've not been talking about LLMs and how ML would be playing a role in our businesses. Look where we are today, uh, we are still going to absolutely need to have, um, CISOs that are, uh, making policy decisions across the integrity of this data. We're gonna still have SMEs that understand this data, um, most intimately.

But Eva, each of us played a critical role in ensuring that we can store this data safely, we can share this data safely, and that we can go ahead and accelerate the outcomes for our organizations by getting this data exchanged with whatever that other party is that's, um, needing to help be able to conduct that, that particular role or business. You mentioned LLMs. Um, can we use AI to save us from ourselves here and apply that to data security?

Um, like everything, um, AI is absolutely not a, uh, a crutch. It's just a tool and it is a tool that, um, much like, you know, maybe RegX, you know, what, 30, 40 years ago started to become some, uh, uh, uh, a, a tool in the, uh, toolbox. Uh, LLMs are gonna absolutely become another one of those tools in the toolbox.

What we absolutely expect to see very, very soon is organizations, um, developing their own, um, corpus of data and then training it against, uh, an LLM an open source cetera, but keeping that running only within their perimeter so that they have no leakage outside the perimeter itself. By building that model, training it on your own corpus, you can start to do some really, really powerful things. Uh, as I had mentioned previously, the idea that you could use it to intelligently start identifying content and giving recommendation to that SME, here's how this should be labeled.

So go ahead and proactively label it. Uh, we're gonna be seeing, uh, LLMs used for that purpose very, very soon. But again, like so many things, it is a tool, not a crutch, uh, crawl, walk, run and implementation.

Learn how your end users within your organization are taking advantage of it, and then find those next logical spots to be able to, um, address more productivity and efficiency gains that will be absolutely recognized, uh, by tools such as that. Alright, on the face of it, data security seems like, you know, intuitively obvious thing to do. So what's the issue that holds people up when making this transition?

Yeah, that's a great question. I, you know what, it's, uh, I think the transition is largely rooted in, um, making sure that you've got internal stakeholders that are convicted to moving this forward. Obviously, if you're in a regulat uh, a regulator regulated industry, uh, uh, whether it's, uh, CMMC or IAR or you know, HIPAA data that you're managing, uh, the, the stick that you get hit with, um, can really hurt.

So by ensuring that your policy folks, um, are constantly working with line of business and there is collaboration there, but most importantly you make it easy for the users, the moment there is a high degree of friction for those end users, that's when mistakes happen. Uh, we saw this back in the, you know, early ts with um, um, rogue IT where, uh, individuals started going out and, you know, getting licenses to SaaS applications that it knew nothing about. It's because they had friction in the process.

You wanna make sure that there is not friction in that process. You wanna make sure that data centric security is, uh, complementary to the existing business processes in the tools that your, uh, end users are using. Don't force them into another tool.

Uh, this should be as transparent as possible to them. Maybe a little popup to say, Hey, this is, you know, a confidential document and that's it. Let 'em get back to their day job.

Let 'em be able to hit send as quickly as possible. It's probably one of the most important things you can do. Well, you mentioned the word conviction.

So, um, um, I think if we have broken this up over the years, we always assume that highly regulated industries will have more, uh, robust security policies and tools like these to go enforce that. But it seems like lately, if I watch how regulations are evolving, especially say data privacy, isn't every organization kind of now in a highly regulated industry. I mean, won't this just become a pervasive requirement?

Data security is everyone's responsibility. Uh, even in our personal lives. Uh, I personally, uh, I am and I, I'm in this industry.

I am numb to the number of massive exploits we hear about day in and day out, whether it's in our own government or in the private sector itself. This is not going away. Um, things such as, um, um, two FA, uh, is not even enough anymore.

We need to be able to use other tools to, again, make it as easy as possible for PB people to be able to adopt and to be comfortable with being able to secure their own information. Um, passphrases, um, pass keys, et cetera, um, will continue to help advance this, but it is everyone's responsibility to make sure that that precious jewel, uh, the crown jewels that are inside that castle that are are being protected, um, are so, and um, and still yet at the same time, being able to ensure that that information can be shared with the right people at the right time, yet be able to pull that data back at any point in time as well. All right, folks.

You heard your data's the asset. So you start there from security and work your way out. 'cause I think historically we've been working from the outside in, in a way that maybe, uh, makes it too easy for the bad guys to do whatever they need to do whenever they wanna do it.

Hey Mike, thanks for being on the show. Appreciate it. Thanks a lot.

All right. And back to you guys in the studio In our second view with ard. Mike speaks to ASI lab, CEO Neil Sahota, and they dive into why cybersecurity is evolving into an AI arms race that requires eternal vigilance.

I think it's always been an arms race. Now it's just ai. Enjoy this interview with Mike.

This is Textron tv. Hey guys, thanks for the throw. We're here with Neil Sahota, who's CEO for ASCI Labs, and we're talking about the AI arms race as it applies to cybersecurity because, well, everybody seems to be delving in, but it's not quite clear who's ahead, who's behind, or for that matter if they're actually doing anything.

Neil, welcome to the show. Hey, thanks for having me on, Michael. Excited to be here.

So what exactly are the bad guys up to? Because on the one hand we hear about the potential to use AI to drive cybersecurity attacks in volume and increasing sophistication, and then the rest of us kind of sometimes look at that a little bit and we say, geez, you know, it's already so easy to launch these attacks. Why would they bother?

Because why do they, why do all the extra heavy lift? Well, it's either, uh, obviously they're looking to score a big heist or they're looking to inflict damage, or sometimes both. And bad actors, uh, unfortunately have gotten the jumpstart in this whole arms race on cybersecurity versus kind of cyber threats.

How do you know what they're doing? I mean, do you, have you seen any examples of them using AI and what does it look like? Yeah, it started with, you know, more traditional attacks, like denial of service and stuff.

But with ai, they could do it at a speed and volume that was just overwhelming for most systems. So no good guys. We, you know, started combating that with our own like, kind of AI cyber warriors and started using AI to figure out other types of attacks and bad actors got more creative.

And so, you know, they're using AI to figure out new types attacks, which is not just cyber. They're actually using AI to probe like physical weakness. And even, um, perhaps the linchpin, the whole model is people weakness.

'cause it's a lot easier to hack a person, like as an individual than it is to hack a system. So does that mean they're kinda using some form of AI to monitor people's behaviors and figure out who's maybe most likely to click on a, on, on a malicious link or something? I mean, how sophisticated does that get?

Yeah, that, that's actually one thing they're looking at. They, they're AI systems that have learned, like psychology and neurolinguistics. So the AI can really get to know a person just like a best friend does.

So they, they understand kind of your, your language, the way you speak, interact. They understand the best channels to, to hit you at. They know kind of the right triggers to get you to take action.

And, you know, we're seeing more and more of this getting prevalent, unfortunately, with the rise of deep fakes. You know, there was a financial secu, uh, services company recently that was just hit. They were literally on a Zoom meeting.

They thought it was a CFO and the CFOs, I think core team seemed, acted just like the CFO said, we, you know, we have an emergency situation, we're gonna wire this money to, you know, cover, you know, whatever cogs cost sold were or something like that. And I think they wired something like $12 million right away, not realizing they were talking to a dfa. As we go along, it seems like, are they inserting themselves into our workflows to monitor that behavior and collect our processes and figure out can they do this from afar?

I mean, you hear the phrase living off the land all the time, but how much access do they need for how long before they can start using AI to kind of create that deepfake that sits in the middle of a workflow? They not, not, they don't need much data at all. I mean, there are tools out there that you, you pull some, you know, video or audio or even pictures off the internet, and that's all you really need to take.

I mean, last year there was a crime ring that, you know, would call parents and tell 'em they had kidnap their child and they called when the child was in school, knowing that most schools don't allow them to have their phones on at the time. And you know, the parent would be like, oh, we'll prove it. I wanna talk to my child.

And they would quote unquote, put the child on. It was really an AI deep fake audio made from their social media. And it sounded like they did talk like they did.

You know, parents are freaking out. You can't confirm the kid's phone, cell phone is off. And I think they, they, they did it, I think it was almost a dozen times, and they were getting paid like 50, 60 grand a ransom before I think, uh, the FBI Interpol really started trying to track them down.

But that's the level it takes. You, you, you really like two minutes of data now, especially audio video to create deep fake. Yikes.

What can the good guys do with AI to help thwart these attacks? 'cause it, uh, hopefully it is an arms race and there is things that, you know, the good guys are doing. We're trying our best one.

One thing that we are doing right now is what we've learned that, you know, DeepFakes, like a lot of things have almost like a unique pattern or fingerprint to them, but the way that that AI is trained, there are some things that kinda reveal themselves as much. Like, you know, how, how do people know if you wrote something or chat, GPT wrote it. It's the same thing we could try and look for in deep fakes, whether their videos, audios, images are a little bit tougher.

Listen, our area, we're trying to also figure out, but, uh, we know that if we don't provide this level of protection, it's, it's one thing like when it happens to a famous person like Taylor Swift or President Biden, but for the average person like those parents that, that their kids were kidnapped, they don't have a whole lot of recourse. So we're trying to build those counter tools right now to give people that, that protection and that that option of verification. Do you think, um, we're gonna have to wait for some massive reach for everybody to kind wake up to this whole thing?

And I'm asking the question. 'cause historically we've always chased after emerging technologies after the fact. And of course, you know, we're told all about it for months and months and months and, but it seems like it's not until there's something catastrophic that everybody goes, all right, we gotta get serious.

Michael, unfortunately, that that's the, the attitude that, you know, we've always been like a reactive society or, you know, something bad happens, but we're at a point where AI can do things with such, do things with such volume, such speed, such large impact that we're not proactively thinking about it and trying to, you know, protect against some of these threats we're it's gonna be too late. That's the honest truth. Primary activism is gonna be too late.

I I seem to be using this quote a lot from Plato. I I do like it, but we learn from pain. We have to break that kinda mold because we can't wait for like, oh, well 50 million people just got impacted.

There's real no way to recover for those people. They still are suffering and feeling real pain. Don't jump ahead of these things.

What are we gonna do? And, and, and my work with the United Nations, that's one of the things we're actually trying to do with the global regulators. It's kinda shift that mindset away from reaction to being proactive, which means we have to get good at scenario planning.

We have to get good at thinking about, you know, these are just tools. How would people use and misuse them? And that's just something we, a skillset set.

We, we are just pulling the beginning of trying to develop, Are we suffering from cybersecurity fatigue? And I asked the question because a lot of the boards are asking questions now, like, well, we invested all this money and are we any more or less secure than we were before? And I might argue that that might be the wrong question to ask in the first place just because, well, it's not like the bad guys don't change their tactics and techniques.

So is this just a continuing, evolving gamer? I dunno if I'd call it a game, Michael, but it's a, it's a nonstop race, that's for sure. There's, there's no finish line.

We know that bad actors figure something out. We find countermeasures, but protections they find either a different path or different way, you know, d better tools to, to break what we've done and we then elevate our game. They elevate their game.

It's, it's nonstop. And I get where the boards are coming from. Infrastructure projects are, are the hardest things to rationalize.

There's really no ROI either you kind of do it or, you know, what's the cost of not doing business. But the truth is, is look, there's not that many bad actors out there as a percentage of the population, but especially with emerging technology like AI, that can cause a horrific amount of damage. That's the reason we make the investment.

So I wish I had better news for everybody, but it's, it's one of those things that it's just never gonna be ending. It's, you know, what's, what's the old cliche, and sorry to be using the cliche here is the price of freedom is, uh, ever constant vigilance. And that's very true when it comes to cyber.

Well, speaking of that vigilance, do you think AI will make it easier for, uh, nation states and companies in general to collaborate with you with each other to th these threats? 'cause I think one of the issues we've had so far is everybody kind of functions in isolation and, um, the bad guys are just going to town because we don't communicate with each other. Yeah, that's unfortunately true.

And AI has been a boost in sharing some information and different types of attacks. I know that Interpol, my work with them has been a lead on that. There's still a hesitancy to, to share some of these things.

We, we know that, you know, some of these big institutions, whether their companies or universities for example, they get bombarded every day by attacks and they don't want to quite reveal that or what kind of attacks are happening. 'cause one, they don't want, you know, their employees, customers, students, faculty to freak out. But two, they don't wanna know just how much at risk they are make themselves a bigger target.

So it's, it's kinda unfortunately a, a weird balance trying to figure out here is how much to share without trying to increase your risk factor. Are the folks at Interpol and other law enforcement agencies getting more proactive? And, um, I asked the question because the honest truth of the matter is cybersecurity always felt like, well, we know there are bad guys out there, but until they rob the bank, we can't do anything about it.

So then we go chase after them. But we knew we could see them walking down the street and they were about to rob the bank, but we had 'em wait for them to actually rob the bank before we could do something about it. Can we change that?

We, we could, right? You just, we just need 194 member nations to agree to it. Michael.

It's one, that's one of the big challenges that, that's why everyone talks about building a better fence, so to speak, better safeguards, because it's, it's almost like the whole minority report movie, right? Is it really a crime of someone thinks about it but hasn't done it yet? That's that think a challenge for the legal system.

Mm-Hmm. So, you know, is it enough to say that someone's trying to probe the defenses or trying to do something? I mean, that's gonna be a debate for the legislatures.

I, I fear. But that's why the focus for a lot of the cybersecurity organizations and law enforcement has just been around trying to create safeguards and protectors. Can we get better offensive capabilities?

I know there are diplomatic niceties involved when we kind of hack into servers that exist in other countries, but it seems like people are starting to say, Hey, we're not gonna take it anymore. So are we gonna get a little more aggressive? I, I think some of that is happening, whether it's sanctioned or unsanctioned.

I, I really couldn't tell you how much of which of each it is, but you know, you probably heard it more about Michael, the black hat versus the white hat type of hacking. You know, I, I think again, that there's no way to effectively regulate that at the moment. And, you know, I'm sure a lot of people saying like, well, why would you wanna stop white hackers?

It's, it's not necessarily stopping them, but it's, I think, I think the real or underlying threat here is that, you know, everyone talks about the next war is gonna be in cyberspace, and we're building a lot of tools that we're reaching a point where, you know, even some of the developers don't fully understand how they work. We could leach something that's very cataclysmic. Think that's the biggest concern when it comes to white hats, black hats.

Well, to that point, you know, if I went back in time, uh, there were bank robbers holding up stage coaches and, uh, railroads and those guys got together and put out little bounties for capturing these people. And it was, um, you know, the niceties of the court thing were kind of, you know, if they were captured great, they would go on trial, but sometimes it never quite got that far. Um, our company's gonna get more aggressive about this because they have so much at risk and, um, they can't wait for the government to actually respond after there's been an incident.

It's a, it's an interesting question, Michael, 'cause there's a debate about that. And the debate is, should they have like their own kind of counter team? And I know that they are using AI for scenario planning predictions to say, you know, probing for their own weaknesses, trying to figure out, you know, new, new types of attacks and they can then create safeguards against.

But there's a growing consensus that the biggest challenge to solve is the people, right? At the end of the day, packers know it's a lot easier to get the information you need through a person clicking on a phishing link or something else, then trying to really break down encryption or cybersecurity systems. The question really becomes is how do we do that?

We, we would, you know, try an education, try some of these other things. You know, there's talk about now could we put people into like a metaverse simulation run by an AI where they actually, they do one of these things, they actually see what the overall impact is, would that make them think twice? So I think right now still a lot of the root solution is can we better educate people?

Because that's really the first line of attack for a lot of hackers. Hmm. But bad guys only need to be right once, so even the smartest person gets tired, they will accidentally click on something and, um, it's just kind of the nature of the human condition.

And frankly, you know, 20% of the population probably isn't that smart to begin with. So, um, I don't know, people is, you know, a good place to start, but I gotta feel like there's gotta be some other ways to augment this because, well, those people are humans. It's very true.

And there's, there's talk of leveraging what we call hybrid intelligence that, you know, people are good at things like, you know, first of a kind creativity, something that requires a lot of like, you know, instinctual type of thinking. Machines are really good at processing lots of data and so forth. And so it's the meld between the two that augmenting our human capabilities with machine capabilities is hybrid intelligence.

And can we exploit that in terms of separate protection? Could it not just be educating the person, but could we have like a little ai you know, security guard as you're security guard, as your, your buddy's helping to review your emails and some of these other things and say, hey, whoa, whoa, before you click that link, let's just double check that, you know, and you know, there, there's some merit to the idea. The challenge is, is twofold in trying to do it.

One that the more variability in the system, the more data AI needs to be trained properly and thinking about how much variability there is in a cyber attack. And two, are you training one weakness for another and that, well if, if great they have the buddy system, but if I could figure out how to hack the AI security buddy, does that solve my problem? Right?

Can I then just incentivize the security buddy to have the person do wrong things? Uh, maybe right. We, we could debate this till we're blue in the face because there's never gonna be a perfect solution.

And I, and I think that's what we unfortunately have to accept. That's why it's a never ending race. Right.

Given the imperfect nature of cybersecurity, then what's your best advice to folks about how to get to where they need to be versus where they are today? 'cause I think a lot of folks are like, they understand that AI exists, but I think they're a little overwhelmed. Yeah, yeah.

Again, it it's the, you see old adage though, trust but verify, right? They're one, one thing we've noticed is that, uh, you know, AI tends to be too perfect, like with deep fakes or, you know, some of these things that either they try and create very obvious flaws that seem weird to us, or we don't see the flaws at all. So subconsciously it feels weird to us.

So if you're feeling weird about something or you gain something that is, it's a lot of money, or there's a link here or something that seems sort of right, still just check it out, right? Do, do the virus scan, hover over the link, all those things we're, we're taught to do. And you know, if you're worried about being deepfake, you gotta, you gotta confirm somehow there, there's really nothing that urgent that can't wait for, you know, an extra few minutes for that kind of verification.

So just trust but verify, be a little guarded. All right folks, you heard it here. I'm not so sure about the trust part, but the verify, absolutely.

I would more maybe argue don't trust anybody and think twice about it and go from there, from there. Hey Neil, thanks for being on the show. Yeah, my pleasure, Michael.

Thanks for having me. All right. And back to you guys in the studio.

Cloud native now is the web's leading resource for the growing cloud native ecosystem. com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more. Stay on the cutting edge of modern application development at Cloud Native.

Now, Well that's gonna wrap up another great action packed fun-filled, uh, text drug TV day. We hope you enjoyed everything. We'll be back, uh, on Monday with another Fresh Tech strong TV show.

Until then, this is Alan Shimel. Be safe. Be well.

Be strong tech, strong. We're out.