Techstrong TV – January 20, 2025

Hey everybody. I'm Mike Ard. We've got a DevSecOps Paradox, some patch management progress, and maybe 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, 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, 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, it, so much of the world that the developer lives in is in their IDE and increasingly in copilots, 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'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.

Lenox 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 alright, 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, 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.

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 hit. 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 of about cars, maybe it's about software development, I don't know.

But, um, you're, The remediation camp I'm unclear about is, I think you can go fast, but you have to be smart. And if you are 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 it, you have to have a dust 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.

That'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 ans 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 Tracy's point as well, I, I haven't given this talk in a while, but I used to give a 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 do 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 PE 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.

You'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 seen, we'll see, right? I think some people will include it. But to what end?

I think we will, in 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 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 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, 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 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. io, come and join the open source project and help us finish it. Definitely.

Arterius 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 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 a 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 been, 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. And 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 we're, that we're, 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 it's 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 soccer was 10 kids running around after the ball in no particular play.

That's what kitty soccer is. Everybody goes where the ball is instead of people playing their positions. 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 costs 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 ops 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 of 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 dev. 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. I'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, not 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. 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. And 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 chacha 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 are 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 NVME 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 release 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 want to 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 host 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. What, 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. Tracy, 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 our 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 ours, 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 back end 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, 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 that 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 on 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. This is Textron tv. Hey everyone, welcome back here to Techstrong tv.

You know, I'm really excited about this next interview. I have been since we originally scheduled this one. I want to introduce you to Frederico Munoz.

Uh, Frederico is the release lead for Kubernetes, and there's a lot in there, but let's welcome him to the show and find out a little bit about what he has to share with us today. Frederico, welcome to Tech Drunk tv. It's great to have you on.

Thank you very much, Alan. Thank you for having me. So, as I mentioned your release lead for Kubernetes, but you know, how does one actually get to be the release lead for Kubernetes?

What does it really mean? Tell us a little bit about your journey to here today. Yeah, I mean, a fair question and one that I sometimes, uh, also think about it, uh, because it's, it's not something that I, I, I would think if you would ask me two years ago, uh, I would say that, that that was impossible.

But, um, so I, I guess it's also tied with my overall journey in technology. So let me just go through that a bit. Um, I've, uh, started then in technology in general with programming and everything else, um, with the rise of the, of the Linux and the free software movement, uh, around there in the late nineties perhaps.

Um, so I, that was the thing that brought me in. Um, it technology, et cetera. My actual, um, academic background, uh, is in archeology and then, and then physics.

But I started with archeology. So, um, in, in a way free software and the open source movement that, um, uh, uh, started, there was my gateway into everything around computers. Um, I, I started with as a programmer, then I moved into, um, platform and system administrator.

Um, and this, uh, in a way ties with the, uh, with the rise of Kubernetes later on. Um, why, because, well then I, I, I, I, I joined, uh, IBM where I've worked on a lot of different stuff from IOT to solution design to quantum computing. Currently I work at the SaaS Institute as a cloud architecture lead for Europe.

But, um, the reason why this is important is because, uh, this background in Linux and Unix in general, uh, actually made, made my, um, going to Kubernetes and the entire cloud native, um, uh, uh, landscape and ecosystem that started just around the announcement of Docker, right? We have that, uh, a fundamental, um, that, uh, fundamental aspect. And then obviously Kubernetes as an orchestrator.

Um, it's built on Linux as well. So, um, I started to work more and more with, uh, with, with, with Kubernetes as a, as part of my day job. Um, and a couple of years ago, um, I've decided to just like I did when I, I, I joined the Dian Project, for example, and others to, uh, join Kubernetes as a contributor to, uh, because, uh, Kubernetes is the second largest open source, uh, project out there.

And that's what I did. So, uh, the, the, the, the more direct path to be being be, uh, being the release lead was like two years ago, two and a half years ago when I joined, um, seek Country ex comms and, and other, um, uh, communities inside Kubernetes to just help out and do my, my my part as a volunteer. Um, when you start doing that with some consistency, you then obviously meet people you trust people.

I joined, uh, the 1 25 Kubernetes release team as a shell just to learn how things, uh, were, um, were done. Um, and I was, uh, consistently done, um, a member of the following releases, 1 26, et cetera, until, uh, last release. I was nominated as a, wanted the ITIES 1 32 release lead, much to my surprise.

But in the end, it's a result of this, uh, path, the short one that started two years ago, that's also a result of a longer, uh, I will, I'll almost say live, um, journey around, uh, uh, free, free software and open source with a cloud native twist. Excellent. So you mentioned this, uh, there's a new release of Kubernetes.

32, and it's called Penelope. But, you know, we were talking off camera before we started, right? When I first became aware of Kubernetes, it was actually at a DockerCon, I think, in Austin, Texas.

So not even the first DockerCon, maybe the third, second or third Docker. You know, while the news was all about docker off to the side at one of the booths or whatever it was, I saw them demonstrating Kubernetes. 8.

And I remember, and people were so excited, right? And you gotta remember at this point, there wasn't, it hadn't been crowned the king of the orchestrators for cloud native or for containers, right? You had Docker Swarm, you had Rancher had Mesos.

There were, there was several different ways of looking at how to orchestrate containers. And, but yeah, the buzz around Kubernetes was, was palpable. com already, security Boulevard.

And I said, you know what? We shouldn't use the name Docker because they have it, uh, trademarked. Maybe we should look at containers.

I said, but everyone there is talking about this thing Kubernetes, but I don't think it's ever gonna catch on. It's too hard. You famous last words.

Um, Well, you what's wrong, but, uh, That's, well, that was good, right? Popular Yeah. But on popularity.

Yes. So, but, you know, so, but Kubernetes has, over that, I guess it's been almost 10 years, Kubernetes has grown from being the, the orchestrator for containers to really, the heart, the beating heart of, of the whole cloud native stack. And the cloud native stack today is in many ways the compute stack for, for modern architecture, right?

Whether, whether, yeah, absolutely. Whether we're, we're talking about a microservices based architecture, serverless, um, containerized. It is at the, at the heart of it.

And what I find remarkable is here we are, you know, 10 year anniversary of Kubernetes. I think it's eight years, or eight and a half years since version one. 32.

We're still in version one, right? It, it's not where you see other releases, you know, they do a ma two major releases a year with a bunch of miners. 32.

So I think it says something about the, the steadfastness and deliberation and what goes into a Kubernetes release. It's not something, you know, where we whip together a recipe for this month or this quarter. 32, Federico, talk to us about how are these releases planned?

Is it purposely, obviously it's purposely that we don't do these quickly, or, you know, by happenstance they're very well thought out. Talk to us absolutely. A little bit about that process.

Sure. That's a a very good question. And, uh, just as an intro to, to that, and based on what you've, um, also mentioned, uh, there's a, an interesting timeline here, uh, as well, because, uh, Python was, um, was released in 91.

Docker was actually announced at the Picon in 2013. Uh, and then, uh, in DockerCon 14, which is in, uh, 20, uh, 14, um, Kubernetes was really, was announced. That was the first announced, uh, announcement was at DockerCon in San Francisco, uh, 2014.

Um, so there's this like Python, docker, um, Kubernetes, uh, being presented in each other's conferences, which is interesting. And, uh, as you mentioned, obviously, uh, Kubernetes has this past in Google as Borg, et cetera. That's almost pre history by, by, by, by this stage.

Um, but you are right in that there were, uh, there were many other competitors that still exist, but competitors, I wouldn't call it competitors, but other viable solutions, uh, that, uh, fall within the same space. Um, certainly it's true that in the last decades, Kubernetes has risen as, uh, as the most common choice in terms of container orchestration, but not only it's as a core piece of the, of, of development platforms everywhere, um, and around the releases themselves. So, um, the first, uh, one, uh, uh, release was somewhere in 2015 actually.

2, which were the ones that, uh, started, um, the now 10th anniversary of Kubernetes. 1. Uh, I think that in the last, uh, in the, in the next year, it was also, uh, one or two releases.

But, um, uh, along with, um, so as time, uh, moved, uh, there was an, an, an adoption of f more, um, well documented and streamlined and, um, uh, uh, structured release project, which is, uh, essentially what we use today. And what is that? So we have three, uh, Kubernetes, um, releases per year, uh, in, in, so once, one at the start of the, of the year, another one right there in the middle.

And like 1 32, 1 at the tail end of the, of the year. Uh, which, uh, explains the, if you do the math, obviously from 2016 to now, if you add up more or less three releases per year, we get to the 1 32 number that we, that we have. Um, so the, the way that the release works, it's actually, it is interesting and, uh, it's, it's the results of a continuous improvement process at each release we do, uh, retro meetings in order to improve the documentation, the process to make things simpler and make things better for the next release team that will pick things up.

Um, I will, I will point out, uh, point out that the, the people in the release team are also, uh, volunteers, which are chosen and nominated by their peers, including through a, uh, open shattering program. Um, and how does the release work? Well, we each, uh, the release that we have a release lead with some release lead channels, we have a release team that contains people that will lead specific sub-teams, like communications, like release notes, like enhancements, um, et cetera.

Uh, and, uh, we have more or less, as I said, three months there. There's a, a timeline that is published at the beginning of the of year, uh, of the, of the release. And, um, there's a call for enhancements.

So any six special instance group, Kubernetes has several different special Insta groups, like, uh, seek notes, seek apps Network will, uh, identify the enhancements, the features that they think are ready to, um, be incorporated into the specific release, either as an alpha feature, a better feature, or as a generally available feature. Each one of these will come with some specific requirements in terms of the feature documentation, tests, um, et cetera. And, uh, the, the release proceeds with the inclusion of enhancements, a code freeze, uh, making sure documentation is there, making sure that the communications is ready, making sure that there's no bugs or regressions tackling any issues that might arise.

And after that three months period, there's a, obviously during that period, there's, um, several release cuts, also one of a two release candidate, one et cetera, until we reach the release day and there's a Kubernetes release that will incorporate all the new features that were identified and chosen by, um, the, the respective six for that release. Excellent. That was fantastic.

32 13, of which, you know, based upon the, the kind of background you just gave us, 13 have graduated to stable, 12 are in better. Yeah, exactly. 19 are still in Alpha.

But if you had to pick out what are the big highlights of this release that our audience should really be looking for? Give, give us your top ones. Um, absolutely.

It's a matter off taste. Um, I would say that there are a couple of interesting ones. Uh, I think that the way that dynamic resource allocation, which is, um, the, the feature and the, the, the capability that enables Kubernetes to, uh, manage things like GPUs, FPGA, so not only memory and ram, but uh, also such devices, which is very important for, uh, many different workloads, including AI related and ML related workloads, obviously.

And in this release, there's a, a, a, a new implementation, and there's also the deprecation of the old IMP implementation. And this new implementation actually plays, plays, uh, well with the Quest autoscaler and, um, overcomes a lot of, uh, some of the limitations that the older implementation had. So I find this interesting because I think that this startup workloads are, it continue to rise in importance, and it shows our, our Kubernetes release, um, incorporates, um, improvements that deal directly with, uh, requirements that exists in the, in the, in the, um, out there, right?

So this is certainly one, um, I think that, um, there are, um, other interesting, uh, aspects as well. I think that we have, um, some good stuff around improving the resource management. Uh, for example, we have the memory, uh, manager going, uh, ga so generally available.

We also have the, some updates and a new feature around the ability to determine, uh, resource limitations at the pod level. So creating like a shared, uh, uh, limits that can be, uh, shared by multi pods, uh, multi container pods, which I, I, I think it's, uh, very useful, uh, in, in terms of streamlining and avoiding overcommitting. So, and a couple of them around this overall, um, improvement team on, on, on resources.

Um, there's one thing that isn't specifically a, uh, a, an enhancement, but I think it's fundamental to highlight here. And 1 32 is the first release that has achieved 100% conformance testing coverage. Uh, and this was something that was done, um, during code freeze, and it was, uh, it was actually the, the PR that, that this was merged, uh, live during the Kubernetes contributor summit.

Uh, it's during North America, uh, because of the relevance that it has. And why is it important, uh, performance testing is what makes Kubernetes be Kubernetes, right? Uh, uh, it's, it's a se series of end-to-end tests that more or less determine the, the answer that a Kubernetes platform should have.

Um, we, up until, obviously when this started, uh, the coverage was, um, below 10%, it's been improving, uh, and trying to cover all the, the endpoint through time. And in this release, during that specific, uh, um, moment, there was 100% coverage, which means that, um, uh, the, the, the very way that the, the testing and the performance testing is done, as has reached a level of maturity that, uh, should make us all product Excellent. Fred Rico, we're, we're over time already, but for people who wanna go get, there's a lot more information than we were able to cover here in 20 minutes.

For people who want to get more information, what, where's the best place to go? io/blog. Um, they have the, the Kubernetes release article there that covers them.

The, the, the, the features, the main statistics around the numbers, uh, the theme, uh, as well. Everything is there. And we have a series of, um, feature blocks coming out.

Some of them have, have already been published that go into a bit more detail into some of the specifics, uh, of the new features. For example, the, the memory management, um, aspect that I mentioned before as a specific blog entry in at Kubernetes io. Excellent.

Credico, you know, people don't realize what really makes the open source world go round and round are people like you, who you don't, you don't do this for the money, obviously, it's volunteer work. Some people luckily, you know, do get paid. We're starting to pay maintainers now.

Yeah. Which I think, you know, CNCF does. And that's a great thing because the amount of time and effort, it's really, you don't do it for the money, as I said, it's a, it's a labor of love, if you will.

And, uh, indeed people like you who donate so much of their time and effort into this. Thank you. Thank you for all you do, and thank you for thank to the team.

Appreciate that. Yeah. And we are looking forward to great things from Penelope.

Thank you for being on Techstrong tv. Was a pleasure, Fred. My pleasure.

Frederico Munoz is, Muna is, uh, release sleep. Kubernetes here on Techstrong tv. We're gonna take a break.

We'll be back in a minute. This is Textron tv. Hey guys, thanks for, we're here with Porter Stowell, who is head of ecosystem and community for the File Coin Foundation, and we'll explain what that is in a minute, but we're talking about the rise of decentralized storage port.

Welcome to Shop. Hi, Cole. Pleasure to be here.

Thanks for having me. We are hearing a lot more about decentralized storage, especially in the age of, uh, Bitcoin and all those things that have come along. But there are, um, enterprise applications for this stuff, and more people are using it.

And a lot of it has to do with just, um, I guess we're trying to consume data closer to the point where it's created and a way that's cost effective, but, or explain what the first, what the Filecoin Foundation does, and then what are we seeing here with decentralized storage? Sure. So, uh, first and foremost, Filecoin is the global leader in decentralized storage across the world.

I think we have the, the most capacity of any other decentralized storage network. Filecoin Foundation specifically is the stewards of the network, again. So we're an independent foundation, and we are here to make sure that, uh, the file co people interacting with Filecoin have the right growth governance, uh, and o operations to make, uh, show the project is continuously successful over a long period of time.

And like, to dive into your question on, like, enter, uh, decentralized storage, it's, it's been an evolution, um, one that has taken, uh, multiple years. Uh, so Filecoin launched in May net in, uh, 2020. So we're four years into our, our journey.

Uh, and I always go back to like, I always love historical reference. Uh, and it really took, you know, AWS as an example, close to six years to really get to the AWS that people realize, well, you know, think of what they think of today. And so, like, doing new technology's hard, doing it a different way is even harder.

And decentralized storage is meant to be an alternative solution to centralized storage providers such as A-W-S-G-C-P, Azure, uh, et cetera. And there's, you know, we think there's a great value proposition, uh, uh, that's hard for people to understand. I mean, most people in the world are still trying to understand what Bitcoin is, and it can be really difficult to go the next level on something like storage and, uh, you know, to solve the puzzle for you.

There's not a lot of people who really care about archival storage. It is at the bottom of the tech stack. Uh, on the one hand that is a nice moat for us.

On the other hand, it's tough to get people to pay attention to it. How big is the network and how does somebody actually in both decentralized storage, because, well, it's storage that's kind of highly distributed, right? Yeah.

So I think we're At about four exabytes of capacity right now. It's really hard to fathom how much data is an exabyte. Uh, I, I don't have my good analogies off the top of my head, but just like a, a petabyte, it's like if you took 4,000 digital photos every day for the rest of your entire life, you probably wouldn't even get to a petabyte of data.

Like, if you take all like, Netflix, like movies, it's like, there, there's, it's really hard to get to a petabyte. So we have four exabytes, which is a thousand petabytes. One, one exabyte is a thousand petabytes of data.

So that's a, it's just a lot of data. It's a lot of hard work. And one of the fun facts is like, people don't really realize that there's, you know, besides Bitcoin, Filecoin is easily one of the most, some of the most hardware investments, uh, out of any protocol out there on Web3 today.

So if I build an application and I wanted to use decentralized storage as an alternative to cloud storage, are there APIs that call? How does that work? Yeah, so, you know, again, when you're a developer, you're, you're looking for a user experience that's familiar with something you already know.

So something akin to the experience you get, uh, working with S3 on AWS Uh, and so what we typically recommend in those situations is you work with a software vendor in our ecosystem. So we have all types of players in our ecosystem, those who do storage, those who do orchestration, those who do software, those who provide services to make it work. You know, it's a very laissez-faire, niche driven economy within Filecoin.

So typically what people do is they work with, uh, a software vendor, so such as Ave Scha Lighthouse, where you can get that, that user interface you're familiar with, with I all having to deal with all the complications of how do you upload data to the network. So all the complication is abstracted for you, and they're still giving you the same feature functionality, uh, value proposition alongside of ease of use. What Are the benefits of using decentralized storage versus the cloud?

What is it that people get outta that? Both, you know, either technically or financially? Uh, I would say the, the special sauce to Filecoin is verifiability.

So every eight hours, uh, when your data is uploaded to the network, there is a proof that occurs that says your data on chain is still there and is in the state that you anticipate it to be. And so, like, that's, again, we're trying to go to the don't trust, verify, uh, era of, uh, building applications. So Filecoin is just doing that for your data.

It's like, don't, you don't need to trust that I have it and it's in the same state. I'm giving you a cryptographic proof every eight hours that it's exactly in the state that you left. Uh, and that, again, when you're storing data over long periods of time, has a lot of value.

So verifiability as a term, and immutability as a term, is really gaining a lot of steam in businesses because, uh, quality of data, trust of data, authenticity of data is really becoming more prominent as AI gets traction. But, you know, to put it in most simplistic terms, uh, you know, insurance or like, you take like a security camera footage. So this is a real heavy footage.

01 seconds that is like relevant film, but you gotta store the whole thing 'cause you don't know what's relevant. So these security cameras are like, they have to store all this data. It gets really expensive really fast.

And not only that, they need to be able to get it in very niche cir circumstances, and they need to show that this video was uploaded for this time from this camera and hasn't been touched at all. And that would stand up in a court of law. I, like you could say, I have on chain verifiability that this video has, you know, hasn't been altered in seven years since it was uploaded to the network.

So you can think of like the legal ramifications, uh, when like, there's a claim against you and you're looking, you're trying to find this video footage from years ago. Uh, you know, right now it's, it's like you can't find it. Uh, it's too expensive to hold longer term, uh, all these different things.

And like, you know, the, uh, financial indu industry only saves your financial information for seven years. Uh, your medical record, your medical data is only saved for seven years, which is crazy. So, um, again, if you had cancer eight years ago, the medical system check is not gonna know that.

So they may see indicators of things that you've done in the last seven years, but they actually don't save your data. Or whether if you broke your leg in high school, uh, none of that data gets saved, it gets thrown out. And that's not really good process.

Um, and then like, you know, you think of something like your own medical records. I want, I expect my medical records to have everything that's ever happened to me, because if I'm in a situation, I want my doctor to have full transparency of everything that's ever happened to me. Um, and again, you're, you have a couple problems you need to solve to get to that state.

You know, like how do you empower someone to store their own data? How do you make sure that the doctor has confidence that the data is accurate and authentic? So, and then how do I, uh, share that data or, you know, provide access controls on who can see it.

When You mentioned archival storage, um, are we also thinking about that in the context of backup and recovery? 'cause a lot of folks are anxious about ransomware attacks and they want some pristine copy of data somewhere that they can get to. Yeah.

Uh, it's a very common use case within file coin, and we see specific individuals coming from with web two backgrounds and disaster recovery, anti ransomware who are setting up practices in businesses selling nothing, but, uh, this types of services, uh, with a Web3 backend versus web two alternatives. So you mentioned this Web 2 0 3, oh. Um, what types of applications are people building on this as a Web3 oh application?

What exactly is that in your head? Yeah, so, uh, so far we're doing very well with, uh, organizations that value verifiability, for example. Uh, we do very well in academia and research.

Well, and you think about that they have a lot of data. They're in, you know, academia and research typically are not revenue generating operations. These are universities doing research projects.

Uh, and when you're not revenue generating, uh, you're just a cost center. So costs become extremely important. Uh, and also with, um, science, academia and research, try telling a researcher to delete some of their, their data.

It, it's the equivalent of asking a parent, well, which kid would you like to orphan? It's like, there's no, there's no right answer, no. Like, it's all important.

I can't get rid of any of it. Uh, and that's like, this is a very emotional issue for people in research, and they want to keep all their data. So we, we typically do well in, in those organizations.

I, I, I'm also seeing like new use cases, you know, I talked about medical records, so I think there's a lot of momentum there. Uh, and how can you use decentralized storage and data protection so people can begin to take control of their own health and medical data? Uh, and how do you authenticate data along those lines so people can be empowered to have control, uh, and full control of other health data.

'cause in the US in particular, you know, if, uh, if you go from one health network to another health network, the robustness of that dataset is, could be entirely different. I'm also seeing things like commercial real estate. Uh, you see, you may see like, well, commercial real estate, why do they need archival storage?

Well, you know, is not in the US particularly, but in the UK they have green mortgages. So green mortgages, uh, are like, I'll, I'll give you a 50 basis point discount on your loan if you can prove that your green solution and that your, your building is maintaining a green status. So now you can put sensors in these rooms and buildings that will put, they'll store and archive that data on chain on something like Filecoin.

And so now the banks issuing these green mortgages have full verifiability and provenance that, hey, this data was generated from, this sensor was stored on chain. So if a regulator keeps coming or anyone wants to challenge that bank on the greenness of their mortgage, they have a full active, robust data set to back up c their claims. And now that allows them to put all this capital to work in a way that's beneficial to the environment in, in these particular regions.

So, you know, that verifiability, you know, you're getting someone willing to pay a premium for verifiability, uh, because other, without it, you know, that those pools of capital for green mor mortgages would never even get put in, put into the market. So have we reached a point Where people kinda realize, well, all right, data has value and it's more critical than ever, but now we're kind of choking on the cost of it, so they're looking at alternative approaches. Yeah.

So there's a, there's a challenge with y and decentralized storage. You know, with Bitcoin, it, it was very easy. It's very, there's a lot of great data and very pithy comments on why Bitcoin, why now.

And you know, again, you can look at with Bitcoin, it's M two money supply, uh, US fiscal deficits going out of control. These are very sticky talking points for people to say, you know what, maybe I will take 1% of my portfolio and, and put it in a dis, you know, a decentralized, uh, store value like Bitcoin now that those are some real pain points. Uh, and decentralized storage doesn't have those sticky pain points yet.

I, I think it's coming, but, you know, I think storage, decentralized storage will follow a, a path, uh, of Bitcoin where the narrative was, well, if I can I put 1% of my wealth in a decentralized alternative? And I think Filecoin is looking for the same thing. Can I take 1% of my data and put it in a decentralized alternative?

Why would I do that? Uh, again, maybe you're just piloting it versus like a GCP or AWS or maybe you have a real reason because it unlocks a use case. Or maybe you just want to take control of your data.

Like in the, the medical, your, your health medical records type scenario, uh, you know, they're, they're, we're working on more compelling reasons why. So for ma people to take it seriously, the thing is with AWS, it works great. GCP works great, uh, you know, yes, you have a risk of being de platformed or censored, but you know, that's, it's a very small portion of the population.

Uh, and I think with the rise of ai, I think it's sh holding up the mirror on data proven ancy in this conversation on data ownership. And the bet is that over the next 20 years in particular, that conversation will change. Just like people say you wanna self custody your Bitcoin, I think there's going to be more of a effort to wanting to self custody your data, whether you're an enterprise or an INTERVI individual.

All right, folks, you heard me here. There's a lot to be said for immutable data and taking control of your data and making sure that, well, that one copy is the gold copy and nothing's been changed or messed with because, hey, AI models need some specific references, and you never know, you might have to go to court someday. And somebody's gonna say, well, how do you know that that data was the data that you expected it to be?

Hey, Porter, thanks for being on the show. Love it. Anytime, Michael.

All right. And back to you guys in the studio. Welcome back to Textron Unplugged.

My name is Cassandra Chin, and today we have Yasin Beba. Hello. Can I do a short introduction?

Yes, of course. So, hi everyone. I'm, uh, Yasin, vba.

Uh, I have a PhD in computer science, and after that, uh, I did 10 years of iOS development at Word Line. Uh, and since two, three years ago, I'm, uh, dev well, and I'm also a teacher and also part of the Lil Android user group. So you're a part of a lot of things.

Try. I try my best to, uh, to have the community and to spread the knowledge as much as I can. So you said you're part of a user group?

Yes. You wanna describe what that is? Yes.

So it, the lil Android user group, so it's an Android user group located in Lil, uh, its goal is to, uh, invite speakers and organize meetups so that these speakers can share the knowledge about Android, coline or anything related to these, uh, to the Android community of Lil. So Lil, it's a, a town in the north of France. And like, uh, how do you contribute to the user group?

Yes. So my contributions, uh, are, for example, getting contacts, uh, with speakers, uh, trying to organize the meetup, like finding the location where to organize the meetup, trying to find, uh, the funds to, uh, pay for the, for the food, for the meal after the meetup, creating the meetup page by itself, uh, like with the images, the description, and so on. You Have to create the actual page Yes, Yes.

On Meetup and also on Google Develop Google Developers group page. Yeah, I think that's really cool. Yeah, it's a great experience.

Yeah. Yeah. I enjoy it so far.

Uh, do you get a lot of new people when you go there? Um, so the, so since it's a meetup, you know, we're, um, uh, we get like 10, five people, sometimes 15. Uh, it depends, you know, on the day of the week, it's like you can come, uh, what whenever you want to, and, uh, just to sit, relax, and, and discuss.

So it's Really flexible and that gets nice. Yeah. Yeah.

Flexible. Everyone is welcome. So, uh, yeah.

And Nick, you also said you're a teacher. Yes. Do you wanna tell me more about it?

Yeah, so, uh, actually since I was a child, I was teaching like private classes, uh, like, uh, to other, uh, students. So since I was a child, I loved like sharing knowledge, teaching, and, uh, now I'm continuing this. During my PhD, uh, I taught, um, some Linux b scripting.

And after that, uh, even after I joined the private company, I continued on teaching, uh, more like programming languages in general, uh, some theoretical, uh, aspects like mark of chain. But, uh, but I really enjoy teaching, sharing knowledge, discussing with students, and it also myself allows me to better understand the topics that I'm teaching and also, uh, to be a better developer and also to, uh, to renew my motivation for work. Look, that's interesting that like, you're teaching others, but you're also learning yourself.

Yeah, indeed. Like, uh, yeah. Every year, like when I do my classes, I discuss with students, uh, I see their needs, so I adapt my lectures and they also follow like, uh, the podcasts, uh, YouTube channels and, uh, and so on and so forth to really, uh, update, get updates.

And, uh, yeah, I really enjoy the, this, this activity. How does the podcast and YouTube channels help you? Yeah, so podcasting and YouTube channels help me get up to date and also get real life, uh, feedback.

Uh, so some YouTube channels like give you, uh, concentrated update, uh, like in 10 minutes. For example, in France, there is a YouTube channel called Dave Cafe. It's a coffee, you know, for developers.

Like every day you have 10 minutes of concentrated news. Uh, there is also like, uh, podcasts, which is, which is a longer format so that you can have, uh, more deeper, uh, understanding and more deeper discussions like syntax for JavaScript developers In France, we have, uh, cast coders for Java, uh, news, uh, also discovered the, the podcast of Raio Gonzalez. So I'm, I'm subscribe, subscribed to it.

So yeah, that's, uh, I really enjoy listening to people talking about programming in general. So you recommend some of these to your students? Uh, yes, of course.

I recommend it. For example, dev Cafe to my students, because they, you know, it's a short format. It's a YouTube, so it's, it speaks to them a lot.

And some students come back to me like they were sharing the same news. You know, we, we watch the same show, so like, when I share news, they, they'll tell me, oh, yeah, I heard it also in deaf cafe. And, uh, yeah, that's really pretty.

You're doing a nice topic you can relate to. Yeah. And do you have like a preferred programming language?

Uh, so currently my preferred programming language is Kotlin, uh, and, uh, yeah, recently, uh, so I That's one, sorry. That's what, um, one part of conferences, uh, that I, uh, go to Kotlin conferences and also like Java conferences to share about Kotlin. Uh, uh, so currently, like it's really powerful, mature language and it's cross-platform and full stack.

So with Kotlin, you can write, uh, JJ you can argue the JVM. So you can use, uh, spring QAs. You can also use Kotlin exclusive framework to develop, uh, backends, like cater.

You can also write front ends, which are cross-platform. Uh, with the compose multi-platform, you can write your UI one, and it runs on, um, Android iOS desktops and the web with web assembly. So Collin runs on both iOS and Android.

Yes. I always thought that like, development for Android and iOS was a little separate. Sorry.

I thought development for iOS and Android is separate. Yeah, it's, uh, like, uh, without these kind of, uh, new frameworks, it's separate. If you want to develop Android apps, you have to download the Android SDK and use Android studio and use like, uh, compose jet pack com to make your UIs for iOS, you have to download code, then use, um, swift and Swift UI to develop your applications.

That's like, You don't need different UIs Now. You don't need different UIs. Yeah.

Now with compost MI platforms, uh, sorry. Compose MI platform, one UI is, uh, runs on both, uh, operating systems. Google.

That's really cool. Like it reads on both now. Yeah.

Um, are there any, uh, apps which you really, you develop or you like? Um, a app that I like in the, in the, in the store That you're working on, or, ah, like more on the development side. Okay.

So on the development side, so I am not more of a mobile developer, but when I was a mobile developer, I de developed a, a drive application for our clients and a mail application also. So it's really fun to like see like the internals of these kind of apps, like caching, you know, because drive apps, you have to be fast when as soon as you open the app, you have to see the list of files that you have on your cloud drive. And, uh, so cing is really important.

It has to be smart. So as soon as you open the app, you have to show what you have in your local cage so that you have an immediate, uh, like feedback from the application, and then you fetch the data from the server and you synchronize it. So that's really challenging in terms of algorithmics also, like, uh, it's not just like develop UIs, and so there's also like some algorithms and some optimizations to take into account.

That's really interesting, like how you have to show something to the user immediately. Yeah. And fetch the data later.

Yeah. That's one thing that we learn when you develop UIs. Uh, because originally I was, uh, I did mostly like backends, uh, with Spring and, uh, even, um, uh, with, uh, called, uh, I forget its name.

Uh, like all the Java framework, uh, all the Java server frameworks, uh, and, um, and like, you don't think about this kind of stuff, like you just, uh, reply to requests. And so, uh, that's it. But when you develop UIs, like a whole world of, uh, like, uh, constraints appear, for example, memory is limited, you know, in Android and iOS, when you reach a certain amount of memory, your app may, might get killed.

Trading is very important. So the UI thread, you don't need, you don't, it's forbidden to do like, uh, time consuming stuff. HT TP requests, for example, in Android, when you do, uh, um, an HTTP request in the main thread in the UI thread, your application will crash.

Oh, Christie. So, yeah, that's, so that's, uh, there are many things, many constraints to consider. And, uh, for example, when I started working on the drive project, like we had the application freezing from time to time.

Yeah. It's because we did HGTP request or database requests locally in the main thread. So while the main thread was busy, like fetching, uh, HTTP data fetching the database, the UI can't work anymore, can't animate, can't do anything.

So you have to, uh, use threads to like, uh, delegate this task and, uh, like lighten the UI thread, you Use multiple threads to kind of spread the workload. Yeah, Yeah, yeah. And currently there are many technologies that simplify, uh, multithreading, uh, like high, higher level APIs like core routines.

Uh, I think weight, this kind of APIs are higher level and allow to do what we call structured concurrency, which is like, uh, con but more, uh, more structured and the like, more with more mastery of it. Like you just launch thread and forget about them. You can like wait for their return and so on.

It's not like a bread management system. Yeah. Okay.

Do you teach a lot of this to students? Yeah, of course. I love, uh, I love teaching this to students, uh, sharing with them, answering their questions.

Uh, yeah, I really enjoy this. Are there any other tricky topics which you like teaching? Uh, tricky topics.

Um, so trading, yes. Optimizations, uh, algorithmics, like whether it is an algorithmic problem when the users like, have to scratch their brain to solve it. Uh, like, uh, I teach the Game of life, electron Game of life, so I also really enjoy it.

It's with Python and they draw it with the pipe plots. The, the, the, the matrix. It's drawn with pipe plot.

Okay. And, uh, yeah, that's an amazing, uh, lecture because even students like it when they see like things animate and move on their own in a random manner, the patterns and so on. Yeah.

So that's one lecture that I really enjoy, uh, teaching. Is It the Game of Life? Like a board game?

Uh, so the game of life is, um, uh, a random pattern generator. So it's not a game like, uh, where you play, it's like a simulation of, uh, of something, you know, you simulate. Um, so you are, um, you have a metrics or grid, which contains cells, and, uh, depending on the, like for each cells, it'll ch the states will change depending on the state of the earth surrounding cells of the neighboring cells.

Okay. So you have like cell is alive or dead, and it switches from alive to dead, depending on the con the cells are around it. And like, uh, given the, so the game of life has certain rules.

For example, if the cell is alive, it'll die if there is no more cell around it, things like that, you know? And in the, when the program starts, you generate random, alive and dead cells, and then you run the algorithm and you see it move, it move by itself. I see.

So the cells flip on their own. Yeah. They make decisions.

Yeah, they make decisions. So they sometimes it, it gives nice patterns. Like you see like live cells moving like that.

Yeah. Or spreading like this. And then you see, you can either see some like infinite, alive, dead cells, like pattern or you can see like, uh, not moving anymore.

Does it usually stop at some point? Yeah, it depends on how it started. You, it can either stop at some point or it can either stay at the state where like some cells become alive and the neighboring become dead, and then they switch back and forth, so it never ends, you know, I would really Love to see it.

It's just the cells flipping, Okay, take a look, uh, game of life. And there are even like, um, variants of variants of it, which make are in many, much more spectacular. Yeah.

Yeah. I think we've had a really good chat today. So thank you.

Welcome. Thank you very much. Same here.

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.

Hey everyone, it's Alan Shimel at Techstrong. Welcome to another edition of the last Great Cloud transformation. It's no longer just my data center or my data centers, it's no longer just my cloud infrastructure, maybe over at AWS, right?

Today. I have data centers, I have multi-cloud presence, I have presence on the edge. My people do anything from anywhere at any time, and we need, it's a whole new paradigm.

First of all, I want to introduce you to Mike Hamilton. Mike is the CIO at CloudFlare. Hey, Mike, welcome to the last great cloud transformation.

Thanks so much for having me. It's great to be here today. So Mike, CIO at CloudFlare.

Man, that's a job. That's a job. It's incredible.

That's gonna be one of the most complex networks in the world. Something like 21 or whatever percent it is of the internet actually passes through your network. How do you sleep at night?

Tell, tell, tell us. I mean, thankfully, thankfully for CloudFlare, this, this is in our DNA, this is what we get outta bed in the morning to do. I'm not alone.

If I was, if I was the, the key brains behind this, I think, uh, you know, I'd be really nervous all the time. But we have incredibly smart people from our C-suite all the way to every engineer that touches every line of code that's thinking about this all the time. And, and I would really say my favorite thing about the company, in fact, is, is being clever.

And we're thinking about really what the next, the next way to approach this is like, how do we, how do we define not, not just follow or, or address concerns that our customers have, but how do we create the next world? How do we create the next paradigm that really makes data secure? And it really helps companies manage this global infrastructure.

The world has changed so much. I've had the good fortune. In fact, I started my career in public sector in 1998, approximately.

And, and everything was on-prem back then. Uh, and my career was all on-prem through about 2011. I was fortunate, in fact, to be one of the first people to adopt virtualization.

I was a bare metal VMware guy back in like 2001, which at the time people thought I was a little bit crazy. They're like, what do you mean you're running 10 servers on one server and you know, what, how would this even work? And I'm showing them VCR controls on servers, and they're like, what?

Like, you can pause a server. What does that even mean? You know?

And then being able to move servers later was really cool. I've had the good fortune of, of having a career that had that strong foundation around data centers and virtualization. But I, I got, you know, my mind was kind of blown getting into the world where companies were being started entirely on SaaS.

You know, working in hypergrowth gave me a really good chance to say, in fact, when I, when I made that tradition in my career, I went from a startup to MuleSoft. And MuleSoft. Part of the appeal there was, they didn't have anything OnPrem.

They were like, everything was in the cloud. All their business applications were not in the cloud. But that advantage was really interesting to me because I was, I was thinking, you know, from my career, I want to have a challenge that's greenfield.

Like, I've never had to do this before. Nobody's had to do this before. How do I do it?

Um, and to end up with my career now today at CloudFlare is kind of mind blowing for me. Every day when I wake up, I'm like, wow, this is such an incredible company, such an incredible time to be here, largely because we're starting to define how businesses run globally, and we're giving them a safe way to do that. So I, you know, I think the responsibility, we take that responsibility really seriously here.

And again, while I, I'm glad it doesn't all rest on my shoulders. We have a lot of smart people here, but, uh, if I were alone, I'd be way more stressed out than I am. We have a great team here.

Good for you. Hi, Mike. From, from a, uh, fellow now former C-I-O-I-I.

I, I'm with you there, brother. I understand that role. You know, one of the great things about, wait a second, Mitchell, I haven't even introduced you yet.

Well, you know, people know who I am. You don't have to introduce, Oh, I go ahead that I'm Mitch Ashley, I'm CTO with Techstrong and VP practice lead for, uh, DevOps and software application development. Um, you know, as you, you get to consume the services that your company creates, right?

As the network. And, uh, you know, there's a lot of innovation happening in the network, programmability of the network developers, you know, moving apps into it as opposed to just edge to edge kind of connection, security, all the things that go into it today. Um, I'm just curious how, you know, you, you obviously have to kind of keep the trains running on time, but you're also looking at how do you take advantage of, you know, what the company's introducing and the customers might be using.

How, how do you, how do you, what's your strategy around that? Well, I do have someone that, that runs customer zero for me, uh, with, with my guidance and direction that that person just started about a month ago. But we are, we have been using our own product for a very long time, and it's, it's actually really natural because we have a business to run and so do our customers.

And so it, I've run, I've run customer zero programs in the past, and it's generally like I, I insist that we follow the exact same path that a customer follows. So it's like, we have an account, we have an admin panel, we file tickets with support. You know, we don't just run to someone's cube and try to find them.

Um, but then we do try to bump things and accelerate them. And it, what I think is most incredible, and what struck me the most about CloudFlare is how our technology can really meet our customers where they are. So we have all these different ways of on ramping technologies.

Like you, you might say, Mike, I'm mostly on-prem right now, or I have some on-prem and some Amazon or some on-prem and some Google, you know, I'm not quite the multi-cloud yet, or I still have some Unix box sitting in a closet somewhere. Um, you know, and, and I want to get this into a zero trust network. And, and our product is designed to do that.

It's designed to make it easy to get your network connected. And so it meets our customers where they are instead of asking them to change everything or, you know, hodgepodge something together and into some kind of word Goldberg machine. Because I think the way the world has changed, the way that, you know, our, our, our employees are no longer at home.

They expect to be able to be all over the place. Our applications are no longer in one place. There was so much you could control back in the day of saying like, we run that application on that server and that data center.

I can look at the traffic flows and control performance and blah, blah, blah. You know, that was one thing. Now the applications like Whyman, Salesforce's data center on the West coast, and I'm in, you know, NetSuite's data center over here, and like the applications are really everywhere.

The users are everywhere. The world's totally changed. Uh, it's cool that to have a technology that meets our customers where they are, we understand that people have on-prem, we understand that they have cloud, we understand that they have SaaS applications, and, and so we're meeting them where we address it.

I get to do that internally. So my job is quite exciting, really, um, in, and it's not that I don't go tap somebody on the shoulder, uh, that works on our product, but I do file a ticket first. You know, where they live, I guess.

Yeah, I Do. I can still it. I'm like, let's just say I can nudge things to make the move.

Yeah, Absolutely. But calling To take really nice email account you've got there, shame, if something happened to it, would you fix my problem? So, you know, when I look at cloud, what drives cloud transformation, what drives cloud transformation?

So we get a lot of app modernization, driving cloud transformation, right? In, in the old days, we used to just lift and shift our stuff from a private data center up to the cloud. That worked for all of six.

It didn't even work for six months. We've quickly realized that that wasn't taking advantage of the cloud. And ever since then, we've been on this quest of transformation by app modernization.

We, we are gonna, you know, micro thread, multi-thread, our apps, uh, microservice our apps, cloud data, modernize our applications to take advantage of the cloud. And by and large, we're doing that a lot. There's a lot of app modernization going on out there.

But you know, just like in the book, the goal, which of course the Phoenix project is based on, right? We just, when you clear up one bottleneck, the next bottleneck shows itself. So as we're modernizing applications now, we've run into network modernization.

What we did before doesn't work in this new cloud native modernized application world, and we need to modernize our network. The connectivity cloud is, is one example. But let's, you know, let's peel that onion back a few layers.

Mike, what do we mean when we're talking network modernization like that? I, I love that you started with applications because I think it's a really interesting way to talk about abstraction. If you think about, let's like rewind through my career for a second.

Like the, the big thing about virtualization was that the network was fast enough to become a bus, and that you could actually like, have memory and storage and compute being different places. Like memory, you were in one place, storage was another place, and yet I could run an application that way. But the abstraction in that case was just about the hardware.

Like we're abstracting the hardware away to make it more flexible so that servers don't die as easily. You know? And, and, and it was easier to modernize them that way.

If you kind of fast forward, like now to the cloud era where we put things in Amazon, what a lot of companies discovered on that journey was, oh shoot, to your point on refactoring applications, um, this application's not designed for an availability zone structure. Like, we want to do this cloud migration. We did lift and shift and oh no, this node went down in availability zone, whatever.

And like, we lost something. So that abstraction, you know, applications had to be refactored to take advantage of high availability scenarios in cloud environments, right? So the abstraction layer had to change.

Then the next phase of abstraction is serverless, where it's like, Hey, look, I don't, I just build the application at this point. I don't really need to think about, you know, the different three tier, like the database server, the API server, the web server. Like that was the abstraction layer we'd built in that world.

The networks undergone a similar thing. Um, but it's gone at a much slower rate because the innovation has had to come from the applications. The thing that serves the user from like an intent perspective.

If we think about applications as like intent engines, somebody wants to accomplish something and they use the application to accomplish something because the network was like the roads that they used to accomplish that. It was one of the later things to evolve. Like that's why we're not seeing it evolve quite as fast, because it's also expensive.

You know, on-prem networks are expensive, they're complicated, and people have a certain level of comfort with them as well. I know I did, like when I went from on-prem to full cloud, it was like, well, but I, I like my on-prem network. I have the inside, I have the outside, I have the DMZ.

These are definitions. I understand now my, my, uh, ERP applications on the cloud, you know, it's a, it's actually in someone else's data center, and I'm running it that way. And then I have these custom applications that are still behind the firewall that I'm trying to move on the other side of the firewall.

And so the dollars weren't going toward something with the network because it wasn't really the place the investment needed to go. The the key was like, how do I enable my users to accomplish things? So the network started to come later.

Now we live in this world where, where we have to think globally from like a performance perspective. And I'll, I'll give you an example of a challenge I faced in one of my roles where we had a big team in Argentina at this company, and they were like, man, Salesforce performance is really, really bad. And, and this is back in the days when I'd actually have to call the telecom and be like, Hey, you know, what's the deal?

What can I do about latency? You know, blah, blah, blah. And like, they changed something in a routing table.

I don't know why, you know, this was South America. Apparently you can change things routing tables in South America. I don't know if that's a good idea.

Really. It got better in another application got worse, right? And so that was the trade off.

And I remember thinking to myself back then, like, man, I need a way to bypass this. Like I, I need a way to, I need an abstraction layer of this. I, I don't want to call the carriers if I'm having one application performance issue in some of the part of the world, I need more flexibility.

But that flexibility would've been really expensive too. I would've had to buy pops in multiple carriers in multiple locations and do some kind of IP sec tunnel meshing to like make multiple pathways so that I can control the routing. And like, that's a drag.

It's expensive, it's hard to maintain. That's not gonna work. This transformation world that we're in now with connectivity cloud and this idea of a connectivity cloud is exactly that abstraction layer.

Why? Like, it doesn't make sense for thousands of customers around the world, thousands of companies around the world to build their own IPSec tunnels across different, you know, mesh networks and try to make this happen. SD-WAN kind of proved that that wasn't a great idea, by the way.

Like SD-WAN was Gonna say, most people think connectivity cloud is put WAN at the edge and you're good. No, I, no, It was actually pretty complicated. Yeah.

SD WAN tried to solve the problem exactly that way. Multiple carriers, multiple sites, SV PN tunnels didn't exactly deliver what they were wanting. Instead, you started seeing companies pop up where they were seeing like, Hey, we're maintaining a bunch of pops all over the world.

You can connect to the closest pop and then we will figure out how to make your traffic optimized. But even that was a bit of a drag because you were still developing like IP sectors to these individual places. And so there's this extra layer of like, I'm encrypting the data through a tunnel and then it's gonna come back through this.

And there's still choke points that, you know, so it's not the optimal thing. Um, at CloudFlare we have technology that literally, uh, decides which path is the fastest on the fly based on circuit utilization. So compared to routing protocols, in routing protocol world, you're, you're picking fastest path based on speed.

You might find a faster path, for example, that's like one hop is faster than the other op, but overall that that path is faster. But BGP only optimizes for certain types of path optimization. In our world, we're looking at like, what's the saturation point of a particular link?

And should I send you this way versus this way based on the actual traffic dynamically in this moment for this packet? And that's, that's one of the things I think is really cool about our technology is this idea that like, I can make performance really what, like great for end users. The user experience is incredible, uh, based on current conditions, which is, which is amazing.

And I've nerding out with all these telecom networking terms you mentioned, uh, zero trust before. You know that, that, that is a, a, a giant elephant to E two. Right?

Two simple words. It sounds good, like a good idea, but implementing that strategy can be a handful. How, how is what we were doing with the connectivity cloud make that easier or at least the path to get there.

I know it isn't all just the network, right? But love your thought, love to hear your thoughts on that. So it's, I like, let's, let's like reminisce for a sec about, Let, let, Hey, we're all, it's good with us.

Go ahead. Absolutely. Hey Alan, would you unplug the router?

Yeah, go ahead. Yeah, I liked it. He said BGVI.

I'll be honest with you, I got a little swell coming on my face. There we go ahead. Yeah, let's like reminisce a little bit.

You know, back in the day when, you know, like one of the, one of my gigs, I, I I, I'd set up what I called like a, a wall of garden approach where if you were trying to get to the database VLAN n and the data center, you had to VPN it, even if you're on the inside, right? Right. And so I had to sort of develop this approach.

The inside interface of the firewall had to allow VPN connections and then only the DB database admin had, right? To get to the vlan. N Like, that was, that was a way that I secured it.

Uh, you know, I, I have had this concept of the outside of the inside and then differing, you know, microsegmentation of the data center in terms of how to secure the business and meet all of our compliance requirements. VPN was how we did that back then. But it was a pain because people had to log in twice.

I logged into my laptop and then I logged into the VPN. Um, and so there's like a two step process and the end user doesn't, they shouldn't have to care. They shouldn't have to think about it.

The best security is the security that just works and is already there. Like the natural, when the natural thing to do is the secure thing to do, we're winning. We know that, that the people are gonna be most likely to follow the path to lose resistance.

They're gonna do the thing that works well for them. And, and let's, let's face it, let's not put any more steps in between them and what they're trying to accomplish, right? Like, we want them to be effective, we want them to, to work well.

So that's the design. So rewinding again, like in the old school world, we did that with IP sec, it was painful. It didn't work well.

Uh, and, and people were frustrated, increased support costs. It was, it was very hard to manage. Now let's wreck that whole paradigm too.

We start moving applications out. My application is not behind the firewall anymore. So the IP secal is kind of a waste.

In fact, the IP cell secon made it worse because someone in Georgia's VPNing, the San Francisco to get you an application in New York, and now more applications are coming from different parts of the country. And that performed like, oh no, my zoom call was terrible. Huh.

That's weird. Well, we routed all your Zoom traffic through the tunnel. Oh, man.

Well, that means that, like, I added latency 'cause my Zoom traffic went all the way to one coast just to get to another coast. Or the first person to join that meet call was, was in Japan. And so the pop that Google spun up for that meet call was in Japan.

And like nobody's latency was good for that one. You know, all these different things are happening. Um, now let's talk about how we would secure that in the modern world.

So with every challenge that we've seen in terms of the evolution of the internet and applications and SaaS, we've created opportunities as well. If the old firewall was here's some IP addresses, uh, and I'm filtering based on IP addresses and domains and blah, blah, blah, the new firewall is actually the person, the new firewall is who you are. What is the device you're on?

Where are you right now? Um, is your antivirus up to date? That's actually the new bit of information.

And being able to make contextual decisions around which applications are you allowed to get to right now based on the context. So like, I can now paint a picture with the zero trust world. I can paint the picture by having the zero trust client on their laptop.

They, they're already authenticated to it, they don't know it's running. You can see the icon, but it's, it really seamlessly disappears in the background. But now I'm evaluating your ability to access applications based on what I know about the device you're on.

You're on a company device, but you're, um, you're in an airport in, you know, some other country, right? Like, well, maybe I don't give you access to certain tiles in the single sign-on profile because I don't want you to have that. You're in a place where you probably shouldn't use that, right?

Or I wanna make sure that you're following the best path. Um, the zero trust client can decide, for example, on the local machine that like, Hey, all Zoom traffic's just gonna get routed straight to Zoom. Like, we, we don't need to route this through a tunnel because it's not gonna be any faster.

In the case of our global network with all the pops that we have, our, our zero trust client could decide that it's faster to go through the, through our connectivity cloud, right? So like the best, the best option wins the most performance options wins. But also the, the context of like, what security outcome am I trying to drive?

Also wins. Like, hey, this, you know, this is sensitive data traffic, we're hitting our dashboard. This needs to always go through the private network and never go through any kind of unsecured channel.

So zero trust is a way of taking who someone is and the information about where they're right now and applying that to what kind of access that they need to have while also giving them performance enhancements. And by making the decision on the laptop or on the, the nearest edge, instead of like somewhere in a central firewall, the performance is naturally better. Like you're making the decision fast, you're protecting the user more quickly, And you've shifted it from that firewall from going back to headquarters to, you know, a basically intelligent app that knows what can take those rules, those policies, and also, you know, these costs routing and what's the best path there.

But, but really that's the whole point of this is we shouldn't have to take anything back. Yeah. To the central, to, to the land, to the, you know, to the big honk and box back there or whatever, or VPN concentrator, Right?

That's the whole point of having an edge and, and doing all the, I mean, you know, we, we wanna be done with that. Um, here's a worry I have though, Mike, and I'll ask you directly, there are only a handful of companies in the world I think that can provide this kind of solution, right? CloudFlare being one of them is that it's a great barrier to entry if you're a shareholder, right?

Um, but is, is that putting all our eggs in in one basket kind of thing? Do we need, like how do we, do we need more modernization as part of that modernization to have a broader set of options? Hard, hard question.

It is a hard question. And I think, let's reminisce again. Okay.

So, you know, back, but going back to the days when people moved their workloads to Amazon, right? There's a lot of trust that had to go into that. Yes.

That massive amount of trust and Amazon learned on the fly. Uh, I'll never forget the first time somebody pointed out Amazon EC2 to me, I spun up an instance and I did some network scanning on it, and I was like, this is terrifying. I could compromise this instance pretty fast because it spun up with a public IP address.

It was completely unprotected when EC2 first launched. It was like, whoa, who is? And so my boss had asked me back then, he was like, alright, so what do you think?

And I was like, now is not the right time, but watch out. Like this is gonna be a big deal. We had to trust these cloud providers over time to like get better at protecting things.

But we still took the risk of siloing. Like when you were in AWS's infrastructure, you're in their infrastructure. You use their terminology, you use the tools they give you.

I mean, let's contrast that with a second before that, that that model, we, we, we all don't like, of like bringing everything into a VPN concentrator, your CEO, right? Like if you h in office, why did people do that? Well, I, I probably bought some product that's sniffing traffic that can decrypt it and help me understand threat analysis or whatever the reason companies felt safe bringing all the traffic home was that like, I can inspect it.

I can try to figure out if something weird's going on, and I, and I can work with it that way. But that didn't really work because the cost was performance. The cost was like, is anybody really looking at that intel?

Um, how up to date is that intel? And, and, you know, in the security space, these type of threat products change constantly. Like the security landscape is constantly changing.

So I don't think there was ever really much of an advantage to that IPSec model where you bring everything in into your house and you inspect all the traffic. But then when we moved to Amazon, it was like, wait, where's my packet inspection? Like, how do I know what's going on?

So I would say, first of all, to, to start to answer the question is like, we've been trusting other companies that have silos for years. GCP has its own silo. Oracle Cloud has its own silo.

You know, Azure has its own silo, and they're incompatible silos. Um, the only compatibility layer they have is the open standard of IPSec. They're like, we can talk over something that works anywhere else, but it really doesn't give us any advantages.

So now zooming out for a second with companies that are providing this, this like glue that stitches all these different clouds together, and they're only being a handful of them. It's no less risky than it ever was to make the first leap of migration. Um, but the performance has to be worth it.

And so I think nobody wants to employ an army of network engineers to try to keep a thousands of psec tunnels online, um, to maintain this in-house and build some weird Goldberg approach, especially when the cost of doing this through provi through providers that are making this their core business is actually really, really low. The trust factor is no, not much different than the old trust factor used to be like, I have to trust somebody or else I can't do business. Um, but I I would say that because we bet the farm on this, this is what we do that makes us accountable.

Yeah. Like we are by nature accountable. And, and one of the things that I love about CloudFlare is how we are accountable in ways that are, that are responsible, like Project Galileo, where we give away services to, to people who can't defend themselves so that they get all the protection of our cloud without connectivity, cloud without having to pay for it to make sure that their voice isn't lost and that someone can't decide to take their voice out.

Um, we take this job very seriously and I think it, it is about following, following the intent. Like, you know, what, what, what do you do with this? Like, we, we really do believe in building a better internet.

And, uh, I mean, that's critical, but to your point, there's only a handful of companies that are gonna be able to compete in this kind of space because the innovation is blazing fast. Uh, and, and really's something you want to get onto. And I, and I thought that the po the title of this was really fascinating to me on the transformation bit, because usually in my world, when you talk about transformation, it's like business process transformation.

You know, can I take some antiquated process and turn it into a digital process? But the network transformation's different because now it's more like treating Earth is is a global network instead of my locations on earth. Yeah.

As, as my individual networks. And I think that's where the, the paradigm shifts starting to come. Agreed.

Agreed. Look, the, you know, this is a, this is the complexity of, of the, of the technology that we use today, as I mentioned in the beginning, right? Sprinkle a little AI and really complicate things.

It's only going to continue to, to become more complex over time. LA maybe we could simplify what an end user's use, you know, it's easy for them to use. But behind that curtain, man, it, it, it's complicated.

I, I wanted to talk a little bit, and this is so a topic we haven't brought up on the last great cloud transformation, which is, look, whether you use AWS or Google or Microsoft or Oracle or any combination thereof, really the more the merrier as far as we're concerned here in terms of the connectivity cloud, right? So there there is no, you know, so early on, you know, reminiscing early on, if you were AWS you were AWS, right? You were all in.

The only thing we can contemplate was a hybrid cloud where maybe I'd keep some of my stuff back in my own data center and some on the public cloud. But of course, in today's world, we've, we've realized that's probably not as realistic as I go to whichever public cloud is, right? For my particular, yeah.

For this particular use case. May have other use cases here, use cases there. And I do need something that kind of buys 'em, brings 'em together.

Um, I you, you know, you've been in this from the get go. When did you realize that this multi-cloud, because it was, I it, I'll be honest, it surprised me. I didn't see it coming.

When did you realize that multi-cloud was gonna become sort of the way, the dominant way, the preferred method? Probably I was thinking back to like 2012 when I worked for a, a VoIP startup and we were using, we were OnPrem and we were using a, um, Amazon to develop VoIP at the edge on their side for customers. Like how would VoIP work in an a AWS context?

And I was thinking like, man, this is a lot of eggs in one basket. Uh, and with, you know, Google's no slouch at cloud and they were talking about cloud, but it wasn't as mature yet. And Amazon had this incredible explosion of Legos, like, because let's face it, they took open source products and productize them as services, right?

Yep. So you just take open source software, productizing services, they're cranking out Legos as fast as you can. It's like all of a sudden elastic search is a Lego that you can just run MySQL with.

Multi-site replication is something you can just run. Like they, they took the stack of the three tier web architecture and sort of made it a service, which is really interesting. And I was like, so initially I was worried about like, God, I hope somebody competes with 'em because it's, they're, they're, they're really far ahead.

They, their work with Netflix pushed their envelope really hard. Like they, I think Netflix was one of the biggest customers that pushed to the edge and to the limit and forced 'em to rethink things. And I was watching Google come up and with less excitement, I was watching Azure come up and I was like, well, at least multi-cloud has to probably exist.

And I was thinking Azure adopters will probably be p people that feel safe with Microsoft, with, they have a lot of Microsoft applications, and it will just naturally make sense for them. And then Google will be the, the other people that are like, just not just not Amazon or I need another cloud strategy, but like, I've been happy to see Google come up and really own it and make, you know, a great cloud product that has a lot more Legos and a lot more connectivity. They've got a good product going, Azure's doing a great job as well of making it easy for their customers to do business on the cloud and have options.

But we're seeing another move now back to colo and back to some on-prem things where companies are realizing that, you know what things, it's way cheaper for me to own the metal. It's way cheaper for me to run it myself, and I'm gonna move this workload. Part of my initial thing with, when I, when I go back for a second for like, oh my gosh, I hope there's competitors.

It's because I was like, man, this is a lot of eggs in one basket, and they can start to control our margins. So like, if I give Amazon too much business, they have too much control over my margins and I don't like that. But moving workloads is not trivial either.

And so my, my fear on multi-cloud early on was like, everybody will need a multi-cloud strategy, but it will be optimized towards maintaining leverage. I need to maintain leverage, and that leverage has to be material. I need to be able to act on it or else it's not really leverage, right?

All the while watching cloud providers try to compete with each other while also trying to escape commoditization, like commoditization, you know? Yeah. Instantly are gonna go down.

Value added services are going to go up it. To think about it in a less technical context, I think about baby carrots, which now you're probably going like, what the hell, Mike? Where where are you going?

But seriously, you know, farmers growing carrots make very little money on carrots. If I sell them raw in the store. All a baby carrot is, is a big carrot that's been chopped into little pieces and skinned like that's a baby carrot.

But that value added product actually goes for more money. Cloud providers do the same thing. They take something like, Amazon's a master of this.

Take an open source product, run it as a service charge way more than it costs you to run it value added service. Like they're nailing it. But me as the buyer, I need some control.

I need to be able to control my cost. And so a multi-cloud strategy is part of what I need to do that because I have to understand like the nuances between, you know, provider A and provider B and my applications and what those needs are. And so any multi-cloud strategy has to be centered around what am I trying to accomplish and what kind of continu business continuity do I need to maintain?

So yeah, it's, it's a fascinating world that we live in, but the, the multi-cloud thing had to happen because in a world where there's only one player, they can, they, they ultimately wouldn't be giving people any kind of choice. Like, it, it's too expensive to run with just one player. Like they really control the cost.

And I, I already think it's really expensive, um, because people leave workloads running, for example, you know, always you're, you're you're trying to figure out like, why is it I call 'em zombies? Like somebody leaves zombie workloads running. You're just like, man, the meter's running, like nobody's using this thing.

Well, yeah, we rack it up to dollar To manage. Yeah. Like I, I think multi-cloud is hard to manage too, but it's also inevitable.

We have to distribute our risk. We have to distribute our workloads and make sure we maintain leverage and negotiations. So multi-cloud was natural, but it took a long time to get here.

'cause keep in mind, I was thinking about this in 2012, and like, you really couldn't have a true multi-cloud strategy in 2012. Even today, it's pretty hard to have one because workloads aren't exactly portable. Like there's some, there's some changes in that world, but they're not portable yet.

No, I I, I'm sorry. Go ahead, Mitch. So Many of us is, I was just gonna say, so many of us have kind of backed into it right?

Through m and a activities. Yeah. You know, where this cloud now, There's a lot of that Pre cloud and you gotta, you know, what do you do to try to make sense of it just to operate it effectively, more or less, get to a point where that's part of your go forward strategy.

And what workloads can you distribute across those or move across those clouds? Not, not a simple question. I, to me it's more, you know, a thing I learned as I was growing up and, and got older was it's not the man, it's the tool and it's the right tool for the job.

I think for particular jobs, there are cloud providers as well as other options, right? My own colo or what have you, my own data center that are the right tool for the job. And I think the job of today's CIOs and, and architects is to figure out what's the right tool for this job?

What's the right domicile for this job? How do I use the connectivity cloud to glue that all together and make it look and appear and act as one contiguous infrastructure, but still use the right tool for the job? And I, I, I think that's what does it, And, and it kind of goes back to the, to sort of ideal state of what a security tool would do, which is like, allow, I'll please allow me to maintain a policy and a posture consistently.

Right? Security Cloud is about that. Like, we have the same players, we have users, we have services, we have servers, we have applications, we have all these different things, but like, allow the policies to be uniformly applied and allow me to prove that I know what's going on.

Agreed. Agreed. Guys, this has been a tremendous conversation.

I, you know, we went far off, we started with better connectivity and security through network modernization and we discussed a lot of that, but we dis, we reminisced a lot, as Mike would say. And, uh, we, it was good doing that. I look forward to continuing this line of conversation in future episodes of the last great tra last great cloud transformation, Mitchell, I think our next one is a live round table, isn't it?

I believe so. Yep. Yeah, we, we just definitely one coming up.

If You're watching this at home, check it out. Make sure you register for the next live one, because I'm sure you've got questions. I can't promise Mike's gonna be there.

He's, he's got a bit of a job to do when he's not doing this. But if you've got questions around the things we're talking about today, we invite you to participate in there. Many thanks Mike to you and CloudFlare for, for participating and co-producing this with us.

It's, these are the kinds of conversations that people like us enjoy. We could talk all day about. Right.

Good stuff. Really flew by. I'm happy to join you anytime, but I had a great time talking to you today.

Absolutely. Well, we'll make sure we'll get you back here. Get don't you worry.

Um, Mitch, I didn't get a chance to introduce you, you jumped right in, but why don't you take the last word out then. You know, I, I, I loved, I loved the walk back, you know, looking at kind of how we got to where we are, right? 'cause that informs where we go forward and there's so much, what, what's really changed is, you said it, Mike, going from points on the earth to the earth is my cloud, right?

That's my location. And thinking about, you know, don't use your points of presence that you know about as your limitation. Just like, don't use your, you know, hauling traffic back to the VV concentrator or the center of the network, either.

That's, it's a different paradigm. It's a distributed processing network and, uh, there's a lot more things we could do with it. So it's an exciting future.

We appreciate you, Mike, sharing your, your experience with it as well. Alrighty. All right.

On behalf of Techstrong and CloudFlare, thanks for joining us today. We'll be back with another show soon. Until then, everyone, good luck.

Take care. Hey, uh, welcome to my skill obsession on from siloed metrics to ai, augmented continuous security insights. I wish to thank people CERT and Techstrong learning program committees for allowing me the opportunity to speak to you today.

Um, if you don't know me, my name's Mark Horn Beak. I am CEO and principal consultant. I have a little boutique consulting firm called Engineering DevOps Consulting.

And as your name implies, you can see what I consult with. I'm also the author of some books, for example, the Engineering DevOps book. And, uh, recent title just published two months ago called Continuous Testing, quality Security and Feedback.

I'm also a member of I-E-E-E-A lifetime member. And, um, I'm a member of the Deming Institute, the, and the Value Stream Management Consortium. I'm also an ambassador for People Cert and the DevOps Institute.

I have been a principal consultant for more than 90 different continuous engineering, uh, DevOps, DevSecOps and SRE transformations, mostly with very large organizations, both, um, public and, uh, enterprise and, uh, or institutions as well. I literally just celebrated my 50th year of my career in September of this year. So I guess I'm one of the old guys.

That's why they call me DevOps the gray, I suppose. Uh, so since publishing engineering DevOps five years ago, I've been pointing out that in an era of escalating cyber threats, and interestingly, these threats continue to escalate over this time. The traditional separation between DevSecOps and SecOps metrics is leaving organizations vulnerable, siloed approaches failed to provide cohesive insights needed to detect vulnerabilities early and to respond effectively to incidents in production.

So emerging technologies like generative AI and machine learning offer transformative potential to bridge these gaps, enabling the creation of intelligent continuous security metrics that adapt and learn in real time across the, uh, development and production boundaries. Included this session will explore how combining DevSecOps and SecOps metrics with AI augmented solutions can redefine security management. We'll examine three real world security events where traditional metrics failed, and to demonstrate how AI and ML could have delivered predictive insights faster, uh, faster incident responses, enhanced vulnerability detection.

And you should get from this some level of knowledge about how to apply AI and machine learning to build smarter unified security insights to safeguard against these more sophisticated threats. Uh, one item to note, I did promise in case you guys, uh, came through my LinkedIn, that anyone that attends this session in person, I'm quite happy to send you a free copy of my most recent book, an ebook copy, uh, continuous testing, quality security, and feedback. com.

Okay, let's, uh, get started here. So there are several goals in the presentation. First of all, to understand what is continuous security itself and the current state of siloed DevSecOps and SecOps.

'cause that's fundamental to understanding the rest of this. Uh, the second is really to explore problems with silos of DevSecOps and SecOps metrics in particular, and then identify AI applications for unified continuous security insights, which is more than just metrics implementing ai, augmented, continuous security insights. I'll talk about how we can go about implementing these things, and I'll end up with a brief summary of the some key takeaways that help you get started on your own journey if you wanna actually go ahead and, you know, implement these AI augmented continuous security insights.

Okay, so let's, first of all with the first topic, understand what is continuous security and really the current state of siloed DevSecOps and SecOps. Uh, so there are really stark differences between DevSecOps and SecOps and the challenges they face due to their cultural as well as operational silos. DevSecOps prioritizes rapid software delivery focusing on things like CICD automation, while SecOps emphasizes stability, risk, and compliance with focusing on monitoring, detection and incident response and production environments.

One of the curious things about DevSecOps that I think some people at least don't seem to realize is even though, you know, SecOps is in the name DevSecOps, there's really not a whole lot of, you know, in, in information within DevSecOps practice themselves about what you should do with security after deployment to production. And that's where SecOps comes into play. So that's, uh, sometimes not understood by people.

It's a little, uh, interesting. The lack of a cohesive security strategy across these teams and boundaries is often causing, you know, misaligned goals, fragmented tools, and in general measures that don't really overlap very well or don't integrate very well. So this disconnect is further exacerbated by legacy structures, insufficient training, and the slow adoption of integrated security tools.

I mean, honestly, I will sort of summarize a lot of that and just say, you know, the complexity of it all. And that's where, again, AI can help to try to deal with the complexity of some people already complaining about the complexity of DevSecOps alone or SecOps alone. So, oh my goodness, if we start integrating these things gonna be more complex.

So you, you know, one could argue they can't even really do what I'm talking about is continuous security unless you have the help from AI tools. So for organizations to truly secure their environments, we need to bring these teams together, aligning their tools, data communication strategies, under one, you know, cohesive security framework. And of course, that's what the next slide talks about.

Uh, AI assisted continuous security focused on applying AI augmented, uh, security practices across the entire software development lifecycle in production operations. So in DevSecOps, the goal is to prevent vulnerabilities during planning engineering and in the CICD pipelines, ensuring that security is integrated from the start. But once you move code into, you know, production with SecOps, the focus shifts to defending against exploits and attacks on the production environments.

What makes AI augmented continuous security powerful is its ability to provide realtime threat detection, automated security testing, and a seamless integration of security measures across both development and operations. So this assures that we progress from development to production and security remains a constant and a, you know, proactive element of, of the work. So let's compare, you know, the traditional approaches of DevSecOps and SecOps with ai, augmented continuous security, and in DevSecOps the focus on shifting security left, integrating security measures into development and the pipelines and ensuring vulnerabilities are caught early SecOps, on the other hand, is concerned with product in production security, focusing on monitoring and protecting live systems from exploitation.

While I ai, augmented continuous security goes a step further by applying end-to-end security practices, continuously securing every phase from development through the production by leveraging AI and machine learning. The key advantage of using AI is the ability to reduce complexity, lower costs, minimize resource requirements, and, and, uh, allowing organizations to enhance security coverage while maintaining efficiency. In fact, you could almost say that it makes it feasible without AI is pretty tough.

Uh, over the last five years, we've seen a significant increase in very real world impacts of security breaches. For example, ransomware payments surged 171% while, uh, cybersecurity insurance premiums have increased by 96%. So a lot of increases in costs there.

The cost of forensic investigations now reached millions of dollars per breach with organizations facing lawsuits, reputational damage, and business losses, often for months, uh, after the event, compliance penalties have also risen as regulatory scrutiny intensifies, and long-term organization disruptions have become a reality. But these trends demonstrate that organizations really need a proactive, you know, AI augmented continuous security approach to prevent costly breaches and minimize damage. By adopting AI-driven security practices, organizations can stay ahead of evolving threats and reduce, you know, the financial, legal and reputational risks.

So let's explore the problems with siloed DevSecOps and, um, SecOps metrics. Let's look at the, um, in DevSecOps, the focus is on shifting left security, left integrating security measures into the pipelines. As we said, ensuring vulnerabilities are caught early.

These metrics are primarily inward focused, reporting the results of security scanners and tasks of software that is transiting through the CICD pipeline. SecOps on the other hand, is concerned with production security defense focusing on monitoring and protecting live systems from external threats and exploitations. Uh, despite the concepts of collaboration, which are certainly, you know, uh, espoused by the dev SecOps and SecOps communities, uh, this in reality, uh, continues to be a gap in many organizations.

There's a lack of co co, uh, correlation between development vulnerabilities and runtime threats and missed patterns and complex attack scenarios due to the fragmented nature of the data. When we examine some real world breaches, such as the SolarWinds supply chain attack and the log four J vulnerability and the Equifax breach, uh, that we've seen recently, we see that many of these incidents occurred due to gaps in both DevSecOps and SecOps practices. In the SolarWinds breach, for example, attackers exploited weaknesses in the software supply chain.

If AI, augmented continuous security had been applied, insights from continuous testing and patching could have identified the te the tampering much earlier for the log four J incident, AI augmented tools could have flagged vulnerable versions of the library and automatically patched systems. As soon as the vulnerability was disclosed, uh, the Equifax, uh, breach highlighted the importance of continuous monitoring with AI tools could have provided ongoing scans and threat detection that would've alerted teams to the on unpatched vulnerability. In all cases, ai augmented continuous security integrates both DevSecOps and SecOps practices enabling continuous realtime protection against emerging threats, you know, across the lifecycle.

And there are plenty of other examples on the slide that we don't have time to talk about, but in each case, you can, uh, look at them and understand how continuous security with AI support could have helped. There are several environments where AI, augmented continuous security becomes essential. Large enterprises where DevSecOps and SecOps teams often operate in silos, uh, AI enables automated collaboration and coordination ensuring security is embedded across both development and production.

In cases where software suppliers are separated from their customers, ai augmented security enables continuous threat monitoring, ensuring that the software is secure even as it integrates with the customer's environment. Where government institutions and military applications where sensitive information is at stake, AI can manage continuous compliance checks, real-time threat detection and security policy enforcement and network infrastructure situations where software manufacturers a disconnect from the network system operators. AI ensures that both software and the network are secured in tandem and in industries like finance, healthcare, and critical infrastructure where security breaches can have catastrophic consequences.

Ai, augmented continuous security provides the continuous protection needed to meet regulatory requirements and defend against every evolving threats. So let's look at, um, AI applications for continuous insights. Generative AI and machine learning are revolutionizing, uh, security elevation by significantly reducing the manual effort required for tasks like threat detection, vulnerability management compliance checks.

First of all, gen AI can accelerate tasks to analyze vast amounts of data and generate meaningful insights, helping identify potential security threats in real time. Uh, for example, automated complex network patterns and user behavior that can drive detection of anomalies that might indicate a security breach before it even happens. Uh, secondly, tools augmented with machine learning applications driven by ai.

Augmented task automation improves vulnerability scanning by using algorithm, prioritizing categorizing the risk based on, you know, uh, based on their potential impact. This ensures that the most critical threats are addressed, first, reducing the chances of oversight. And altogether, uh, gen AI and machine learning augmentation facilitate more intelligent automated solutions.

Fundamentally, AI transforms the way compliance is managed by automating what has traditionally been a very manual and resource intensive process. First of all, AI can continuously monitor systems and application for compliance with regulatory frameworks and security standards. Instead of waiting for periodic audits or manually checking adherence policies, AI ensures compliance in real time.

AI can reduce the manual workload involved in compliance checks and AI's ability to quickly assess and adapt to changes and regulations ensures that compliance remains a continuous process, not a reactive one. AI can also automate threat detection by continuously, uh, analyzing vast amounts of data from across your systems in real time. Using machine learning, AI can identify unusual patterns of behaviors that indicate potential threats or vulnerabilities.

Uh, this enhances speed and accuracy. Once the threat's detected, AI can automatically initiate mitigation steps. And ultimately, AI automation ensures that your systems are continuously monitored with real-time identification or response as well reducing the risk of damage.

AI can also significantly improve vulnerability management by helping automate processes from detection to remediation, identify vulnerabilities faster by continuously scanning code infrastructure and systems. Using, for example, AI agents. It, uh, analyzes vast amounts of data, as we said before, uh, including known vulnerability databases.

And using machine learning can detect potential weaknesses. Once vulnerabilities are identified, AI can automatically prioritize them based on risk, and finally, even automate the patching process itself. Uh, three types of continuous security insights are important to help understand the progress of the transformations, the effectiveness of the solution, and the impact on the business mission.

To understand the progress of AI augmented continuous security transformation efforts, we look at the percentage of automated security checks and CICD pipelines and compare vulnerabilities detected pre-production versus post-production, things like meantime to detect, as well as DevSecOps, SecOps collaboration metrics like joint incident response paths. Uh, as far as, um, in effectiveness insights, these are derived from improvements to things like meantime to remediate reduction in security incidents, false alerts, compliance and costs, metrics and insights, uh, business mission insights such as downtime due to security breaches and security spending as a percentage of IT budgets are critical to understand the overall effectiveness. So these metrics are important to demonstrate how AI augmented security improves, uh, security outcomes and business performance.

So let's look at how you can implement AI enhanced continuous security insights. Leadership is where you start, right? Leadership sets the tone for the whole security culture.

Prioritizing security is in the decision making processes, resource allocation, communication in general leader, set the tone for the entire organization and champion security as a core value and not just a checkbox. Empowering teams to take ownership, providing continuous security education and awareness, or at least budgeting for that collab. Uh, supporting collaboration between development, operational security teams, uh, establishing security policies and metrics, prioritizing, encouraging a shift left mentality for trying to identify security concerns early, both on the production side and the development side, and building a security of accountability and communication.

Just some of the ways that, you know, the importance of, um, leaders play in this whole process. They'll start with leadership. Basically.

AI assisted value stream engineering is a game changer because it identifies both efficiency and security by automating key processes and optimizing workflows at a layer above the CICD pipelines and in production monitors. And that's the key, right? You're not looking typically at just an individual CICD pipeline.

When you're looking at continuous security across all of these environments, you need to be able to aggregate the data across the different environments. So as organizations scale and threats evolve, traditional manual approaches struggle to keep up as well as traditional, you know, monitoring, uh, approaches struggle to keep up. So AI helps overcome these challenges by making security metrics and insights at the next level.

So, ai, augmented virtual, uh, value stream engineering streamlines process by automating repetitive monitoring and analysis tasks that would traditionally be very manual and time consuming. This is actually a short version of my blueprint that illustrates how to use AI for front end, uh, and end-to-end value stream engineering transformations, including how you can establish observability metrics and analysis for insights. The very first step is to use ai, uh, to generate standard templates and artifacts that are used in different sections of the value stream.

And then those templates include things like codified standards for specifications, processes and output artifacts. And these templates and artifacts are then version managed so they can evolve over time. As the organization continues to improve its practices across the end-to-end value stream, then people trained in the use of generative AI generate standard compliant code.

And ai augmented tools are used to orchestrate and, and automate security tasks across the DevSecOps. Value stream results are generated from ai, augmented observability tools. Results in analysis tools are processed by people with, you know, with assistance of the generative AI tools.

Uh, basically this creates a closed loop in which AI is continuously, you know, directed, controlled and approved at every step. Uh, ultimately where human users are, are still in control, but trained and, uh, reciprocally, you know, help, uh, what they're doing and help each other. The AI tool sets are used at every stage in the value stream, as well as in combination with that generative AI help of automation.

So this slide provides a prescriptive guidance, and again, very high level, uh, but give you an idea the major steps. First of all, take an inventory and and assess where you are, what are your gaps in the current metrics? And you're looking at, uh, DevSecOps across SecOps.

Adopt AI tools. Decide what tools you're gonna use for automation. Things like chat, GBT or Bard or other customized ML models, uh, for both the DevSecOps side of the SecOps side.

Try to get agreement on what those are gonna use. Then train the models using historical data, both predictive and generative AI systems can be used to that. Automate responses to implement AI driven playbooks and reduce the manual interventions.

So finally, let's talk about key takeaways. There are several takeaways from my talk. If you summarize the whole talk in just a few bullets.

Essentially, ai, augmented automation of threat detection, vulnerability management and compliance reduces manual efforts and enhances real time end-to-end security responses. Ai, augmented continued security transforms, siloed DevSecOps and SecOps reactive metrics to more unified proactive insights by predicting lifecycle vulnerabilities and mitigating risks and gaps before they can cause harm. And, uh, key metrics such as reduced incident response times faster deployments, enhanced compliance demonstrates the success of AI and improving security and efficiency.

Uh, bottom line call to action if you want to evaluate your current DevSecOps and SecOps metrics and augment it, you know, a unified set of insights with AI towards automating, uh, with tools and automated practices using ai. So that's, uh, basically my talk. And, you know, I would encourage you to learn more about this topic.

You're to say you're welcome to pick up a copy of my book. com. I will gladly send you an e-copy of the book and, uh, I wish you the best on the rest of your day and your conference.

Thank you for your attention. I appreciate it. Hey everybody, I'm Mike Vard.

We've got a DevSecOps Paradox, some patch management progress, and maybe the conversation about cloud computing alternatives, whether they're gaining traction or not. You're watching Text Gang, we'll be back in a middle. All right, 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. And a slightly lower climate maybe or you know, cold, but desert climate, I'm not entirely sure, but Reese 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 week. Cold.

Pardon? Austin, I don't know if you know, we've got this big freeze coming in 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 that they've been tracking this thing for 15 years now. So Mitch is 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 indivi, 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 plus 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, its 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, it, uh, 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 they're kind of two parts of a bigger, bigger picture. Tracy, what's your take on this? Do developers just don't want no stinking training?

'cause they're basically in the hands-on, 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 unlimited 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 GI 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.

Lenox Foundation has a free course if you wanna 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 this developer side. We have to think, we've had, security is a continuing, right.

Continuous processes 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, that's gotta Continually be alright. Yeah. Otherwise we're making the same kind of way.

We used to do security and networks of, 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, 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 on, or even developers ever been punished for going too fast? Because I feel like a lot of the shift 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 hit. 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 and 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 derive 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 of 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 m 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, 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 SBUs, which I am totally for it, you have to have a s 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. That'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 if, 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, then I'm just giving people the 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 Tracy's point as well, I, I haven't given this talk in a while, but I used to give a 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 their 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 PE teams should be thinking in this, in this way with, you know, adding s bombs, 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 it, it, 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 those 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 seen, we'll see, right?

I think some people will include it. But to what end? I think we will, in 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 two NIS two, not nist.

Um, so there are a number of kind of regulat regulations that either have or 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 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 know, I wanna say, So these, these regulations like Dora on are seem 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 mo shifting left or 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, 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 Orillia project incubating at the Linnux Foundation, we consume the, the, you know, that 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 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 a package is 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 in into gi, but it's not useful there.

io, come and join the open source project and help us finish it. Definitely. Orus is a great, great open source option.

There's commercial tools available as 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 they 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 turns out that the cybersecurity thread 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? Management?

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, it 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 a 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, of 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, 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. And 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? Well, I'm not gonna patch it.

'cause that's their responsibility. And organizations recognize that and they've, they've gotta kind of get their act together and decide what's their process, who's gonna do it. It doesn't necessarily many 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 it goes in and that it's been applied. Guy.

Do you think people are just, you know, calculating some odds here and it's essentially, uh, gambling and they're trying to figure out, you know, what is the cost of mean 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 become more conscious Russian roulette rather than essentially, you know, unconscious or subconscious Russian ette. 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. They, 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 to kitty soccer was 10 kids running around after the ball in no particular play. That's what kitty soccer is.

Everybody goes where the ball is instead of people playing their positions. 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 costs 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 a, 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 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 SO, which is very easy.

Everybody, it's super easy, but we don't wanna touch it. So let's, 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. 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 it, 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 dev. It has a life cycle 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. I'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 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, not 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 a, you know, working on a startup to solve this exact problem.

Mm-hmm. Because I do believe it will be a primary issue. Like, but 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 may need to 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 my favorite word? The blast. Right?

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, then 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 in 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. 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 because we're afraid of the pipeline? Or is there something else that 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 a 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 patchy 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's 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 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 in that other category. And I feel like a lot of the services that we're using in the cloud are 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 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 Release 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, 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 some 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 want to 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 by 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 host 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 it kind of falls uniquely in, in the space of offering, both dedicated hosting. There'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. It's, but it, but it's a feature.

So I don't over rotate on, you know, it's not gonna change the industry. Trace what 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. 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 Circle CI 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 back end 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 an, you know, we're not a Bank of America 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 to, 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, 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 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 there, 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 per 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-sized companies kind of start looking at outside the hyperscalers? What do you think? Well, 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 know 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 and 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. I'm 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 talk 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. This is Textron tv. Hey, everyone, welcome back here to Techstrong tv.

You know, I'm really excited about this next interview. I have been since we originally scheduled this one. I want to introduce you to Frederico Munoz.

Uh, Frederico is the release lead for Kubernetes, and that is a lot in there, but let's welcome him to the show and find out a little bit about what he has to share with us today. Frederico, welcome to Text Drunk tv. It's great to have you on.

Thank you very much, Alan. Thank you for having me. So, as I mentioned, you're release lead for Kubernetes, but you know, how does one actually get to be the release lead for Kubernetes?

What does it really mean? Tell us a little bit about your journey. Yeah.

Here today. Uh, I mean, a fair question and one that I sometimes, uh, also think about it, uh, because it's, it's not something that I, I, I would think if you would ask me two years ago, uh, I would say that, that that was impossible. But, um, so I, I guess it's also tied my overall journey in technologies.

So let me just go through that a bit. Um, I've, uh, started then in technology in general with programming and everything else, um, with the rise of the, of the Linux and the free software movement, uh, around there in the late nineties perhaps. Um, so I, that was the thing that brought me in.

Um, it technology, et cetera. My actual, um, academic background, uh, is in archeology and then, and then physics. But I started with archeology.

So, um, in, in a way free software and the open source movement that, um, uh, uh, started. There was my gateway into everything around computers. Um, I, I started with as a programmer, then I moved into, um, platform and Unix system administrator.

Um, and this, uh, in a way ties with the, uh, with the rise of Kubernetes later on. Um, why, because, well then I, I, I, I, I joined, uh, IBM, where I've worked on a lot of different stuff from IOT to solution design to quantum computing. Currently, I work at the SaaS Institute as a carbon architecture lead for Europe.

But, um, the reason why this is important is because, uh, this background in Linux and Unix in general, uh, actually made, made my, um, going to Kubernetes and the entire cloud native, um, uh, landscape and ecosystem that started just around the announcement of Docker, right? We have that, uh, fundamental, um, that, uh, fundamental aspect. And then obviously Kubernetes as an orchestrator.

Um, it's built on Linux as well. So, um, I started to work more and more with, uh, with, with, with Kubernetes as a, as part of my day job. Um, and a couple of years ago, um, I've decided to just like I did when I, I, I joined the Dian Project, for example, and others to, uh, join Kubernetes as a contributor to, uh, because, uh, Kubernetes is the second largest open source, uh, project out there.

And that's what I did. So, uh, the, the, the, the more direct path to beaming, uh, be, uh, being the release lead was like two years ago, two and a half years ago when I joined, um, seek country ex comms and, and other, um, uh, communities inside Kubernetes to just help out and do my, my my part as a volunteer. Um, when you start doing that with some consistency, you then obviously meet people you trust people.

I joined, uh, the 1 25 Kubernetes release team as a shell just to learn how things, uh, were, um, were done. Um, and I was, uh, consistently than, um, a member of the following releases, 1 26, et cetera, until, uh, last release. I was nominated as a one, the 2, 1 32 release lead, much to my surprise.

But in the end, it's a result of this, uh, path, the short one that started two years ago, that's also a result of a longer, uh, I will, I'll almost say life, um, journey around the, uh, software and open source with a cloud native twist. Excellent. So you mentioned this, uh, there's a new release of Kubernetes.

32, and it's called Penelope. But you know, we were talking off camera before we started, right? When I first became aware of Kubernetes, it was actually at a DockerCon, I think, in Austin, Texas.

So not even the first DockerCon, maybe the third, second or third Docker current. And, um, you know, while the news was all about docker off to the side at one of the booths or whatever it was, I saw them demonstrating Kubernetes. 8.

And I remember, and people were so excited, right? And you gotta remember at this point, there wasn't, it hadn't been crowned the king of the orchestrators for cloud native or for containers, right? You had Docker swarm, you had rancher, Mesos.

There were, there were several different ways at looking at how to orchestrate containers. And, but yeah, the, the buzz around Kubernetes was, was palpable. com already, security Boulevard.

And I said, you know what? We shouldn't use the name Docker because they have it, uh, trademarked. Maybe we should look at containers.

I said, but everyone there is talking about this thing Kubernetes, but I don't think it's ever going to catch on. It's too hard. You famous last words.

Um, well, you what's wrong, but, uh, that's hard. Well, that was good, right? Popular Yeah.

But on popularity, yes. So, but, you know, so, but Kubernetes has, over that, I guess it's been almost 10 years, Kubernetes has grown from being the, the orchestrator for containers to really, the heart, the beating heart of, of the whole cloud native stack. And the cloud native stack today is in many ways the compute stack for, for modern architecture, right?

Whether, whether, yeah, absolutely. Whether we're, we're talking about a microservices based architecture, serverless, um, containerized. It is at the, at the heart of it.

And what I find remarkable is here we are, you know, 10 year anniversary of Kubernetes. I think it's eight years, or eight and a half years since version one. 32.

We're still in version one, right? It, it's not where you see other releases, you know, they do a ma two major releases a year with a bunch of miners. 32.

So I think it says something about the, the steadfastness and deliberation and what goes into a Kubernetes release. It's not something, you know, where we whip together a recipe for this month or this quarter. 32, Federico, talk to us about how are these releases planned?

Is it purposely, obviously it's purposely that we don't do these quickly, or, you know, by happenstance they're very well thought out. Absolutely. Talk to us a little bit about that process.

Sure. That's a, a very good question. And, Uh, just as an intro to, to that, and based on what you've, um, also mentioned, uh, there's a, an interesting timeline here, uh, as well, because, uh, Python was, um, was released in 91.

Docker was actually announced at a Python in 2013. Uh, and then, uh, in DockerCon 14, which is in, uh, 20, uh, 14, um, Kubernetes was really, was announced. That was the first announced, uh, announcement was at DockerCon in San Francisco, uh, 2014.

Um, so there's this like Python, docker, um, Kubernetes, uh, being presented in each other's conferences, which is interesting. And as you mentioned, obviously, uh, Kubernetes has this past in Google as Borg, et cetera. That's almost pre history by, by, by, by this stage.

Um, but you are right in that there were, there were many other competitors that still exist, but competitors, I wouldn't call it competitors, but other viable solutions that fall within the same space. Um, certainly it's true that in the last decades, Kubernetes has risen as, as the most common choice in terms of container orchestration, but not only it's as a core piece of the, of, of development platforms everywhere, um, and around the releases themselves. 0 release was somewhere in 2015 actually.

2, which were the ones that, uh, started, um, the now 10th anniversary of Kubernetes. 1. Uh, I think that in the last, uh, in the, in the next year, it was also, uh, one or two releases.

But, um, uh, along with, um, so as time moved, uh, there was an, an, an adoption of f more, um, well documented and streamlined and, um, uh, a structured release project, which is, uh, essentially what we use today. And what is that? So we have three, uh, Kubernetes, um, releases per year, uh, in, in, so one's, one at the start of the, of the year, another one right there in the middle.

And like 1 32, 1 at the tail end of the, of the year. Uh, which, uh, explains the, if you do the math, obviously from 2016 to now, if you add up more or less three releases per year, we get to the 1 32 number that we, that we have. Um, so the, the way that the release works, it's actually, it is interesting and, uh, it's, it's the results of a continuous improvement process.

At, at each release we do, uh, retro meetings in order to improve the documentation, the process to make things simpler and make things better for the next release team that will pick things up. Um, I will, I will point out, uh, point out that the, the people in the release team are also, uh, volunteers, which are chosen and nominated by their peers, including through a, uh, open shattering program. Um, and how does the release work?

Well, we, it, the release that we have a release lead with some release lead shadows. We have a release team that contains people that will lead specific sub teams, like communications, like release notes, like enhancements, um, et cetera. Uh, and, uh, we have more or less, as I said, three months.

There's a, a timeline that is published at the beginning of the of year, uh, of the, of the release. And, um, there's a call for enhancements. So any six special instance group, Kubernetes has several different special instance groups like, uh, seek notes, seek apps, seek network will, um, identify the enhancements, the features that they think are ready to, um, be incorporated into the specific release, either as an alpha feature, a better feature, or as a generally available feature.

Each one of these will come with some specific requirements in terms of the feature documentation, tests, um, et cetera. And, uh, the, the release proceeds with the, uh, inclusion of enhancements, a code freeze, uh, making sure documentation is there, making sure that the communications is ready, making sure that there's no bugs or regressions tackling any issues that might arise. And after that three months period, there's a, obviously during that period, there's, um, several release cuts, alpha one, alpha two, release candidate one, et cetera, until we reach the release day and there's a Kubernetes release that will incorporate all the new features that were identified and chosen by, um, the, the respective six for debt release.

Excellent. That was fantastic. 32 13, of which, you know, based upon the, the kind of background you just gave us, 13 have graduated to stable, 12 are in bed.

Yeah, exactly. 19 are still in an alpha. But if you had to pick out what are the big highlights of this release that our audience should really be looking for, give, give us your top ones.

Um, absolutely. It's a better off taste. Um, I would say that there are a couple of interesting ones.

Uh, I think that the way that dynamic resource allocation, which is, um, the, the feature and the, the, the capability that enables Kubernetes to, uh, manage things like GPUs, FPGA, so not only memory and ram, but uh, also such devices, which is very important for, uh, many different workloads, including AI related and ML related workloads. Obviously, um, in this release there's a, a, a, a new implementation, and there's also the deprecation of the old IMP implementation. And this new implementation actually plays very, plays, uh, well with the A Quest autoscaler and, um, overcomes a lot of, uh, some of the limitations that the older implementation had.

So I find this interesting because I think that this sort of workloads are, it continue to rise in importance and it shows our, our Kubernetes release, um, incorporates, um, improvements that still directly with, uh, requirements that exists in the, in the, in the, um, out there, right? So this is certainly one, um, I think that, um, there are, um, other interesting aspects as well. I think that we have, um, some good stuff around improving the resource management.

Uh, for example, we have the memory, uh, manager going, uh, ga so generally available. We also have the, some updates, some a new feature around the ability to determine, uh, resource limitations at the pod level. So creating like a shared, uh, uh, limits that can be, uh, shared by multi pods, uh, multi container pods, which I, I, I think it's, uh, very useful, uh, in, in terms of streamlining and avoiding overcommitting.

So, and a couple of them around this overall, um, improvement team on, on, on resources. Um, there's one thing that isn't specifically a, a re a, an enhancement, but I think it's fundamental to highlight here. And 1 32 is the first release that has achieved 100% conformance testing coverage.

Uh, and this was something that was done, um, during code freeze, and it was, uh, it was actually the, the PR that did this was merged, uh, live during the Kubernetes contributor summit, uh, during Q Con North America, uh, because of the relevance that it has. And why is it important? Uh, performance testing is what makes Kubernetes be Kubernetes, right?

Uh, uh, it's, it's a se series of end-to-end tests that more or less determine the, the answer that a Kubernetes platform should have. Um, we, up until, obviously when this started, uh, the coverage was, um, below 10%, it's been improving, uh, and trying to cover all the, the end points through time. And in this release, during that specific, uh, um, moment, there was 100% coverage, which means that, um, uh, the, the, the very way that the, the testing and the performance testing is done has, has reached a level of maturity that, uh, should make us all proud.

Excellent. Fred Rico, we're, we're over time already, but for people who wanna go get, there's a lot more information than we were able to cover here in 20 minutes. For people who want to get more information, what, where's the best place to go?

io/blog. Um, they have the, the Kubernetes release article there that covers them. The, the, the, the features, the main statistics around the numbers, uh, the theme, uh, as well.

Everything is there. And we have a series of, um, feature blocks coming out. Some of them have, have already been published that go into a bit more detail into some of the specifics, uh, of the new features.

For example, the, the memory management, um, aspect that I mentioned before as a specific blog entry in at Kubernetes io. Excellent. Credico, you know, people don't realize what really makes the open source world go round and round are people like you, who, you know, you don't do this for the money, obviously, it's volunteer work.

Some people luckily, you know, do get paid. We're starting to pay maintainers now. Yeah.

Which I think, you know, CNCF does. And that's a great thing because the amount of time and effort, it's really, you don't do it for the money, as I said, it's a, it's a labor of love, if you will. And, um, indeed people like you who donate so much of their time and effort into this.

Thank you. Thank you for all you do. Thank, thank you.

Thank to the team. Appreciate it. Yeah.

And we are looking forward to great things from Penelope. Thank you for being on text tv. It was a pleasure, Fred.

My pleasure. Frederico Moz Muni's, uh, release sleep Kubernetes here on Textron tv. We're gonna take a break.

We'll be back in a minute. This is Textron tv. Hey guys, thanks for thorough.

We're here with Porter Stowell, who is head of ecosystem and community for the File Coin Foundation. And we'll explain what that is in a minute, but we're talking about the rise of decentralized storage port. Welcome to Shop Michael.

Pleasure to be here. Thanks for having me. We are hearing a lot more about decentralized storage, especially in the age of, uh, Bitcoin and all those things that have come along.

But there are, um, enterprise applications for this stuff, and more people are using it. And a lot of it has to do with just, um, I guess we're trying to consume data closer to the point where it's created in a way that's cost effective, but order explain what the first, what the File Coin Foundation does, and then what are we seeing here with decentralized storage? Sure.

So, uh, first and foremost, Filecoin is the global leader in decentralized storage across the world. I think we have the, the most capacity of any other decentralized storage network. Filecoin Foundation specifically is the stewards of the network, again.

So we're an independent foundation, and we are here to make sure that, uh, the file people interacting with Filecoin have the right growth governance, uh, and o operations to make, uh, sure the project is continuously successful over a long period of time. And like, to dive into your question on, like, enter, uh, decentralized storage, it's, it's been an evolution, um, one that has taken, uh, multiple years. Uh, so Filecoin launched in May net in, uh, 2020.

So we're four years into our, our journey. Uh, and I always go back to like, I always love historical reference. Uh, and it really took, you know, AWS as an example, close to six years to really get to the AWS that people realize, well, you know, think of what they think of today.

And so, like doing new technologies hard, doing it a different way is even harder. And decentralized storage is meant to be an alternative solution to centralized storage providers such as A-W-S-G-C-P, Azure, uh, et cetera. And there's, you know, we think there's a great value proposition, uh, that's hard for people to understand.

I mean, most people in the world are still trying to understand what Bitcoin is, and it can be really difficult to go the next level on something like storage and, uh, you know, to solve the puzzle for you. There's not a lot of people who really care about archival storage. It is at the bottom of the tech stack.

Uh, on the one hand that is a nice moat for us. On the other hand, stuff to get people to pay attention to it. How big is the network and how does somebody actually in both decentralized storage, because, well, it's storage that's kind of highly distributed, right?

Yeah. So I think We're at about four exabytes of capacity right now. It's really hard to fathom how much data is an exabyte.

Uh, I, I don't have my good analogies off the top of my head, but just like a, a petabyte, it's like if you took 4,000 digital photos every day for the rest of your entire life, you probably wouldn't even get to a petabyte of data. Like, if you take all like, Netflix, like movies, it's like, there, there's, it's really hard to get to a petabyte. So we have four exabytes, which is a thousand petabytes.

One, one exabyte is a thousand petabytes of data. So that's a, it's just a lot of data. It's a lot of hardware.

And one of the fun facts is like, people don't really realize that there's, you know, besides Bitcoin, Filecoin is easily one of the most, you know, some of the most hardware investments, uh, out of any protocol out there on Web3 today. So if I build an application and I wanted to use decentralized storage as an alternative to cloud storage, are there APIs that call? How does that work?

Yeah, so, you know, again, when you're a developer, you're, you're looking for a user experience that's familiar with something you already know. So something akin to the experience you get, uh, working with S3 on AWS Uh, and so what we typically recommend in those situations is you work with a software vendor in our ecosystem. So we have all types of players in our ecosystem, those who do storage, those who do orchestration, those who do software, those who provide services to make it work.

You know, it's a very laissez-faire, niche driven economy within Filecoin. So typically what people do is they work with, uh, a software vendor, so such as Ave Scha Lighthouse, where you can get that, that user interface you're familiar with, with I all having to deal with all the complications of how do you upload data to the network. So all the complications is abstracted for you, and they're still giving you the same feature functionality, uh, value proposition alongside of ease of use.

What are the benefits of using decentralized storage versus the cloud? What is it that people get out of that, both, you know, either technically or financially? Uh, I would say that the special sauce to file coin is verifiability.

So every eight hours, uh, when your data is uploaded to the network, there is a proof that occurs that says your data on chain is still there and is in the state that you anticipate it to be. And so, like, that's, again, we're trying to go to the don't trust, verify, uh, era of, uh, building applications. So Filecoin is just doing that for your data.

It's like, don't, you don't need to trust that I have it and it's in the same state. I'm giving you a cryptographic proof every eight hours that it's exactly in the state that you left. Uh, and that, again, when you're storing data over long periods of time, has a lot of value.

So verifiability as a term, and immutability as a term, is really gaining a lot of steam in businesses because, uh, quality of data, trust of data, authenticity of data is really becoming more prominent as AI gets traction. But, you know, to put it in most simplistic terms, uh, you know, insurance or like, you take like a se security camera footage. So this is a real heavy footage.

01 seconds that is like relevant film, but you gotta store the whole thing 'cause you don't know what's relevant. So these security cameras, like they have to store all this data, it gets really expensive really fast. And not only that, they need to be able to get it in very niche cir circumstances, and they need to show that this video was uploaded for this time from this camera and hasn't been touched at all.

And that would stand up in a court of law, like you could say, I have on chain verifiability that this video has, you know, hasn't been altered in seven years since it was uploaded to the network. So you can think of like the legal ramifications, uh, when like, there's a claim against you and you're looking, you're trying to find this video footage from years ago. Uh, you know, right now it's, it's like you can't find it.

Uh, it's too expensive to hold longer term, uh, all these different things. And like, you know, the, uh, financial indus industry only saves your financial information for seven years. Uh, your medical record, your medical data is only saved for seven years, which is crazy.

So, um, again, if you had cancer eight years ago, the medical system check is not gonna know that. So they may see indicators of things that you've done in the last seven years, but they actually don't save your data. Or whether if you broke your leg in high school, uh, none of that data gets saved.

It gets thrown out. And that's not really good process. Um, and then like, you know, you think of something like your own medical records.

I want, I expect my medical records to have everything that's ever happened to me, because if I'm in a situation, I want my doctor to have full transparency of everything that's ever happened to me. Um, and again, you're, you have a couple problems you need to solve to get to that state. You know, like how do you empower someone to store their own data?

How do you make sure that the doctor has confidence that the data is accurate and authentic? So, and then how do I, uh, share that data or, you know, provide access controls on who can see it. When You mentioned archival storage, um, are we also thinking about that in the context of backup and recovery?

'cause a lot of folks are anxious about ransomware attacks and they want some pristine copy of data somewhere that they can get to. Yeah. Uh, it's a very common use case within Filecoin, and we see specific individuals coming from with web two backgrounds in disaster recovery, anti ransomware who are setting up practices and businesses selling nothing, but, uh, those types of services, uh, with a Web3 backend versus web two alternatives.

So you mentioned this Web 2 0 3, oh. Um, what types of applications are people building on this as a Web3 oh application? What exactly is that in your head?

Yeah, so, uh, so far we're doing very well with, uh, organizations that value verifiability, for example. Uh, we do very well in academia and research. Well, and you think about that they have a lot of data.

They're, you know, academia and research typically are not revenue generating operations. These are universities doing research projects. Uh, and when you're not revenue generating, uh, you're just a cost center.

So costs become extremely important. Uh, and also with, um, science, academia and research, try telling a researcher to delete some of their, their data. It, it's the equivalent of asking a parent, well, which kid would you like to orphan?

It's like, there's no, there's no right answer, no. Like, it's all important. I can't get rid of any of it.

Uh, and that's like, this is a very emotional issue for people in research, and they wanna keep all their data. So we, we typically do well in, in those organizations. I, I, I'm also seeing like new use cases, you know, I talked about medical record, so I think there's a lot of momentum there.

Uh, and how can you use decentralized storage and data protection so people can begin to take control of their own health and medical data? Uh, and how do you authenticate data along those lines so people can be empowered to have control, uh, and full control of other health data. 'cause in the US in particular, you know, if, uh, if you go from one health network to another health network, the robustness of that dataset is, could be entirely different.

I'm also seeing things like commercial real estate. Uh, you see, you may see like, well, commercial real estate, why do they need archival storage? Well, you know, not in the US particularly, but in the UK they have green mortgages.

So green mortgages, uh, are like, I'll, I'll give you a 50 basis point discount on your loan if you can prove that you're a green solution and that your, your building is maintaining a green status. So now you can put sensors in these rooms and buildings that will put, they'll store and archive that data on chain on something like Filecoin. And so now the banks issuing these green mortgages have full verifiability and provenance that, hey, this data was generated from, this sensor was stored on chain.

So if a regulator keeps coming or anyone wants to challenge that bank on the greenness of their mortgage, they have a full active, robust data set to back up c their claims. And now that allows them to put all this capital to work in a way that's beneficial to the environment in, in these particular regions. So, you know, that verifiability, you know, you're getting someone willing to pay a premium for verifiability, uh, because other, without it, you know, that the, those pools of capital for green mor mortgages would never even get put in, put into the market.

So, have we reached a point where people kinda realize, well, all right, data has value and it's more critical than ever, but now we're kind of choking on the cost of it. So they're looking at alternative approaches. Yeah.

So there's a, there's a challenge with why in decentralized storage, you know, with Bitcoin, it, it was very easy. It's very, there's a lot of great data and very pithy comments on why Bitcoin, why now. And you know, again, you can look at with Bitcoin, it's M two money supply, uh, US fiscal deficits going out of control.

These are very sticky talking points for people to say, you know what, maybe I will take 1% of my portfolio and, and put it in a dis, you know, a decentralized, uh, store value like Bitcoin now that those are some real pain points. Uh, and decentralized storage doesn't have those sticky pain points yet. I, I think it's coming, but, you know, I think storage, decentralized storage will follow a, a path, uh, of Bitcoin where the narrative was, well, if I can I put 1% of my wealth in a decentralized alternative?

And I think Filecoin is looking for the same thing. Can I take 1% of my data and put it in a decentralized alternative? Why would I do that?

Uh, again, maybe you're just piloting it versus like a GCP or AWS or maybe you have a real reason because it unlocks a use case. Or maybe you just want to take control of your data. Like in the, the medical, your, your health medical records type scenario, uh, you know, they're, they're, we're working on more compelling reasons why.

So for ma people to take it seriously, the thing is with AWS, it works great. GCP works great, uh, you know, yes, you have a risk of being de platformed or censored, but you know, that's, it's a very small portion of the population. Uh, and I think with the rise of ai, I think it's sh holding up the mirror on data proven ancy in this conversation on data ownership.

And the bet is that over the next 20 years in particular, that conversation will change. Just like people say you wanna self custody your Bitcoin, I think there's going to be more of an effort to wanting to self custody your data, whether you're an enterprise Or an INTERVI individual. All right, folks, you heard me here.

There's a lot to be said for immutable data and taking control of your data and making sure that, well, that one copy is the gold copy and nothing's been changed or messed with because, hey, AI models need some specific references, and you never know, you might have to go to court someday. And somebody's gonna say, well, how do you know that that data was the data that you expected it to be? Hey, Porter, thanks for being on the show.

Love it. Anytime, Michael. All right.

And back to you guys in the studio. Welcome back to Textron Unplugged. My name is Cassandra Chin, and today we have Yasin Beba.

Hello. Can you do a short introduction? Yes, of course.

So, hi everyone. I'm, uh, Yasin VBAs. Uh, I have a PhD in computer science, and after that, uh, I did 10 years of iOS development at Word Line.

Uh, and since two, three years ago, I'm, uh, dev Re and I'm also a teacher and also part of the Lil Android user group. So you're a part of a lot of things. So I try my best to, uh, to have the community and to spread the knowledge as much as I can.

So you said you're part of a user group? Yes. You wanna describe what that is?

Yes. So it's the lil Android user group. So it's an Android user group located in Lil, uh, it's called, is to, uh, invite speakers and organize meetups so that these speakers can share the knowledge about Android, coline or anything related to these, uh, to the Android community of Lil.

So Lil, it's a, a town in the north of France. And like, uh, how do you contribute to the user group? Yes.

So my contributions, uh, are, for example, getting contacts, uh, with speakers, uh, trying to organize the meetup, like finding the location where to organize the meetup, trying to find, uh, the funds to, uh, pay for the, for the food, for the meal after the meetup, creating the meetup page by itself, uh, like with the images, the description, and so on. You have to Create the actual page Yes, yes. On Meetup and also on Google Develop Google Developers group page.

Yeah, I think that's really cool. Yeah, it's a great experience. Yeah.

Yeah. I enjoy it so far. Uh, do you get a lot of new people when you go there?

Um, so the, so since it's a meetup, you know, we're, um, uh, we get like 10, five people, sometimes 15. Uh, it depends, you know, the day of the week, it's like, you can come whenever you want, uh, and, uh, just to sit, relax, and, and discuss. So It's really flexible and that gets nice.

Yeah. Yeah. Flexible.

Everyone is welcome. So, yeah. And then you also said you're a teacher.

Yes. Do you wanna tell me more about it? Yeah.

So, uh, actually since I was a child, I was teaching like private classes, uh, like, uh, to other, uh, students. So since I was a child, I love the, like sharing knowledge teaching, and, uh, now I'm continuing this. During my PhD I taught, um, some Linux Bash scripting.

And after that, uh, even after I joined a private company, I continued on teaching, uh, more like programming languages in general, uh, some theoretical, uh, aspects like mark of chain. But, uh, but I really enjoy teaching, sharing knowledge, discussing with students, and it also myself allows me to better understand the topics that I'm teaching and also to be a better developer and also to, uh, to renew my motivation for work. That's interesting that like, you're teaching others, but you're also learning yourself.

Yeah, indeed. Like, uh, yeah. Every year, like when I do my classes, I discuss with students, uh, I see their needs, so I adapt my lectures and they also follow like, uh, the podcasts, uh, YouTube channels and, uh, and so on and so forth to really, uh, update, get updates, and, uh, yeah, I really enjoy the, this, this activity.

How do the podcast and YouTube channels help you? Yeah, so podcasting and YouTube channels help me get up to date and also get real life, uh, feedback. Uh, so some YouTube channels like give you a concentrated update, uh, like in 10 minutes.

For example, in France, there is a YouTube channel called Dave Coffee. It's a coffee, you know, for developers. Like every day you have 10 minutes of concentrated news.

Uh, there is also like, uh, podcasts, which is, which is a longer format so that you can have, uh, more deeper, uh, understanding and more deeper discussions like syntax for j developers. In France, we have, uh, cast coders for Java, uh, news, uh, also discovered the podcast of Gonzalez, so I'm subscribed to. So yeah, that's, uh, I really enjoy listening to people talking about programming in general.

Do you recommend some of these to students? Uh, yes, of course. I recommend it.

For example, dev Cafe to my students, because like, you know, it's a short format. It's in YouTube, so it's, it speaks to them a lot. And some students come back to me like they were sharing the same news.

You know, we, we watch the same show, so like, when I share news, they, they'll tell me, oh, yeah, I heard it also in Dev cafe. And, uh, yeah, that's really pretty. You do a nice topic you can relate to.

Yeah. And do you have like a preferred programming language? Uh, so currently my preferred programming language is Kotlin.

Uh, and, uh, yeah, recently, uh, so I That's one, sorry. That's what, um, one part of conferences, uh, that I, uh, go to Kotlin conferences and also like Java conferences to share about Kotlin. Uh, so currently, like, it's really powerful, mature language and it's cross-platform and full stack.

So with Kotlin, you can write, uh, JJ you can't argue the JVM, so you can use, uh, spring Q case. You can also use Kotlin exclusive framework to develop, uh, backends, like ctor. You can also write front ends, which are cross-platform.

Uh, with the composed multi platform, you can write, it's your UI once, and it runs on, um, Android iOS desktops and the web with web assembly. So Collin runs on both iOS and Android? Yes.

I always thought that like, development for Android and iOS was a little separate. Sorry. I thought development for iOS and Android is separate.

Yeah, it's, uh, like, uh, without these kind of, uh, new frameworks, it's separate. If you want to develop Android apps, you have to download the Android SDK and use Android studio and use like, uh, compose jet pack compose. To make your UIs for iOS, you have to download code and use, um, swift and Swift UI to develop your applications.

That's Like, you don't need different UIs. No, you don't need different UIs. Yeah.

Now with compose mi platforms, uh, sorry. Compose MI platform, one UI is, uh, runs on both, uh, operating systems. Think That's really cool.

Like it runs on both now. Yeah. Uh, are there any, uh, apps which you really, you develop or you like?

Um, an app that I like in the, in the, in the store That you're working on, or, ah, like more on the development side. Okay. So on the development side, so I am not more of a mobile developer, but when I was a mobile developer, I de developed a, a drive application for a client and a mail application also.

So it's really fun to like, uh, see like the internals of these kind of apps, like coaching, you know, because drive apps, you have to be fast when as soon as you open the app, you have to see the list of files that you have on your cloud drive. And, uh, so caching is really important. It has to be smart.

So as soon as you open the app, you have to show what you have in your local cage so that you have an immediate, uh, like feedback from the application, and then you fetch the data from the server and you synchronize it. So that's really challenging in terms of algorithmics also, like, uh, it's not just like develop UIs, and so there's also like some algorithms and some optimizations to take into account. That's Really interesting, like how you have to show something to the user immediately.

Yeah. And then fetch the data later. Yeah.

That's one thing that we learn when you develop UIs. Uh, because originally I was, uh, I did mostly like backends, uh, with Spring and, uh, even, um, uh, with the called, uh, I forget its name, uh, like all the Java framework, uh, all the Java server frameworks, uh, and, um, and like, you don't think about this kind of stuff, like you just, uh, reply to requests. And so, uh, that's it.

But when you develop UIs, like a whole world of, uh, like constraints appear, for example, memory is limited, you know, in Android and iOS, when you reach certain amount of memory or app, may might get killed. Trading is very important. So the UI thread, you don't need, you don't, it's forbidden to do like, uh, time consuming stuff.

HTTP requests, for example, in Android, when you do, uh, um, an h TT P request in the main thread in the UI thread, your application will crash. Oh, Christy. So, yeah, that's, so that's, uh, there are many things, many constraints to consider.

And, uh, for example, when I started working on the drive project, like we had the application freezing from time to time. Yeah. It's because we did HTTP request or database requests locally in the main thread.

So why the main thread was busy, like fetching, uh, H TT P data fetching the database, the UI can't work anymore, can't animate, can't do anything. So you have to, uh, use threads to like, uh, delegate this task and, uh, like lighten the UI thread, you Use multiple threads to kind of spread the workload. Yeah, yeah, Yeah.

And currently there are many technologies that simplify, uh, multithreading, uh, like high, higher level APIs, like core routines. Uh, I think awai, this kind of APIs are higher level and allow to do what we call structured concurrency, which is like, uh, concurrency, but more, uh, more structured than the, like, more, with more mastery of it. Like you just launch, read and forget about them.

You can like wait for their return and so on. It's not like a bread management system. Yeah.

Okay. Do you teach a lot of this to students? Yeah, of course.

I love, uh, I love teaching this to students, uh, sharing with them, answering their questions. Uh, yeah, I really enjoy this. Are there any other tricky topics which you like teaching?

Uh, tricky topics. Um, so trading, yes. Optimizations, uh, algorithmics, like whether it is algorithmic problem when the users like, have to scratch their brain to solve it.

Uh, like, uh, I teach the Game of life Yeah. And the lecture on Game of Life. So I also really enjoy it.

It's with Python and they draw it with the pipe plots, the, the, the, the metrics. It's drawn with pipe plot. Okay.

And, uh, yeah, that's an amazing, uh, lecture because even students like it when they see like things animate and move on their own in a random manner, the patterns and so on. Yeah. So that's one lecture that I really enjoy, uh, teaching.

Is it the Game Of Life? Like a board game? Uh, so the game of life is, um, uh, a random pattern generator.

So it's not a game like, uh, where you play, it's like a simulation of, uh, of something, you know, you simulate. Um, so you, uh, you have the metrics or grid, which contains cells, and, uh, depending on the, like for each cells, it'll ch the states will change depending on the state of the surrounding cells of the neighboring cells. Okay.

So you have like, cell is alive or dead, and it switches from alive to dead, depending on the con the cells are around it. And like, uh, given the, so the game of life has certain rules. For example, if this cell is alive, it'll die if there is no more cell around it, things like that, you know?

And in the, when the program starts, you generate random, alive and dead cells, and then you run the algorithm and you see it move, it move by itself. I See. So the cells flip on their own.

Yeah. They make decisions. Yeah, they make decisions.

So they sometimes it, it gives nice patterns. Like you see like live cells moving like that. Yeah.

Or spreading like this. And then you see, you can either see some like infinite, alive, dead cells, like pattern or you can see like, uh, not moving anymore. Does it usually stop at some point?

Yeah, it depends on how it started. You, it can either stop at some point or it can either stay at the state where like some cells become alive and the neighboring become dead, and then they switch back and forth. So it never ends, you know?

I Would really love to see it. It's just the cells flipping, Okay, take a look. Uh, game of life.

And there are even like, uh, variants of variants of it, it, which make are in many, much more spectacular. Yeah. Yeah.

I think we've had a really good chat today. So thank you. Welcome.

Thank you very much. Same here. 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. Hey everyone, it's Alan Shimmel at Techstrong.

Welcome to another edition of the last Great Cloud transformation. It's no longer just my data center or my data centers, it's no longer just my cloud infrastructure, maybe over at AWS, right? Today.

I have data centers, I have multi-cloud presence, I have presence on the edge. My people do anything from anywhere at any time. We need, it's a whole new paradigm.

First of all, I want to introduce you to Mike Hamilton. Mike is the CIO at CloudFlare. Hey, Mike, welcome to the last great cloud transformation.

Thanks so much for having me. It's great to be here today. So Mike, CCIO at CloudFlare.

Man, that's a job. That's a job. It's incredible.

That's gonna be one of the most complex networks in the world. Something like 21 or whatever percent it is of the internet actually passes through your network. How do you sleep at night?

Tell, tell, tell us. I mean, thankfully, thankfully for CloudFlare, this, this is in our DNA, this is what we get outta bed in the morning to do. I'm not alone.

If I was, if I was the, the key brains behind this, I think, uh, you know, I'd be really nervous all the time. But we have incredibly smart people from our C-suite all the way to every engineer that touches every line of code that's thinking about this all the time. And, and I would really say my favorite thing about the company, in fact, is, is being clever.

We're thinking about really what the next, the next way to approach this is like, how do we, how do we define not, not just follow or, or address concerns that our customers have, but how do we create the next world? How do we create the next paradigm that really makes data secure? And it really helps companies manage this global infrastructure.

The world has changed so much. I've had the good fortune. In fact, I started my career in public sector in 1998, approximately.

And in everything was on prem back then. Uh, and my career was all on-prem through about 2011. I was fortunate, in fact, to be one of the first people to adopt virtualization.

I was a bare metal VMware guy back in like 2001, which at the time people thought I was a little bit crazy. They're like, what do you mean you're running 10 servers on one server and you know, what, how would this even work? And I'm showing them VCR controls on servers, and they're like, what?

Like, you can pause a server. What does that even mean? You know?

And then being able to move servers later was really cool. I've had the good fortune of, of having a career that had that strong foundation around data centers and virtualization. But I, I got, you know, my mind was kind of blown getting into the world where companies were being started entirely on SaaS.

You know, working in hypergrowth gave me a really good chance to say, in fact, when I, when I made that tradition in my career, I went from a startup to MuleSoft. And MuleSoft. Part of the appeal there was, they didn't have anything on-prem.

They were like, everything was in the cloud. All their business applications were not in the cloud. But that advantage was really interesting me, because I was, I was thinking, you know, from my career, I want to have a challenge that's greenfield.

Like, I've never had to do this before. Nobody's had to do this before. How do I do it?

Um, and to end up with my career now today at CloudFlare is kind of mind blowing for me. Every day when I wake up, I'm like, wow, this is such an incredible company, such an incredible time to be here, largely because we're starting to define how businesses run globally, and we're giving them a safe way to do that. So I, you know, I think the responsibility, we take that responsibility really seriously here.

And again, while I, I'm glad it doesn't all rest on my shoulders. We have a lot of smart people here, but, uh, if I were alone, I'd be way more stressed out than I am. We have a great team here.

Good for you. Hi, Mike. From, from a, uh, fellow now former C-I-O-I-I.

I, I'm with you there, brother. I understand that role. You know, one of the great things about, wait a second, Mitchell, I haven't even introduced you yet.

Well, you know, people know who I am. You don't have to ntroduce, explain. Oh, go ahead.

I'm Mitch Ashley, I'm CTO with Techstrong and VP practice lead for, uh, DevOps and software application development. Um, you know, as you, you get to consume the services that your company creates, right? As the network.

And, uh, you know, there's a lot of innovation happening in the network, programmability of the network developers, you know, moving apps into it as opposed to just edge to edge kind of connection, security, all the things that go into it today. Um, I'm just curious how, you know, you, you obviously have to kind of keep the trains running on time, but you're also looking at how do you take advantage of, you know, what the company's introducing and the customers might be using. How, how do you, how do you, what's your strategy around that?

Well, I do have someone that, that runs customer zero for me, uh, with, with my guidance and direction that that person just started about a month ago. But we are, we have been using our own product for a very long time, and it's, it's actually really natural because we have a business to run and so do our customers. And so it, I've run, I've run customer zero programs in the past, and it's generally like, I, I insist that we follow the exact same path that a customer follows.

So it's like, we have an account, we have an admin panel, we file tickets with support. You know, we don't just run to someone's queue and try to find them. Um, but then we do try to bump things and accelerate them.

And it, what I think is most incredible, and what struck me the most about CloudFlare is how our technology can really meet our customers where they are. So we have all these different ways of on-ramping technologies. Like you, you might say, Mike, I'm mostly on-prem right now, or I have some on-prem and some Amazon or some on-prem and some Google, you know, I'm not quite the multi-cloud yet, or I still have some Unix box sitting in a closet somewhere.

Um, you know, and, and I want to get this into a zero trust network. And, and our product is designed to do that. It's designed to make it easy to get your network connected.

And so it meets our customers where they are instead of asking them to change everything or, you know, hodgepodge something together into some kind of word Goldberg machine. Because I think the way the world has changed, the way that, you know, our, our, our employees are no longer at home. They expect to be able to be all over the place.

Our applications are no longer in one place. There was so much you could control back in the day of saying like, we run that application on that server and that data center. I can look at the traffic flows and control performance and blah, blah, blah.

You know, that was one thing. Now the applications like WM in Salesforce's data center on the West coast, and I'm in, you know, NetSuite's data center over here, and like, the applications are really everywhere. The users are everywhere.

The world's totally changed. Uh, it's cool that to have a technology that meets our customers where they are, we understand that people have on-prem, we understand that they have cloud, we understand that they have SaaS applications, and, and so we're meeting them where we address it. I get to do that internally.

So my job is quite exciting, really. Um, and, and it's not that I don't go tap somebody on the shoulder, uh, that works on our product, but I do file a ticket first. You know, where they live, I guess.

Yeah, I do. I can still it. I'm like, let's just say I can nudge things to make the move.

Yeah, Absolutely. But probably to take Really nice email account you've got there, shame, if something happened to it, would you fix my problem? So, you know, when I look at cloud, what drives cloud transformation, what drives cloud transformation?

So we get a lot of app modernization, driving cloud transformation, right? In, in the old days, we used to just lift and shift our stuff from a private data center up to the cloud. That worked for all of six months.

It didn't even work for six months. We've quickly realized that that wasn't taking advantage of the cloud. And ever since then, we've been on this quest of transformation by app modernization.

We, we are gonna, you know, micro thread, multi-thread, our apps, uh, microservice our apps, cloud data, modernize our applications to take advantage of the cloud. And by and large, we're doing that a lot. There's a lot of app modernization going on out there.

But, you know, just like in the book, the goal, which of course the Phoenix project is based on, right? We just, when you clear up one bottleneck, the next bottleneck shows itself. So as we're modernizing applications now, we've run into network modernization.

What we did before doesn't work in this new cloud native modernized application world, and we need to modernize our network. The connectivity cloud is, is one example. But let's, you know, let's peel that onion back a few layers.

Mike, what do we mean when we're talking network modernization like that? I, I love that you started with applications because I think it's a really interesting way to talk about abstraction. If you think about, let's like rewind through my career for a second.

Like the, the big thing about virtualization was that the network was fast enough to become a bus, and that you could actually, like, have memory and storage and compute being different places. Like memory, you were in one place, storage was another place, and yet I could run an application that way. But the abstraction in that case was just about the hardware.

Like we're abstracting the hardware away to make it more flexible so that servers don't die as easily. You know? And, and, and it was easier to modernize them that way.

If you kind of fast forward, like now to the cloud era where we put things in Amazon, what a lot of companies discovered on that journey was, oh, shoot, to your point on refactoring applications, um, this application's not designed for an availability zone structure. Like, we want to do this cloud migration. We did lift and shift and oh no, this node went down in availability zone, whatever.

And like, we lost something. So that abstraction, you know, applications had to be refactored to take advantage of high availability scenarios in cloud environments, right? So the abstraction layer had to change.

Then the next phase of abstraction is serverless, where it's like, Hey, look, I don't, I just built the application at this point. I don't really need to think about, you know, the different three tier, like the database server, the API server, the web server. Like that was the abstraction layer we'd built in that world.

The network undergone a similar thing. Um, but it's gone at a much slower rate because the innovation has had to come from the applications. The thing that serves the user from like an intent perspective.

If we think about applications as like intent engines, somebody wants to accomplish something and they use the application to accomplish something because the network was like the roads that they used to accomplish that. It was one of the later things to evolve. Like that's why we're not seeing it evolve quite as fast, because it's also expensive.

You know, on-prem networks are expensive, they're complicated, and people have a certain level of comfort with them as well. I know I did, like when I went from on-prem to full cloud, it was like, well, but I, I like my on-prem network. I have the inside, I have the outside, I have the DMZ.

These are definitions. I understand now my, my, uh, ERP applications on the cloud, you know, it's a, it's actually in someone else's data center, and I'm running it that way. And then I have these custom applications that are still behind the firewall that I'm trying to move on the other side of the firewall.

And so the dollars weren't going toward something with the network because it wasn't really the place the investment needed to go. The the key was like, how do I enable my users to accomplish things? So the network started to come later.

Now we live in this world where, where we have to think globally from like a performance perspective. And I'll, I'll give you an example of a challenge I faced in one of my roles where we had a big team in Argentina at this company, and they were like, man, Salesforce performance is really, really bad. And, and this is back in the days when I'd actually have to call the telecom and be like, Hey, you know, what's the deal?

What can I do about latency? You know, blah, blah, blah. And like, they changed something in a routing table.

I don't know why, you know, this was South America. Apparently you can change things around tables in South America. I don't know if that's a good idea.

Course got better and another application got worse, right? And so that was the trade off. And I remember, remember thinking to myself back then, like, man, I need a way to bypass this.

Like, I, I need a way to, I need an abstraction layer of this. I, I don't want to call the carriers if I'm having one application performance issue in some other part of the world, I need more flexibility. But that flexibility would've been really expensive too.

I would've had to bypass pops in multiple carriers in multiple locations and do some kind of IP sec tunnel meshing to like make multiple pathways so that I can control the routing. And like, that's a drag. It's expensive.

It's hard to maintain. That's not gonna work. This transformation world that we're in now with connectivity cloud and this idea of a connectivity cloud is exactly that abstraction layer.

Why? Like, it doesn't make sense for thousands of customers around the world, thousands of companies around the world to build their own IPSec tunnels across different, you know, mesh networks and try to make this happen. SD-WAN kind of proved that that wasn't a great idea, by the way.

Like sdwan, I Gonna say most people think connectivity cloud is put SD-WAN at the edge and you're good. No, I, no, It was actually pretty complicated. Yeah, SD WAN tried to solve the problem exactly that way.

Multiple carriers, multiple sites, SVPN tunnels didn't exactly deliver what they were wanting. Instead, you started seeing companies pop up where they were saying like, Hey, we're maintaining a bunch of pops all over the world. You can connect to the closest pop and then we'll figure out how to make your traffic optimized.

But even that was a bit of a drag because you were still developing like IP SEC tunnels to these individual places. And so there's this extra layer of like, I'm encrypting the data through a tunnel and then it's gonna come back through this. And there's still choke points, uh, that, you know, so it's not the optimal thing.

Um, at CloudFlare we have technology that literally, uh, decides which path is the fastest on the fly based on circuit utilization. So compared to routing protocols, in routing protocol world, you're, you're picking fastest path based on speed. You might find a faster path, for example, that's like one hop is faster than the other hop, but overall that that path is faster.

But BGP only optimizes for certain types of path optimization. In our world, we're looking at like, what's the saturation point of a particular link? And should I send you this way versus this way based on the actual traffic dynamically in this moment for this packet?

And that's, that's one of the things I think is really cool about our technology is this idea that like, I can make performance really what, like great for end users. The user experience is incredible, uh, based on current conditions, which is, which is amazing. And I'm nerding out with all these telecom networking terms you mentioned, uh, zero trust before.

You know that, that, that is a, a giant elephant E two, right? Two simple words. It sounds good, like a good idea, but implementing that strategy can be a handful.

H how is what you're doing with the connectivity cloud make that easier or at least the path to get there? I know it isn't all just the network, right? But love your thought.

I'd love to hear your thoughts on that. So it's, I'll like, let's, let's like reminisce for a sec about Hey, we're old. It's good with us.

Go ahead. Absolutely. Hey Allen, would you unplug the router?

Yeah, go ahead. Yeah, I liked it. He said BGPI.

I'll be honest with you, I got a little swell coming on my face. There we go. Yeah, let's like reminisce a little bit.

You know, know back in the day when, you know, like one of the, one of my gigs, I, I I, I'd set up what I called like a, a wall garden approach where if you were trying to get to the database VLAN and the data center, you had to v VP n it, even if you're on the inside, right? Right. And so I had to sort of develop this approach.

The inside interface of the firewall had to allow VPN connections and then only the DB database admin had, right? To get to the vlan. Like, that was, that was a way that I secured it.

Uh, you know, I, I had this concept of the outside and the inside and then differing, you know, microsegmentation of the data center in terms of how to secure the business and meet all of our compliance requirements. VPN was how we did that back then. But it was a pain because people had to log in twice.

I logged into my laptop and then I logged into the VPN. Um, and, and so there's like a two step process and the end user doesn't, they shouldn't have to care. They shouldn't have to think about it.

The best security is the security that just works and is already there. Like the natural, when the natural thing to do is the secure thing to do, we're winning. We know that then the people are gonna be most likely to follow the path to least resistance.

They're gonna do the thing that works well for them. And, and let's, let's face it, let's not put any more steps in between them and what they're trying to accomplish, right? Like, we want them to be effective, we want them to, to work well.

So that's the design. So rewinding again, like in the old school world, we did that with IPSec. It was painful, it didn't work well.

Uh, and, and people were frustrated. It increased support costs. It was, it was very hard to manage.

Now let's wreck that whole paradigm too. We start moving applications out. My application is not behind the firewall anymore.

So the IP secal is kind of a waste. In fact, the IP secal made it worse because someone in Georgia's VPNing, the San Francisco to get you an application in New York, and now more applications are coming from different parts of the country. And that perform like, oh no, my zoom call was terrible.

Huh. That's weird. Well, we routed all your Zoom traffic through the tunnel.

Oh, man. Well, that means that, like, I added latency 'cause my Zoom traffic went all the way to one coast just to get to another coast. Or the first person to join that meet call was, was in Japan.

And so the pop that Google spun up for that meat call was in Japan. And like nobody's latency was good for that one. You know, all these different things are happening.

Um, now let's talk about how we would secure that in the modern world. So with every challenge that we've seen in terms of the evolution of the internet and applications and SaaS, we've created opportunities as well. If the old firewall was here's some IP addresses, uh, and I'm filtering based on IP addresses and domains and blah, blah, blah, the new firewall is actually the person, the new firewall is who you are.

What is the device you're on? Where are you right now? Um, is your antivirus up to date?

That's actually the new bit of information. And being able to make contextual decisions around which applications are you allowed to get to right now based on the context. So like, I can now paint a picture with the zero trust world.

I can paint the picture by having the Zero trust client on their laptop. They, they're already authenticated to it, they don't know it's running. You can see the icon, but it's, it really seamlessly disappears in the background.

But now I'm evaluating your ability to access applications based on what I know about the device you're on. You're on a company device, but you're, um, you're in an airport in, you know, some other country, right? Like, well, maybe I don't give you access to certain tiles in the single sign-on profile because I don't want you to have that.

You're in a place where you probably shouldn't use that, right? Or I wanna make sure that you're following the best path. Um, the zero trust client can decide, for example, on the local machine that like, Hey, all Zoom traffic's just gonna get routed straight to Zoom.

Like we, we don't need to route this through a tunnel because it's not gonna be any faster. In the case of our global network with all the pops that we have, our, our zero trust client could decide that it's faster to go through the, through our connectivity cloud, right? So like the best, the best option wins the most performance options wins.

But also the, the context of like, what security outcome am I trying to drive also in it's like, hey, this, you know, this is sensitive data traffic, we're hitting our dashboard. This needs to always go through the private network and never go through any kind of unsecured channel. So zero trust is a way of taking who someone is and the information about where they're right now and applying that to what kind of access that they need to have while also giving them performance enhancements.

And by making the decision on the laptop or on the, the nearest edge, instead of like somewhere in a central firewall, the performance is naturally better. Like you're making the decision fast, you're protecting the user more quickly, And you've shifted it from that firewall from going back to headquarters to, you know, a basically intelligent app that knows what can take those rules, those policies, and also, you know, these costs routing and what's the best path there. But, but really that's the whole point of this, is we shouldn't have to take anything back.

Yeah. Mm-hmm. To the central, to, to the land, to the, you know, to the big honk and box back there or whatever, Or VPN Concentrator, right?

That's the whole point of having an edge and, and doing all that. I mean, you know, we, we wanna be done with that. Um, here's a worry I have though, Mike, and I'll ask you directly, there are only a handful of companies in the world I think, that can provide this kind of solution, right?

CloudFlare being one of 'em is that it's a great barrier to entry if you're a shareholder, right? Um, but is, is that putting all our eggs in, in one basket kind of thing? Do we need, like how do we, do we need more modernization as part of that modernization to have a broader set of options?

Hard question. It is a hard question. And I think, let's reminisce again.

Okay. So, you know, back, but going back to the days when people moved their workloads to Amazon, right? There's a lot of trust that had to go into that.

Yes. That that massive amount of trust and Amazon learned on the fly. Uh, I, I'll never forget the first time somebody pointed out Amazon EC2 to me, I spun up an instance and I did some network scanning on it, and I was like, this is terrifying.

I could compromise this instance pretty fast because he spun up with a public IP address. He was completely unprotected when EC2 first launched. It was like, whoa, who is?

And so my boss had asked me back then, he was like, alright, so what do you think? And I was like, now is not the right time, but watch out, like, this is gonna be a big deal. We had to trust these cloud providers over time to like get better at protecting things.

But we still took the risk of siloing. Like when you were in AWS's infrastructure, you're in their infrastructure. You use their terminology, you use the tools they give you.

I mean, let's contrast that with a second before that, that that model, we, we, we all don't like, of like bringing everything into A VPN concentrator, your CEO, right? Like in office. Why did people do that?

Well, I, I probably bought some product that's sniffing traffic that can decrypt it and help me understand threat analysis or whatever the reason companies felt safe bringing all the traffic home was that like, I can inspect it. I can try to figure out if something weird's going on, and I, and I can work with it that way. But that didn't really work because the cost was performance.

The cost was like, is anybody really looking at that intel? Um, how up to date is that Intel? And, and, you know, in the security space, these type of threat products change constantly.

Like the security landscape is constantly changing. So I don't think there was ever really much of an advantage to that IPSec model where you bring everything in into your house and you inspect all the traffic. But then when we moved to Amazon, it was like, wait, where's my package inspection?

Like, how do I know what's going on? So I would say, first of all, to, to start to answer the question is like, we've been trusting other companies that have silos for years. GCP has its own silo.

Oracle Cloud has its own silo. You know, a a Azure has its own silo and they're incompatible silos. Um, the only compatibility layer they have is the open standard of IPSec.

They're like, we can talk over something that works anywhere else, but it really doesn't give us any advantages. So now zooming out for a second with companies that are providing this, this like glue that stitches all these different clouds together, and they're only being a handful of them. It's no less risky than it ever was to make the first sleep in migration.

Um, but the performance has to be worth it. And so I think nobody wants to employ an army of network engineers to try to keep a thousands of IPSec tunnels online, um, to maintain this in-house and build some real Goldberg approach, especially when the cost of doing this through provi through providers that are making this their core business is actually really, really low. The trust factor is no, not much different than the old trust factor used to be like, I have to trust somebody or else I can't do business.

Um, but I I would say that because we bet the farm on this, this is what we do that makes us accountable. Yeah. Like we are by nature accountable.

And, and one of the things that I love about CloudFlare is how we are accountable in ways that are, that are responsible, like Project Galileo, where we give away services to, to people who can't defend themselves so that they get all the protection of our cloud without connectivity, cloud without having to pay for it to make sure that their voice isn't lost and that someone can't decide to take their voice out. Um, we take this job very seriously and I think it, it is about following, following the intent. Like, you know, what, what, what do you do with this?

Like, we, we really do believe in building a better internet. And a and that's critical, but to your point, there's only a handful of companies that are gonna be able to compete in this kind of space because the innovation is blazing fast. Uh, and, and really something you want to get onto.

And I, and I thought the, the po the title of this was really fascinating to me on the transformation bit, because usually in my world, when you talk about transformation, it's like business process transformation. You know, can I take some antiquated process and turn it into a digital process? But the network transformation's different because now it's more like treating Earth is is a global network instead of my locations on earth.

Yeah. As, as my individual networks. And I think that's where the, the paradigm shift's starting to come.

Agreed. Agreed. Look, the, you know, this is a, this is the complexity of, of the, of the technology that we use today.

As I mentioned in the beginning, right? Sprinkle a little AI and really complicate things. It's only going to continue to, to become more complex over time.

Maybe we could simplify what an end user's use, you know, it's easy for them to use. But behind that curtain, man, it, it, it's complicated. I, I wanted to talk a a little bit, and this is a topic we haven't brought up on the last great cloud transformation, which is, look, whether you use AWS or Google or Microsoft or Oracle or any combination thereof, really the more the merrier as far as we're concerned here in terms of the connectivity cloud, right?

So there there is no, you know, so early on, you know, reminiscing early on, if you were AWS you were AWS, right? You were all in. The only thing we can contemplate was a hybrid cloud where maybe I'd keep some of my stuff back in my own data center and some on the public cloud.

But of course, in today's world, we've, we've realized that's probably not as realistic as I go to whichever public cloud is, right? For my particular, yeah, for this particular use case. They have other use cases here, use cases there.

And I do need something that kind of buys 'em, brings 'em together. Um, you, you know, you've been in this from the get go. When did you realize that this multi-cloud, because it was, I it, I'll be honest, it surprised me.

I didn't see it coming. When did you realize that multi-cloud was gonna become sort of the way, the dominant way, the preferred method? Probably I was thinking back to like 2012 when I worked for a VoIP startup and we were using, we were OnPrem and we were using a, um, Amazon to develop VoIP at the edge on their side for customers.

Like how would VoIP work in an a AWS context? And I was thinking like, man, this is a lot of eggs in one basket. Uh, and with, you know, Google's no slouch at cloud and they were talking about cloud, but it wasn't as mature yet.

And Amazon had this incredible explosion of Legos, like, because let's face it, they took open source products and productized them as services, right? Yep. So you just take open source software, productizing services, they're cranking out Legos as fast as you can.

It's like all of a sudden the elastic search is a Lego that you can just run MySQL with. Multi-site replication is something you can just run. Like they, they took the stack of the three tier web architecture and sort of made it a service, which is really interesting.

And I was like, so initially I was worried about like, God, I hope somebody competes with them because it's, they're, they're, they're really far ahead. They're, their work with Netflix pushed their envelope really hard. Like they, I think Netflix was one of the biggest customers that pushed Amazon to the edge and to the limit and forced 'em to rethink things.

And I was watching Google come up and with less excitement, I was watching Azure come up and I was like, well, at least multi-cloud has to probably exist. And I was thinking Azure adopters will probably p people that feel safe with Microsoft, with, they have a lot of Microsoft applications and it will just naturally make sense for them. And then Google will be the, the other people that are like, just not just not Amazon or I need another cloud strategy, but like, I've been happy to see Google come up and really own it and make, you know, a great cloud product that has a lot more Legos and a lot more connectivity.

They've got a good product going, Azure's doing a great job as well of making it easy for their customers to do business on the cloud and have options. But we're seeing another move now back to colo and back to some on-prem things where companies are realizing that, you know what things, it's way cheaper for me to own the metal. It's way cheaper for me to run on myself, and I'm gonna move this workload.

Part of my initial thing with, when I, when I go back for a second for like, oh my gosh, I hope there's competitors. It's because I was like, man, this is a lot of eggs in one basket, and they can start to control our margins. So like, if I give Amazon too much business, they have too much control over my margins and I don't like that.

But moving workloads is not trivial either. And so my, my fear on multi-cloud early on was like, everybody will need a multi-cloud strategy, but it will be optimized towards maintaining leverage. I need to maintain leverage and that leverage has to be material.

I need to be able to act on it or else it's not really leverage, right? All the while watching cloud providers try to compete with each other while also trying to escape commoditization, like commoditization, you know? Yeah.

Instant prices are gonna go down. Value added services are going to go up it. To think about it in a less technical context, I think about baby carrots, which now you're probably going like, what the hell, Mike?

Where where are you going? But seriously, you know, farmers growing carrots make very little money on carrots. If I sell them raw in the store, all a baby carrot is, is a big carrot that's been chopped into little pieces and skinned like that's a baby carrot.

But that value added product actually goes from warm money. Cloud providers do the same thing. They take something like, Amazon's a master of this.

Take an open source product, run it as a service charge way more than it costs you to run it value added service. Like they're nailing it. But me as the buyer, I need some control.

I need to be able to control my costs. And so a multi-cloud strategy is part of what I need to do that because I have to understand like the nuances of, you know, provider A and provider B in my applications and what those needs are. And so any multi-cloud strategy has to be centered around what am I trying to accomplish and what kind of continu business continuity do I need to maintain?

So yeah, it's, it's a fascinating world that we live in, but the, the multi-cloud thing had to happen because in a world where there's only one player they can, that they ultimately wouldn't be giving people any kind of choice. Like, it, it's too expensive to run with just one player. Like they really control the cost.

And I, I already think it's really expensive, um, because people leave workloads running, for example, you know, always you're, you're you're trying to figure out like, why is it I call 'em zombies, like somebody leaves zombie workloads running. You're just like, man, the meter's running, like nobody's using this thing. Well, yeah, we rack it up to Dollar.

It's good to manage. Yeah. Like I think multi-cloud is hard to manage too, but it's also inevitable.

We have to distribute our risk. We have to distribute our workloads and make sure we maintain leverage and negotiations. So multi-cloud was natural, but it took a long time to get here.

'cause keep in mind, I was thinking about this in 2012, and like you really couldn't have a true multi-cloud strategy in 2012. Even today, it's pretty hard to have one because workloads aren't exactly portable. Like there's some, there's changes in that world, but they're not portable yet.

No, I I I'm sorry. Go ahead, Mitch. So Many of us is, I was just gonna say, so many of us have kind of backed into it right through m and a activities.

Yeah. You know, we're this cloud Now there's lot of that Pre cloud and you had to, you know, what do you do to try to make sense of it just to operate it effectively, more or less, get to a point where that's part of your go forward strategy and what workloads can you distribute across those or move across those clouds? Not, not a simple question.

I, to me it's more, you know, a thing I learned as I was growing up and, and got older was it's not the man, it's the tool and it's the right tool for the job. I think for particular jobs, there are cloud providers as well as other options, right? My own colo or what have you, my own data center that are the right tool for the job.

And I think the job of today's CIOs and, and architects is to figure out what's the right tool for this job? What's the right domicile for this job? How do I use the connectivity cloud to glue that all together and make it look at and appear and act as one contiguous infrastructure, but still use the right tool for the job?

And I, I, I think that's what does it, And it, and it kind of goes back to the, to sort of ideal state of what a security tool would do, which is like, allow, please, allow me to maintain a policy and a posture consistently, right? It activity cloud is about that. Like, we have the same players, we have users, we have services, we have servers, we have applications, we have all these different things, but like, allow the policies to be uniformly applied and allow me to prove that I know what's going on.

Agreed. Agreed. Guys, this has been a tremendous conversation.

I, you know, we went far off, we started with better connectivity and security through network modernization and we discussed a lot of that, but we dis, we reminisced a lot, as Mike would say. And, uh, we, it was good doing that. I look forward to continuing this line of conversation in future episodes of the last great tra last great cloud transformation, Mitchell, I think our next one is a live round table, isn't it?

I believe so. Yep. Yeah, we we're just, everyone coming out, if you're Watching this at home, check it out.

Make sure you register for the next live one, because I'm sure you've got questions. I can't promise Mike's gonna be there. He's, he's got a bit of a job to do when he is not doing this.

But if you've got questions around the things we're talking about today, we invite you to participate in there. Many thanks Mike to you and CloudFlare for, for participating and co-producing this with us. It's, these are the kinds of conversations that people like us enjoy.

We could talk all day about. Right. Good stuff.

I really flew by. I'm happy to join you anytime, but I had a great time talking to you today. Absolutely.

Well, we'll make sure we'll get you back here. Don't you worry. Um, Mitch, I didn't get a chance to introduce you, you jumped right in, but why don't you take the last word out then?

You know, I, I, I loved, I loved the walk back, you know, looking at kind of how we got to where we are, right? 'cause that informs where we go forward and there's so much, what, what's really changed is, uh, you said it, Mike, going from points on the earth to the earth is my cloud, right? That's my location.

And thinking about, you know, don't use your points of presence that you know about as your limitation. Just like, don't use your, you know, hauling traffic back to the VP and concentrator or the center of the network, either. That's, it's a different paradigm.

It's a distributed processing network and, uh, there's a lot more things we can do with it. So it's, it's an exciting future. We appreciate you, Mike, sharing your, your experience with it as well, Alrightyy.

All right. On behalf of Techstrong and CloudFlare, thanks for joining us today. We'll be back with another show soon.

Until then, everyone, good luck. Take care. Hey, uh, welcome to my skill obsession on from siloed metrics to ai, augmented continuous security insights.

I wish to thank people CERT and Techron learning program committees for allowing me the opportunity to speak to you today. Um, if you don't know me, my name's Mark Horn Beak. I am CEO and principal consultant of a little boutique consulting firm called Engineering DevOps Consulting.

And as your name implies, you can see what I consult with. I'm also the author of some books, for example, the Engineering DevOps book. And, uh, recent title just published two months ago called Continuous Testing, quality Security and Feedback.

I'm also a member of I-E-E-E-A lifetime member. And, um, I'm a member of the Deming Institute, the, and the Value Stream Management Consortium. I'm also an ambassador for People Cert and the DevOps Institute.

I have been a principal consultant for more than 90 different continuous engineering, uh, DevOps, DevSecOps and SRE transformations, mostly with very large organizations, both, um, public and, uh, enterprise and, uh, or institutions as well. I literally just celebrated my 50th year of my career in September of this year. So I guess I'm one of the old guys.

That's why they call me DevOps the gray, I suppose. Uh, so since publishing engineering DevOps five years ago, I've been pointing out that in an era of escalating cyber threats, and interestingly, these threats continue to escalate over this time. The traditional separation between DevSecOps and SecOps metrics is leaving organizations vulnerable.

Siloed approaches fail to provide cohesive insights needed to detect vulnerabilities early and to respond effectively to incidents in production. So emerging technologies like generative AI and machine learning offer transformative potential to bridge these gaps, enabling the creation of intelligent continuous security metrics that adapt and learn in real time across the, uh, development and production boundaries. Included this session will explore how combining DevSecOps and SecOps metrics with AI augmented solutions can redefine security management.

We'll examine three real world security events where traditional metrics failed, and to demonstrate how AI and ML could have delivered predictive insights faster, uh, faster incident responses, enhanced vulnerability detection. And you should get from this some level of knowledge about how to apply AI and machine learning to build smarter unified security insights to safeguard against these more sophisticated threats. Uh, one item to note, I did promise in case you guys, uh, came through my LinkedIn, that anyone that attends this session in person, I am quite happy to send you a free copy of my most recent book, an ebook copy, uh, continuous testing, quality security, and feedback.

com. Okay, let's, uh, get started here. So there are several goals in the presentation.

First of all, to understand what is continuous security itself and the current state of siloed DevSecOps and SecOps. 'cause that's fundamental to understanding the rest of this. Uh, the second is really to explore problems with silos of DevSecOps and SecOps metrics in particular, and then identify AI applications for unified continuous security insights, which is more than just metrics implementing ai, augmented, continuous security insights.

I'll talk about how we can go about implementing these things, and I'll end up with a brief summary of some key takeaways that help you get started on your own journey if you wanna actually go ahead and, you know, implement these AI augmented continuous security insights. Okay, so let's, first of all with the first topic, understand what is continuous security and really the current state of siloed DevSecOps and SecOps. Uh, so there are really stark differences between DevSecOps and SecOps and the challenges they face due to their cultural as well as operational silos.

DevSecOps prioritizes rapid software delivery focusing on things like CICD automation, while SecOps emphasizes stability, risk, and compliance with focusing on monitoring, detection and incident response in production environments. One of the curious things about DevSecOps that I think some people at least don't seem to realize is even though, you know, SecOps is in the name DevSecOps, there's really not a whole lot of, you know, in information within DevSecOps practice themselves about what you should do with security after deployment to production. And that's where SecOps comes into play.

So that's, uh, sometimes not understood by people. It's a little, uh, interesting. The lack of a cohesive security strategy across these teams and boundaries is often causing, you know, misaligned goals, fragmented tools, and in general measures that don't really overlap very well or don't integrate very well.

So this disconnect is further exacerbated by legacy structures, insufficient training, and the slow adoption of integrated security tools. I mean, honestly, I will sort of summarize a lot of that and just say, you know, the complexity of it all, all, and that's where, again, AI can help to try to deal with the complexity of some people already complaining about the complexity of DevSecOps alone or SecOps alone. So, oh my goodness, if we start integrating these things gonna be more complex.

So you, you know, one could argue they can't even really do what I'm talking about is continuous security unless you have the help from AI tools. So for organizations to truly secure their environments, we need to bring these teams together, aligning their tools, data communication strategies, under one, you know, cohesive security framework. And of course, that's what the next slide talks about.

Uh, AI assisted continuous security focused on applying AI augmented, uh, security practices across the entire software development lifecycle and production operations. So in DevSecOps, the goal is to prevent vulnerabilities during planning engineering, and in the CICD pipelines, ensuring that security is integrated from the start. But once you move code into, you know, production with SecOps, the focus shifts to defending against exploits and attacks on the production environments.

What makes AI augmented continuous security powerful is its ability to provide real-time threat detection, automated security testing in a seamless integration of security measures across both development and operations. So th this assures that we progress from development to production and security remains a constant and a, you know, proactive element of, of the work. So let's compare, you know, the traditional approaches of DevSecOps and SecOps With AI admitted continuous security and in DevSecOps the focus on shifting security left, integrating security measures into development and the pipelines and ensuring vulnerabilities are caught early SecOps, on the other hand, is concerned with product in production security, focusing on monitoring and protecting live systems from exploitation.

While I ai, augmented continuous security goes a step further by applying end-to-end security practices, continuously securing every phase from development through the production by leveraging AI and machine learning. The key advantage of using AI is the ability to reduce complexity, lower costs, minimize resource requirements, uh, and, uh, allowing organizations to enhance security coverage while maintaining efficiency. In fact, you could almost say that it makes it feasible without AI is pretty tough.

Uh, over the last five years, we've seen a significant increase in very real world impacts of security breaches. For example, ransomware payments surged 171% while, uh, cybersecurity insurance premiums have increased by 96%. So a lot of increases in costs there.

The cost of forensic investigations now reach millions of dollars for breach with organizations facing lawsuits, reputational damage and business losses, often for months, uh, after the event, compliance penalties have also risen as regulatory scrutiny intensifies, and long term organization disruptions have become a reality. But these trends demonstrate that organizations really need a proactive, you know, AI, augmented continuous security approach to prevent costly breaches and minimize damage. By adopting AI driven security practices, organizations can stay ahead of evolving threats and reduce, you know, the financial, legal and reputational risks.

So let's explore the problems with siloed DevSecOps and, um, SecOps metrics. Let's look at the, um, in DevSecOps, the focus is on shifting security left, integrating security measures into the pipelines. As we said, ensuring vulnerabilities are caught early.

These metrics are primarily inward focused, reporting the results of security scanners and tasks of software that is transiting through the CICD pipeline. SecOps, on the other hand, is concerned with production security defense focusing on monitoring and protecting live systems from external threats and exploitations. Uh, despite the concepts of collaboration, which are certainly, you know, uh, espoused by the DevSecOps and SecOps communities, uh, this in reality, uh, continues to be a gap in many organizations.

There's a lack of co co, uh, correlation between development vulnerabilities and runtime threats and missed patterns in complex attack scenarios due to the fragmented nature of the data. When we examine some real world breaches, such as the solar winds supply chain attack and the log four J vulnerability and the Equifax breach, uh, that we've seen recently, we see that many of these incidents occurred due to gaps in both DevSecOps and SecOps practices and the SolarWinds breach, for example, attackers exploited weaknesses in the software supply chain. If AI augmented continued security had been applied, insights from continuous testing and patching could have identified the te the tampering much earlier for the log four J incident, AI augmented tools could have flagged vulnerable versions of the library and automatically patched systems.

As soon as the vulnerability was disclosed. Uh, the Equifax, uh, breach highlighted the importance of continuous monitoring with AI tools could have provided ongoing scans and threat detection that would've alerted teams to the un unpatched vulnerability. In all cases, AI augmented continuous security integrates both DevSecOps and SecOps practices enabling continuous real-time protection against emerging threats, you know, across the lifecycle.

And there are plenty of other examples on the slide that we don't have time to talk about, but in each case, you can, uh, look at them and understand how continuous security with AI support could have helped. There are several environments where AI, augmented continuous security becomes essential. Large enterprises where DevSecOps and SecOps teams often operate in silos, uh, AI enables automated collaboration and coordination, ensuring security is embedded across both development and production.

In cases where software suppliers are separated from their customers, ai augmented security enables continuous threat monitoring, ensuring that the software is secure even as it integrates with the customer's environment. Where government institutions and military applications where sensitive information is at stake, AI can manage continuous compliance checks, real-time threat detection and security policy enforcement and network infrastructure. Situations where software manufacturers are disconnected from the network system operators, AI ensures that both software and the network are secured in tandem and in industries like finance, healthcare, and critical infrastructure where security breaches can have catastrophic consequences.

Ai, augmented continuous security provides the continuous protection needed to meet regulatory requirements and defend against every evolving threats. So let's look at, um, AI applications for continuous insights. Generative AI and machine learning are revolutionizing, uh, security elevation by significantly reducing the manual effort required for tasks like threat detection, vulnerability management compliance checks.

First of all, gen AI can accelerate tasks to analyze vast amounts of data and generate meaningful insights, helping identify potential security threats in real time. Uh, for example, automated complex network patterns and user behavior that can drive detection of anomalies that might indicate a security breach before it even happens. Uh, secondly, tools augmented with machine learning applications driven by ai.

Augmented task automation improves vulnerability scanning by using algorithm, prioritizing categorizing risks based on, you know, uh, based on their potential impact. This ensures that the most critical threats are addressed, first, reducing the chances of oversight and altogether, uh, gen AI and machine learning augmentation facilitate more intelligent automated solutions. Fundamentally, AI transforms the way compliance is managed by automating what has traditionally been a very manual and resource intensive process.

First of all, AI can continuously monitor systems and applications for compliance with regulatory frameworks and security standards. Instead of waiting for periodic audits or manually checking adherence policies, AI ensures compliance in real time. AI can reduce the manual workload involved in compliance checks and AI's ability to quickly assess and adapt to changes and regulations ensures that compliance remains a continuous process, not a reactive one.

AI can also automate threat detection by continuously, uh, analyzing vast amounts of data from across your systems in real time. Using machine learning, AI can identify unusual patterns of behaviors that indicate potential threats or vulnerabilities. Uh, this enhances speed and accuracy.

Once the threat's detected, AI can automatically initiate mitigation steps. And ultimately, AI automation ensures that your systems are continuously monitored with real-time identification and response as well, reducing the risk of damage. AI can also significantly improve vulnerability management by helping automate processes from detection to remediation, identify vulnerabilities faster by continuously scanning code infrastructure and systems.

Using, for example, AI agents. It, uh, analyzes vast amounts of data, as we said before, uh, including known vulnerability databases. And using machine learning can detect potential weaknesses.

Once vulnerabilities are identified, AI can automatically prioritize them based on risk, and finally, even automate the patching process itself. Uh, three types of continuous security insights are important to help understand the progress of the transformations, the effectiveness of the solution, and the impact on the business mission. To understand the progress of AI augmented continuous security transformation efforts, we look at the percentage of automated security checks and CI ICD pipelines and compare vulnerabilities detected pre-production versus post-production, things like meantime to detect, as well as DevSecOps, SecOps collaboration metrics like joint incident response, swans paths.

Uh, as far as, um, effectiveness insights, these are derived from improvements to things like meantime to remediate reduction in security incidents, false alerts, compliance and costs, metrics, insights, uh, business mission insights such as downtime due to security breaches and security spending as a percentage of IT budgets are critical to understand the overall effectiveness. So these metrics are important to demonstrate how AI augmented security improves, uh, security outcomes and business performance. So let's look at how you can implement ai, enhance continuous security insights.

Leadership is where you start, right? Leadership sets the tone for a whole security culture. Prioritizing security is in the decision making processes, resource allocation, communication in general leader, set the tone for the entire organization and champion security as a core value of not just a checkbox, empowering teams to take ownership, providing continuous security education and awareness, or at least budgeting for that collab.

Uh, supporting collaboration between development, operational security teams, uh, establishing security policies and metrics, prioritizing, encouraging a shift left mentality for trying to identify security concerns early, both on the production side and the development side, and building a security of accountability and communication. So just some of the ways that, you know, the importance of, um, leaders play in this whole process. So start with leadership.

Basically, AI assisted value stream engineering is a game changer because it identifies both efficiency and security by automating key processes and optimizing workflows that are layer above the CICD pipelines and in production monitors. And that's the key, right? You're not looking typically at just an individual CICD pipeline.

When you're looking at continuous security across all of these environments, you need to be able to aggregate the data across the different environments. So as organizations scale and threats evolve, traditional manual approaches struggle to keep up as well as traditional, you know, monitoring, uh, approaches struggle to keep up. So AI helps overcome these challenges by making security metrics and insights at the next level.

So, ai, augmented virtual, uh, value stream engineering streamlines process by automating repetitive monitoring and analysis tasks that would traditionally be very manual and time consuming. This is actually a short version of my blueprint that illustrates how to use AI for front end, uh, and end-to-end value stream engineering transformations, including how you can establish observability metrics and analysis for insights. The very first step is to use ai, uh, to generate standard templates and artifacts that are used in different sections of the value stream.

And then those templates include things like codified standards for specifications, processes and output artifacts. And these templates and artifacts are then version managed so they can evolve over time as the organization continues to improve its practices across the end-to-end value stream, then people trained in the use of the generative AI generates standard compliant code and ai augmented tools are used to orchestrate and, and automate security tasks across the DevSecOps. Value stream results are generated from ai, augmented observability tools.

Results and analysis tools are processed by people with, you know, with assistance of the generative AI tools. Uh, basically this creates a closed loop in which AI is continuously, you know, directed, controlled and approved at every step. Uh, ultimately where human users are, are still in control, but trained and, uh, reciprocally, you know, help, uh, what they're doing and help each other.

The AI tool sets are used at every stage in the value stream, as well as in combination with that generative AI help of automation. So this slide provides a prescriptive guidance, and again, very high level. Uh, but to give you an idea, the major steps, first of all, take an inventory and, and assess where you are.

What are your gaps in the current metrics when you're looking at, uh, DevSecOps across SecOps? Adopt AI tools. Decide what tools you're going to use for automation.

Things like chat, GB Key or Bard or other customized ML models, uh, for both the DevSecOps side and the SecOps side. Tried to get agreement on what tools you're gonna use. Then train the models using historical data, both predictive and generative AI systems can be used to that.

Automate responses to implement AI driven playbooks and reduce the manual interventions. So finally, let's talk about key takeaways. There are several takeaways from my talk.

If you summarize the whole talk in just a few bullets. Essentially, ai, augmented automation of threat detection, vulnerability management and compliance reduces manual efforts and enhances real time end-to-end security responses. Ai, augmented continued security transforms, siloed DevSecOps and SecOps reactive metrics to more unified proactive insights by predicting lifecycle vulnerabilities and mitigating risks and gaps where they can cause harm.

And, uh, key metrics such as reduced incident response times, faster deployments. Enhanced compliance demonstrates the success of AI and improving security and efficiency. The bottom line call to action if you want to evaluate your current DevSecOps and SecOps metrics and augmented current, you know, a unified set of insights with AI towards automating, uh, with tools and automated practices using ai.

So that's, uh, basically my talk. And, you know, I would encourage you to learn more about this topic. You're to say you're welcome to pick up a copy of my book.

dot com. I will gladly send you an e-copy of the book, and, uh, I wish you the best on the rest of your day and your conference. Thank you for your attention.

I appreciate it.