Techstrong Gang – January 20, 2025

Hey everybody. I'm Mike Ard. We've got a DevSecOps Paradox, some patch management progress, and maybe at the conversation about cloud computing alternatives, whether they're gaining traction or not.

You're watching Textron Gang. We'll be back in the middle. All right, and everybody, welcome back.

Let me introduce today's guest. We have, of course, Mitch Ashley joins us once again from high up in the Rocky Mountains of Colorado. Mitch, good to see you.

All right. In a slightly lower climate, maybe, or, you know, cold, but desert climate, I'm not entirely sure, but Recy Reagan, welcome back. Oh, thank you.

And we're actually at a higher level than, than Mitch. I know. Not everybody knows that New Mexico's at a higher level than Colorado, but some parts are, and we are All right.

Not that it's a contest, but there you go. All right. And then Guy Courier, I assume you're in Texas today still.

Yep, yep. Uh, I got to spend all last week back home in Austin. Um, may have to jet off to California this week, but so far looking good for staying in Austin.

All we cold, Austin, I don't know if you know, we've got this big freeze coming with snow and everything coming through just today. Yikes. Well, I'm in New York and they're actually saying we might get some snow this weekend.

So I'm like looking around in the garage going, do we have a shovel? And how much ice do I have? You know, but all those things that you guys probably have already dealt with.

Anyway, let's jump into this first topic. 'cause there's been a, a post this week, I guess, a report from Black Duck talking about the progress that's being made in DevSecOps. And on the upside it says, well, there's more usage of software composition analysis tools, and we're actually seeing people act, generate some of these SBOs that we've been talking about, otherwise known as software bill of materials.

But at the same time, training of folks on cybersecurity, especially developers, is now at an all time low than they've been tracking this thing for 15 years now. So, Mitch, there's a bit of a paradox in all of this. Is this mean ship left is dying?

Or what's going on here? Well, it's, it's kind of two parts of a general topic of software security, but they aren't the same thing. I think the rise on, uh, software composition analysis, SBOs is driven by a lot of things.

One of them is regulatory front, especially in Europe, because there's some in effect actions and more things coming that require SBOs, uh, and also software decom. I call it decomposition now. 'cause that's kinda what it is to me.

Like decompose this, right? Um, so you know, those tools are on the rise and those are looking at all the software that we're building, right? Not just what one developer or each individual, the individual developer contributes.

So that's actually a really good thing. Why is training going down, uh, for individual developers? I'm not sure why.

You know, I'm kind of, I've always been I'm and minus on training because it's a good thing to do. But if you just do it once a year and it kind of becomes this rote thing, then everybody sort of blows it off and forgets everything after a week anyway, sorry. Nothing gets developers, but I think most people do that when it becomes, you know, we've gotta do our whatever certification training each year.

So, you know, so much of the world that the developer lives in is in their IDE and increasingly in co-pilots, uh, that are part of that environment. That's where the real security happens in terms of what developers are doing on a day-to-day basis. So there're kind of two parts of a bigger, bigger picture.

Tracy, what's your take on this? The developers just don't want no stinking training. 'cause they're basically in the hands on the code.

And if something comes up, they want the IDE to tell 'em about it while it's relevant to 'em. Oh, I think that there's, uh, there, there's that, there's always the cultural stuff. If you could hand it to me, please just hand it to me and don't make, make me work.

But the other thing to remember is that, uh, there is a limited amount of money spent on training Limited, uh, most, uh, I think most budgets maybe give each developer, you know, one class a year, something of that sort, which they get to choose. Now, if I'm, if I'm in that boat, I'm not gonna choose cybersecurity as my thing to learn. I'm gonna be doing something around AI because that's where I'm gonna get paid more, right?

So there's there, there's problems in, in training being the one road to safety, because not every developer's going to sign up for those, uh, cybersecurity classes, unless, of course, for some reason it's forced and it comes from the top and the entire organization has a, um, has a goal to be completely trained. So there's that. But on the other side, I just have to point this out.

Vulnerabilities are dynamic. They happen all the time. SBOs and static.

Um, composition analysis is exactly that. You can do a really great job of finding, um, vulnerabilities when, when you go to create your container and clean it all up, you get the deployment done and freaking tomorrow there's a vulnerability. So we have to stop thinking in a, in a way of, in, in a static kind of world that just doesn't work anymore.

And SBOs are fabulous. But as a, a, a blog I wrote about two years ago with Vincent Danon from Red Hat, we titled it SBOs. So far so good.

So what, you know, because it just becomes a text file that's checked into get, and we're not not using it. So we have a long road to go. We really do.

And I believe it's squarely in the, in the hands of the DevOps engineers and trying to train developers in cybersecurity. May is a good idea. I'm not saying it's not.

Linux Foundation has a free course if you were to take it, but it's not the, it's not the sole road or it's, it's, I don't even think it's a 20%, uh, a student solving the problem. And we're gonna get tooling. That's better that we don't have to have developers.

We're gonna squiggly line problems all the, you know, when, when we, when we start coding them. So, you know, this is gonna get solved in a different way from the developer side. We have to think, we've software security as a continuing, right, continuous process.

It's like continuous integration. Continuous deployment. It's gotta be continuous software composition now is continuous.

Um, We call it continuous vulnerability management. Exactly. That's, that's gotta continually Be all right.

Yeah. Otherwise we're making the same kind of way. We used to do security and networks of the, oh, I got my, got my firewall, I got my gateway, I got, et cetera.

It's not a point in time thing guy. I stepped on you. Uh, apologize.

Well, I've just been wondering, particularly lately, and this is bringing it to a point, um, ha has DevOps sort of as a culture or an industry, um, or even developers ever been punished for going too fast? Because I feel like a lot of the ship left or, or code analysis, um, or, you know, other forms of, uh, uh, uh, prevention or, or remediation of these things, a big, uh, uh, a big reason that they are not adopted and used and training as well, is it slows things down. And I, I've seen research to support this sort of thing that it's a big issue.

The DevOps pipeline slows things down. There's a lot of things that slow things down, but the sort of thing like a security or vulnerability or whatever, that has never hit you and your team particularly, and that you don't know when it will hit. That's that amorphous thing that you want to try to, right.

Um, at least be able to. I mean, Tracy, I think one of your big points, um, lately has been, and I think you just made it embrace the fact that this is going to happen. Um, build processes and systems around it and culture in order to address it.

Right? Um, I think that, and we had a discussion about this at the predictive event, uh, uh, last week, um, where there's, there's, that's the, you know, embrace it side of things, be prepared for it, continue to be able to release and drive value and all of that sort of thing at speed. But the other one is remediation, which Mike, I mean, I, I feel like that is how you framed up a whole question.

What, you know, how do we make sure that this happens less often with training, with tools and that sort of thing. I just feel like all the incentives are more on the just keep barreling forward side and deal with it when it happens. I say, where's, sorry?

I say, uh, where's Ralph Nader when you need him? Right? We need the republished unsafe at any speed, but instead about cars.

Maybe it's about software development, I don't know. But, um, you're The remediation camp. I'm unclear about this.

I think you can go fast, but you have to be smart. And if you using smaller pieces of code that you're working with, you should be able to make that more secure and higher quality as you go along without compromising speed. I think we just don't necessarily do things as smart as we should.

But Tracy, what's your thought? Well, we have a lot of SBOs, right? If we're in a decoupled environment, every time we create a container, we have a new sbo and there's different kinds of SBOs, right?

There's code level SBOs, and there's the ca container SBO itself. And then we have, you know, literally with APIs and microservices, we have hundreds of them that make up an application. So, and you could have a vulnerability with a, a vulnerability version of a, a, a package in a container or in multiple containers.

And different containers have different versions of that particular package. So we have this dependency, this giant, I like to call it a death star 'cause that's what it reminds me of, this giant death star of dependencies and the lines that are drawn between them make it really, really difficult to manage this stuff. And we're, when we create SWAs, which I am totally for, you have to have a desk problem.

I'm just saying that. But we have to consume the data. We have to consume and use the data in order to make it continuous.

It's the only way to move forward. And I think that DevOps, we've got a lot of work yet to do in the DevOps area and to touch a workflow is the last thing that, uh, that teams wanna do. They don't wanna add a lot of tooling.

They don't wanna go and, and muck around with those, those workflows because they're complicated themselves. So we have a problem, we have statically coded workflows, we have static code analysis and static SBOs, and we feel good about generating them. We check market and three days later we have a severe, uh, or a high risk vulnerability we have to address.

Yeah, they're already outta date is your point. So, Yeah. So if the S bomb is outta date, by the time it's generated, I don't know, Mitch, is this thing, you know, kind of the software development of a binky pacifier that I'm just giving people to suck on, but it doesn't really mean anything.

It, it can be a feel good moment, right? Oh, we did an sbo, now what do you do with it? To, to Tracy's point as well, I, I haven't given this talk in a while, but I used to give talk about software and software security are not a solid, they're fluids.

They're constantly changing. I mean, it is actively being worked on all the time. Even you think it's the, the weekend and it's midnight on Saturday, or 1:00 AM somebody's probably in there dinking around and trying something 'cause they were up playing around.

Or maybe, you know, maybe you're working around the, the sun or there's a new software package that gets updated that's gonna go into the next build. It, it is a continuous flow of change. And so doing software composition analysis, doing an SBO m those are good, but they're point in time.

They have to, they have to be a continuous process. Now, when you ship the FBO with, with the code, probably when it goes into production, it goes to a customer. Uh, you, you, you wanna be able to, to know what, what was built in the, uh, in the software build that goes into a test environment or into, into production.

But I think that's the way we've gotta think about it. And to your point, Tracy, static workflows, and I totally agree, people have, it's the fear of death to go in and change a, uh, a, uh, workflow in A-C-I-C-D pipeline. 'cause it, you easily break things.

Or if there's something broken and trying to fix it, you know, it takes pretty, pretty smart DevOps engineer to do that. So we can't have such brittle workflows, such brittle pipelines. They have to be able to be able to change, um, on a continual basis.

Not every second. But it can't be something we don't touch. 'cause we're afraid we're gonna break it.

So we just saw that the door regulations from the EU went into effects. Uh, Tracy, do you think that we're gonna see a lot of people adding SBOs and SCA tools, but to what end exactly. Just to check a box?

I don't know. I think that those become guidelines. Uh, and unless they're being asked for, for very specific reporting, um, it's gonna be hard to enforce that.

Uh, I, it, I think that teams should be thinking in this, in this way with, you know, adding SBOs for example. But, um, you know, it's like my example, I always use, I live on a dirt road and it's got a sign that says 20 miles an hour. But who's enforcing that?

I drive 40. I don't get tickets from my neighbor. Maybe, I don't know.

He'll have to, you know, put up some tickets. Would I respond? No.

So, you know, the accountability isn't there yet. And in these modern architectures with so many SBOs, which SBO are we talking about? Can you most, most teams can't generate an application level sbo.

They're gonna hand off 25 or 200 SBOs. And a lot of the information's redundant and it's ugly and gory. Those, those SBOs are really gory.

They're just a, a spew of text information. So yeah, we'll, maybe they'll generate them. But to what end, what's the point?

And you know, that's, you know, I love talking about this 'cause I've thought about it for quite some time. And at Deploy Hub we're trying to solve some of these issues. Uh, but are we gonna see a huge rise in SBO M generation?

That'll be, see, we'll see, right? I think some people will include it. But to what end, I think we will.

And some places it's called out. Um, not necessarily in Dora. Dora has kind of, by the way, Dora only applies to financial institutions, credit institutions, things like that.

So it isn't universally applicable, but there's a cybersecurity act, um, in the eu. There's also a NIST to NIS too, not nist. Um, so there are a number of kind of regulat regulations that either have or are impending in effect, uh, impacts of now doing what, what they described there is, is like US law, right?

Here's the law, but now you gotta interpret, well, what does that mean? How do you and put it into effect? And then how do you enforce it?

So there's a lot to be left to, to figure it out on this. But it is becoming a requirement and becoming at least I think, close to a boardroom room conversation of what are we gonna do to comply with this? 'cause some of the fines are really, I mean, they're extremely, uh, extremely high.

Especially if you look at the software liability changes in Europe where it's a percentage of your revenue. It, it's, it could be substantial. Now, you know where people are gonna get fined for that and how much litigation is there gonna be, et cetera, et cetera.

But nobody wants to be the, uh, the, the poster child for the first company to go through that. And you're not, I wanna say, so These regulations like Dora, um, are, it seemed to be an attempt to force the remediation side of things. Force.

It's like taking away the punch bowl type stuff, right? Uh, make sure that you are, uh, being a little bit more cautious and understanding and, and, and forcing you into changing a workflow and or shifting after what have you. But, uh, I think that, um, there's a real point to be made around understanding that none of this, however compliant you are, is really gonna prevent everything.

Um, even recognizing the static nature of, of the s bomber or, or any other documentation, um, and trying to fix it. Nothing gets fully fixed. It just doesn't, Right?

Tracy? And I think that the, the, I think door metrics are a bit long in the tooth too. They were built around monolithic, uh, and legacy, uh, code development.

All right? So, and the way we build code now is very different. It really is.

So, Tracy, if we have a lot of ugly SBO m data, is this not an opportunity to build an AI agent that's gonna like, sort all this stuff for us? And maybe that's how we get to continuous, Oh, Orillia already did it. So if this is something you really are interested in, the Arterius projects incubating at the Linux Foundation, we consume the, the, you know, the, the, the SBO M and then we aggregate it up to the application level.

So you can actually generate an application level, sbo m and then we constantly, uh, uh, uh, scan OSV dev with the SBO M data that we normalize, by the way, because you don't want so much data, um, to show on a regular basis the, the vulnerabilities that are hitting the system long after the deployment's done. And we're not sticking agents. 'cause he, everybody knows, I don't like agents out in production environments to open up your container and scan it at that point.

'cause that's just over, that's just over-engineered. The DevOps pipeline has all the answers. We are generating all the information we need, including where packages running in a particular container in a particular environment.

We're just not consuming that data. We just leave it out fragmented with lots of logs. We maybe check it into Git, but it's not useful there.

So I say, Hey, if you guys wanna solve this problem, ortus, do io come and join the open source project and help us finish it. Definitely. TIUs is a great, great open source option.

There's commercial tools available. You know, folks like Sonotype do do some things in this area. There.

We're talking about kind of a later part of the process in the, in the workflow, in the pipeline. There's also a great companies, you know, folks like Chain Guard and Cloud Smith who are helping you groom and contain what, what goes into your pipeline. So you're having less problems with maybe you filter out the vulnerabilities that might be the present there, uh, and being, you know, cautious about how you select, uh, software that's part of your builds, et cetera.

So it it's a holistic solution and yes, we've gotta have much better ways, you know, management systems for SBOs part of the solution, but we've gotta fix it coming in or else those SBOs get really even worse. Well, folks, it sounds like we have the tools. We just may, may not have the will to kind of put them in place just yet, but we're getting there and I feel like there's some progress being made, but we'll see what the year brings.

We're gonna move on to our next topic. We'll be back in a minute. Modernize your business to fuel innovation and elevate customer experiences with the builder community.

Hub AWS and its partner network. Provide essential tools for transforming applications and infrastructure to fully leverage the cloud. Discover free trials, in-depth demos and essential resources to empower DevOps engineers and developers to deliver value faster and more reliably.

Visit the builder community hub to learn more. Hey folks, we're backing, we're gonna have a little chat that's related to the first chat. We're gonna talk about patch management in the sense of, there's a new report out from at apba, and there you are talking about how, well, it still takes more than a week or so to apply a patch, but that could be progress in some regards.

And one of the things that they were noting is that IT teams just the average IT service management team is automating a lot of this process and doing it on their own. They're not standing around waiting for someone to tell 'em it's okay to patch that thing because, well, it turns out that the cybersecurity threat is often more expensive than actually taking down the application if something goes wrong. Tracy, I know you've been following this space, but are, are we evolving our thinking about patch management here?

I am so glad that people are starting to talk about the, the, the issues around patching vulnerabilities. Now, I, people get confused. You when you're talking about a remediation, I means, okay, we found a, we found a, a vulnerability.

It's a severe zero day vulnerability. The open source, uh, team gets the fix out. Okay, great.

You know, again, SBOs, so far so good. So what we have a remediation. Now what we have to do is be able to get that deployed and it means that you have to have a clear, very clear understanding of where that vulnerability is running in your, your environment, which, which container.

And not just, it's not just the vulnera, it's not just the package, it's the package version. And so what we see are teams going, okay, if we don't know who's using what, we need to redeploy a, you know, 50% of our, our, our code to fix this. It's a, it's a shotgun approach.

Again, we have to have the, we have to have the insights. We have to have the SBO m we have to have the packages, and we have to start mapping those packages to where they're deployed in order to make the patching as efficient as possible. Um, at one point, I think Jfr said that it takes about 227 days to resolve the single vulnerability across the, the, the globe, right?

So you get a zero day vulnerability and it's gonna take about a year before it all goes away. We were on a webinar with, uh, the SONOTYPE folks, and they said there are still people downloading the vulnerable version of Log four J because it's in a, it's in a script someplace. And they don't, they don't recog they don't know it.

So much of what we're struggling with, in particular in patch management is the lack of, of a, a full view, a comprehensive sweeping view of where packages are running in the, in our, all of our environments, not just production. And once we have that, the DevOps pipeline should be able to push that, those fixes out far more efficiently than we're doing it today. But as I explained in the last block, we have the data, we don't do anything with it.

So I've, you know, this has been a complaint for, for me for a long time. You know, we talk about ai, we talk about applying DevOps, uh, AI to DevOps, but you gotta have the data. And most of the data that we have is fragmented and checked into static log files in Git.

And we have to get it out. We have to pull that information to a central, a central evidence store in order to start being smart and applying any kind of AI to it, or just be able to, to do our pra our, our standard DevOps practice to get something out. But we have to know where to put it.

And the knowing where to put it is the biggest challenge that companies have. So I think this, that, that article was spot on, and I'm not surprised at all. I, I do wanna, um, uh, say one thing about, uh, that study and article, um, which also we discussed actually last week to predict, um, which is, uh, the majority of organizations are doing are automating patch management for at least one application.

Or they, that that's the thing that it's, it's worth remembering that they're, that they have automation and that's a good step forward. But it doesn't mean that more than one application is being, or environment is being automated in that way. So I would say that if we had that data, which the survey did not test for, we might find less than 10%, maybe less than 5% of applications are actually, uh, being automated in this way.

And we also don't know the degree of automation that we're talking about. So it's encouraging. I agree, but I put that healthy dose of salt into it, especially since the general report was, uh, that, um, there's, uh, like 64% or something like that of organizations, um, say that they are not coordinated at all in either detecting or remediating the response.

And that's what causes delays of a week for even to begin a patch automated or not. So Mitch, I mean, Tracy kind of alluded to, we can push out the patch through our DevOps pipelines, and yet a lot of the patching is still done by traditional IT admins and those types of folks. Do we even disconnect in the system here between all our DevOps stuff and what the ITSM people are doing?

And is, is this where it manifests itself? There definitely can be, you know, bifurcated, you know, three different paths into getting into production. It, it, it argues for the trend that, that we see, which is in some, in some form platform engineering, a DevOps system, administration, IT ops, uh, parts of that are coming together, whether it's all living in a platform engineering group or whatever it is.

A lot of those functions are the same because platform engineering people are starting to do or have been doing DevOps tool management and pipeline management that's been shifted as part of their responsibility. Or maybe they're working closely with the DevOps people, engineers to do that work. Same thing for patching and the platforms that were, that were, they're providing to those environments and keeping those up to date, et cetera.

But oftentimes that has, that's an in production kind of thing versus what we provide to deploy into production. So it's, it's a little bit of a convoluted, uh, multiple paths. And I think that's often where the confusion happens is who's patching this?

Who is it? Oh, I'm not gonna patch it. 'cause that's their responsibility.

And organizations recognize that. And if they've gotta kind of get their act together and decide what's their process, who's gonna do it? It doesn't necessarily ma matter which team, but it needs to be done.

And there has to be a process. So we all know what's been validated before goes in and that has been applied. God, you think people are just, you know, calculating some odds here and it's essentially a gambling and they're trying to figure out, you know, what is the cost of me if I patch this thing, how much trouble I might get in 'cause I broke it, versus what's the probability that some vulnerability will be exploited?

So are we all kind of playing, you know, some version of Russian roulette here? Oh, we, I I definitely think that's the case. I do think it's, there's more awareness and um, as you know, sort of one of my predictions for this year is that, uh, this will be become more conscious Russian roulette rather than essentially, you know, unconscious or subconscious Russian roulette.

Um, I think that there's, there's politics and culture that plays into this so much going along to get it to getting along, going along, to get along, whatever it may be. And I think that there is this huddle or what I, you know, picked up from someone else, sort of called kitty soccer element. Something's happening.

Oh my God, we're all gonna get together and talk about it. We're gonna figure out who's gonna do what. We're gonna reassure each other point the finger at some, like all that sort of stuff that goes on.

It's just social and cultural instead of a real cold hearted, like cold hard look at what's going on and addressing it in a systematic way. I, I think things are getting better, but it's like going from bad to not so bad. That's sort of how I feel about it.

I know last time I went team soccer was 10 kids running around at the ball with no particular play. That's what kitty soccer is. Everybody goes where the ball is instead of people playing their positions.

Alright. And I wanna point out too, that not every vulnerability is the same. Um, and when you, and, and not every system is treated the same.

So how many, how many companies actually have a Jenkins workflow for the operating system, right? Or any of any, any kind of cost that they may have that they may be integrating with. And so there are teams that are highly regulated, let's just say the application teams that have a, they're, they've got a, a Jenkins workflow, they're really trying to automate.

They're really trying to create the visibility. And then you have the software that just gets installed by somebody on the op side and that, and, and oftentimes there's a mismatch in how that, um, a release to an operating system level could impact multiple applications and they will never know. And it's the same with, uh, in a decoupled environment, you might be, you might be consuming the standard logging, uh, routine, right?

And they make a patch because they found a vulnerability. So they push a patch out, and now you, you, you're getting errors every time that your, your system goes to do the logging and you don't know why. You have no clue.

You have no insights of what's happened. So we're, we're just, we're we're in a new world now. We've got people still going through digital transformation and trying to modernize applications.

We have cybersecurity on our tail and everybody says we should be writing AI applications. What is it that we should be doing first? In my opinion, cybersecurity is very, very important.

And we've gotta get our DevOps, uh, practice back online and start understanding how all these pieces are interconnected and they all should have similar requirements for moving to production. Now, You and I have talked about that Tracy, that that, that there may be a certain level of, uh, shoring up to be done in DevOps right around now. That was your insight to me.

I don't want to take any credit for it, but I, it really resonates and I feel like that that is, you know, something that might actually start to be recognized now and that is encouraging. Mm-hmm. Well, I hope it is because the CD events at the, at the, uh, Linux Foundation, it's one of my favorite open source projects there.

And we have not seen any of the, what I like to call the giants. Um, IBM is actually push pushing it. They've got a developer on it, but none of the rest of the giants have really started to look at it.

And if we could get rid of plugins, really, or even command line and start driving, uh, DevOps through event processing, we wouldn't be talking about the fact that we have brittle, uh, you know, pipelines that we don't wanna touch. We don't even wanna go in there and add a workflow, add a, a a a step to generate an S one, which is very easy. Everybody, it's super easy, but we don't wanna touch it.

So let's help. You're saying we Need to, we need to modernize DevOps, not just our applications. We need to modernize DevOps something fierce right now.

There we go. There we go. Yes, we do.

Right? You know, and, and guy, you kind of alluded to this a little bit, but I want to get into it a little bit more. So people say they've automated patch management.

Well, I think they've automated the deployment of the patch, but when something goes wrong, they, it's not automated on the return. So, you know, winds up being a manual kind of thing at the end of the day. So maybe that's why I'm scared to patch.

Yeah. So, uh, automation is ap it has a lifecycle of its own, it should have creation, test, promotion and so forth. I don't wanna overdo it, but what we're more or less talking about is a certain thoughtfulness that should go into all of this that is lacking.

Not because these people aren't thoughtful people, but because the incentives both from the culture and from the business or the organization they're in can often be at odds with it. And that's all. That's all.

So, yeah, exactly. It's not how many organizations, it's how many organizations to what degree and at what depth are they automated patch management. Those are the three elements of it that tells us whether we're really making progress or not.

And we know developers love spending their time patching software. Oh, yeah, yeah. Well, so now, so now, right.

It'll, I'll bring, I'll, I'll bring it, bring up the, you know, the elephant in every room. So now there are ai there are ways to use AI to help with that, right? And we also know that it is not just an answer.

It it, it gives you more assurance to do because it, it, it's a less of a burden. A developer can have a little more fun or a little less pain doing it with an AI service of some kind. But then they still need to validate that it works, that it's correct, that it wasn't done improperly.

That that human intervention. So it's not, it's an easier button on an easy button. So it can create a whole new level of problems with the automation to to, to use ai.

So Tracy, do you think AI is gonna force this issue in an ugly way? And I'll describe the ugly way. It seems like the bad guys are figuring out how to use AI to scan for vulnerabilities and then generate a piece of code or something to exploit that vulnerability using that AI tool.

And there's just gonna be a, a boatload more of these zero day vulnerabilities as a result. And you're gonna get about no notice and you're gonna be expected to fix this issue in 24 hours or less. Is that where we're headed?

I'm banking on it. I am banking on it. I spend every single day as, you know, working on a startup to solve this exact problem.

Mm-hmm. Because I do believe it will be a primary issue. Let's just face it.

The complexity in modern applications is way too broad for a human to sort out. Mm-hmm. We have to, and, and we don't really need AI to fix this problem.

We really don't. We have the data, we have the technology that can fix this problem. We just need to make a commitment to doing it.

We just ma need to ma create an understanding that while we might have a great, uh, you know, a single great workflow for one container when it comes to putting a patch across hundreds of containers, it's a whole different environment. Because you have to understand the impact of making that patch. What is, by favorite word, the blast radius, Where, where's our drink?

That, that was a tradition on one show. You could take a step If you don't understand the blast radius and you're gonna make the patches, but you may not be able to complete it because you don't know all the locations where it needed to go. And you may patch things that didn't need being patched.

So it's a, this is a very broad problem. We can't expect humans and operations or DevOps eng engineers or developers to try to fix it. It's too big.

We need better visibility and we be need better understanding of what, what the impact is of a single fix and where we need to put it. Mm-hmm. Which leads to our se second favorite term, unintended consequences by updating stuff that didn't need it.

That Didn't need it. Yeah. Mm-hmm.

So, and the time it took to do that. So Mitch, I mean, we keep circling around this particular issue, but what is it just a matter of will and a lack of will in these organizations? 'cause we seem to have tools and capabilities, but we're not willing to go the extra mile and what is, it's because we're afraid of the pipeline, or is there something else at work here?

Well, when we're incented, incented to get features and capabilities out, right? That's what the business needs and that's what we want to be able to deliver on. Strategies, business goals, customer experience, et cetera.

So that's, you know, for developers, that's, that's where their kind of bread and butter is. So the more time we consume by from developers of doing patches, you know, that takes us, that's the toil part of it, right? That's that technical backlog.

Um, I think, I think the, the issue is you're, you're afraid to touch, you're afraid to touch it because if you break something, you bought it, you get to fix it, right? Kind of to Tracy's point about this, could patch could go a lot of places. Where do we deploy it and who's making the call about how important it is?

You know, coordinating with security or using whatever you tool, tool that you use to assess, you know, it's the severity against where do we use it and how do we use it? And does that functionality that even can be exposed. So for security patch, so it, it's not as simple as kind of upgrading your iPhone and saying, yep, go ahead and update all those applications.

I wish it was, uh, but, but it is a good, I think it is a good application for AI to apply specific kinds of patches. I wouldn't turn achi PT to go loose to go apply all my patches. But I think as we have specialized upgrading operating systems, upgrading part of your stack, upgrading Kubernetes, things like that, that involve, you know, getting really into some of the meat of what's going on in the app.

And does this patch depend on an Okta update or vulnerability that you need to get patched? And if so, what are the implications That's where we can help it. 'cause we're seeing AI start to help us analyzing code bases for doing application modernization.

What is the architecture? What's the functionality? How does this work?

So I think there are some tools that are really gonna help us bring down the, the fear factor. All right, folks, I think ultimately to Mitch's point, they say compensation drives behavior and developers may not like to do patching, but if we change the way we compensate them, they focus more on well, ensuring the quality of the applications and the developing patches, guess what they're gonna do? Hey folks, we'll be back in a minute with our next topic, but stay tuned.

Discover Techron Group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us.

You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients, let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group.

Alright folks, we're back and we're talking about cloud computing, and this is one of those topics that I gotta say always leaves me scratching my head. Um, and the issue is, and I'm gonna start with Guy, um, I, we all know there's the top three, uh, cloud service providers, the hyperscalers, and then there's, you know, maybe the next tier underneath that and a couple of Chinese companies. And then there's this other category and there's like 10 times, maybe even 20 times more companies than that other category.

And I feel like a lot of the services that we're using in the cloud or commodities at this point, 80% of it probably is using the same kind of basic infrastructure stack. So why aren't we seeing more folks kinda use alternative cloud service providers? And last week we saw a lease web, for example, come out with an aggressively priced set of services based on the latest generation of a MD processors.

They got NVM storage, they got 10 gig networks. So what's going on here? Uh, well, clearly a vendor is producing something, um, at a price point because, uh, they see an opportunity for that.

Um, I scratch my head and say, how is this different? What, what, what about this is different than 10 years ago? Because we had these 10 years ago, we had bare metal as a service 10 years ago.

And I I also asked myself, and I didn't do the research, so maybe it's readily available, but what stack or stacks are offered and how are they managed? It really comes down to, um, uh, deficiencies, uh, or immaturity in management, in operations and in platform. So I'm gonna go and use, uh, this virtual private server from Lease web.

Great. It's cheap. Four euros a month.

Um, let's say I have my choice of stack, it's lamp, it's Linux, it's, you know, windows, whatever it is. Good. All that's good.

Um, and if what I'm trying to do is house one web app or one particular database or app or what have you, um, where the siloed nature of it is not a big deal. And these apps exist in every organization of almost every size. Great.

But what we are really trying to drive towards is, you know, mobile apps, scalability, up and across, up and out, uh, uh, um, and, uh, an ability to manage in a relatively simple way. Um, the proverbial pane of glass, I think is mostly a myth, but you do want to have a relatively simple way to look at your estate and know what's happening in various servers and in various points, wherever they are housed, I don't really see, um, the, the, we're getting there. We're starting to get there.

We're trying to get to, so mobility is, I have a single unified managed, there may be multiple Kubernetes implementations out there, but I can manage them all at least in one paradigm, if not literally in one pane of glass. And I can move things around. This is really important for the app lifecycle because there are things I may want to trial that I want to trial in a public cloud, but then I wanna have a more controlled environment, which could be this lea web environment.

And then when it gets into production, um, and audit and all those other sort of things that I need to do, then I have, whether it's a private cloud provided, buy one of the hyperscalers or that may not be appropriate. There's lots of options out there, but many of these processes of initial assessment, promotion of environment, ultimate management, there are manual elements to it. There are multiple panes of glass, there's a service provider involved.

I have someone in house who's part-time working on it. That complexity is not really fully addressed yet. And, and it may just be an ongoing sort of a thing.

So it is a very attractive idea to have this single hyperscaler that I can post all the environments in. And then for a number of specialty, it might be 20% of my estate, a number of specialty or particular databases or, or applications where the cost of the, the fact that they're separated out, um, is far outweighed by the convenience of management of this little, I'll call it, I'll say it again, silo, um, that persists, that persists to this day. Do we have more choices?

The reason we have more choices, Mike, is because it is lot cheaper and easier for lease web to stand up this inexpensive offer than it than ever before. That also means it is cheaper and easier for you to do it yourself in your data center, under your desk, in your closet, wherever else. It's, so I still look at the management platforms, the operations platforms, which includes mobility and all that other sort of thing.

And the, the, well, the, the operating, the, sorry, the runtime platforms as needing to continue to evolve before we really have this, we'll start to approach this nirvana of, I am going to have, you know, I'm gonna go into a web browser and with one or two panels, I'm gonna be able to instantiate an environment, offer it up to the application manager or developer, and manage its lifecycle cradle to grave. We're just, we're very far from that. Mitch, I know you've been diving into this area in the last year or so, pretty heavily.

What's your take on what's going on with these alternative clouds? Well, it, it, the, um, at least what kind of falls uniquely in, in the space of offering both dedicated hosting, here's a physical, physical servers, physical storage, et cetera. You know, we we're used to think it's just hosting provider and then they also have, uh, virtualized cloud-based offerings, which is part of what this VPC is our VPS, sorry, uh, different product, another vendor.

Um, but similar kind of product. So, you know, it's not something that I think is gonna, somebody's gonna say, oh, I'm in Amazon, so let me, let me, let's go over and use this web. I don't know that it's gonna drive people to, to use it because it's so much cheaper.

Um, because you're probably talking about more of a dedicated offering. But I think people that do need that, and they, they, they're, I think they're Dutch based, if I remember right. And they have, you know, they have a, a a, a data center, Montreal in the US and, and in Europe.

So there are some good places that would be great for some applications. So I think this is a, um, cost savings, a little bit more flexibility. It's a feature and uh, I think that's, it's a good thing.

But, but it's a feature. So I don't, I don't over rotate on, you know, it's not gonna change the industry. Trace what's, Nobody's gonna, I'm sold as soon as I get off the call.

Well, I did just sign up why, when you said that I signed up for commissions, so thank you. Mm-hmm. I mean, you have to understand where a startup comes from.

You know, we're looking at saving every single penny anywhere we can find. And at the same time, we're trying to host an, uh, an open source community, um, for the continuous delivery foundation who has lost, uh, sponsorship. And they don't, they don't support development environments for us anymore.

So I have a ton of software developers who are trying to do development around Artelia and they're all sitting at raspberry pies at home, right? So if we could provide, if we could use something like this to provide a central place for us to do a lot of the kinds of testing we need to do integrations with tools like CircleCI and Jenkins, it would be so helpful. It would be so helpful.

And even hosting, um, our SaaS environment in, uh, in some place that's gonna be cheaper would be amazing. I mean, literally we're looking at saving, if this is true, we could be saving about, I don't know, $297 a month, which is a cr like crazy amount of money for a startup. So, um, and, and when it comes to the cloud, one, there's no such thing as one size fits all.

And even in some organizations where they're doing maybe a monthly processing, um, something they have to do on the backend to do reconciliation of some sort, batch processing, I think this is a better alternative. And we're just coming to a place where it's, we're gonna have to acknowledge that we're not every company's not gonna just be Google, just be AWS we are gonna be using different services because it makes sense and it, it, it, it saves money. And so kudos to lease way to opening up some doors for younger startups that are not a, you know, we're not a Bank of America that need an Amazon support Guy.

Do you think that the way that, I mean, I'm, it's, I'm certain of this, but you know, the cloud, the big guys create these enterprise license agreements, and then what happens is the organization needs to hit a certain amount of threshold for compute for those discounts to kick in. And I think it discourages people from looking at the workloads to say, which one makes the most sense to run where, based on the total cost. So, um, you know, do we need to kinda unpack some of those licensing agreements?

We have to think more about these workloads to have, maybe, you know, to your point, it is gonna be a multi-cloud world, but how are we gonna get there? Yeah, I think the startups and the smaller companies as well as the, um, service providers, um, the smaller service providers, the regional ones, um, they're gonna lead the way because they don't qualify. They don't have the budgets, um, to, uh, get those kinds of enterprise level agreements.

I, I, I'm a big, you know, uh, uh, I talk a lot about how a lot of what appear to be small business activity actually takes place in the enterprise because, you know, these are big companies, there's budgets all over the place and people just go and start doing stuff. Um, but I think that there are a lot of incentives, as you note, they're mostly business incentives, but somewhat cultural as well away from using these smaller offers. Now, where are we?

Uh, or let's, let me, let's not call 'em a, let's not call it a smaller offer. Let's call it a simpler offer. This is utterly simple.

I think that's a lot what I took out from what Tracy said, it's, it's a simpler decision. 'cause it's cheap, it's simpler because it's really, really straightforward. It's not coming with all of these bells and whistles and attachments and everything that you'd get, you have to deal with with a hyperscaler.

Um, this is one case where I, I don't think the enterprise or larger organizations that are gonna qualify for those sorts of the binding contract that you're talking about, Mike, I don't think that this is a place where people want to really be, um, uh, in terms of, you know, finding and using environments where you're gonna have a little bit less of that kind of innovation and trials and that sort of thing. It's really gonna happen south of their medium sized companies, smaller SPS and so forth, that's, and that's what's gonna do it. That's what's gonna do it.

They are mature enough now. 10 years ago they weren't nearly so mature, you know, in terms of technological capabilities. Now it's just perva pervasive everywhere at every size of organization.

So Mitch, if that's true, are we gonna see the market segment more and will the smaller mid-size companies kind of start looking at outside the hyperscalers? What do you think? Uh, we, we, we have had this already, um, Leno that's now part of Akamai was sort of a variation of lease web, more focused on developers with APIs and lots of tools for setting up Kubernetes and, and uh, training materials.

And in a way, lease web is focusing on let's focus on the basics in terms of infrastructure for hardware and add some cloud services. We think the key ones you're gonna need and leave it at that. Don't, don't, don't over complexify.

That's a word I made up. That's self-defining by the way. Yes.

Don't over complexify, you know, the offerings by like, okay, what, what is all this stuff on? What should I really be using? So I, I think you know what Tracy said for startup environment, um, for projects they do, by the way, support dev test environments have offerings around that.

Um, it may be just the right solution. You're, you know, bank of America's not gonna move all their stuff onto it, you know, tomorrow. That's not, probably not the provider of choice for them.

Not that I know that I don't have any inside information, but I think for many businesses is a great option. I, I think what I'm trying to say is that at Bank of America is a great example at Bank of America, there's lots of weird and wacky stuff going on, especially in Dev using platforms or, you know, things that are not part of the, you know, the, the marketplace that they have internally and all that sort of thing. Um, so there's a lot of that activity that happens.

Um, both hardware, software, dev, the whole thing. But I think this category of cloud service is a lot less likely to be so because they are offered up lot, you know, lots of ways to go and use stuff and do stuff via the hyperscalers at almost no cost to them. Alright, Well guys, thanks for the insights.

Everybody I talked to is doing something around cloud optimization and I think that may also need to include looking at alternative sources for the right workload in the right place. Hey guys, thanks for spending some time with us again and good to see you all. You bet.

Always good, Mike. Great to be here. Absolutely.

Always learn something. All right, me too. I You bet.

Folks, thank you all for watching this latest episode and please stay tuned. We have a ton of content on text drawing TV today. That's just gonna be equally awesome.

We'll see you next time.