Techstrong TV – March 10, 2025

AIOps, ML Ops, DevOps, it's all Greek to me. You're watching Techstrong Gang. Hello everyone.

Happy Monday. It's Alan Shimmel here for Techstar Gang. Hope you've had a great weekend and you're ready to get back to work this morning.

There's a lot going on in the world. We're gonna try to just cover just three things. Just three things.

That's what we do here on Textron Gang. We just do three things every day. Um, got a great gang of, uh, cast of gang members to go over stuff with.

Let me quickly, quickly introduce you to them. First of all, the lady from New Mexico, she's the CEO of Deploy hub, open source expert extraordinaire, and one of our favorite people here at Techron World. Tracy Reagan.

Hey Tracy. How are you? Hey, Alan.

Thank you. Thank you for that. I like being a favorite person.

Well, you are. Thank you. Thank you.

Um, joining jc, he is in the streets of New York City Manhattan, that he is Futurum Chief, not Futurum, excuse me. Visible impact Chief Analyst, guy Courier. Hey guy.

I hope I got that right for you. You got it right. Thank you.

Just Wanted to clarify and It's great to be here Again. You're not in New Jersey? Uh, what Exit?

What exit? That's right. I'm in.

Yeah, I'm in, I'm in, I'm staying in New Jersey, uh, with my nephew, but I'm coming into Manhattan every day. 'cause I Not near exit 13. Elizabeth Newark.

No, right by the bridge. Right by Fort Lee. Oh, okay.

You're up by the GW and the Henry Hudson. That's, you Know, we came up with congestion pricing to keep you people on that side of the bridge. But no, I love when you use you people And that's why I take the bus.

That's you people. You people. Alright, let's move over.

Take the bus that's over from you people. We'll stay in New York. We'll go up to Harrison.

Looking mighty Raddish pinkish today, our own life are, yeah, well I'm, I'm actually just back from a run, so There you go. Alright, good for you. I, I did a bike ride this morning myself.

It was cold. Well, it's all relative, but it was cold down here today. It was probably in the sixties.

I was freezing, um, moving there. I'm sure it's at least in the sixties up in, in the high mountains of Colorado. Uh, no one, no one commented on that.

It's our, uh, FU VP analyst for DevOps. Mitch Ashley. Hey, Mitch.

How are you? You're on mute. Oh, now you're not doing great.

Always doing great. Good to see the gang. Good to be on the gang again.

All righty. All right, let's jump into it. This fine fi this fine Monday, Mike, we, we had some text drawing AI coverage on, uh, on J Frog's.

I think you were outta Jfr event in New York last week, weren't you? Yeah. They had an event down in, uh, Rockefeller Center, and they had about 200 people show up for the launch of a jfr ML lops platform, which is based on, uh, a code, I guess, code they got from a startup that they acquired last year.

And now we're productizing and it's much more integrated with their core DevOps platform. They gave out these lovely mugs here, you know, and, um, I gotta say, you know, it took me about 15 minutes to figure out how to move this thing actually works. But what it does Is that the one that heats it up?

Yeah. And it continuously stirs it. Yes, I have one in us, Which is, um, you know, of course core to DevOps.

We're continuously stirring things. So I want to thank AOG for yet another first roll platform issue solved. I was gonna say, what are you putting in there?

You need to have a continuous Well, that's my promise. I'm not a coffee drinker. And I, so it's still sitting in the box.

I've had it a while. I think it's aim for. So what, what was it you said in the intro?

What was it you said in the intro? Allen ml ops ai, AI ops, DevOps. And we have coffee Ops, and now we have coffee ops.

It's all ops, it's new ops, no ops. But what was really interesting about it is that the folks who came to this event were largely data science types, and they all work with these ml lops platform and J frog's making a case and a hard one. Every speaker got up said, you know, if if those folks want people to use their AI models, they have to be integrated with the existing DevOps workflows, or the developers are never gonna find them.

And what I was trying to puzzle out in my mind, and I'll start with Tracy on this, is, is there kind of a divide between these data science teams that are using these ML ops platforms and the rest of the DevOps teams, and each of them has like a different culture and we need to bridge that? Well, I'm not sure it's a different culture. Um, I think that the ML ops community have been somewhat underserved when it comes to DevOps.

Um, you know, I, the reason why I love this, the reason why I totally love what's happening here is that we're finally stopping to think about ML ops and AI and the components that we use, like models and data sets. They're just components that need the same kind of management as any other kind of component. So when we think of artifact management, we, you know, in, in Artifactory, we often think of just binaries.

It's kind of what, where our brain goes, it's artifacts of binary, but artifact can be anything. So being able to start to bring in the AI components, models, data sets, as well as binaries into a central place and treat it just like any other DevOps, um, any other type of component pushed through the DevOps pipeline is going to be, um, a time saver. And it's gonna offer a lot of clarity to those data scientists who may not have had that kind of products in the past.

Now, I believe, I understand we have things like TensorFlow that help them build, uh, these models. Uh, but when it comes to all the other pieces of the DevOps pipeline, the ML ops teams have not had the luxury of, of these kinds of tools. So imagine how hard it is to try to manage just a deployment of, of one of those without a DevOps engine.

I, as a DevOps person, can't imagine doing it. So, you know, I, I saw last year, I think is when, um, JFR bought quack. It's probably, it's been almost a year now.

So, uh, they've taken some time to really, it looks like, to me, to kind of sort out how to integrate the, these, you know, the ML ops components into their process. Uh, but it, it's time. Um, you know, I don't know if we're we're too late on the ML ops question because I know people are still doing it, but it doesn't feel like it's as, as popular as it once was.

But for the data scientists, this is what they need. So yay jfr, they're, they're actually servicing that community from a DevOps perspective because it's the same, the problems are all the same. It's just a different component.

You know, the mike, there are differences in how the teams work, and I think that's great to see jfr taking that on through their acquisition of Quack. Um, you know, software has its own iterative process as, uh, ML and ML Ops also has its own kind of development workflow, which isn't exactly the way software is created. Usually in, in machine learning type of applications.

You have a, you have a data engineer, a data analyst, you'll have a developer, usually a domain expert that's helping you. And you iterate on the model. You iterate on the format and the, the structure of the data that the model uses and the algorithm use.

And you go through this iterative process where you create what they call features. This is like, okay, this is what it can answer for this kind of a question or this kind of analysis or this type of data that it's gonna analyze and produce some predictable results. That iterative process, you know, where is it released at?

It's sort of kind of, when is the software ready? Same thing happens in ML ops. When is, when is the model ready?

And eventually those two things, uh, have to join the, the kind of traditional software and the machine learning language algorithms and, uh, and models. So it's good to see Jfr take that on. I don't think it's just a matter of let's put your, our stuff in our, in our artifacts.

I think it's also the workflow. So I'm curious to see how this is gonna be adopted. And I, you know, I wish, uh, jfr the, the best at this.

'cause I think it's important for us to figure this out so we don't have this kind of chocolate peanut butter impedance mismatch between the two approaches to developing what we're creating. Yeah. And I think that the model training is where the, that, you know, pulling the data sets and training the models and then, and storing them is where the ML ops, uh, workflow is the most important.

Um, but centralizing that into a, a, a kind of a, a central platform, um, will make things easier in the long run. Just make it part of the DevOps workflow is a win Right There. Or vice versa, you know, DevOps part of the ML workflow.

I actually think also the, uh, uh, experiment tracking and, um, hyper parameter management, these are really important elements of what the data scientist does. Um, and, uh, having, you know, you know, a agile and agile workflow, um, for that sort of thing, um, is, uh, is, is really helpful as well. I like the bridge here.

Like everyone's noted, the bridge out to the data scientists and the data scientist's particular types of work that really differ significantly from the coder and yet still bringing them into this, uh, DevOps like paradigm. Hey, Alan, um, you know, we saw an outfit called, uh, a couple of weeks back, DataRobot bought some distributed computing platform startup. And I wonder if we're about to see some major convergence here.

Will all the DevOps companies kind of go after ML ops companies and will the ML ops people start acquiring DevOps companies? And, you know, are, are, are these two trains gonna coll? What?

I don't know if they're gonna collide, but, you know, I sometimes themes seems things seem too forced. Too forced. I get why you would want the ML ops to help in developing, deploying AI apps, training LLMs.

Not everything has to be part of my DevOps workflow. And I just, you know, I, I remember when they bought Quack. I was at, um, swamp Up.

I think I had a chance to meet the founder, one of the co-founders of Quack. Actually. I interviewed, you know, I I I, I smell what they're cooking.

I just don't know if we're eating it or if it's, if it's a necess, if it's on my food pyramid, I would argue that this conversation we've been having about platform engineering for a while will force this issue and that people are gonna start centralizing the management of application development. And they will naturally view those AI models as an extension of that conversation. So I think it may happen.

Well, to Alan's point, if we look at, uh, DBAs, DBAs have never embraced the DevOps pipeline, right? They have their own process and they've never, ever really, um, decided that that was a good idea. DevOps, well, There is this kind of, there is this kind of tiering, so to, I mean, it literally, it's called tiering of applications, the old monolithic model.

And, and, and the data and the data services, um, are, and can be seen as a sort of a separate layer or tier. But I, Alan, I don't think, and Tracy, I guess I don't, I think, you know, I'm a fan of saying there's no such thing as an AI application. What, what, there are AI services that get exposed or injected into other applications.

And as such, AI has become just so pervasive that what I would think the problem, uh, uh, J Rog is solving for is all the developers using DevOps and wanting to do more and more of it now need to incorporate ai. Um, and those AI services, if they're being tuned, developed, tuned or, or, you know, rag based or whatever it is, there's a data scientist involved. And that's, I think, a little bit more of a, of an opportunity.

Let's not call it a problem, it's an opportunity. Um, compared to, uh, what I, I completely agree with Tracy's, you know, statement about how the DBAs have never really wedded with Dev DevOps very well, but I think this is, this is different because of how infused and integrated, um, AI is in every application. It's going the other direction, right?

It's not being pushed out from ai, it's being pulled in from the development. Exactly. Well, that a unique characteristic that you're pushing not just algorithms, machine learning algorithms, you're pushing data with it, right?

The model includes data. So it, it is kinda incongruent with what we think about a normal DevOps up, uh, workflow of pushing software, right? Usually not pushing a lot of data through the process, which is also, to your point Tracy, about why data and data database engineers, analysts ha, haven't been kind of part of that DevOps workflow, right?

It has its own flow, it's own process. And I think that's the key to this is Alan, it's not just about does jfr bolt on a AI or ML ops into their products? That is not gonna solve the problem.

You're not gonna attract people, you know, it's like saying, I have open APIs, as long as you use my APIs, they're open. Right? No, it is.

It's like you have to adapt to the workflow and, and intersect those workflows in the way that it makes sense. I don't think we know enough about that yet, or, or have experimented enough to really truly know what the right approach is. So hopefully we have some folks that, uh, make some progress in that area.

Well, I hope that we continue just thinking about parts or parts, right? And obviously different parts have different requirements around them, and there may be different workflows for different parts, but it's still a component. It still has to do a vulnerable, we still have to think about how to add testing and vulnerability scanning.

It's a part that has to go through the software factory floor and the DevOps engine is the best place to do that. And these are developers, even though we have new terms like data, data scientists, they're still developers and they're still part of the development community. And to embrace them and provide them tools that allow them to support the DevOps pipeline is the direction we should go with this.

Because we all know it helps things move faster and we always wanna go faster. Yeah. I would say, you know, we talked about this in a previous show, but the DVAs are gonna get rolled up theoretically into this platform engineering motion as well.

So, you know, maybe we're coming for the data scientists, the DBAs, and they're little dogs too. I dunno. Well, when they come for the data scientists, we didn't say anything.

That's a different thing. Um, but, but let me just tell you that the is one more chip here that Jfr has in their pocket to play. And that is, they've announced a, a partnership with Nvidia and this ML ops platform and Flow is supposed to be integrated into the, uh, NVIDIA of dawn.

What's the NVIDIA software? It's NIM is the framework Nim, I actually learned what it stands for. It's Nvidia inference microservices.

Nim, who knew? There you go. Yeah.

It's a, it's a tool set for, for a deploying AI into containerized environments. Uh, yeah. And, and hugging face also, Alan, that's, that's really significant.

Hugging face is a quasi standard now, uh, yes. For model development and, uh, um, benchmarking of systems, um, for ML and, and, and ai. Yeah.

And it's just like going out and pulling a package down, an open source package. We're pulling down an open source LLM, treating it like a component and then starting to track the changes in it, right? Right.

This, it's, it's basic to what we've always done. Agreed Not, not to be left out, but they brought in Databricks and they got an outfit called Bowl Plan, which makes some sort of serverless data lake. So they got it.

And three maker AW Ws part of their JF fraud's, doing their, you know, we, we spoke yesterday about playing checkers versus three dimensional chess. Jfr definitely is playing three dimensional chess in, in this market with that. Right?

And you look at, you know, who their traditional competitors are in the DevOps DevSecOps platform. You look at GitHub, GitLab, CloudBees Harness, and you see, you know, well Harness is, is making some moves along in this space as well. I'm not sure if the others are yet.

But anyway, I'll leave that to the analyst to, to comment on. I'm just, I'm just, what? I don't know what I am.

But let's take a break here on Techron gang. We'll come back and we'll talk about our next block. 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.

Hey folks, we're back. And the gang's gonna talk about this new AI agentic offering that goes on top of a platform called Open Rewrite that was created by Modern. And what they've done is made it more accessible to a broader number of folks.

'cause it's set the core of a lot of the application modernization efforts that people have. A KAI am gonna upgrade from Java, single digit number, pick your favorite double digit number, and you can use this tool to automate a lot of that workflow. It doesn't do it all entirely, but it might take something that might have taken you, I don't know, a year and a half to cut it down and maybe six months.

And now they're putting some AI agents in front of that. Um, Mitch, I guess, you know, when I looked at this, I was wondering if the cost of switching from different platforms is about to drop and maybe people won't be as locked in as they used to be, because it won't take as much time to migrate. Well think about migration in a couple ways, or modernization in a couple ways.

One is, to your point about upgrading versions of Java, right? Some of those changes are no, no small attempt. I mean, it's, it's a big effort to go between different versions of say, you know, between Python two and three, it was a big deal, right?

Things are different in those languages. So it takes more than just syntax changes and new features that are in the language when we talk about converting COBOL to something else, right? To, uh, Python or c or or whatever it might be.

Now you're talking about architecturally some really big differences between how that application and all of its different programs code were put together and how you would build that, whether it's in a monolith or semi monolith or more microservice oriented. So we're, we're talking about, you know, baby steps here. We're not throwing COBOL systems at it and said, great, it's all done.

We're all good. But I think to the point is, they've taken what they've created so far and now put this into this lossless tree structure, um, that has kind of more semantic richness about understanding the interdependencies between code and analyzing different code bases. I'm not sure all the things that it does.

Sounds pretty interesting. I'd like to learn more about it. But this is something that they have also open sourced, um, as well as built into their product.

I think the important thing, really interesting thing is the agent part of it is sending that off to do specific tasks. The task around analyzing multiple code bases, doing some rewrites, finding issues that can be addressed. And again, this is a stair step process of maturity of what it can do.

Ally versus guided versus it still takes a human. Mm-hmm. It takes us, go ahead.

It takes us back to that conversation. Mono versus poly repos and the problems that they do create. But in you're, when you're in a decoupled architecture in particular, microservices, we talked, we used that word the last, last block.

We know that we are, when one application is going to be, uh, an aggregation of, of several repos, it's not just one application is not, does not have one repo. So tools like this makes it a lot easier to say, I need to aggregate, I need to scan all of these because this is one application, right? And this isn't just a problem here.

It's a problem in, in other ways as well. So I, I think taking on that poly repo problem, um, for doing this, for doing rewrites and, um, you know, updating your code is a super useful thing to use. I I'll tell you, they were a little miff because all these companies are out there claiming that they have, uh, upgraded something using AI tools.

And they were like, the truth of the matter is, yeah, they pointed their AI tool, but they used our repository to do it and all. So most of the work was done on the repository side from them and not by the AI agent, according to them at least. And they feel like, um, some folks are taking too much credit for things that their open source platform actually does.

I have a hard time believing that because tell me what, what code base, what repository, especially when it's been around for a long time, is that organized? That cleaned up that easy to, to work with? Those things tend to, they're like wiring closets, you know, for your network and your office.

So as you close the door, it's a mess the next time you open it. Um, so, so I wouldn't put as much stock into that. Maybe they're take getting some advantages, the course of what's there, but there's a lot of work to go from point A to point B on this.

I, I don't know. I want, I kind of wanna challenge you on this, Mitch, 'cause I kind of feel like that's one of these things that generative AI does so well is masses of seemingly disorganized data and information and, um, I mean, it's not a pattern detection tool. Exactly.

Um, but, uh, through that iterative, you know, training process, it, it, it finds plausible further strings of data based on input strings of data. And, and this is far beyond what, you know, uh, what the human mind right now can, can do. So like, isn't it sort of like, uh, I don't know, a new weapon to, to deploy against what everybody has put together in a disorganized fashion and therefore can't use, uh, in the same way It's kind of the, there's a pony in there syndrome, right?

Like, what does this, all this stuff do? And if I'm gonna modernize it or migrate it or replatform it, whatever it is, you know, what do I have and what do I need to modernize? What can I leave behind?

I don't wanna leave things behind that need to be there. So generative ai, and there's a lot of different products that are doing this now are really good or getting better, let's put it that way, at analyzing code bases and first telling you functionally what the requirements or what this software does. Second is the architecture of it, describing of it, how it, it is organized or disorganized to whatever degree it is.

So then you can make some decisions that human can about, well then how am I gonna re-architect this? How do I move forward with this? And maybe I use AI to do some of the development with it.

Maybe I don't. But to your point, guy, it's an extremely useful tool. I think it's gonna be even more useful over time as it gets better and better.

Let me give you a use case that we talked about. 'cause and this will become readily apparent to all of you, I think. So vendor A decides that it wants to raise licensing fees for its platforms.

We've seen a lot of that lately. Um, and they pick a, a price point for that hike that's just kind of right below the cost of moving off that platform. So people suck it up, but imagine it didn't cost as much to move off that platform.

And then maybe vendor a that rose prices miscalculated and more people will migrate away to something else, which we've seen a lot of people trying to at least experiment with. So Is there any specific vendor you have in mind there, Mike? This is like the, all the characters in this are fictional and don't, if they may resemble some real, We, we've changed the names to protect the guilty Boy.

You're a little transparent there, Mike. Uh, Hi, Joe. Friday here.

Drive. We have, we have always done this. I mean, you know, we're, we're talking about this like, it's a new brand new tool, but come on.

We've had COBOL to CC to Java. We've done this for a long, quite a long time. We've had these converters.

Uh, you know, maybe AI makes it better. Um, I'm hoping it does because I've used some of those conversion tools you go from see to Java and there's a lot of, it gives you a baseline, but there's a lot of work yet to do. So I'm hoping that it does a better job of what we used to have in the past.

I hope so. I, I, Well, yeah. You know, from a VC point of view, right?

That typical VC looking at how it looks at the world, there's a big opportunity, there's a big market, right? There's a lot of legacy applications that are gonna have to be converted to a cloud native architecture over the next three years, five years. You know, they, I I was reading and think 85% of greenfield new applications will maybe even more will be cloud native architected from, from scratch.

But you've literally got millions and billions of existing applications that need to be converted that need to be modernized, is the word. And, Uh, But, but to market Tracy's point, a big, the way it's been done historically has been, you know, people went out and they hired some global SI to come in and they said they would do this project for them, and then the bus shows up and about 30 kids roll off and they move in for a year and a half, and then they never actually finished the gig. So I'm hoping that this gets better to enable what you just described.

But, But you know, uh, I think a better analogy is moving from private data center to cloud, right? What'd we see? That first wave was just lift and shift, right?

And, and it's only now 20 years later, 15 years, 20 years later, that we're seeing real cloud migration that maybe even not some of it's cloud native, but even the ones that are not cloud native, really taking advantage of a cloud architecture versus just lift and shift off the on-prem data center or the closet. Well, we're li we're living this in another kind of parallel universe, and that's not called modernization, but it's called development using AI tools. 7, you know, it, it we're, we're in an era now where we're interactively saying analyze the code.

Doesn't have to be COBOL from 30 years ago or 40 years ago. It's my code I just wrote or I picked up in this new job or part of a code I haven't worked with before. Maybe I know it really well.

But we have AI now analyzing existing code ba code bases and making changes to it, recommending changes, ally making changes in some cases with, uh, with Claude code. So it's, you know, it's on a spectrum now. It isn't just moving the old stuff to something new.

It's taking what we have and using AI to continue to develop it. I think we need Mel Gibson from Braveheart just screaming freedom and, and everybody will get going. Yeah, it didn't end Well for him.

I think we got enough people doing that in the country, Mike, take it easy. But, you know, to Aaron's point, I think the, the taking the monolithic and breaking it up into, to decoupled components and features is probably the biggest challenge companies have. And these kinds of tools can do that better.

At least get, again, like I said, it's not perfect, it's a baseline, but to be able to break it up is really, can be really challenging. And so if we're using AI to make, you know, you know, modernizing our monolithic into decoupled architecture that we can take advantage of cloud native, all the cloud native features we've been talking about for the last, I don't know, seven, eight years, um, it's probably about time we have a tool like this, and that will help a lot of companies move into that direction. Fair enough.

Here's what I find interesting. So you described earlier, Tracy, you know, the, the sort of the old way, the old way up until last year still going on now, which is, which is, yeah, like originally just all this manual lay we're talking 30 years ago or whatever, and only for those applications where you really needed to do some kind of translation and experience and logging and then starting to post these things. Here's how you do it.

And then, then automated tools, like you say, started to appear. These were not AI based and all this work has gone in and it's such that we now have an open source community. com, how to glue this to that, right?

This is now like how to move from this code base to that code base. And then here comes modern and says, Hey, thanks for all the work. We just trained an AI on this and you can pay to do all of this so much faster.

You know, that's the story that sort of popped out at me is, uh, you know, thanks, thanks for all the work over the decades, guys. We got, we, we now have an AI trained to do it. But isn't Isn't that the AI way?

That is the AI way. And, and I completely agree about the usefulness of this. It's wonderful.

It's terrific. Um, it's an interesting example of something, uh, uh, that's not me by the way. I, I I have the horns someone else.

No, no. Mitchell has the dog sound effects. Um, you know, so, so something you were sort of talking about, Alan, uh, uh, we've been talking about a little bit is, is open source under threat?

Mm-hmm. It is an under threat because now we have all of this community work over decades and all these different areas, and we can, we, you know, AI is trained and then we're gonna put more human data in, and then maybe we're gonna start using, we use synthetic data already. And at what point does it become this recursive circle that's training itself and going off, I dunno, the edge of the world, Isn't there a tipping point guy is, is we, we generate so much more code using AI or, or modify it at some point.

You have to have AI to be able to manage it. You know, we have so much code. You can't hire humans to do all the work on it.

You have to be able to kinda reest it, modify it, change it, whatever it is. So we're kind of creating this world where it is inevitable that you have to have ai if you're gonna be generating this much, this amount of code this fast, I think you, I think so. If you ever saw the bill from a global SI on one of these projects, you will lose your sympathy quickly.

Oh, for sure. Yeah. I was in one of those buses that pulled up Outside early in my career.

Yep. All right. Let's take a break here on the gang.

We're gonna come back and discuss C block. You know, HashiCorp part of IBM? Is it a kinder, gentler Hashi?

You're watching? 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 folks, we're back. And as Alan alluded to, yes, Hashi Corp is now finally formally part of IBMI think it operates semi independently, but the issue becomes, well, where does Hashi Corp fit in with the rest of IBM, including Red Hat and ft o?

And they have some ambitions in that space, but Guy, you've been following this for a little while, talked to a lot of the folks at Hashi Corp over the years. What's your take on all this? Where do you think it all winds up?

Well, I think it, what what's really interesting here is, um, so IBM right, uh, or the original gangster of, uh, of, uh, um, you know, computer systems that transformed itself through, um, software delivery to now, um, essentially a, a a A services, uh, firm for building, um, and deploying and acquiring and managing enterprise software and other types of software. Um, where, you know, the acquisition of Red Hat seemed to start this latest phase of, um, enabling organizations, uh, owning and running off the shelf, as well as building and deploying their own applications on various platforms, puts IPM in a pretty strong position, both in the public and the private sector. So where does HashiCorp fit into this?

I mean, most famous product, Terraform infrastructures code, um, ways to, uh, tighten the integration and responsiveness back and forth between the, um, the, the code, the software where they're off the shelf or developed, um, and the infrastructure. Um, I don't think it necessarily means we're bringing Terraform Disease systems or anything like that sys as being the big mainframes that IBM has, but maybe it does. Maybe it does.

And this sort of general enablement of IBM in the enterprise and in the public sector, which the two big areas where IBM plays of DevOps, um, has been, I think, you know, uh, a maybe surprising force of good in the industry. Um, red Hat remains independent. We can expect HashiCorp itself to remain independent, Apptio's remain independent, you know, as brands with their own go-to market, their own user base and so forth.

While the main line IBM, uh, uh, uh, you know, product lines or service lines really get to incorporate and use and influence development of all of these, they all have a part to play in application development, um, uh, production and, you know, delivery to user basis for the business or the agency goal. Uh, the only other thing I'd add, um, is that, um, uh, you know, uh, Hashi Corp in particular has a really robust set of tools around automating and running and maintaining service health of all kinds of infrastructure. And that helps broaden IBM's ability to also be an additional player as opposed to a single source.

They've had this sort of single source model forever. They take on the entire application. And by the way, when you talk about off off the shelf enterprise applications every off-the-shelf enterprise application has all kinds of, you know, customized and own code in the enterprise or in the institution, um, that adapts that enterprise software to the particular needs and uses of the organization.

There's lots for IBM to do there, even if they are, you know, secondary vendor or secondary player to begin with. Mm-hmm. So, Mitch, go ahead.

I'm sorry, Mitch. They were describing it somewhat like this where Terraform is kind of like day zero and Ansible is day two management of the environment, and those will be those different automations. And I'm not quite clear if that makes sense or how much overlap there is between Terraform and Ansible as we kind of go forward.

And frankly, in the age of ai, I am wondering, you know, are those just all gonna wind up being backend services that some AI agent is gonna deliver and they all just kind of fade away in the background? I, I think of it as just platforms that are automated, right? Processes for provisioning, updating configurations, configuration management of that.

You have to remember, you have a huge embedded base of Terraform users, open source and HashiCorp, um, and uh, so open to tofu kind of folks. Um, but of course also Ansible, you know, it's been one of the early earliest, um, that and Chef, um, been around a long time. So it Puppet and Puppet.

Yes. Thanks. Exactly.

So I, I don't, I don't think you can say this is day zero and this is day one, and this is day two. People use these tools across the, both the operational and development life cycles. They use 'em to create development environments.

They use 'em to create test environments. They use 'em in production. So you know what the blending of all that will look like.

Maybe they stay somewhat separate since they're in business, different business units, maybe they all benefit from Watson ai that becomes a feature, a part of these technologies as part of the AI strategies take place. But we'll see. Can I be a bit of a jerk, Mitch, and say that, uh, Ansible is the, is the, you know, Linux cloud native, ERL sort of, uh, you know, religion quote unquote, whereas Terraform is a lot more the enterprise religion Enterprise.

Uh, we use both. I mean, one of, there's to me, they're completely separate tools. Yeah.

You know, I seeable overlap a configuration. Yeah. The Ansible is, you know, that's what, that is a full on DevOps tool.

Terraform is a platform engineering tool, you know, and that's a good way of Looking at it. Yeah. And I, I get using both because you have to go and stand up an environment before you can point to it.

But guys, I I want take off the rose colored glasses here for a second. If you think Red Hat Apptio name other IBM acquisitions exist as quasi independent companies and have not been assimilated into Big Blue, I've got a bridge for you guy. There's one right out the window there.

Okay. Red. This ain't, this ain't, this ain't Red Hat pre IBM, But Well, no, no, I, I referred to the brands remaining independent.

There's Sales teams, independent marketing teams, they're allowed to go and continues to develop their own Customers. Yeah. Because it goes to the heart of what is IBM today, right?

They spun off NDL right then, but IBM itself still remains a, a consulting firm. And now, and, and they always prided themselves on being able to, and ndl still does, will we'll help you deploy whatever the right tool for your job is. But now they have some favorite tools.

They have Red Hat, they've got Apptio now they've got Hashi. And so the IBM consulting team, you know, those are their favorite tools. I'm gonna assume the, the underlying the, the, the brand Red Hat, and I assume it'll be Hashi and, and Aptio, you know, they're still selling those products.

But in a perfect IBM world, those products are wrapped around some sort of version of the IBM Cloud, some sort of version of, of Watson X or Granite or whatever the IBM AI's gonna be. But it's all wrapped around IBM services, right? Because that's still the mothership here.

And It Yeah, go ahead. It, it buttresses, it not buttress, it supports greatly the IBM services offering. But you use the word consulting.

RY is the consulting arm that got spun off. Yes. I, I think of IBM when I said services.

Well, ND is global services that, That's, that's not entirely correct. NDL is a services company that does manage services in a lot of maintenance work, but Ken Build Field, IBM Global Services build exists within IBM and that's still a huge Driver's. Okay.

Yeah. Now Hasi, let's remember how Hasi got into this mess, Right? And, and look, Mitchell Hashimoto did an amazing job with Hashi and he started that company, I think he was 18 years old and he built, there are two or three Terraform is probably in and of itself a multi-billion dollar pla uh, project, uh, you know, product.

And then don't forget, vault and Secrets Management and all that good stuff is, is big. And there's a third, and I'm not remembering it right now, but, Or the service match console. Yes.

And you know, they changed their open source licensing and there was a big pushback in the community, right? That was quite a, quite a row over at Coup Con, uh, two years ago or whatever it was. 4 billion.

If you know a billionaire. A billionaire, that's a big deal. 4, it's a great pickup.

They've got three great products. I think the issue is gonna be how well they integrate into Red Hat, how well IBM services wraps around these things. How well they work with Ansible or, or in the finops or the rest of the I-B-M-I-B-M security.

IBM security's still a major player in the game, right? Man, they got Vault to play with, you know, to, to lead with. Now that's gonna be a big tip of the spear for them as well.

So I think overall, this, this, I always thought this was a great deal for IBM. It was a great outcome for Mitchell. I think Hashi could have gone on to do Hashi Corp could have gone on to do bigger and better things, perhaps independent.

It'll be, I think we will have to see how the big bluing of, has she corp. You know, talk to me in two or three years if you have brain drain, if you have continued development of product, if you have continued integration that that's Well if you My take, yeah. If you want me to be equally pessimistic about, well you're not really being pessimistic.

No, I'm not less, less rosy about it. Um, I do think you have a point because IBM acquires these companies and they start to turn more towards details. Right.

Really important and helpful and valuable details as opposed to pushing envelopes or, or, or innovation. And that is not, that's just a different business model, uh, and a necessary one. And I really, I want to emphasize that.

Um, I don't think that's a bad thing. I don't think standing Up will Be doing, it's BM incredible what new things no one has done before is as is as much as it's, Hey, there's a reason they're around Guy. There's a reason they're around a hundred plus years, right?

There is what they do now is Red Hat the daring darling of, of the Linux open source world that it was seven years ago. Probably not. So, so I have a question for Mitch.

Will IBM Open Source Terraform under some sort of consortium play and, and, and, and maybe much the way that Red Hat has been adding more things to the consortium later. And then will that bring open Tofu and Terraform back together? Or is Open Tofu off on its own and maybe we'll gain momentum because, you know, there's a lot of folks out there that aren't in love with IBM and Red Hat.

I don't think Open Tofa is going anywhere. No, it's, I think it's Gonna stay right there. It's hard cf.

Yeah. And they're not gonna, they're not gonna open source bring, uh, bring, uh, sorry. They're not gonna open source their, any of their products.

They're gonna leave 'em as is what I'm saying about My Wait, wait, wait, wait. Mitch, let, let's, I, you know, there's, there's, there's, what's the word I'm looking here? There's nuances here.

Yes, there is an Open source Version of Terraform. Terraform was open source. They just, yeah, they changed the license a little bit.

Why Would, why would they go back and Open? I don't think, don't they'll go back to an os I license. I mean, you step back and look at all the things we're talking about, whether it's Red Hat or Ansible or Terraform Vault, all of these things have been around for a while.

At least 10 years if not more. When you go back to, to Red Hat. And so what is IBM acquiring?

Yes, they're acquiring product companies. No, they're acquiring customer bases that use all these products, right. That they can serve.

Right. They're not buying it just to sell a lot more product. They're buying it.

'cause they're getting massive customer bases from this. It's huge. Ansible's been around for a long time.

There are a lot of people that use it. Same for, for, uh, Terraform. So I, you know, you talk about the consulting services in, in the kind of what got spun off with ndl.

IBM is still an operations infrastructure process kind of company. That's what they serve really well. That's what their bread and butter has been for a long time since they've shifted out of just doing mainframes.

You can argue mainframes were infrastructure too. So, so Well, don't don't add application management. I just wanna put in No, that's, but that's part of it.

It's not, we're not talking about IBM's buying Cursor. You know, we're talking about IBM buying staples that have been out in the industry for a while because That's, they got, they got customer, got Red letter brands here with Hashi. They got 3 billion.

They're Great companies. I'm not disparaging them am all, I'm just saying they're not on the bleeding edge of acquisitions, let's be Frank. No, but, and also to the point on the open source.

Hey, red Hat changed Rail's license too. And a lot of people push back. Oh Yeah, yeah.

But they're still around. They're still around. I, so no, I do not see IBM going back on the licensing change.

I think Open Tofu ISS doing just fine under CNCF and, and whatever your cup of tea is, your cup of tea is. But Mitch, and as we've all been, yeah, we've been saying that this has been, so these tools are pretty, I don't wanna don't wanna call 'em old, but respectively they are, they're old, They're stable, mature tools. They're Mature.

And many of, many of their competitors we don't even talk about anymore. You know, puppet and Chef. Those tools have, you know, they're slowly being replaced by other tools.

And I, I think what we should be looking at is if IBM has, you know, Terraform and Ansible together and some of these other tools, isn't this a way for them to start looking at how to put some money behind the space in terms of ai, right. They, they basically own. Now the, there aren't too many other tools that we've talked about in this space.

Terraform and Open Tofu kind of are it, I mean, Lummi has something out, some stuff out there. Cross Plane got a lot of attention for, uh, quite some time. I don't see those very, very often anymore.

Um, I see Terraform and Open Tofu being the two that are, uh, most competitive with each other. So, uh, I think that there's a bigger play that we're, we're, we may not be seeing, um, that IBM sees. And how do we disrupt both this configuration management and IAC uh, these platforms?

And Don't, to Your point, Tracy, I think we, the reason why we talk about Ansible, that's 'cause Red Hat bottom, otherwise we Would talk about otherwise because Right. If it was progress or who bought Puppet, the people in Minneapolis, uh, Um, The testing company Horse or, or Right. And you, you see where those are.

But let me just add one other thing. And why bullish on IBM, they do have the ai don't, don't underestimate the work they've done with Watson all these years. That's what I'm saying.

Yep. And don't underestimate what they've come, you know, there's this granite thing actually, if UR is the Ryan Shroud over its signal, 65 Labs has done some work on, uh, on, uh, granite. I think the report is available.

We're gonna feature, I I interviewed Ryan on Tech Drunk tv. I think it's out today. It's a great paper.

Definitely Checking it out. Don't, don't discount their quantum work too, which Is and their qua, right? Well, Quantum's a whole look all of a sudden, guys.

I don't know. No, That's a, that's a, that's a, that's a service to expose, just like, you know, talking about gay. But in the last two, three weeks, we're seeing, we're seeing quantum sneakingly becoming real before our eyes.

I actually, can I give you That's, that's why I mention it. Yeah, exactly. Can I, can I give you a nice word for old just so you have it in the future?

It's called venerable, as in mainframes are venerable. So then, you know, You don't have to Well, thank you from the dean of Paris. That's your word for today, folks.

You college or something. You Get that venerable. And I want everybody to acknowledge that Alan has said that we might be on the, you know, that quantum might be here sooner than 10 to 15 years, which was another conversation we had.

And I was like, but we might be here. No. So now I'm seeing maybe 2028.

I, I actually copied a offer of LinkedIn. Someone posted a quantum ecosystem with all the logos for it. I, I'm thinking instead.

So yeah, this is not a quantum discussion, but Tracy, I think it's next year. I don't think it's 28. I think it's next year.

com, something like that. Not It's time. It's time.

Just gimme an Yeah, we're good to go. Just going back to this conversation, I wanna point out that any of these, uh, tools that are infrastructures, code, um, what other kinds of tool, even Ansible, GI Ops, they are in a position to be disrupted at this point with ai, all of these tools. So we should be looking at what that disruption looks like.

We should look, be looking forward, uh, and looking forward to it because it is time. And, and, and this is the case for, you know, helm charts, uh, the Docker files, uh, Jenkins workflow files, all of these types of scripts that we've been Relying on. All vulner, not vulnerable.

Vulnerable. They are vulnerable for disruption and the disruptions needed it's time Here, here we Go. Check out cloud code if you wanna talk about disruption.

I think that's Alright guys, I gotta reign this in. What a great discussion. Tracy.

I think you're dead on, by the way, that might have been one of the best closings we've ever had on Techron gang. Mike, would you say that was venerable? I I would say you're venerable.

So there You're, I'm venerable. Yeah. Age, like fine wide.

Alright, I think we all are. Hey, we've Got vulnerable. I feel vulnerable.

I Vulnerable Mitchell and I wanted to do a commercial like that when we did still secure. It was supposed to be like, are you feeling vulnerable? Have you been intruded upon?

Um, come to Still secure anyway. Yep. Yes.

Um, okay, I lost my train, but hey, we've got Techstrong TV coming up after this. Stay tuned for the rest of our day's programming. Tracy, Mitch, guy Mike, thanks for joining in.

Thank you for watching this. Alan Shovel, we're out. This is Textron tv.

Hey everyone, welcome back here to techron tv. I'm really happy to have our next guest on here. It's the first time he's been on.

I hope it won't be the last time I'd like to welcome. And if I mispronounce, I apologize. Nora Spu, close senior VP and general manager for WebEx devices over at Cisco.

Nora is, how bad was that? No, I think you did a good job, Alan. And, and, uh, you know, uh, with a name like that, as long as it closely resembles my name, I'm, I'm perfectly fine.

And, um, I actually head up, uh, employee experiences at Cisco now with, uh, both the WebEx suite with calling and meetings and the rest of the Suite plus devices. So we have lots to talk about Today actually. Absolutely, absolutely.

And, um, thank you for being so gracious about me, mangling your name. I'm sure I'm not the first or the last person, but, uh, for those at home who might be wondering, snorts name is of Norwegian descent, and it's a very, we're not gonna go into it here, but it's a, a name with Rich, rich in history and tradition, and I'll leave it at that. Um, so snore.

Everyone out here has used WebEx, I think, right? Other people have used some of the other solutions out in the market. Other people say I don't really care what I use as long as it works and that that's okay.

When we think about WebEx though, and WebEx devices, it, it's more than, you know, the mission may have started out as just doing simple video conferencing, but it's grown into something much more rich or much more expansive, much more useful. Why don't we, if you don't mind, and I don't wanna put you on the spot, but I am, tell us what, you know, talk to us about the mission now. Yeah, so I think the mission, if you think about it, is that when we look at any collaboration tool, whether that's from Cisco or from any of our competitors, the whole purpose of that, I would say are two things.

First of all, communication today, using video, using, uh, chat, uh, you having devices, et cetera, is mission critical for the companies out there. So I think that's number one. And that has dramatically changed over the last few years.

So, uh, it has to be reliable. It has to provide the things you need when you need it. The second thing is the technology should never get in the way of what's happening in the meeting.

I tell my team when we are developing these products, that we should make a product that people find easy to use that doesn't get in the way of what they're doing. And that should be the best supporting actor if we're talking an Oscar term of actually the real meeting. So we should never get technology in the way of, but it should do what you expect it to do, uh, uh, when you need the different type of functions.

And I think that creating a great product, creating a great user experience is key to be able to create that. Yeah. And, and you know, if I, I'm far from an expert on, on in this matter, in this subject, but, but creating that experience is I think kinda what separates, excuse my sexist, but what separates the men from the boys, if you will, in, in this whole area, right?

I think kind of doing basic video conferencing is almost table stakes these days, but creating a rich user experience, create, adding all of the, the, the surrounding richness, if you will, is, is what distinguishes, you know, premium from, from others. Yeah. And, And I think there are the two facets to that, if I may.

Um, one is actually the people that are using the service, uh, uh, in a meeting, in a conversation, uh, that are using the equipment and everything that actually gets stuff done. But then you also have the people in the organization that own and operates. That is the IT organization.

That's the facilities organization that it's actually running this service. And as I said in the beginning, with this now being mission critical, you need to make sure that they have all the right tools as Well, and I think where Cisco has a strong offer is that we have both the meeting and the calling and the contact center backend. We have, uh, application that runs on your phone, on your, uh, laptop.

We have the hardware devices as the front end. We have a fabric of AI that actually goes across all of these, both, uh, uh, both all the way out at the edge and in the back. But then what's interesting with Cisco is that because of our networking and security, uh, business, we also have the manageability and the observability that will actually allow you to run this and, uh, and operate this at scale, uh, as well.

And I think that bringing all of these things together and think about that holistically, uh, is, is absolutely, uh, absolutely, uh, key to us. And we call that full stack collaboration because it basically builds, uh, on, on everything. Absolutely.

One thing you left added there that Cisco brings to this security, Uh, absolutely. Security and security is woven in. Thank you for reminding me.

And, uh, uh, you know, this is my elevator pitch when I, whenever I asked why Cisco. Mm-hmm. This is, is really the elevator pitch.

And, and if I can go into some, some really deep details, uh, on the networking side, we have a tool called Thousand Ice, uh, which basically means that you can do full, uh, uh, overview of your network or all the way from the cloud, all the way out, uh, uh, into the network. And we even have implemented thousand ice agents on our devices, which means that, uh, that we take things from the networking business, we introduce that into CoLab, which means that you have a whole different suite of tools as well, uh, that that can actually be used for people that own and operate the service. Uh, and, and, uh, I think that those tools are also super powerful.

Agreed. Agreed. They are, um, snore.

If it's okay, I wanna jump in. We, we've kind of been skirting the edges of it, but let's dive into optimizing IT and employee experiences using things like scalable video collaboration, streamline workspace design. When, when we talk about that, dive in for us here, if you can.

Yeah. So when it comes to, to scalable, um, I think scalable comes one for the number of participants you can bring into meetings. And, and if you can do large scale meetings today, we can cover meetings up to a hundred thousand people.

So that's one part of scale. The other part of scale that's really key to us is the ability to scale your deployment. Um, we had a, uh, an organization that during COVID went from two meeting rooms to 600 without adding people to their IT org because it's scaled, uh, because of the tools that are available and because the way we also use those tools in, in, in, in the manageability and observability of the service.

So I think that scale comes from, from both ends, um, so that you can actually increase your footprint and you can do this without, uh, without adding people. I think that is also really key about, uh, about scale. Absolutely.

You know, you mentioned AI before. Usually the, you know, we have the par the balloons go off when someone mentions ai. Right.

How long can you go without mentioning ai? What role is AI playing in that, though, in delivering that sort of scalability without adding, you know, additional IT resources, which are at a premium today? Yeah, so with ai, I think the way we have been thinking about ai, uh, at Cisco is really along three axis.

Uh, we started incredibly early with a partnership with Nvidia back in 2015. That's 10 years ago. Uh, so all of our Cisco devices have actually been running an NVIDIA platform for a decade.

Uh, through that we developed a whole, uh, uh, library of algorithms out at the edge that we've been using, uh, all along. So that's, that's something where we've just put stone on top of stone on top of stone that has been helpful for, uh, better video, for noise canceling, et cetera. And we, we do that and we, we call a lot of what we do, uh, there, RMM or realtime medium models where we are actually using ai, uh, on audio and video and, and, and using that.

Then we use large language models, uh, to transcribe meetings, to, uh, take actions to do all the things that, that you expect from AI in, in 2025. And this is core to any type of meeting. And to be able to, uh, to actually use that and use those rich tools.

The third thing, which I think is pretty unique for Cisco, is that we also use AI on the manageability side. So we have a tool called Control Hub, where you gather all of the information from your, uh, from your estate. And let's say you have, uh, a problem in a room where, um, uh, where, uh, something is going wrong or you have a problem in a network where, where there are challenges, then we have the ability to actually use AI to prioritize, to, uh, propose ways of solving that.

They would actually go through a lot of different tools to be able to gather that information as well and say, you know what, the first thing you should do is to fix this problem because that has the highest impact, that has the most amount of users or the highest seniority of meetings, et cetera, et cetera. And so for us, AI goes really across all of those three. And also with the acquisition we made of a company called Baby Labs, uh, some years back, we have some advanced AI technologies when it comes to optimizing for voice, take out, uh, uh, any type of disturbances as well in, in the meetings.

Excellent. Sonora, I'm gonna ask you to put on some crystal glasses here, if you will. All of this we've been talking about is great.

We've come a long way from just the basic conference call, video call, but the promise is to deliver so much more here, more immersive, more, more useful, I guess is the best word I could think of. More valuable If I, if I asked you to, you know, look in your crystal ball and say, Hey, what, what can we deliver that would make this even more valuable? Where do you, you know, where do you think, and not, maybe not just Cisco, but the industry in general, where are we going here that can make this happen?

Yeah. So, uh, and I think this is valid actually for, for the entire industry. Uh, so we were working a lot on what is going to be our vision, uh, going forward.

And, uh, it took us a long time to land on two simple words, and that is what we call distance zero. And what we mean by distance zero is that regardless of where you are attending from, regardless of the shape of your meeting, it should feel like you're in the action. Uh, I think that if you look at what we did on the Covid with all of us had one square each, uh, I think we had a good experience for certain type of meetings, but when you have people back in the office, you have people calling in from a remote, and then all of us sudden you're going to discuss an object.

How do you make sure that there is zero distance for everyone in that meeting when that object is being discussed? And what we are striving for is to make sure we tear down the barriers between people that are together and people that are remote. And that we're also trying to not only make that about the human and the human interaction, but also when you start discussing objects.

That is why the collaboration that we have with Apple, uh, around stereoscopic video, uh, there were that you can basically, now when you use WebEx meetings and WebEx devices, you get 3D stereoscopic video used using Apple Vision Pros. We have brought down the distance as well when you start, uh, when you start, uh, discussing objects and you start discussing, uh, both concepts and objects together, et cetera. So I think that if you asked me to look into the crystal ball, I think what we are going to strive for, um, is to really try to drive distance zero across all of the meeting types and all of the type of work that you will do in an organization.

And I think we've just scratched the surface there, and I think a lot of things are going to happen in that space. I don't disagree. So we're about outta time, but for people who want to get more information, who wanna plug into what, you know, WebEx is cooking, what, what's the be what's the best place to send them out?

com WebEx, but give us, what do you where, give us the on-ramp. Uh, so, uh, the, the OnRamp I would say are a couple things. I mean, first of all, the obvious ones that you just mentioned, go to our, uh, go to our web landing pages and, and, and things like that.

But what we have done is that we have created a tool that you could just download and use. And in that tool, uh, you can actually just specify the sizes of your room and, uh, the number of people you would like in that room. And then the tool will actually propose for you the type of equipment you should have there, the number of microphones, uh, if there are dead zones in the room, or maybe even if you're over specified it, maybe you should take some equipment out or may, maybe you could have a smaller screen.

And I think that using that tool, uh, is something that will really, uh, get you starting. And I think that that would be a great, uh, starting point and we'll, we'll send a link over. Absolutely.

We'll have it there. Snore. Thank you so much for coming here on Text Trunk tv.

We appreciate you, uh, coming on here. Um, you know what, for people, look, everyone's going to conferences again, right? It's no more just virtual, which, you know, it wasn't bad with WebEx, all this virtual stuff.

It was good for it. But where, where, you know, anywhere in the world that you can think of, you guys are gonna be at that maybe some folks in our audience might be able to get some hands on. No, absolutely.

And, uh, you know, we have Enterprise Connect coming up, uh, this month actually. Uh, we'll have a big presence there. Uh, you know, we have ISE that was just done in Europe.

We have Infocom coming up, uh, now and in, in the summer. And then we have WebEx one coming in the fall, and then we have three Cisco lives during the year. So there are a lot of possible interactions when you go there.

You could touch it, you could feel it, you could talk to the people that actually develop the GA or that's who we are. You'll be hands-on, meet people that can go deep with you. You could come and listen to our, our, our presentations where we try to take a broad, uh, approach looking into what's happening in the industry.

And, uh, it would be lovely to, uh, see, uh, uh, your audience there and, uh, it would be great to meet with. Fantastic. Thank you.

Thank you. Snore. Thank you for coming on today.

Um, senior vp, well actually that title's a little out of date. What, what is the right title now? You know, I'm, I'm more focused than what I do, which is I jump outta bed every single morning to make distance zero happening.

Uh, but I'm the senior vice president and general manager for employee experiences, which is basically WebEx, suite plus, uh, devices. And thank you for having me. It was an honor.

My pleasure. It was my honor to have you. Good luck.

Keep up the great work. Can't wait to see what else comes down out of this. It's an exciting time, certainly in the industry.

We're gonna take a break here on Textron tv. We'll be back in a moment. This is Textron tv.

Hey guys, thanks Withrow. We're here with Emily Long, who's CEO for Adera startup that just raised $15 million in additional funding for workload isolation technology. And I'm gonna let her explain what that is.

But Emily, welcome to the show. Thanks for having me, Mike. Appreciate it.

We've been trying to isolate workloads since somebody invented the virtual machine. So my question to you is, um, what's different about your approach here and what is the problem we're trying to solve? Exactly.

Yeah, so if you kind of take a step back, if you're looking at, like you said, virtual machine technology back in the day, um, what we're really focusing on at Adera and why we just closed our 15 million, uh, series A round, um, with Microsoft as one of our backers, M 12 as well as a couple others. But, um, the reason why we really are focusing on isolation at the container level is because in virtual machine world, there are a lot of isolation technologies that are fairly effective. But when containers came onto the market and people started using them, you know, over a decade or so ago, uh, containers actually have a false, uh, word to describe them.

Containers actually don't contain, which is quite funny in their name convention. Uh, and it, I think it's taken some time for us to really appreciate how much they don't contain. And so a lot of, um, the, the industry has kind of started to move on and really realize the risks.

Here. You see a lot of people talking about vulnerability, exploitation, and people's secrets getting exposed. And really a lot of that has to do with the lack of container isolation that's present today.

Now, Adera really focuses on the premise that you should be able to trust your workloads and trust your containers and have them be isolated as you really did with VMs back in the day. And so we really came forward with a isolation technology that really uses, um, a lot of older primitives using some older technology blended with some new technology to make it really able to be used anywhere at any time. And so we really focus on making sure that you can't get exploited for lateral movement, living off the land attacks, those types of things.

And so we care a lot about this, um, particularly in the age of AI because people are now using GPUs and even the attack surface on GPUs is exponentially greater and scarier. And so we ca really came forward to try to solve that problem at a really fundamental, simple way. 'cause there are actually some technologies out there that exist, but they're really complicated to use or have performance degradation and those types of things.

So it's been kind of this fight between how much do we lean into security and how much can we actually run our infrastructure, um, simply and and meet our customer's needs In this need to isolate kind of, uh, lead to some, for lack of a better phrase, I'll call it unnatural acts, where people were putting containers in Kubernetes on top of virtual machines to guarantee the isolation. But in so doing, adding overhead or maybe not being able to move off of a virtual machine altogether, which increased cost if it was a commercial one. Yep.

So, um, has this been something, I feel like it's a long time in coming, but is this something that's a little on the overdue side? Uh, we, we believe so, yes. I think the hard thing with computing, when you kind of look at it from a, a holistic perspective, you know, we, we end up with a lot of technical debt, right?

We're kind of like layering upon layer upon layering over time. You end up with top-down solutions that are kind of plugging certain holes here and there, and we end up with this really complex ecosystem of layered tooling. It is overdue, um, mostly because I don't think there's been anyone focused on really trying to solve it at the lowest levels.

And very simply, like you hear the premise of like, secure by design or secure by default making things just run securely naturally, which is really where we come in that's a little bit different. Um, there's people, you know, trying to look at kind of the isolation or, uh, I wouldn't even say isolation as much as inhibiting vulnerability, exploitation to be a problem by alerting you. And you look at your dashboard and you can see if something's going on.

That's really been the industry's response to the need for isolation because the problem itself had not been solved yet. And what we came in to do is really this overdue need is to solve it simply at the lowest levels, levels and being able to plug it in really simply because we, we recognize most of our team here at Adera has worked with enterprises for years and years, and you can't tell an enterprise to start over and rebuild, and you can't tell an enterprise to slow down their production environments because customers, you know, that they're serving have certain expectations. And so how do we evolve with the, you know, increased threat landscape, but also create a simplistic solution to do so?

And that's really where we came in on the isolation side specifically. And if I don't do that, it comes really hard to limit the blast radius of a breach, right? Because otherwise this malware starts moving around laterally and it's too easy to do.

So is that part of the thinking here? Yeah, I'm really, that that is the, the premise is that, um, because containers don't contain, if you get an exploit in one container and you're running containers alongside each other, they all have what you call a shared kernel state. So in any environment, you're kind of setting up, there's a shared kernel running your, your workloads.

If you get a container exploited, they can pop over to other c containers and the shared kernel, which in the current day and age means you burn your infrastructure down. You don't know where they've gone, you don't know what's been taken, you don't know where they're lurking. And so you have a really, um, unfortunate situation as a, you know, person who's running infrastructure to have to start over.

It's not, um, we, we wanna try to avoid that all together and, and we really should be able to trust the infrastructure that we're on. And, and that's really where we, we come in, is to make sure that when you're running your containers, if you have a isolation boundary around each workload, and the way we see it is that you should not have a shared kernel state. So we also isolate the kernel, um, that allows you to then not worry about the blast radius at all.

And so it really gives the power back to people running a secure infrastructure, um, themselves. So it's, it's pretty powerful technology. And again, like you said earlier, overdue.

So you raised the 15 million, um, I'm assuming you bought everybody at least one beer and but what, what on from here? Yeah. I mean, yeah, the virtual beer, but we'll, we'll come together and celebrate soon.

Yeah. Um, we actually, so, um, we, we closed the series A, um, recently, like I said, with Microsoft. We also had some other investors coming on, um, with Inq Tel as well as, um, mantis Venture funds.

And then we also had the, our existing events investors from our seed, um, in the Act six per five FPV come back in, we act, we actually ALS only raised our, our se our seed, um, three months prior to closing the series A. Um, the reason I mentioned that is because I think that there's just a lot of, um, recognition that this is a huge area for opportunity in making things easier. So really what we're focusing on now is our AI products.

Um, it's not AI in the way that it runs, it secures AI workloads. And so really what our focus is with this money is putting into the further an increased development or, or pace in which we're developing our G-P-U-T-P-U and DPU security offering. So when we're talking about kind of isolation of workloads and then being important holistically, um, over 65% of people are using Kubernetes and containers in their AI ML workloads already.

And we already know that the isolation primitives that exist aren't there. And so we're really here trying to push that forward as fast as we can to make sure that the amount of AI workloads that are being processed now have the same security guarantees with GPUs as, as we want to do with the holistic container environment. You know, I'd love to get your opinion, but we talk a lot about DevSecOps over the years, and we make, you know, some progress, but not as much as we would hope.

And I have to wonder how much of that is just kinda something we're doing to make up for a lack of a capability in the core platform itself. So, um, if we can isolate the workloads, can we just have better DevSecOps workflows based on how we deploy the software in the first place? Yeah, I would agree with that.

You know, there's incredibly smart people out there trying to do things themselves, but it's with the, with the inability to do something at the base, like at the actual infrastructure level, we will always be in a reactive state. You know, I think we've talked a lot about, um, or, or the industry has been talking a lot about the proactive measures of security versus the reactive measures of security. And we're putting a lot of DevSecOps teams in a reactive stance, and we really need to do better for them so they could spend time doing more important thing.

I not to say it's not important, but there, if we can actually stop it at the source, then we'd be able to enable them to do a lot better work. So yes, I think that, you know, we haven't really gone down deep to solve the hard problems that's really changing the way computing works, which is really our, our ultimate goal. Um, because we, you can't just keep stacking like the Jenga tower eventually will fall.

And, you know, what we wanna do is be able to like put the foundation back together again so that we don't have that problem where I, I think there's a misconception that it's too far gone and it, we don't believe that that's the case at all. And Yet if I look around, the bad guys seem to be just sitting around taking advantage of the way we built everything in the past and almost daring us to go fix it. Right?

I agree. I agree. And we are taking that challenge over here.

Uh, and, and it's a hard one. We know, we, we, you know, we recognize the, the depth at which you have to kind of change the way of thinking. You know, in some ways the industry has gotten comfortable with this idea that, you know, well, we have this alert dashboard, at least I know what's going on, all these alerts, but you can't actually then stop them before they start.

And so we're really working to shift kinda that mindset of we don't need to rely on this dashboard, it should still exist, but we should have context like what's important, why should we care, um, what's actually at day, you know, at risk. And we don't need to give any sort of attackers any easier way to get in than we already do. And, and we do believe that we wanna empower the industry with the ability to keep their infrastructure safe from the start.

So when you talk about this with customers, what's the part that's the most challenging to help them get their heads around? I think the idea that this is possible, we, we call it kind of the, uh, 15 minute skeptic effect. And I think it's because we've been in this industry so long to assume that it's not something you can fix, uh, and not do it in, in a way that's not performance inhibitive.

'cause there have been other open source technologies who have tried to do this, but when you try to run it, there's the, you know, 30, 40, 50% performance impact and it's just not a viable solution to use. Um, but most of what we get through is people being really, I can run this anywhere. It's that simple.

Um, because I think most people believe that to, to create something that really allows multi-tenancy, um, and to, to decrease costs in this way would somehow require some sort of major trade off. And that's been our big conversation starter here, is that we, we have intentionally architected it so that the trade off doesn't exist, um, because we don't believe that there should have to be one. And thankfully, you know, I'm, I work with incredible technologists.

We, you know, we've been really fortunate to be able to find a solution to this, this problem. And the other question we get is, how come nobody's thought of this before? Um, and I think it's, you know, again, you have to have a really deep knowledge of computer history meets the present day, need to be able to architect something like we've done Now Inertia's a powerful thing, and yet we are seeing the rise of these platform engineering teams.

So is it easier to have this conversation now because so many people are kinda rethinking the way the platform functions? Yes, I would say definitely. So, and, and also, you know, the, the relationship between platform teams and security is a really important one too.

And we found that, uh, for many years it's, they've been somewhat at odds with each other because you're really trying to, you know, a lot of times security tools require this just very heavy, um, large kind of lift. And so if things are slowing down and stuff like that, um, but when you're looking at platform teams, you know, they're really looking to simplify and they're really looking to do things optimally. And, um, we've been really fortunate as we've come out.

We've, we've only been around since April of last year, but we've had great conversations with large enterprises, mostly the platform teams too, because they're looking for this solve and platform teams too are also starting to get the lift of certain compliance measures, like specifically Kubernetes container based things through FedRAMP and stuff like that. So they have even more interest in trying to make sure that the infrastructure they run is inherently ins own, right? Simplistic.

Well folks you heard in here, Hey, if you keep doing the same thing the same way over and over again expecting a different result, they call you crazy. So that's alright, have to change the way we do this thing. Emily, thanks for being on the show.

Thank you, Mike, I appreciate it. All right, and back to you guys in the studio. Hey everyone, it's Alan Shimmel, CEO founder at Techstrong, and welcome to my first adventure on LinkedIn Live here.

We're starting a new show and we call it Shimmy says, because it's me saying whatever I wanna talk about. But it's not just what I wanna talk about. I want to hear what you guys have to say as well.

Um, look, we're gonna aim for 10, 15, 17 minutes here, so it's not gonna be too long. But if you've got something you wanna ask me or a topic you want me to, you know, comment on, I'm happy to do it. If you're not familiar with what we do here at Techstrong, you know, we cover DevOps and cyber and cloud native ai, ITSM and everything else.

So that being said, I really wanted to talk today though about what, what seems to be capturing a lot of new cycles. And that's this project Stargate that was announced yesterday by the Trump administration, along with in-person, uh, appearances by Sam Altman of open API of, uh, excuse me, chat, GPT OpenAI, uh, Larry Ellison of Oracle, and Maan of SoftBank. Now, there's a lot of people out here saying, holy mekel, $500 billion, that's a lot of money.

What a great thing. There's a lot of other people saying $500 billion. Who are they kidding?

All those companies together don't have $500 billion to invest in this. And even if they did, would they, when they would, they, when will they, what will come of it? How are they, are they all gonna play nice?

Because it's not just those three companies. There's Microsoft involved, and you could bet Google and Amazon and the usual cast of Tech High, uh, hyperscalers will be involved. There's another group of people.

And, and quite frankly, this was my initial reaction too, is now that $500 billion isn't coming from commercial private investment, that's money that the Trump administration's gonna take out of the federal funds. And it's kind of the payback to the tech bros who've invested all the money, all the money they have in the Trump campaign, and, you know, making gifts to the inaugural fund and so forth. So, you know, what, where does the truth lie here?

So first of all, let me say I'm a big fan of investing as much as we can into AI infrastructure. I do think that AI is going to change the very fabric of civilization, much the way the internet has. As a matter of fact, I think AI is the biggest thing since the internet.

So let, let's see what that has to, to stay on it. Um, I do think that we are in a race for technology, much like the space race of the sixties, except this time it's China or not the Soviet Union. And we want to take as much, take down as much as we can, uh, here in the US to con continue our dominance and lead in technology and specifically in this AI field.

But it's not just the us. I think this is a game of the entire western liberal, you know, modern liberal western world trying to do this. And I don't know how much they're gonna be willing to just abdicate it over to the US And this is a global game.

Make, make no doubt about it, right? You're gonna have investments from Japan, from friendly countries and people in the Middle East as well as Europe. I read an interesting point of view on it in Forbes today, which is really what they're looking to do is soak up as much of the venture capital that's being, you know, set aside for AI is possible before it makes its way to China.

And you know, again, I I took a different view of that 'cause how much VC actually makes its way to China. I think VCs have been burned. Western VCs, Western sources of funding have been burned investing in China because China follows a predictable path.

They take your money, they make goods until they don't wanna make your your goods, or they don't want to let you make your goods. They'll make your goods themselves. You see it with cars, you've seen it with planes, you've seen it with toys and clothing in factories.

This is what China does. They take the money, they offer you promise to their, you know, huge market. And then they, they don't exactly open the kimono, so to speak to their market and they wind up keeping it for themselves.

So I don't know if western dollars are gonna be flowing to China for AI investment. However, there are, there will be competitors for AI investment beyond the us. There'll be Canada, there'll be Western Europe, there'll be Israel, there'll be Eastern Europe as well.

Um, it's a global market that we live in. And even with that though, $500 billion, I don't see how, if that's a real number that we're gonna spend in four years, that's $125 billion a year. I just don't see us spending anywhere near that kind of money.

'cause we just, the, the capacity to do so is, is not there. Um, how much of it will be government? Is it for every, you know, 1 billion in private, you're gonna have 10 billion in government money set aside to this?

I don't know. And, and let me say, I'm not against the government putting money into this, right? If you look at every million dollars that the US government spent at NASA during the space race, it probably returned 10 x in in private a accomplishments either in new, new technologies, new products, new processes that really helped the American economy boom, from the sixties into the seventies.

So this is, this is an amazing kind of thing. Um, I, so I'm, I'm not against the federal government paying into this and, and making it happen. I would like to make sure that it doesn't just end up in the hands of a few oligarchs, right?

I think this is, it will create a lot of jobs. It will be a defining moment for the rest of this century if American can really get behind this. But it has to be done right?

It can't, it can't wind up being like a, a Vladimir Putin and his and his, you know, oligarch friends, divvying up this big pie that we all put into. I see we've got a question. It's from our friend Paul, and he wants to know, what do you think about the plan $500 billion investment?

Well, I think I just told you my, my 2 cents on it, but I, I'd be interested to hear what you guys think. A lot of people, or not a lot, but some people say that, Hey, AI is relatively unproven. Frankly, we haven't seen the results in terms of business that we thought we would see up to this point.

Well, it's still early in the game. What is that $500 billion gonna go into? Well, they're talking primarily about data centers, but in order to have the data center, you have to have energy that feeds that data center.

So whether we're talking, you know, I'm not going out and saying, let's go frack and drill, baby drill, but we need energy, whether it's compact, nuclear, hydroelectric, solar, wind, natural gas, some sort of clean, I would hope renewable sources as well. We need to figure out the energy formula. Secondly, the, the, just the cooling and so forth for these chips.

We need better technology, not just at the chip level. 'cause we need to make these chips. Right now, these chips are basically all made in, in Taiwan.

Daniel Newman, over at the Futurum group of which we're part of. Put out a nice LinkedIn post today with a chart. You know, the fact of the matter is when you look at foundry, uh, Taiwan semiconductor still has, I think 62% of the foundry market.

We need to change that equation and have those foundries here in the US as well, I think. Um, so you've got chips, you've got energy and cooling you need, you're gonna need more networking, right? Uh, there was a time I thought we had overbuilt.

I think we all thought we had overbuilt fiber and so forth. But whether it's 5G or other resources, we're going to need more of that. Jody has a question.

Will it create as many jobs as it potentially eliminates? There's not a doubt in my mind that AI will create more jobs than it eliminates. And the jobs that it creates are gonna be higher paying jobs than the jobs it eliminates.

'cause I think at the first thing it, AI takes out lower paying, lower hanging fruit jobs that is sort of remedial and the jobs that will create will be higher paying. I think the bigger question for this operation Stargate is will it create net net new jobs? So it's not just replace one for everyone you lost.

Does it create whole new classes of jobs? And not just the AI jobs you're thinking about? Someone's gotta build these data centers that's construction jobs and all that goes into constructions, architects, electricians, and plumbers.

And people are gonna have, you know, these data centers will be staffed by people. So you need facilities for those. You are going to need screens, you're going to need alarm systems.

You need, you know, everything that goes along with a modern data data center. So I think it create then you have the fact that the economics of the data center, the people who work there need to eat lunch every day. They need a health club to go to a gym.

They need doctors, they need schools for their children around these data centers. This kind of, and this is why I'm, I'm all for the government getting involved in it. This kind of investment is like planting a seed of which a whole town or a whole ecosystem grows up around it.

There are plenty of studies that show for every dollar you invest in infrastructure, it throws off three to $10 in, in other kinds of economic investments supporting that infrastructure. And I think the same is true here. Again, the, the same way, we don't want to concentrate this though into just, but a handful of oligarchs getting this money.

We need to make sure that these data centers are geographically dispersed, right? Maybe we don't put them in hub zones, as we used to call it when I was selling to the federal government, economically disadvantaged areas. I don't know if we need to do that.

I, I know for instance, there's a huge data center going up in Abilene, Texas where my son Bradley works and happy to I, having been to Abilene, I can only imagine what a huge data center will would do for that economy. Um, but we need to spread 'em around. It shouldn't be just Texas.

It shouldn't be just red states or blue states. It shouldn't be just disadvantaged areas. That $500 billion has to find its way throughout the US if it's gonna be there.

I mentioned earlier, Canada, Mexico, Western Europe, I don't, you know, they're not gonna sit on their hands, nor should they sit on their hands and let all this money flow into the us. I think corresponding dollars will probably flow into locations where it makes sense there, right? I I think capital goes like fluid to the lowest level where it makes the most sense.

So I'm hoping we, we'll, we'll see, you know, the, the, the repercussions and the, and the fallout from this will make its way even beyond the borders of the us. Um, but make no mistake, we, in the US look, we, we invented the internet. We've been, you know, technology has, has been the linchpin of our economy now since the nineties as we moved to a service economy, I think if we wanted to continue.

So we need to be the kings of AI technology and we can't, uh, sit idly by and watch other countries out, maneuver us out, out, fundraise us out, technology us out, innovate us. So I'm, I'm, you know, when you add it all up, the pros and the cons, I'm a huge fan of Project Stargate. I, I think if it's done right and it doesn't become some big fat pork barrel for a couple of tech bros who supported the current administration, this could be a fantastic thing for America, for the west and, and for, and for the tech market, right?

And we've had a tough year in the tech market. Last year was a tough year. I had a lot of friends looking for jobs.

This really could ignite things. And you know, I'm just really bullish on it. Another thing I wanted to mention is because of all that, we're able to see real innovation and techno and AI capabilities, which can disrupt so many different fields and bring so many more jobs and opportunities to us.

So I'm bullish on ai, I'm bullish on Project Stargate. I'm bullish on investing. To me, this is sort of an infrastructure investment, which is something even, I mean the Biden administration was in on with the CHIPS act and everything else.

I was bullish on that. I'm bullish on this. That's it for Shimmy.

Says this week we're gonna be back next Thursday, 2:30 PM Eastern time and I'll talk about whatever, whatever is happening next week. But until then, hey everyone, have a great day. Check us out on Techron Gang every day, or any of our techron properties is Alan Hummel.

We're out. Hello everyone and welcome to today's webinar, reducing Fatigue While Keeping Your Software Supply Chain Secure. A look into SNYs 2024 state of the open source report.

Each year Snyk conducts a survey on the state of open source security gathering trends and insight from peers on securing open source software. Join us for a closer look today at some of the statistics and get insights into things like why over 50% of security teams are failing to meet vulnerability management goals and which way supply chain security practices are still immature and how overtrust and AI generated code can lead to some pretty serious security concerns. Hi, I am Richard, she staff product manager here at snyk, and I'll be your presenter today and taking us through this, uh, insight into SNYs 2024 state of open source report.

You know, we're going through a high level overview today of each of the sections of the report. I'm going to touch upon a couple of observations from each of the sections. We'll then cover some key takeaways from that section and some talking points that can you, you can use in your conversations.

Uh, some overall background. You know, open source software is everywhere. It helps organizations really build software faster by leveraging the open source community credit and manage software that it presides.

Um, effective prioritization, kinda leave fixed fatigue. One area will cover will be the concept of security or fixed fatigue, including how it will fit in with, uh, SLAs. The software supply chain security challenge.

Open source is a key element in software supply chain security, but it's not the only element. Expanding automation and AI today are playing an increasing important role as well. Just, uh, an overview here of the, the 24 state of open source reports.

You can get it through the websites, through the PDF link as well. And we also have blog posts. Uh, we're going to go through a high, um, we surveyed over 450 technologists across application development and security.

We used many of the same questions we had asked in the 2023 state of open source security and compared the past results to this year's where applicable. And we mixed, you know, a, a number of yes and no questions, as well as thank ranking questions. Uh, we published this in December of 2024.

We'll run through the four uh, sections of that, uh, covering slowly expansion and open source security efforts and signs of exhaustion covering supply chain security, uh, remains immature. They're gonna look into there. Uh, also looking at continued misplacement of confidence in the security of AI generated code and evidence that of general open source security progress, uh, is progressing well.

I'll start with a quick overview of the software supply chain and in particular where the coverage of the questions fit in sny, because we're sny we, uh, put a, an a lot of emphasis on the developer. Um, there were questions around generative ai. You know, do you use it?

What about, uh, do ga uh, AI concerns you? What impact are you seeing from it? We also, uh, explored the open source ecosystem.

How libraries are choose are chosen, how they're chosen, and how often you make sure they're secure. We asked about the SCM checks and things like the C-I-C-D-A pipelines and commit and PR checks in your security practice. We also dug in on, you know, folks and what they're doing with SBOs software bill of materials.

We want to see where in the SDLC teams are bullying, insecurity and what they're doing to make it happen. And let's take a look at those results today. The first section, slowly, uh, slowing expansion into open source security efforts and signs of OPSEC exhaustion.

There are signs of slowing in the open source security efforts and in the DevSecOps efforts more broadly across many questions about supply chain security. We saw either little change year over year or surprisingly declines in adoption and usage. Some background and insights into the how the teams work.

Uh, we asked, uh, one of the questions how frequently organizations are releasing code today. Uh, and the code deployment frequency remained fairly consistent with the vast majority of our, uh, orgs shipping at least monthly. But when you look at this in the frequency of security scans, uh, we see that dropped with less than 50% actually auditing daily.

So a shift to the lower task frequency is, uh, is a view that we saw. So let's zoom in that a little bit more in a detailed view of this. We noticed that shift across the board compared to 2023, where the shift from the continuously or daily scanning to moving out to more of a weekly or monthly audits.

With that this is bad news for zero day vulnerabilities entering into your code base, uh, where they can enter in, uh, in between those frequencies. But for organizations, it's really about finding that balance between frequency of auditing and security testing and possible vulnerabilities entering the organization impact by the software supply chain or open source vulnerabilities coming in, you know, how has your org been impacted in the last year, uh, with these two areas? And this was really a two-way question.

How were you impacted and what did your organization do to try to make things better? If there was a decline in tooling adoption as well as a, a drop in education, it's clear to see that a large number of organizations are impacted by vulnerabilities. We saw there, uh, around 50% of organizations either with open source or the software supply chain have been impacted, but we must remain vigilant in the fight.

Continued effort to really educate and train development is a key in our fight against security. We did see a mixed delta in security tool usage this year. You know, we saw SCA went up a bit, uh, around nearly 70%, uh, but SAS and everything else went down.

The question, is this due to the economy or what's going on here? Um, we also saw a decline in license and security scanning. These are really gaps that can be pose serious risks to an organization.

Secrets obviously leaving, you know, it's like leaving your car keys on the seat in your sports car licenses on the other hand may not be as obvious. Knowing which licenses and license types your applications and the dependencies use allows you to be proactively verify whether or not your applications carry on known license risks. License compliance is still an important piece of the software.

Supply chain dependency analysis was pretty much unchanged from a yes no standpoint, but with a nice shift on where the depend on which dependencies are being tracked. This slight shift in direct versus indirect dependency tracking is encouraging to see as well. Tracking all your dependencies is key to fully understanding your risk from all angles, so you get a true insight into your security posture.

Overall dependency analysis remains stable. We can see here. Um, continuously, uh, testing and analyzing your package managers in an automated fashion is still very popular.

Now when it comes to SLAs and missing volfi SLAs, it's very, uh, we see that fairly strong SLAs are in place with organizations having a committed higher or greater severity fixes in under one week. However, when we see, uh, we see signs that meeting these SLAs is challenging though, for organizations with over 50% missing at least sometimes or more often, uh, than that in terms of frequency of missing SLAs, prioritization of vulnerabilities is important here to meeting those SLAs. It's also a sign of vulnerability fixed fatigue creeping in when these SLAs are starting to be missed.

Now, some key takeaways for our first section, you know, hence of AppSec fatigue are showing through. And some actions to take away from here is scan frequency can directly impact your ability to quickly react to zero day vulnerabilities. Yeah, the reporting can help when you're, you know, which package is bad, but you need to know in order to have that, putting the insecurity gates through the SDLC encouraging developers to leverage IDE security checks or testing via s uh, CLI and training is also very important at this stage as well.

Avoid or at least reduce security fatigue by prioritizing your best base on your business critical context applications. AppSec, you know, we need to keep up a good work here. Keep up that good work, but don't get discouraged.

Look towards your security champions to help you with this and educate new security champion, uh, program in place might be worthwhile looking into one and implement one for your organization. Section two, this section focuses on a bit on lessons learned and the software supply chain trends. Okay, so a middle, this is a fairly broad set of technologies and there's no way to encapsulate a gauge for software supply chain in one question.

This one was meant to be as much thought provoking or, you know, are you doing this since no single vendor out there can really secure your entire software supply chain? If they say they can, they either don't know what that actually means or well, they're, you know, lying to you. There are a few themes in this, knowing what's in the things you're running, making sure that you're right from a trusted source and then making sure that people can change stuff that they're not, uh, cannot change stuff that, uh, they're not supposed to.

Just like there's no single vendor angle. You may not need to do everything here, but if you are doing one of these things, you wanna ask you whether, what should you be doing instead? So the SBO parts are a good example of this.

You might not need to if you're monitoring everything through an SEA, but again, make sure that it's not a gap also in your organization. Some of the questions start to get into guidelines and specifications like the SLA, which helps organizations make sure that the processes are following good security practices. Roughly, um, two thirds of respondents are using SEA or SAS static analysis security testing.

Unfortunately, we don't know what that overlap is. Also to note that there's also some level of error in these surveys. These numbers are slightly different than the way the question was phrased, but it's the same ballpark.

Just over half of the respondents are scanning IAC, maybe not everyone uses IAC, so that's a valid reason not to use it. And your practice, uh, slightly more are performing das dynamic application security testing. Think of this as an automated black box testing that checks your application from the outside, um, for the same types of vulnerabilities that SaaS does.

Uh, just side note, you might have heard the sneaks recent acquisition or probably is a DAS and API security testing company. So we'll be adding that to our portfolio as well. So check that out.

There's also a low rate of container testing. I'd really hope to see that, um, closer to the CM level as the SEA honestly. And a lot of the c vulnerabilities that you might find in open source projects still live in your, uh, containers.

Hearing across the SE d uh, SDLC here we get a good insight into where the companies are placing the security gates across their I ds across the bold systems into their ci cd pipelines. Uh, it's good to see the companies are applying security practices across the SDLC, attacking it from multiple perspectives. Note that, um, the bars here do go to the right, it's a skill thing.

No single one, uh, of these is more than 50%. If you note this is one of those select all, um, apply all questions. So I expect that there's, some of these are stacked.

The first two that we look into are the bare minimum, uh, around CVSS, severity scoring, uh, and internal scoring systems. With that, it's better than no prioritization method at all, but this can be where a lot of fatigue comes in. Spending time fixing vulnerabilities that might not even matter.

EPSS score and somewhat related exploit maturity start weighing in here. And those take into consideration a bit more of the likelihood, which is a nice progression, but we're still looking at static prioritization here. Now reachability is where we start to get more personalized scoring.

It can tell you when there appears to be a call path from your first party code to that particular vulnerability. It's a nice indicator, but it's not, uh, only definitive tell that when there is suffering in a path, it doesn't tell you for certain that there's not suffering in a path. So it's a good metric.

But also, you know, not every vulnerability has that function level details to perform reachability calculations either. And the last one around here is around business context and deployment status. These are really the next gen prioritization tools.

Do you really need to prioritize a vulnerability in the component that isn't even deployed? What if it is deployed but not directly exposed to the internet? Sure, you probably want to fix it, but maybe not fix it first.

So section two takeaways. Um, good trends. Preventing monitoring may help offset the slow tool adoption, but relying on those static prioritization techniques can add fatigue and analysis paralysis.

With that, some actions to take away here is give developers the tools they need to secure your apps before they check in, like in the ID or through CLI, and encourage them to learn how to use them as well as security best practices. Treat external SBOs with the same scrutiny you would with your open source projects. And finally, don't rely on just the traditional or static prioritization techniques.

Look to those smarter fix, uh, advice and stick can help you with your prioritization, including a, a more robust risk score as well as those dynamic risk factors as well. Section three, continued misplacement confidence in the security of AI generated code. Three, focus on the impact of automation and developers increasing usage of AI in their coding practices.

We saw pretty similar results to the last year and as this, uh, descriptions of the between expectations and reality and even more folks using AI are more, are unsure if they are or not orgs fail or maybe hope the generator of AI is helping developers write more secure code. The stats show that that's not simply the case, even if you drop the very few here in this me. Um, question more than half the respondents said that it increased by at least a monitor amount.

So this is the first party code, uh, vulnerabilities. Things like SQL injections, cross eye scripting. Really AI is not, uh, securing as well as you think it is.

So it's a concern for risks introduced by j uh, gen AI might be also suggesting codes that requires new open source libraries. And if the libraries for those libraries aren't compatible with your RX policies, there could be an issue. There could also be hidden issues.

What data sets were the backing AI model trained on? If it's trained on code with restrictive licenses, it could generate, might be violating copyrights as well. You just don't know.

And here's, uh, where I always say with a gen ai, it's simply, uh, this certainly is taking the place for trust, but verify, make sure you're testing all the code paths, whether it be open source software or gen ai, code generated code. Section three takeaways, automation and AI risks, opportunities that disconnect between expeditions and real world experiences. Some of the actions to take away here, devs are likely going to be using gen ai.

Make sure they know your rules. If you don't have these rules defined, maybe come up with some guidelines for your development organization. Gen AI can introduce some efforts of security risks that handle, uh, the risks that handwritten code can, but likely must, uh, much more faster into your organization and really educate your developers on ai, both the pros and the cons.

Sns deep, deep code AI doesn't use off the shelf engines, but rather we use multiple AI models that are securely aware. But you also need to think about the s uh, SEA side of it to check the open source as well as the first party code. And again, educating developers on AI along with general security uh, practices is really key and important here.

Section four, uh, looks at some high level trends and the overall health of open source ecosystem with respect to fixing vulnerabilities across the board. The overall, uh, total time to fix for open source community has dropped per critical or high severity vulnerabilities. We've seen that across the years, and if we're looking at, you know, open source community is still our ping proprietary code fixes for the total time to fix for highend critical.

Uh, we see this across the years from 2019 to today, 2024, where shorter is better, and we see that over time that the fixes is getting implemented faster. So overall, it does look like the open source communities are stepping up, taking more responsibility and responsiveness to the impact vulnerabilities really have on their projects. So, some of the takeaways for, uh, section four, the open source community has really become even more responsible, uh, responsive and responsible for fixing critical vulnerabilities.

And priority teams seem like, uh, they're slowing down a little bit. Prioritization smarter is key here. Open source mat, uh, maintainers are fixing vulnerabilities faster, which means that you can remediate even sooner.

Checks for vulnerabilities earlier in the SDLC is key, uh, blocking emerge or using pre-commit checks or grid, but remediating these vulnerabilities before they even hit the SAM is even better. Take advantage of automa, uh, automated fixed prs here and check everywhere in your SDLC, uh, that you can continuously check your existing projects for new zero days and scan containers before you push and before you deploy. So, report, uh, conclusions.

Now, these findings suggest that the industry must find new ways to balance security requirements with team capacity while maintain vigilance against emerging trends, including those potentially introduced by the over reliance on AI tools without addressing these challenges and adjusting attitudes towards AI generated code security and organizations risk falling further behind in their security posture as threats continue to evolve. So, first step, um, is really assess your approach to security to prevent burnout and ensure sustainable practices in your organization. Second step is to improve prioritization in your vulnerability management and other software supply chain risk management tasks.

With that, thirdly, prioritize the adoption of fundamental supply chain and security measures, and deploy newer supply chain and security measures to improve your security posture overall. Fourthly, include more holistic risk analysis as part of the SLA determination to ensure security teams can focus more time on the risks that really matter. And fifth, lastly, take a more cautious and measured approach to AI generated code implementing rigorous security reviews rather than ensuring the inherent security of gen AI is important.

And again, education of your development organization is key ongoing practice for your security practice and your security posture. Now, that brings us to the end. Uh, don't forget to download your full report.

You can get it at the available link from that, and we'd be help, uh, happy to enter and a or ask answer any additional questions that you may have on the 2024 state of open source report from sny. Hey, thank you and, uh, have a good day. Hey, everyone, I'm Alan Hummel of Text Drug tv, and welcome to another episode of the Last Great Cloud Transformation.

You know, uh, we've been doing this show for months now, and we hope you've caught some of the previous episodes, but if you're not clear on what it is we do here, you know, we're, we're seeing, we call it the last great cloud transformation, but what we're really referring to is that this next wave of cloud migration, if we could call it that, is a little different than what we've seen before for the last almost 20 years, 18 years, something like that. For many people, cloud migration meant moving from a private data center, whether it was a private cloud or, or just a, you know, posted in a private data center up to one of the public clouds, the hyperscale, cloud hyperscale, you know, provider clouds. And, and a lot of times it was just a shift in lift from, from private to public.

Other times there was some transformation, maybe moving to a cloud native microservice architecture or something like that. Um, but what we've seen over the last three years, five years, may, let's say, since covid times, right, is a migration not only from the private data center to the hyperscaler public cloud, but from there to the edge, from the edge to the endpoint, in some cases from the public hyperscaler cloud, back to the private data data center or private cloud running things like Kubernetes on bare metal and, and so forth, right? And so really our cloud infrastructure is everywhere.

And so in many ways, this latest wave is the last great cloud transformation. Our partner for this show is our friend, our friends at CloudFlare Cloud, CloudFlare, which look, I think 22% or something like that of the internet travels over its network, right? CloudFlare has come up with a solution, a, a aid in this last great cloud transformation, and they call it the connectivity cloud because what they have found is look, when you have a little bit of something everywhere, right?

You get some assets in the public cloud, some in the private cloud, some on the edge, some exist on endpoints, everywhere, you need something that connects all of them. And, and in connecting all of them, you're dealing with several key issues, latency, security, huge, right? And some sort of intelligence, I'm not going to use the AI word per se, but some sort of intelligence that knows where to go when and what to put, what where, right?

Does this is, is the edge the the right place for this? Is the core the right place for it? Is the private this, should this be on a, an endpoint?

So that's what we're talking about when we talk about the last great cloud transformation. I hope that makes sense to you. Let me, um, introduce you to our panel today is we're gonna discuss just a, a small slice of this.

We're gonna focus in on securing the API economy within the context of this last great cloud transformation. Joining me today, first of all, from CloudFlare. I went through all that time.

I hope I get his name right. S Krishna ChAARI. Am I close?

Very close. I'm Sai Krishna Chaley. Thank you Alan for the introduction.

Uh, product marketing at CloudFlare. Been in the security space for a decade now, actually, uh, started off in application security and now back to the API and application economy. So excited to talk to all of you.

Absolutely. And Cy Christian, it's great to have you on here. Joining Cy Krishna and myself, though is my co-host of the last great cloud transformation.

Uh, him and I co-host a whole bunch of things and we like to do things together for a long time now, he's a, uh, fu VP for DevOps analyst, Mitch Ashley. Hey, Mitchell. How are you, man?

Good to be there. And I'm glad I'm buttoned down in my cold little bunker here in Colorado. We're getting some snow this week in cold weather, so You all might see a little bit goodness later on the East Coast, so hang in there.

Absolutely. All right, let's, um, let's turn to the issue at hand, gentlemen, right. Securing the API economy, before we talk about securing the API economy, I think that we probably need to define what we mean by the API economy, right?

Yep. And you know, it's a term that's, I've, I've seen the term used probably for 10 years already, right? Eight years.

And, and really what it is, is so much turns so much of our economy, so much of our e-commerce, so much of our online digital presence turns on API to API communication, right? In fact, uh, I'm actually doing an interview with Grant is a Baz Bazookas Berser, yeah. From CloudFlare, uh, on this, and I've done in the past with him on this, a majority of all the traffic on the internet today is actually API to API traffic.

It's a majority of all the traffic on the internet. So when we talk about the API economy, we're talking about a majority of every bit that gets pushed over the internet. So, I mean, that's, that's the scale of this thing, but peeling that off, what do we, you know, what is this API to API traffic?

So, Krishna Mitchell, do you want to expand on that? Sure, sure. So actually I, I wanna do a quick overview of, uh, APIs itself, because I think the API economy is a, um, maturation of how we have been using APIs.

Uh, and one of the things that APIs compared to web apps or mobile apps, you're touching them every day. You're using them as a consumer, even as a, a business user, et cetera. But APIs, you don't think about that happen behind the scenes, and they're meant to be behind the scenes.

The, the value of APIs is that they can enable one system to talk to another system, exchange data, and do that in an automated fashion. And so all the automation that we talk about in the world out there is happening via APIs that are between applications, whether they are APIs in the, you know, software defined JSON format, or whether they're in older school formats, or whether they're specific to an industry. It actually, when you think about APIs, they've always existed inside of applications not to the, to the public world, um, when there were service buses.

But since then, and especially when we think about the first big push with mobile phones and mobile apps, especially the, when Steve Jobs talked about the app store, um, and then Google, Android store, et cetera, the Play Store, what it meant was all of those apps were being run behind the scenes via APIs. So mo the mobile economy provided a huge boost to APIs. Second, we saw that, um, the social and e-commerce space became a huge area whereby when you're just a very active uploading fo photos from your phone to the cloud, um, to back it up or put it on Instagram, et cetera, was all via APIs.

And so that provided another second boost, uh, with the consumers coming in to play. And then what we are seeing in today's world, you know, uh, organizations trying to reimagine how their applications are built, uh, as you talked about Alan, with the rearchitecting of applications, that was that microservices element behind the scenes to make sure they break down their applications, to talk to each other and talk each service talking to each other using APIs. And the the fourth one that we are living in today, that everybody is familiar with, generative ai, I know you didn't want to use that word, but I brought it in.

Um, It is being run while a lot of us are using it via web apps, behind the scenes. It is all being run via APIs. And that is how this API economy is continuing to explode, um, whereby organizations are now making money just like the open ais and the other AI models, um, making money based on how much their API is being used and being integrated into other systems.

So when you talk about the API economy, it has many tentacles, and it is continuing to grow, uh, in importance. You know, side Krishna, uh, excellent, uh, description, I think of how the match oration of AI have taken place. So I'll just, I'll just add to what you said and, uh, kind of build from it.

One is, as APIs have gone from sort of the exception to being the rule, the exception was those are the few things we exposed to other applications outside the organization, outside the firewall. Um, maybe you mentioned message bus, but boy, I had a, I had a flashback there for a moment, going back to so architectures and things. Um, but, um, but it's evolved even even beyond that to the point where we now think of, uh, AI a IS products.

Many services on the net only are offered via API, that that's how you use it. You consume it, you might stick a front end to it, a web interface or a mobile phone, but, uh, the service may be only a APIs. So you think about that as your storefront for your service is other pieces of code talking to your services through APIs.

Another, another aspect that's changed, which is kinda how it's manifest, which you talk about in that, that fourth wave is, is what's called API first, where essentially applications are built around the fact that everything is an API, and it will all talk to each, each component, whether it's the user interface or some backend service, front end microservice, whatever it is, everything will talk via APIs. And what's interesting about that from a networking perspective is, you know, sometimes software and software architecture is a bit of a head scratcher for a network security person or maybe even a network person. It's really a network inside the application that's talking to itself over T-C-P-I-P, whatever we're using, whatever graph QL or restful interfaces, fancy words for different kinds of APIs.

Um, so it's, it's, we've really gone from it being the exception to being how everything works. And that's the, that's why you see all this traffic, whether it's over The internet and the cloud providers or inside your own networks. That's why it's all happening over APIs.

Agreed. I'm, um, Mitch, because when we talk about that last great, uh, cloud transformation, it's again, back to the fact that the, at the app layer, you're exposing all of these APIs, but coordinating them mm-hmm. Maintaining them, making sure the performance is optimal, is all part of the cloud transformation that is so critical, even before you get security.

And obviously security is a critical portion. Good point. Very good point.

Yeah. I want to turn to security and, and specifically around securing all this, but before we do, you know, so Krishna, you opened up the, the, the, the Pandora's box with the AI stuff, we weren't yet, right? It would, it's gonna happen at some point in every cover.

Yeah, yeah. So look, this, this, this is a whole different ballgame, quite frankly right now, especially with the onset of, of agentic ai, right? Who do you think these, all of these AI agents are going to be talking to people?

No, they're gonna talk to APIs. So if we think that a majority of the internet traffic now is API to API, how much of it is gonna be agentic AI to API? Some may say that really what is, you know, a good chunk of the very essence of what an AI agent is, is some sort of AI bridge, API bridge, right?

It, it, it's an API that lets you plug into everything, or that plugs into other things. So I think, you know, we're just at the beginning of the API economy and, and how much of it, or how much of the total digital world is gonna be riding on that, right? But let's, as I said, let's turn to security.

Well, before you do, I just wanna mention this. Go ahead. This is so pervasive that my granddaughter told me she wants to dress up as an API for her Halloween costume this year.

That's how pervasive this is. Really? I'm kidding.

Of course. Oh, okay. I was getting sure.

She's wired it. I'm the security, not just security though. So look, if something's this important, you know, it's the law of why we can't have nice things, it becomes a target.

There's a bull bullseye on its back, so to speak, right? Of, of how can that be disruptive? How can you know, how can it be disrupted?

Excuse me. How can people exploit it, hack it, make something out of it? And therein lies the problem.

Therein lies the issue, right? How do we, how do we secure this gigantic monster of API to API or API to agent communication? So, Christian, I know CloudFlare, I mean, you guys have put a lot of resources into this very issue.

Let, let's talk about some of the things, you know, some of the ways and things that you guys have come up with. Yeah. So we've done a bit of research into what are we seeing in terms of threats.

So, we'll, we'll break this down into what are the threats we are seeing live, and then what are the problems around API security to do API security well in an organization? Um, so in terms of threats, let's just kind of break it down. The, the actually most common threat that you see on in, uh, kinda real time traffic is business logic or de di distributed Nile of service attacks that are just hitting their APIs to try and either exhaust resources or to try and get into a service and then figure out what is a, what is behind that service at the end of the day, you know, an API is mostly a communication mechanism, and therefore they're trying to figure out what is that API talking to in the backend.

Um, and that's something that we are seeing a lot of constant traffic, uh, around that. Beyond that, when we think about actual data breaches, what's unfortunately very clear is that we hadn't fully thought through what needs to be behind a authentication mechanism. And then, you know, we're still, we're still trying to figure out what is the authorization mechanisms and methods that we go through.

But even authentication, putting basic authentication is not something that was, uh, has been very common. And therefore we have seen a lot of public major data, uh, breaches that have an API that's just openly accessible. So that's the second part.

Now, on that, when you're talking about leakage, you're essentially leaking data. And the most important, uh, types of data that what we are seeing is attackers using that to do reconnaissance, to then use that in other attacks that are a bit more targeted in nature, um, because they found all these public APIs just spewing a lot and lot of data, um, that can be used in other places. So it may not be necessarily sensitive on its own, but it's a piece in the larger, uh, targeted attacks that we are seeing.

And then lastly, what we also see is just like with, uh, applications, APIs at the end of the day are also code. And so there can be vulnerabilities in that zero day attacks that we, zero day exploits, that we are seeing, just like with applications, they can happen with APIs as well. Just because an API does not have a front end does not mean that it will not have the, the code level vulnerabilities, um, given they may be written in similar languages to, um, the, the, uh, web application, uh, code that is, or the, uh, the, um, code behind the web applications, uh, that we all use.

And so being able to protect against that helps you protect against, as we think about, as Isha talked about the economy and Alan talking about how the economy will continue to grow, so will fraud, and we're gonna see fraudsters trying to go after the APIs to get access to money, to get access to, um, credentials, et cetera. And so that's the next area that we are, we are really seeing growth in, unfortunately. Yeah.

Mitch, thoughts? You know, I was just thinking about, um, not to bring AI back into the conversation, there's a lot of discussion about how did deep seek train its models, and it's done through something called reinforcement learning. And of course, um, the other aspect of it was as trained on open AI's models or other people's models kind of ing models models, that that's a great example of where automation comes in, where something you couldn't do on a large scale through any other way other than through automated API calls, uh, into applications or models or whatever it might be.

So it's, it probably would be shocking to, to just the average user or maybe us that has a little more technical background of how much of what's happening inside an app or looks like it's inside an app, is actually taring through API calls, and how our apps wouldn't function at all without it. I mean, some of 'em wouldn't even start up, right. Couldn't present a user interface to you.

So I'm, I'm curious, uh, aside, Krishna, as, as you think about from a cloud perspective, when so much of the traffic is APIs rather than, you know, HT B calls over web browsers and, and email types of things, protocols, you know, the old, the old internet protocols, right? That, that built the internet. Uh, how, how does that make you think about the cloud differently?

Especially because customers like myself, we are a customer of CloudFlare, by the way, um, wanna put parts of our apps in the cloud, not only at at the Edge, but also in multiple places across your cloud instead of us trying to figure out how to deploy it to some point past the cloud? Yeah, I think this gets to some of the, uh, big problems with trying to secure your APIs. So there is two parts to this broadly.

One is, at the end of the day, APIs are written as code, just like web applications are. And there is a portion of it, which is the typical vulnerabilities that, um, the laws or open web application security, uh, project has, uh, kind of outlined as the top 10, uh, kind of risks are very similar between web applications and, um, APIs. So being able to protect against those so that they don't even reach your API servers, um, wherever they may be, is going to be super critical.

The second is making sure that when you are, when you are looking at, uh, APIs unique part about APIs is they should have some sort of authentication and authorization on them. And exceptions should be those that are unauthenticated, that should be the exception. Whereas with the web applications, vast majority of the traffic maybe are not authenticated because they're just looking at, um, and reading data.

But with, with, um, with APIs, that should be an exception. And so being able to put that in place and then be able to enforce it function, that developers don't have to come up with it, come up with their authentication mechanism every single time they're creating a new API, which, which is just so very common in organizations, which, which just as an aside, that forces developers to become security experts. And while we want developers to know something about security, security expertise is not gonna be the first thing on that plate.

Um, and therefore being able to standardize that and push that to, to the edge is gonna be so very critical. Um, on, on the authentication side, and the last part is, as a security team, you're constantly thinking about governance. What is happening in, in my estate of APIs, applications, other assets that might be there?

What are, how are they being configured? Because once you have, you know, coded an application or an API, and then you have, um, put it into a release cycle and it's out there, they're gonna be multiple ways that it's being deployed, run, configured for different, uh, use cases. And so all of those can have misconfigurations.

And we see that all the time today. In fact, one of the things that we see is the, uh, problem of APIs, leaking sense of data, because once they, when they were first, um, released, they were very pristine, well done over time. You keep adding a bit of fun functionality.

And over time that leads to things where just for that one use case, you will, you are, uh, uh, you know, able to kind of expose a bit of data, but now in another context, it is leaking sensitive data. So, um, that is something that you need to be able to constantly be able to monitor and where appropriate without having to burden the development teams be able to put in place, uh, protections in real time at the edge so that, again, there's much less burden on developers and those that malicious traffic is not reaching your, um, your, your, um, API servers themselves. And the way that connectivity cloud really helps in this context is to make sure that all of those protections, you don't have to put them in place at each of your data centers on each of your APIs separately.

You can push, you know, rules into a, uh, common engine and then make sure that they're propagated at all locations that you are, that you are serving, uh, from which you're serving your applications on, in what we call an edge or a connectivity cloud edge. Excellent. Excellent.

You know, Mitch, I, I was listening to what you said, and then what, say Krishna came with, I, I think one of the things I said earlier really is, I mean, it complicates thing, but it's so true of what, what, what applications look like today, right? Our applications are dispersed, they're microservice based applications. And you know, when people think of APIs, they may think of, I'm a user of an application, and I, and that's the A PII interface with that internal to external or external to internal, if you will.

But in the microservice cloud native kind of world that we live in now, right? Something like 70% of greenfield applications are built in a cloud native, uh, architecture, much more than that. External to internal.

API is the internal to internal API, it's one container talking to another container. It's one function of an application going out to a SaaS based API coming back in, talking to another piece of the internal, right? Internally, an API to API thing.

As you know, our applications are sort of little Frankenstein's, if you will, right? We're all stitched, they're all stitched together. And what's, and what is the thread?

What is those stitches? It's, it's APIs. And so I, I'm going to guess that there's probably four x five x internal API calls for every internal or external API call, and they have their own security requirements.

And that's, those security requirements have to be orchestrated, governed. What have you managed, you know, whether it's at that COBE level, the orchestrator level, or the mesh level, right? Of how these things are, are talking to each other.

But that's a, you know, and, and they're all, you know, let me add one more little complicator in there. They're all over the place. They're in the edge, they're in the core, they're in the data center, they're on the endpoint.

Mm-hmm. It's enough to make you go crazy, right? Because that, now that's a job, right?

If you could secure all that, that's a job. I don't know if it's A good analogy, but it, it's kinda like an air traffic control system of multiple lands. Yeah.

Really it's Whether international travel, continental, you know, local, et cetera. It's 3D 360 degrees, right? You mentioned cobe, Kubernetes, you know, and then the cluster has an API gateway and it does security for APIs.

What can talk to what within that and other, other Kubernetes clusters. And of course things go outside of that. And then service providers have API gateways and firewalls and things that control, uh, both security and authentication, uh, as well as traffic of those APIs.

So it, it is, it's, it's kind of a cellular system almost, if you want to think of it that way, of multiple layers of, uh, how APIs work. And, and the good thing is the APIs give you a lot of autonomy in code and design. 'cause I can create a, a microservice that just specialize in pulling data from Salesforce because I need these customer records for my application to process an order or to go get, uh, background information from, you know, say a science database that's got, uh, medical information in what I'm gonna OC include in some deliverable to a end user, some product I'm producing, but that can be specialized.

So it lets us build autonomous pieces of code, not, maybe it's a agent AI agents at some point not too far down the road that can go do, do it thing and not worry about the rest of the world of all the software and the APIs happening. It also lets developers go, eh, nail, okay, I, I know, I know where those API calls happen, or I know how to trace it down using observability tools and things like that around tracing. Um, but it, it, it's a different world.

It's a very different world than the days of I will talk over a SOA bus, um, or a monolith application. Um, but it's like everything, it's, it's just a different mindset has advantages, brings with it other challenges and, but the advantages outweigh the negatives. And I think, Mitch, you mentioned, um, something around, uh, agent AI agents, but that touches back to Alan's point, which is, you know, Alan, you were talking about there'll be one, um, a one API call between the, or many fewer API calls between external and internal boundaries.

Um, and there'll be a lot on the internal side. Totally agree on the internal side, but the unique part now is there is an even more blurring with agent AI agents of what is internal and external when you are calling AI models to do things as a step in your application. And so you are, uh, a service may actually be calling, not the application, the application that everybody's touching, but a service that is trying to do some data analysis, trying to pull the latest information so that it can be passed to a user may actually just call on its own an AI model of, of some sort that has to do some data analysis and then be brought back to the application.

And now what is happening is when in the old world you had an understanding of, okay, here are things that are exposed to the internet, everything that the developers are doing behind the scenes, I, I don't really have to really care about that. Now you need to be thinking about all of those services as well, because those could be exposed. And when you are talking to another, um, AI models that are open source, you know, by third party commercial one, or whether it is sitting in some other location that you, you own your building your own, um, it just makes the, that world of API traffic even more complicated.

And one of the things that we are finding is, um, in the past, even just pre pre covid, think the pre covid days when APIs were still, uh, quite common, um, not as common as today. One of the thing, one of the things that customers struggled with was identifying what are all the APIs that my organizations have exposed? Because the security team is not everywhere.

And talking to every development team, now this problem has multiplied. Now it is not just what are the APIs, but developers, what are the AI models you're u using? 'cause almost always those are being discussed or, or that's being communicated with through APIs.

And we need to think about what is the data not just coming out of the API, but what is the data I'm putting into the, uh, into the API that is going into an AI model, whether it could be PO for poisoning purposes or leaking your organization's sensitive information. So I think those two things, especially with the world of agent AI, have become a lot more critical, uh, for organizations to deal with. That is the cutting edge of what we think of API security today.

You know, there's another dimension to this too, and that is, um, what, what goes hand in hand with API first software architecture is also stateless, which means, you know, we used to make calls, meaning I hope a connection to this, whatever it is. On the other side, I do things across, you know, whatever that connection, the socket or whatever it was back then. Um, and then close the connection.

It's kind of the difference between TP and UDP, right? You, am I doing that connection an open a close, or am I just sending it and it will happen? That's a lot of how software in order to scale and, and have that independence of microservices or whatever that function is that is providing or requesting the service, that's a lot of what scales this up.

So that also increases not only the security, but also the manageability of those applications, because I can't take, like, freeze point time of the state of the machine and I can go see where everything is at. No. You know, that that same process that requested that might've been updated two minutes ago, or might have scaled from one to 53 instances of that microservice across the network that's distributed.

So that's why we're able to get such high performance out of systems because we can distribute 'em through that stateless architecture as well as APIs and networks Network. I, I think that, I just wanna mention one thing on that, on the stateless point, because it's so very critical in, and it, it applies to cybersecurity in the sense that the CIA triad one part, one leg of that stool is availability and the importance of a stateless architecture, um, that can be ideally based, uh, edge, uh, you know, pushed out to the edge. Um, especially some things that are, can be provided by a connectivity cloud enable cold starts to be diminished because you be waiting, when you're thinking about being very dynamic providing data, and this is of data we're talking about, especially with AI models and AI agents, that difference between a bit of latency is very significant to the user, uh, at the end of the day.

And so minimizing call starts, and that is something that, you know, only in a, a provider and a that has been thinking about stateless architecture at the edge can, can really provide. Um, and that's something that we have definitely been, uh, seeing with a lot of customers, um, that they need, that those cold starts to be reduced so that whenever they call a function and it is un up, the instances un up, they're ready to take, uh, workloads. You had to mention cold starts.

It was 11 degrees when I woke up here this morning. So thanks for that reminder there. Like Christian.

All right guys, we're about outta time like Krishna, for people wanting to get more information about connectivity Cloud, securing their APIs and so forth on CloudFlare, where, where's the best place for them to go? com has very in-depth technical analysis on the latest cybersecurity threats and API performance and security conversations. Thank you.

So Krishna, thank you for coming on here today. What a great conversation, Ben Mitchell. Good work.

I, I enjoyed, I Learned a little too, which is always a good thing. It's gonna wrap up though, this episode of the last Great Cloud transformation. Stay tuned.

I think our next one might be a live round table again. So if you watching this, you enjoyed it, you want to be involved in the next one, it's live. You could come in and chat your questions and comments and we will incorporate those into the show.

But until then, on behalf of CloudFlare text Strong Mitchell, Ashley s Krishna, help me, Val, val, val, I always think give it a little French there at the end, Val and myself, I hope you've enjoyed this episode. Take care. We're out.

AIOps, ML ops DevOps, it's all Greek to me. You're watching Tech Gang. Hello everyone.

Happy Monday. It's Alan Shimmel here for Textron Gang. Hope you've had a great weekend and you're ready to get back to work this morning.

There's a lot going on in the world. We're gonna try to just cover just three things. Just three things.

That's what we do here on Textron Gang. We just do three things every day. Um, got a great gang of, uh, cast of gang members to go over stuff with.

Let me quickly, quickly introduce you to them. First of all, the lady from New Mexico, she's the CEO of Deploy hub, open source expert extraordinaire, and one of our favorite people here at Textron World. Tracy Reagan.

Hey Tracy, how are you? Hey Alan. Thank you.

Thank you for that. I like being a favorite person. Well, you are.

Thank you. Thank you. Um, joining Tracy, he is in the streets of New York City Manhattan, that he is FU chief, not Futurum, excuse me.

Visible impact chief analyst, guy Courier. Hey guy. I hope I got that right for you.

You got it right. Thank you. Just wanted to clarify and It's great to be here Again.

You're not in New Jersey? Uh, what? Exit For exit, that's right.

Yeah. I'm in, I'm in, I'm staying in New Jersey, uh, with my nephew, but I'm coming into Manhattan every day 'cause I Not near exit 13. Elizabeth Newark.

No, right by the bridge. Right by Fort Lee. Oh, okay.

You're up by the GW and the Henry Hudson. That's y You know, we came up with congestion pricing to keep you people on that side of the bridge. But no, I love when you use You people and that's why I take the busts.

That's you people. You people. Alright, let's move the bus over from you people.

We'll stay in New York. We'll go up to Harrison. Looking mighty Raddish pinkish today our own life are, yeah, I'm, I'm actually just back from a run, so there you go.

Alright, good for you. I I did a bike ride this morning myself. It was cold.

Well, it's all relative, but it was cold down here today. It was probably in the sixties. I was freezing, um, moving there.

I'm sure it's at least in the sixties up in, in the high mountains of Colorado. Uh, no one, no one commented on that. It's our, uh, future VP analyst for DevOps.

Mitch Ashley. Hey, Mitch. How are you?

You're on mute. Oh, now you're not doing great. Always doing great.

Good to see the gang. Good to be on the gang again. Alrightyy.

All right, let's jump into it. This fine, fine. This fine.

Monday, Mike, we, we had some text drawing AI coverage on, uh, on J Frog's. I think you were at a JFR event in New York last week, weren't you? Yeah, they had an event down in, uh, Rockefeller Center, and they had about 200 people show up for the launch of a jfr ML ops platform, which is based on, uh, a code, I guess code they got from a startup that they acquired last year and now are productizing and it's much more integrated with their core DevOps platform.

They gave out these lovely mugs here, you know, and, um, I gotta say, you know, it took me about 15 minutes to figure out how to move this thing actually works. But what it does Is that the one that heats it up? Yeah.

And it continuously stirs it. Yes, I have one It does. Which is, um, you know, of course core to DevOps, where continuously stirring things.

So I want to thank mm-hmm. AOG for yet another first roll platform issue solved. Um, I was gonna say, what are you putting in there?

You need to have a continuous Well, that's my problem is I'm not a coffee drinker and I, sorry, it's still sitting in the box. I've had it a while. I think it's For So what, what was it you said in the intro?

What was it you said in the intro? Allen ml ops ai, AI ops, DevOps. And now we have coffee ops, and Now we have coffee ops.

It's all ops, it's New ops, no ops. But what was really interesting about it is that the folks who came to this event were largely data science types, and they all work with these ML ops platform and J frog's making a case and a hard one. Every speaker got said, you know, if if those folks want people to use their AI models, they have to be integrated with the existing DevOps workflows, or the developers are never gonna find them.

And what I was trying to puzzle out in my mind, and I'll start with Tracy on this, is, is there kind of a divide between these data science teams that are using these ML ops platforms and the rest of the DevOps teams and each of them has like a different culture and we need to bridge that? Well, I'm not sure it's a different culture. Um, I think that the ML ops community have been somewhat underserved when it comes to DevOps.

Um, you know, I, the reason why I love this, the reason why I totally love what's happening here is that we're finally stopping to think about ML ops and AI and the components that we use, like models and data sets. They're just components that need the same kind of management as any other kind of component. So when we think of artifact management, we, you know, in artifacty we often think of just binaries.

That's kind of what, where our brain goes, it's artifacts of binary, but artifact can be anything. So being able to start to bring in the AI components, models, datasets, as well as binaries into a central place and treat it just like any other DevOps, um, any other type of component pushed through the DevOps pipeline is going to be, um, a time saver. And it's gonna offer a lot of clarity to those data scientists who may not have had that kind of products in the past.

Now, I believe, I understand we have things like TensorFlow that help them build, uh, these models. Uh, but when it comes to all the other pieces of the DevOps pipeline, the ML ops teams have not had the luxury of, of these kinds of tools. So imagine how hard it is to try to manage just a deployment of, of one of those without a DevOps engine.

I, as a DevOps person, can't imagine doing it. So, you know, I, I saw last year I think is when, um, JFR bought quack. It's probably, it's been almost a year now.

So, um, they've taken some time to really, it looks like, to me, to kind of sort out how to integrate the, these, you know, the ML ops components into their process. Uh, but it, it's time. Um, you know, I don't know if we're we're too late on the ML ops question because I know people are still doing it, but it doesn't feel like it's as, as popular as it once was.

But for the data scientists, this is what they need. So yay jfr that they're, they're actually servicing that community from a DevOps perspective because it's the same, the problems are all the same. It's just a different component.

You know, the mike, there are differences in how the teams work, and I think that's great to see jfr taking that on through their acquisition of Quack. Um, you know, software has its own iterative process as, uh, ML and ML Ops also has its own kind of development workflow, which isn't exactly the way software is created. Usually in, in machine learning type of applications.

You have a, you have a data engineer, a data analyst, you'll have a developer, usually a domain expert that's helping you. And you iterate on the model. You iterate on the format and the, the structure of the data that the model uses and the algorithm use.

And you go through this iterative process where you create what they call features. This is like, okay, this is what it can answer for this kind of a question or this kind of analysis or this type of data that it's gonna analyze and produce some predictable results. That iterative process, you know, where is it released at?

It's sort of kind of when is the software ready? Same thing happens in M mo ops. When is, when is the model ready?

And eventually those two things, uh, have to join the, the kind of traditional software and the machine learning language algorithms and, uh, and models. So it's good to see Jfr take that on. I don't think it's just a matter of let's put your, our stuff in our, in our artifacts.

I think it's also the workflow. So I'm curious to see how this is gonna be adopted. And I, you know, I wish, uh, jfr the, the best at this.

'cause I think it's important for us to figure this out so we don't have this kind of chocolate peanut butter impedance mismatch between the two approaches to developing what we're creating. Yeah. And I think that the model training is where the, that, you know, pulling the data sets and training the models and then and storing them is where the ML ops, uh, workflow is the most important.

Um, but centralizing that into a a, a kind of a, a central platform, um, will make things easier in the long run. Just make it part of the DevOps workflow is a win Right There. Or vice versa, you know, DevOps part of the ML workflow.

I actually think also the, uh, experiment tracking and, um, hyper parameter management, these are really important elements of what the data scientist does. Um, and, uh, having, you know, you know, a agile, an agile workflow, um, for that sort of thing, um, is, uh, is, is really helpful as well. I like the bridge here.

Like everyone's noted, the bridge out to the data scientists and the data scientists particular types of work that really differ significantly from the coder and yet still bringing them into this, uh, DevOps like paradigm. Hey Alan, um, you know, we saw an outfit called, uh, a couple of weeks back, DataRobot bought some distributed computing platform startup. And I wonder if we're about to see some major convergence here.

Will all the DevOps companies kind of go after ML ops companies and will the ML ops people start acquiring DevOps companies and, you know, are, are, are these two trains gonna collide? I dunno if they're gonna collide, but, you know, I sometimes things seems, things seem too forced, too forced. I get why you would want the ML ops to help in developing, deploying AI apps, training LLMs.

Not everything has to be part of my DevOps workflow. And I just, you know, I, I remember when they bought Quack. I was at, um, swamp Up.

I think I had a chance to meet the founder, one of the co-founders of Quack. Actually. I interviewed, you know, IIII smell what they're cooking.

I just don't know if we're eating it or if it's, if it's a necess, if it's on my food pyramid, I would argue that this conversation we've been having about platform engineering for a while will force this issue and that people are gonna start centralizing the management of application development and they will naturally view those AI models as an extension of that conversation. So I think it may happen. Well, to Alan's point, if we look at, uh, DBAs, DBAs have never embraced the DevOps pipeline, right?

They have their own process and they've never, ever really, um, decided that that was a good idea. DevOps so Well, there is this kind of, there is this kind of tiering, so to, I mean, it literally, it's called tiering of applications. The old monolithic model and, and, and data and the data services on are, and can be seen as a sort of a separate layer or tier.

But I, Alan, I don't think, and Tracy, I guess I don't, I think, you know, I'm a fan of saying there's no such thing as an AI application. What, what, there are AI services that get exposed or injected into other applications. And as such, AI has become just so pervasive that what I would think the problem, uh, uh, JFR is solving for is all the developers using DevOps and wanting to do more and more of it now need to incorporate ai.

Um, and those AI services, if they're being tuned, developed, tuned or, or, you know, rag based or whatever it is, there's a data scientist involved. And that's, I think, a little bit more of a, of an opportunity. Let's not call it a problem, it's an opportunity.

Um, compared to, uh, what I, I completely agree with Tracy's, you know, statement about how the DBAs have never really wedded with Dev DevOps very well, but I think this is, this is different because of how infused and integrated, um, AI is in every application. It's going the other direction, right? It's not being pushed out from ai, it's being pulled in from the development.

Exactly. This is a unique characteristic that you're pushing not just algorithms, machine learning algorithms, you're pushing data with it, right? The model includes data.

So it, it is kinda incongruent with what we think about a normal DevOps up, uh, workflow of pushing software, right? Usually not pushing a lot of data through the process, which is also to your point Tracy, about why data and data database engineers, analysts ha, haven't been kind of part of that DevOps workflow, right? It has its own flow, its own process.

And I think that's the key to this is Alan, it's not just about does jfr bolt on a AI or ML ops into their products? That is not gonna solve the problem. You're not gonna attract people, you know, it's like saying, I have open APIs, as long as you use my APIs, they're open, right?

No, it is. It's like you have to adapt to the workflow and, and intersect those workflows in the way that it makes sense. I don't think we know enough about that yet or, or have experimented enough to really truly know what the right approach is.

So hopefully we have some folks that, uh, make some progress in that area. Well, I hope that we continue just thinking about parts or parts, right? And obviously different parts have different requirements around them and there may be different workflows for different parts, but it's still a component.

It still has to do a vulnerable, we still have to think about how to add testing and vulnerability scanning. It's a part that has to go through the software factory floor and the DevOps engine is the best place to do that. And these are developers, even though we have new terms like data, data scientists, they're still developers and they're still part of the development community.

And to embrace them and provide them tools that allow them to support the DevOps pipeline is the direction we should go with this. Because we all know it helps things move faster and we always want to go faster. Yeah.

I would say, you know, we talked about this in a previous show, but the DBAs are gonna get rolled up theoretically into this platform engineering motion as well. So, you know, maybe we're coming for the data scientists, the DBAs and they're little dogs too. I dunno.

Well, when they come for the data scientists, we didn't say anything. That's a different thing. Um, but, but let me just tell you that the, there is one more chip here that Jfr has in their pocket to play, and that is they've announced a, uh, partnership with Nvidia and this ML ops platform and Flow is supposed to be integrated into the, uh, NVIDIA of dawn.

What's the NVIDIA software? It's NIM is the framework Nim, I actually learned what it stands for. It's Nvidia inference microservices.

Nim, who knew? There you go Now. Yeah.

It's a, it's a tool set for, for, uh, deploying AI and to containerized environments. Uh, yeah. And, and hugging face also, Alan, that's, that's really significant.

Hugging face is a quasi standard now, uh, yes. For model development and uh, um, benchmarking of systems, um, for ML and, and, and ai. Yeah.

And it's just like going out and pulling a package down, an open source package. We're pulling down an open source LLM, treating it like a component and then starting to track the changes in it, right? Right.

This, it's, it's basic to what we've always done. Agreed. And not, not to be left out, but they brought in Databricks and they got an outfit called Bow Plan, which makes some sort of serverless data lake.

So they got it. And three maker aws part of their doing their, you know, we, we spoke yesterday about playing checkers versus three dimensional chess. Jfr definitely is playing three dimensional chess in, in this market with that.

Right? And you look at, you know, who their traditional competitors are in the DevOps DevSecOps platform. You look at GitHub, GitLab, cloud CloudBees Harness, and you see, you know, well Harness is, is making some moves along in this space as well.

I'm not sure if the others are yet. But anyway, I'll leave that to the analyst to, to comment on. I'm just, I'm just, I don't know what I am.

But let's take a break here on Techron gang. We'll come back and we'll talk about our next block. 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.

Hey folks, we're back. And the gang's gonna talk about this new AI agentic offering that goes on top of a platform called Open Rewrite that was created by Modern. And what they've done is made it more accessible to a broader number of folks.

'cause it's at the core of a lot of the application modernization efforts that people have. A KAI am gonna upgrade from Java, single digit number, pick your favorite double digit number and you can use this tool to automate a lot of that workflow. It doesn't do it all entirely, but it might take something that might have taken you, I don't know, a year and a half to cut it down to maybe six months.

And now they're putting some AI agents in front of that. Um, Mitch, I guess, you know, when I looked at this, I was wondering if the cost of switching from different platforms is about to drop and maybe people won't be as locked in as they used to be because it won't take as much time to migrate. Well think about migration in a couple ways, or modernization in a couple ways.

One is, to your point about upgrading versions of Java, right? Some of those changes are no, no small attempt. I mean, it's, it's a big effort to go between different versions of say, you know, between Python two and three, it was a big deal, right?

Things are different in those languages. So it takes more than just syntax changes and new features that are in the language when we talk about converting COBOL to something else, right? To, uh, Python or c or or whatever it might be.

Now you're talking about architecturally some really big differences between how that application and all of its different programs code were put together and how you would build that, whether it's in a monolith or semi monolith or more microservice oriented. So we're, we're talking about, you know, baby steps here. We're not throwing COBOL systems at it and said, great, it's all done.

We're all good. But I think to the point is they've taken what they've created so far and now put this into this lossless tree structure, um, that has kind of more semantic richness about understanding the interdependencies between code and analyzing different code bases. I'm not sure all the things that it does.

Sounds pretty interesting. I'd like to learn more about it, but this is something that they've also open sourced, um, as well as built into their product. I think the important thing, really interesting thing is the agent part of it is sending that off to do specific tasks.

Tasks around analyzing multiple code bases, doing some rewrites, finding issues that can be addressed. And again, this is a stair step process of maturity of what it can do genetically versus guided versus it still takes a human. Mm-hmm.

It takes us, go ahead. It takes us back to that conversation, mono versus poly repos and the problems that they do create. But in you're, when you're in a decoupled architecture in particular, microservices, we talked, we used that word the last last block.

We know that we are, when one application is going to be, uh, an aggregation of, of several repos, it's not just one application is not, does not have one repo. So tools like this makes it a lot easier to say, I need to aggregate, I need to scan all of these because this is one application. Right.

And this isn't just a problem here. It's a problem in, in other ways as well. So I think taking on that poly repo problem, um, for doing this, for doing rewrites and, um, you know, updating your code is a super useful thing to use.

Mm-hmm. I, I'll tell you, they were a little miff because all these companies are out there claiming that they have, uh, upgraded something using AI tools. And they were like, the truth of the matter is, yeah, they pointed their AI tool, but they used our repository to do it and all.

So most of the work was done on the repository side from them and not by the AI agent, according to them at least. And they feel like, um, some folks are taking too much credit for things that their open source platform actually does. I have a hard time believing that because tell me what, what code base, what repository, especially when it's been around for a long time, is that organized?

That cleaned up that easy to, to work with? Those things tend to, they're like wiring closets, you know, for your network in your office. So as you close the door, it's a mess the next time you open it.

Um, so, so I, I wouldn't put as much stock into that. Maybe they're take getting some advantages, the course of what's there, but there's a lot of work to go from point A to point B on this. I, I don't know.

I want, I kind of wanna challenge you on this, Mitch, 'cause I kind of feel like that's one of these things that generative AI does so well is masses of seemingly disorganized data and information and, um, I mean it's not a pattern detection tool. Exactly. Um, but, uh, through that iterative, you know, training process, it, it, it finds plausible further strings of data based on input strings of data.

And, and this is far beyond what, you know, uh, what the human mind right now can, can do. So like, isn't it sort of like, uh, I don't know, a new weapon to, to deploy against what everybody is put together in a disorganized fashion and therefore can't use, uh, in the same way It's kind of the, there's a pony in there syndrome, right? Well, like what does this, all this stuff do?

And if I'm gonna modernize it or migrate it or re-platform it, whatever it is, you know, what do I have and what do I need to modernize? What can I leave behind? I don't wanna leave things behind that need to be there.

So, generative ai, and there's a lot of different products that are doing this now are really good or getting better, let's put it that way, at analyzing code bases and first telling you functionally what the requirements or what this software does. Second is the architecture of it, describing of it how it is organized or disorganized to whatever degree it is. So then you can make some decisions that human can about, well then how am I gonna rearchitect this?

How do I move forward with this? And maybe I use AI to do some of the development with it. Maybe I don't.

But to your point guy, it's an extremely useful tool. I think it's gonna be even more useful over time as it gets better and better. Lemme give you a use case that we talked about.

'cause and this will become readily apparent to all of you, I think. So vendor A decides that it wants to raise licensing fees for its platforms. We've seen a lot of that lately.

Um, and they pick a, a price point for that hike that's just kind of right below the cost of moving off that platform. So people suck it up, but imagine it didn't cost as much to move off that platform. And then maybe vendor A, that Rose Price is miscalculated and more people will migrate away to something else, which we've seen a lot of people trying to at least experiment with.

So is there any specific vendor you have in mind that Mike, This is like the, all the characters in this are fictional and don't, if they may resemble some real, We, we've changed the names to protect the guilty Boy. You're a little transparent there, Mike. Uh, yeah.

Hi, Joe. Friday here. We, we have, we have always done this.

I mean, you know, we're, we're talking about this like, it's a new brand new tool, but come on. We've had COBAL to C seed to Java. We've done this for a long, quite a long time.

We've had these converters. Uh, you know, maybe AI makes it better. Um, I'm hoping it does because I've used some of those conversion tools you go from see to Java and there's a lot of, it gives you a baseline, but there's a lot of work yet to do.

So I'm hoping that it does a better job of what we used to have in the past. I hope so. I, I, Well, well, yeah.

You know, from a VC point of view, right? That typical VC looking at how it looks at the world, there's a big opportunity, there's a big market, right? There's a lot of legacy applications that are gonna have to be converted to a cloud native architecture over the next three years, five years.

You know, they, I I was reading and think 85% of greenfield new applications will maybe even more will be cloud native architected from, from scratch. But you've literally got millions and billions of existing applications that need to be converted that need to be modernized, is the word. And, Uh, market.

And, but, but but's point, the way it's been done historically has been, you know, people went out and they hired some global SI to come in and they said they would do this project for them, and then the bus shows up and about 30 kids roll off and they move in for a year and a half, and then they never actually finish the gig. So I'm hoping that this gets better to enable what you just described. But, But you know, uh, I think a better analogy is moving from private data center to cloud, right?

What'd we see? That first wave was just lift and shift, right? And, and it's only now 20 years later, 15 years, 20 years later, that we're seeing real cloud migration that maybe even not some of it's cloud native, but even the ones that are not cloud native, really taking advantage of a cloud architecture versus just lift and shift off the on-prem data center or other closet.

Well, we're, we're living this in another kind of parallel universe, and that's not called modernization, but it's called development using AI tools. 7, you know, it, it we're, we're in an era now where we're interactively saying analyze the code. Doesn't have to be COBOL from 30 years ago or 40 years ago.

It's my code I just wrote or I picked up in this new job or part of a code I haven't worked with before. Maybe I know it really well. But we have AI now analyzing existing code ba code bases and making changes to it, recommending changes, genetically making changes in some cases with, uh, with cloud code.

So it's, you know, it's on a spectrum now. It isn't just moving the old stuff to something new. It's taking what we have and using AI to continue to develop it.

I think we need Mel Gibson from Braveheart just screaming freedom and, and everybody will, uh, get going. Yeah, it didn't end well for him. I think we got enough people doing that in the country.

Mike, take it easy. You, but, you know, to our's point, I think the, the taking the monolithic and breaking it up into, into decoupled components and features is probably the biggest challenge companies have. And these kinds of tools can do that better.

At least get, again, like I said, it's not perfect, it's a baseline, but to be able to break it up is really, can be really challenging. And so if we're using AI to make, you know, you know, modernizing our monolithic into decouple architecture that we can take advantage of cloud native, all the cloud native features we've been talking about for the last, I don't know, seven, eight years, um, it's probably about time we have a tool like this, and that will help a lot of companies move into that direction. Fair Enough.

Here's what I find interesting. So you described earlier, Tracy, you know, the, the sort of the old way, the old way up until last year still going on now, which is, which is, you know, like originally just all this manual late, we're talking 30 years ago or whatever. And only for those applications where you, you really needed to do some kind of translation and experience and logging and then starting to post these things.

Here's how you do it. And then, then automated tools, like you say, started to appear. These were not AI based and all this work has gone in and it's such that we now have an open source community.

com, how to glue this to that, right? This is now like how to move from this code base to that code base and then here comes modern and says, Hey, thanks for all the work. We just trained an AI on this and you can pay to do all of this so much faster.

You know, that's the story that sort of popped out at me is, uh, you know, thanks, thanks for all the work over the decades, guys. We got, we, we now have an AI trained to do it. But Isn't isn't that the AI way?

That is the AI way. And, and I completely agree about the usefulness of this. It's wonderful.

It's terrific. Um, it's an interesting example of something, uh, uh, that's not me by the way. I, I I have the horns someone else.

No, no. Mitchell has the dog sound effects. Um, you know, so, so something you were sort of talking about, Alan, uh, uh, we've been talking about a little bit is, is open source under threat?

Mm-hmm. It is an under threat because now we have all of this community work over decades and all these different areas and we can, we, you know, AI is trained and then we're gonna put more human data in, and then maybe we're gonna start use, we'll use synthetic data already. And at what point does it become this recursive circle that's training itself and going off, I dunno, the edge of the, Isn't there a tipping point guide is we, we generate so much more code using AI or, or modify it at some point.

You have to have AI to be able to manage it. You know, you have so much code, you can't hire humans to do all the work on it. You have to be able to kinda reest it, modify it, change it, whatever it is.

So we're kind of creating this world where it is inevitable that you have to have ai if you're gonna be generating this much, this amount of code this fast. I think if I think so. If you ever saw the bill from a global SI on one of these projects, you will lose your sympathy quickly.

Oh, for sure. I was in one of those buses that pulled up outside early in my career. Yep.

Alright, let's take a break here on the gang. We're gonna come back and discuss C block. You know HashiCorp part of IBM?

Is it a kinder, gentler Hashi? 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 folks, we're back. And as Alan alluded to, yes, Hashi Corp is now finally formally part of IBMI think it operates semi-independently, but the issue becomes, well, where does Hashi Corp fit in with the rest of IBM, including Red Hat and aptio?

And they have some ambitions in that space, but Guy, you've been following this for a little while, talked to a lot of the folks at HashiCorp over the years. What's your take on all this? Where do you think it all winds up?

Well, I think it, what what's really interesting here is, um, so IBM right, uh, we're the original gangster of, uh, of, uh, um, you know, computer systems that transformed itself through, um, software delivery to now, um, essentially a, a a A services, uh, firm for building, um, and deploying and acquiring and managing enterprise software and other types of software. Um, where, you know, the acquisition of Red Hat seemed to start its latest phase of, um, enabling organizations, uh, owning and running off the shelf, as well as building and deploying their own applications on various platforms, puts IPM in a pretty strong position, both in the public and the private sector. So where does HashiCorp fit into this?

I mean, most famous product, Terraform infrastructures code, um, ways to, uh, tighten the integration and responsiveness back and forth between the, um, the, the code, the software where they're off the shelf or developed, um, and the infrastructure. Um, I don't think it necessarily means we're bringing Terraform Disease systems or anything like that sys as being the big mainframes that IBM has, but maybe it does. Maybe it does.

And this sort of general enablement of IBM in the enterprise and in the public sector, which are the two big areas where IBM plays of DevOps, um, has been, I think, you know, uh, a maybe surprising force of good in the industry. Um, red Hat remains independent. You can expect Hashi corporate self to remain independent.

Apptio's remain independent, you know, as brands with their own go to market, their own user base and so forth. While the main line IBM, uh, uh, uh, you know, product lines or service lines really get to incorporate and use and influence development of all of these, they all have a part to play in application development, um, uh, production and, you know, delivery to user bases for the business or the agency goal. Uh, the only other thing I'd add, um, is that, um, uh, you know, uh, Hashi Corp in particular has a really robust set of tools around automating and running and maintaining service health of all kinds of infrastructure.

And that helps broaden IBM's ability to also be an additional player as opposed to a single source. They've had this sort of single source model forever. They take on the entire application.

And by the way, when you talk about off off the shelf enterprise applications every off-the-shelf enterprise application has all kinds of, you know, customized and own code in the enterprise or in the institution, um, that adapts that enterprise software to the particular needs and uses of the organization. There's lots for IBM to do there, even if they are, you know, secondary vendor or secondary player to begin with. Mm-hmm.

So, Mitch, Mitch, go ahead. I'm sorry. Hold On, Mitch.

They were describing it somewhat like this where Terraform is kind of like day zero and Ansible is day two management of the environment, and those will be those different automations. And I'm not quite clear if that makes sense or how much overlap there is between Terraform and Ansible as we kind of go forward. And frankly, in the age of ai, I am wondering, you know, are those just all gonna wind up being backend services that some AI agent is gonna deliver and they all just kind of fade away in the background?

I I think of it as just platforms that are automated, right? Processes for provisioning, updating configurations, configuration management of that. You have to remember, you have a huge embedded base of Terraform users, open source and HashiCorp.

Um, and, uh, so open tool, tofu kind of folks. Um, but of course also Ansible, you know, it's been one of the early earliest, um, bat and Chef, uh, been around a long time. So it Puppet and Puppet.

Yes. Thanks. Exactly.

So I, I don't, I don't think you can say this is day zero and this is day one, and this is day two. People use these tools across the, both the operational and development life cycles. They use 'em to create development environments.

They use 'em to create test environments. They use 'em in production. So you know what the blending of all that will look like.

Maybe they stay somewhat separate since they're in business, different business units, maybe they all benefit from Watson ai that becomes a feature part of these technologies as part of the AI strategies take place. But we'll see. Can I be a bit of a jerk, Mitch, and say that, uh, Ansible is the, is the, you know, Linux cloud native EL sort of, uh, you know, religion quote unquote, whereas Terraform is a lot more the enterprise religion Enterprise?

Uh, we use both. Yeah. I mean, one of, there's to me, they're completely separate tools.

Yeah. You know, I see Ansible overlap a configuration. Yeah.

The Ansible is, you know, that's what, that is a full on DevOps tool. Terraform is a platform engineering tool, you know, and that's a good way Of, of looking at it. Yeah.

And I, I get using both because you have to go and stand up an environment before you can point to it. But guys, I, I wanna take off the rose colored glasses here for a second. If you think Red Hat Apptio name other IBM acquisitions exist as quasi independent companies and have not been assimilated into Big Blue, I've got a bridge for you guy.

There's one right out the window there. Okay. Red.

This ain't, this ain't, this ain't Red Hat pre IBM, But Well, no, no. I referred to the brands remaining independent. Yeah, there's Independent marketing teams.

They're allowed to go and continue to develop their own Customers forth. I mean, because it goes to the heart of what is IBM today, right? They spun off NDL right then, but IBM itself still remains a, a consulting firm.

And now, and, and they always prided themselves on being able to, and NDL still does we'll, we'll help you deploy whatever the right tool for your job is, but now they have some favorite tools. They have Red Hat, they've got Apptio now they've got Hasi. And so the IBM consulting team, you know, those are their favorite tools.

I'm gonna assume the, the underlying the, the, the brand Red Hat, and I assume it'll be Hasi and, and Aptio, you know, they're still selling those products. But in a perfect IBM world, those products are wrapped around some sort of version of the IBM Cloud, some sort of version of, of Watson X or Granite or whatever the IBM AI is gonna be. But it's all wrapped around IBM services, right?

Because that's still the mothership here. And It Yeah, go ahead. It, it buttresses it not buttress, it supports greatly the IBM services offering.

You used the word consulting, Kyra is the consulting arm that got spun off. Yes. I I think of IBM when I said S Global services, That that's, that's not entirely correct.

NDL is a services company that does managed services and a lot of maintenance work, but Rel yields IBM Global Services build within IB and that's yes, that's Driver. Okay. Yeah.

Now, Hashi, let's remember how Hasi got into this mess, right? And, and look, Mitchell Hashimoto did an amazing job with Hashimoto. He started that company, I think he was 18 years old, and he built, there are two or three Terraform is probably in and of itself a multi-billion dollar pla uh, project, uh, you know, product.

And then don't forget, vault and Secrets Management and all that good stuff is, is big. And there's a third, and I'm not remembering it right now, but, Or the service match console. Yes.

And, you know, they changed their open source licensing and there was a big pushback in the community, right? That was quite a, quite a row over at Coup Con, uh, two years ago or whatever it was. 4 billion.

If you know, a billionaire. A billionaire, that's a big deal. 4, it's a great pickup.

They've got three great products. I think the issue is gonna be how well they integrate into Red Hat, how well IBM services wraps around these things. How well they work with Ansible or, or in the finops or the rest of the I-B-M-I-B-M security.

IBM security's still a major player in the game, right? Man, they got Vault to play with, you know, to, to lead with. Now that's gonna be a big tip of the spear for them as well.

So I think overall, this, this, I always thought this was a great deal for IBM. It was a great outcome for Mitchell. I think Hashi could have gone on to do Hashi Corp.

Could have gone on to do bigger and better things, perhaps independent. It'll be, I think we will have to see how the big bluing of Hashi Corp, you know, talk to me two or three years if you have brain drain, if you have continued development of product, if you have continued integration that that's Well if you, My take, yeah. If you want me to be equally pessimistic about, well, you're not really being pessimistic.

No, I'm not less, less rosy about it. Um, I do think you have a point because IBM acquires these companies and they start to turn more towards details. Right?

Really important and helpful and valuable details as opposed to pushing envelopes or, or, or innovation. And that is not, that's just a different business model, uh, and a necessary one. And I really, I want to emphasize that.

Um, I don't think that's a bad thing. I don't think standing up will. It's be Doing incredible what new things no one has done before is as is as much as it's, hey, There's a reason they're around Guy.

There's a reason they're around a hundred plus years, right? This is what they do now is Red Hat the daring darling of, of the Linux open source world that it was seven years ago? Probably not.

So, so I have a question for Mitch. Will IBM Open Source Terraform under some sort of consortium play and, and, and, and maybe much the way that Red Hat has been adding more things to the consortium later. And then will that bring open Tofu and Terraform back together, or is Open Tofu off on its own and maybe we will gain momentum because, you know, there's a lot of folks out there that aren't in love with IBM and Red Hat.

I don't think Open Tofus going anywhere. I think it's Stay right there. It's gonna stay right there.

Hard. The cfcf. Yeah.

And they're not gonna, they're not gonna open source. Bring, uh, bring, uh, sorry. They're not gonna open source their, any of their products.

They're gonna leave 'em as is what I'm seeing About Well, wait, but wait, Mitch, let, let's, I, you, there's, there's, there's, what's the word I'm looking here? There's nuances here. Yes, there is an open source version of Terraform.

Terraform was open source. They just, they changed the license a little bit. Why would, why would they go back and Open source?

I don't think they don't, they, they'll go back to an OSI license. I mean, you step back and look at all the things we're talking about, whether it's Red Hat or Ansible or Terraform Vault, all of these things have been around for a while, at least 10 years if not more. When you go back to, to Red Hat.

And so what is IBM acquiring? Yes, they're acquiring product companies. No, they're acquiring customer bases that use all these products, right.

That they can serve. Right. They're not buying it just to sell a lot more product.

They're buying it. 'cause they're getting massive customer bases from this. It's huge.

Ansible has been around for a long time. There are a lot of people that use it. Same for, for, uh, Terraform.

So I, you know, you talk about the consulting services in, in the kind of what got, uh, spun off with ndl. IBM is still an operations structure process kind of company. That's what they serve really well.

That's what their bread and butter has been for a long time since they've shifted out of just doing mainframes. You can argue mainframes where infrastructure too. So, so well don't don't about application management.

I just wanna Put No, no, that's, but that's part of it. It's not, we're not talking about IBM's buying cursor. You know, we're talking about IBM buying staples that have been out in the industry for a while because That's, they got, they got some red letter brands here with hhi.

They got $3 billion business. They're great companies. I'm not disparaging them am all, I'm just saying they're not on the bleeding edge of acquisitions.

Let's Frank, But, and also to the point on the open source. Hey, red Hat changed Rails license too, and a lot of people push back. Oh yeah, yeah.

But they're still around. They're still around. I, so no, I do not see IBM going back on the licensing change.

I think Open Tofus doing just fine under CNCF and, and whatever your cup of tea is, your cup of tea is. But Mitch, and as we've all been, yeah, we've been saying that this has been, so these tools are pretty, I don't want, don't wanna call 'em old, but respectively they are, they are old. They're stable, mature tools.

Mature. And many of, many of their competitors we don't even talk about anymore. You know, puppet and Chef.

Those tools have, you know, they're slowly being replaced by other tools. And I, I think what we should be looking at is if IBM has, you know, Terraform and Ansible together and some of these other tools, isn't this a way for them to start looking at how to put some money behind the space in terms of ai, right? They, they basically own.

Now the, there aren't too many other tools that we've talked about in this space. Terraform and Open Tofu kind of, are it, I mean, Lummi has something out, some stuff out there. Cross Plane got a lot of attention for, uh, quite some time.

I don't see those very, very often anymore. Um, I see Terraform and Open Tofu being the two that are, uh, most competitive with each other. So, uh, I think that there's a bigger play that we're, we're, we may not be seeing, um, that IBM sees.

And how do we disrupt both this configuration management and IAC uh, these platforms? And To your point, Tracy, I think we, the reason why we talk about Ansible is 'cause Red Hat bought him. Otherwise we Would talk about other way because Right.

If it was progress or who bought Puppet, the people in Minneapolis, uh, The testing company Horse or, or Right. And you, you see where those are. But let me just add one other thing and why it bullish on IBM.

They do have the ai don't, don't underestimate the work they've done with Watson all these years. That's what I'm saying. Yep.

And don't underestimate what they've come, you know, there's this granite thing actually, if you term is the Ryan Shroud over at Signal 65 Labs has done some work on, uh, on, uh, granite. I think the report is available. We're gonna feature, I I interviewed Ryan on text Drunk tv.

I think it's out today. It's a great paper. Definitely Check it out.

Don't, don't discount their quantum work too, which is, And they're qua, right? Well, Quantum's a whole look all of a sudden, guys. I don't know.

No, That's a, that's a, that's a, that's a service to expose, just like, you know, talking About. No, but the last two, three weeks we're seeing, we're seeing quantum sneakingly becoming real before our eyes. I actually, can I give you That's, that's why I mention it.

Yeah, exactly. Can I, can I give you a nice word for old just so you have it in the future? It's called venerable, as in mainframes are venerable.

So then, you know, You don't have to Well, thank you from the dean of, that's your word for today, folks. You missed college or something. You that venerable.

And I want everybody to acknowledge that Alan has said that we might be on the, you know, that quantum might be here sooner than 10 to 15 years, which was another conversation we had. And I was like, but we might be here. No.

So now I'm seeing maybe 2028. I, I actually copied a, uh, off of LinkedIn. Someone posted a quantum ecosystem with all the logos for it.

I, I'm thinking we instead, So yeah, this is not a quantum discussion, but Tracy, I think it's next year. I don't think it's 28. I think it's next year.

com something. Sure. Why not that It's time.

It's time. Just gimme an just Yeah, we're good to go. Just going back to this conversation, I wanna point out that any of these, uh, tools that are infrastructures, code, um, what other kinds of tool, even Ansible, GI Ops, they are in a position to be disrupted at this point with ai, all of these tools.

So we should be looking at what that disruption looks like. We should look, be looking for it, uh, and looking forward to it because it is time. And, and, and this is the case for, you know, helm charts, uh, the Docker files, uh, Jenkins workflow files, all of these types of scripts that we've been relying on, Not venerable vulnerable.

They are vulnerable for disruption and the disruptions needed it's time Here, here, Go check out cloud code if you wanna talk about disruption. I think that's alright Guys, I gotta reign this in. What a great discussion.

Tracy. I think you're dead on, by the way, that might have been one of the best closings we've ever had on Textron gang. Mike, would you say that was venerable?

I, I would say you're Venerable, so there you go. I'm venerable. Yeah.

Age, like fine wide. Alright, I think we all are. Hey, We've got vulnerable.

I feel vulnerable. I'll Mitchell and I wanted to do a commercial like that when we did still secure. It was supposed to be like, are you feeling vulnerable?

Have you been intruded upon? Um, come to Still secure anyway. Yep.

Yes. Um, okay. I lost my chain, but hey, we've got Techstrong TV coming up after this.

Stay tuned for the rest of our day's programming. Tracy, Mitch, guy Mike, thanks for joining in. Thank you for watching.

This is Alan Sch, we're out. This is Textron tv. Hey everyone, welcome back here to Techstrong tv.

I'm really happy to have our next guest on here. It's the first time he's been on. I hope it won't be the last time I'd like to welcome.

And if I mispronounce, I apologize, snore to just SPU close senior VP and general manager for WebEx devices over at Cisco. Nora is, how bad was that? No, I think you did a good job, Alan.

And, and, uh, you know, uh, with a name like that, as long as it closely resembles my name, I'm, I'm perfectly fine. And, um, I actually head up, uh, employee experiences at Cisco now with, uh, both the WebEx suite with calling and meetings and the rest of the Suite plus devices. So we have lots to talk about Today.

Absolutely. Absolutely. And, um, thank you for being so gracious about me, mangling your name.

I'm sure I'm not the first or the last person, but, uh, for those at home who might be wondering, snores name is of Norwegian descent, and it's a very, we're not gonna go into it here, but it's a, a name with Rich, rich in history and tradition, and I'll leave it at that. Um, so snore. Everyone out here has used WebEx, I think, right?

Other people have used some of the other solutions out in the market. Other people say, I don't really care what I use as long as it works, and that that's okay. When we think about WebEx though, and WebEx devices, it, it's more than, you know, the mission may have started out as just doing simple video conferencing, but it's grown into something much more richer, much more expansive, much more useful.

Why don't we, if you don't mind, and I don't wanna put you on the spot, but I am, tell us what, you know, talk to us about the mission now. So I think the mission, if you think about it, is that when we look at any collaboration tool, whether that's from Cisco or from any of our competitors, the whole purpose of that, I would say are two things. First of all, communication today, using video, using, uh, chat, uh, you having devices, et cetera, is mission critical for the companies out there.

So I think that's number one. And that has dramatically changed over the last few years. So, uh, it has to be reliable.

It has to provide the things you need when you need it. The second thing is the technology should never get in the way of what's happening in the meeting. I tell my team when we are developing these products, that we should make a product that people find easy to use that doesn't get in the way of what they're doing.

And that should be the best supporting actor if we're talking an Oscar term of actually the real meeting. So we should never get technology in the way of, but it should do what you expect it to do, uh, uh, when you need the different type of functions. And I think that creating a great product, creating a great user experience is key to be able to create that.

Yeah. And, and you know, if I, I'm far from an expert on, on in this matter, in this subject, but, but creating that experience is I think kinda what separates, excuse my sexist, but it separates the men from the boys, if you will, in, in this whole area. Right?

I think kind of doing basic video conferencing is almost table stakes these days, but creating a rich user experience, create adding all of the, the, the surrounding richness, if you will, is is what distinguishes, you know, premium from, from others. Yeah. And, And I think there are, there are two facets to that, if I may.

Um, one is actually the people that are using the service, uh, uh, in a meeting, in a conversation, uh, that are using the equipment and everything that actually gets stuff done. But then you also have the people in the organization that own and operates. That is the IT organization.

That's the facilities organization that it's actually running this service. And as I said in the beginning, with this now being mission critical, you need to make sure that they have all the right tools as well. And I think where Cisco has a strong offer is that we have both the meeting and the calling and the contact center backend.

We have, uh, application that runs on your phone, on your, uh, laptop. We have the hardware devices as the front end. We have a fabric of AI that actually goes across all of these, both, uh, uh, both all the way out at the edge and in the back.

But then what's interesting with Cisco is that because of our networking and security, uh, business, we also have the manageability and the observability that will actually allow you to run this and, uh, and operate this at scale, uh, as well. And I think that bringing all of these things together and think about that holistically, uh, is, is absolutely, uh, absolutely, uh, key to us. And we call that full stack collaboration because it basically builds, uh, on, on everything.

Absolutely. One thing you left added there that Cisco brings to this security, Uh, absolutely security and security is woven in. Thank you for reminding me.

And, uh, uh, you know, this is my elevator pitch when I, whenever I asked why Cisco. Mm-hmm. This is, is really the elevator pitch.

And, and if I can go into some, some really deep details, uh, on the networking side, we have a tool called Thousand Ice, uh, which basically means that you can do full, uh, uh, overview of your network or all the way from the cloud, all the way out, uh, uh, into the network. And we even have implemented a thousand eyes agents on our devices, which means that, uh, that we take things from the networking business, we introduce that into CoLab, which means that you have a whole different suite of tools as well, uh, that that can actually be used for people that own and operate the service. Uh, and, and, uh, I think that those tools are also super powerful.

Agreed. Agreed. They are.

Um, SNO, if it's okay, I wanna jump in. We, we've kind of been skirting the edges of it, but let's dive into optimizing IT and employee experiences using things like scalable video collaboration, streamlined workspace design. When, when we talk about that, dive in for us here, if you can.

Yeah. So when it comes to, to scalable, um, I think scalable comes one for the number of participants you can bring into meetings. And, and if you can do large scale meetings today, we can cover meetings up to a hundred thousand people.

So that's one part of scale. The other part of scale that's really key to us is the ability to scale your deployment. Um, we had a, uh, an organization that during covid went from two meeting rooms to 600 without adding people to their IT org because it's scaled, uh, because of the tools that are available and because the way we also use those tools in, in, in, in the manageability and observability of the service.

So I think that scale comes from, from both ends, um, so that you can actually, uh, increase your footprint and you can do this without, uh, uh, without adding people. I think that is also really key about, uh, about scale. Absolutely.

You know, you mentioned AI before, usually the, you know, we have the par the balloons go off when someone mentions ai, right? How long can you go without mentioning ai? What role is AI playing in that though, in delivering that sort of scalability without adding, you know, additional IT resources, which you're outta premium today?

Yeah, so with ai, I think the way we have been thinking about ai, uh, at Cisco is really along three axis. Uh, we started incredibly early with a partnership with Nvidia back in 2015. That's 10 years ago.

Uh, so all of our Cisco devices have actually been running an NVIDIA platform for a decade. Uh, through that we developed a whole, uh, uh, library of algorithms out at the edge that we've been using, uh, all along. So that's, that's something where we've just put stone on top of stone on top of stone that has been helpful for, uh, better video, for noise canceling, et cetera.

And we, we do that and we, we call a lot of what we do, uh, there, RMM or realtime media models where we are actually using ai, uh, on audio and video and, and, and using that. Then we use large language models, uh, to transcribe meetings, to, uh, take actions to do all the things that, that you expect from AI in, in 2025. And this is core to any type of meeting.

And to be able to, uh, to actually use that and use those rich tools. The third thing, which I think is pretty unique for Cisco, is that we also use AI on the manageability side. So we have a tool called Control Hub, where you gather all of the information from your, uh, from your estate.

And let's say you have, uh, a problem in a room where, um, uh, where, uh, something is going wrong or you have a problem in a network where, where there are challenges, then we have the ability to actually use AI to prioritize, to, uh, propose ways of solving that, that would actually go through a lot of different tools to be able to gather that information as well and say, you know what, the first thing you should do is to fix this problem because that has the highest impact, that has the most amount of users or the highest seniority of meetings, et cetera, et cetera. And so for us, AI goes really across all of those three. And also with the acquisition we made of a company called Baby Labs, uh, some years back, we have some advanced AI technologies when it comes to optimizing for voice takeout, uh, uh, any type of disturbances as well in, in the meetings.

Excellent. Sonora, I'm gonna ask you to put on some crystal glasses here, if you will. All of this we've been talking about is great.

We've come a long way from just the basic conference call, video call, but the promises to deliver so much more here, more immersive, more, more useful, I guess is the best word I could think of, more valuable. If I, if I asked you to, you know, look in your crystal ball and say, Hey, what, what can we deliver that would make this even more valuable? Where do you, you know, where do you think, and not, maybe not just Cisco, but the industry in general, where are we going here that can make this happen?

Yeah. So, uh, and I think this is valid actually for, for the entire industry. Uh, so we were working a lot on what is going to be our vision, uh, going forward.

And, uh, it took us a long time to land on two simple words, and that is what we call distance zero. And what we mean by distance zero is that regardless of where you are attending from, regardless of the shape of your meeting, it should feel like you're in the action. Uh, I think that if you look at what we did on the Covid with all of us had one square each, uh, I think we had a good experience for certain type of meetings, but when you have people back in the office, you have people calling in from a remote, and then all of a sudden you're going to discuss an object.

How do you make sure that there is zero distance for everyone in that meeting when that object is being discussed? And what we are striving for is to make sure we tear down the barriers between people that are together and people that are remote. And that we're also trying to not only make that about the human and the human interaction, but also when you start discussing objects.

That is why the collaboration that we have with Apple, uh, around stereoscopic video, uh, there were that you can basically, now when you use WebEx meetings and WebEx devices, you get 3D stereoscopic video used using Apple Vision Pros. We have brought down the distance as well when you start, uh, when you start, uh, discussing objects and you start discussing both concepts and objects together, et cetera. So I think that if you asked me to look into the crystal ball, I think what we are going to strive for, um, is to really try to drive distance zero across all of the meeting types and all of the type of work that you will do in an organization.

And I think we've just scratched the surface there, and I think a lot of things are going to happen in that space. I don't disagree. So we're about outta time, but for people who want to get more information, who wanna plug into what, you know, WebEx is cooking, what, what's the be what's the best place to send them out?

com WebEx, but give us, what do you where, give us the OnRamp. Uh, so, uh, the, the OnRamp I would say are a couple things. I mean, first of all, the obvious ones that you just mentioned, go to our, uh, go to our landing pages and, and, and things like that.

But what we have done is that we have created a tool that you could just download and use. And in that tool, uh, you can actually just specify the sizes of your room and, uh, the number of people you would like in that room. And then the tool will actually propose for you the type of equipment you should have there, the number of microphones, uh, if there are dead zones in the room, or maybe even if you're over specified it, maybe you should take some equipment out or may maybe you could have a smaller screen.

And I think that using that tool, uh, is something that will really, uh, get you starting. And I think that that would be a great, uh, starting point and we'll, we'll send a link over. Absolutely.

We'll have it there. Snore. Thank you so much for coming here on Text Trunk tv.

We appreciate you, uh, coming on here. Um, you know what, for people, look, everyone's going to conferences again, right? It's no more just virtual, which, you know, wasn't bad with WebEx, all this virtual stuff.

It was good for it. But where, where, you know, anywhere in the world that you can think of, you guys are gonna be at that maybe some folks in our audience might be able to get some hands on. No, absolutely.

And, uh, you know, we have Enterprise Connect coming up, uh, this month actually. Uh, we'll have a big presence there. Uh, you know, we have, uh, ISE that was just done in Europe.

We have Infocom coming up, uh, now and, and in the summer. And then we have WebEx one coming in the fall, and then we have three Cisco lives during the year. So there are a lot of possible interactions when you go there.

You could touch it, you could feel it, you could talk to the people that actually develop the, or that's who we are. You'll be hands-on, meet people that can go deep with you. You could come and listen to our, our, our presentations where we try to take a broad, uh, approach looking into what's happening in the industry.

And, uh, it would be lovely to, uh, see, uh, uh, your audience there and, uh, it would be great to meet with. Fantastic. Thank you.

Thank you. Snore. Thank you for coming on today.

Um, senior vp, well actually that title's a little out of date. What, what is the right title now? You know, I'm, I'm more focused on what I do, which is I jump outta bed every single morning to make distance zero happening.

Uh, but I'm the senior vice president and general manager for employee experiences, which is basically WebEx, suite plus, uh, devices. And thank you for having me. It was an honor.

My pleasure. It was my honor to have you. Good luck.

Keep up the great work. Can't wait to see what else comes down out of this. It's an exciting time, certainly in the industry.

We're gonna take a break here on Textron tv. We'll be back in a moment. This Is Textron tv.

Hey guys, thanks with Throw, we're here with Emily Long, who's CEO for Adera, a startup that just raised $15 million in additional funding for workload isolation technology, and I'm gonna let her explain what that is. But Emily, welcome to the show. Thanks for robbing me, Mike.

Appreciate it. We've been trying to isolate workloads since somebody invented the virtual machine. So my question to you is, um, what's different about your approach here and what is the problem we're trying to solve?

Exactly. Yeah, so if you kind of take a step back, if you're looking at, like you said, virtual machine technology back in the day, um, what we're really focusing on at Adera and why we just closed our 15 million, uh, series A round, um, with Microsoft as one of our backers, M 12 as well as a couple others. But, um, the reason why we really are focusing on isolation at the container level is because in virtual machine world, there are a lot of isolation technologies that are fairly effective.

But when containers came onto the market and people started using them, you know, over a decade or so ago, uh, containers actually have a false, uh, word to describe them. Containers actually don't contain, which is quite funny in their name convention. Uh, and it, I think it's taken some time for us to really appreciate how much they don't contain.

And so a lot of, um, the, the industry has kind of started to move on and really realize the risks. Here. You see a lot of people talking about vulnerability, exploitation, and people's secrets getting exposed.

And really a lot of that has to do with the lack of container isolation that's present today. Now Adera really focuses on the premise that you should be able to trust your workloads and trust your containers and have them be isolated as you really did with VMs back in the day. And so we really came forward with a isolation technology that really uses, um, a lot of older primitives using some older technology blended with some new technology to make it really able to be used anywhere at any time.

And so we really focus on making sure that you can't get exploited for lateral movement, living off the land attacks, those types of things. And so we care a lot about this, um, particularly in the age of AI because people are now using GPUs and even the attack surface on GPUs is exponentially greater and scarier. And so we ca really came forward to try to solve that problem at a really fundamental, simple way.

'cause there are actually some technologies out there that exist, but they're really complicated to use or have performance degradation and those types of things. So it's been kind of this fight between how much do we lean into security and how much can we actually run our infrastructure, um, simply and and meet our customer's needs. You this need to isolate kind of, uh, lead to some, for lack of a better phrase, I'll call it unnatural acts, where people were putting containers in Kubernetes on top of virtual machines to guarantee the isolation.

But in so doing, adding overhead and maybe not being able to move off of a virtual machine altogether, which increased cost if it was a commercial one. Yep. So, um, has this been something, I feel like it's a long time incoming, but is this something that's a little on the overdue side?

Uh, we, we believe so, yes. I think the hard thing with computing, when you kind of look at it from a a holistic perspective, you know, we, we end up with a lot of technical debt, right? We're kind of like layering upon layer pulling, layering over time.

You end up with top-down solutions that are kind of plugging certain holes here and there, and we end up with this really complex ecosystem of layered tooling. It is overdue, um, mostly because I don't think there's been anyone focused on really trying to solve it at the lowest levels. And very simply, like you hear the premise of like, secure by design or secure by default making things just run securely naturally, which is really where we come in that's a little bit different.

Um, there's people, you know, trying to look at kind of the isolation or, uh, I wouldn't even say isolation as much as inhibiting vulnerability exploitation to be a problem by alerting you. And you look at your dashboard and you can see if something's going on. That's really been the industry's response to the need for isolation because the problem itself had not been solved yet.

And what we came in to do is really this overdue need is to solve it simply and the lowest lever levels and being able to plug it in really simply because we, we recognize most of our team here at Adera has worked with enterprises for years and years, and you can't tell an enterprise to start over and rebuild, and you can't tell an enterprise to slow down their production environments because customers, you know, that they're serving have certain expectations. And so how do we evolve with the, you know, increased threat landscape, but also create a simplistic solution to do so? And that's really where we came in on the isolation side specifically.

And if I don't do that, it comes really hard to limit the blast radius of a breach, right? Because otherwise this malware starts moving around laterally and it's too easy to do. So is that part of the thinking here?

Yeah, I'm really, that that is the, the premise is that, um, because containers don't contain, if you get an exploit in one container and you're running containers alongside each other, they all have what you call a shared kernel state. So in any environment, you're kind of setting up, there's a shared kernel running your, your workloads. If you get a container exploited, they can pop over to other c containers and the shared kernel, which in the current day and age means you burn your infrastructure down.

You don't know where they've gone, you don't know what's been taken, you don't know where they're lurking. And so you have a really, um, unfortunate situation as a, you know, person who's running infrastructure to have to start over. It's not, um, we, we wanna try to avoid that all together and, and we really should be able to trust the infrastructure that we're on.

And, and that's really where we, we come in, is to make sure that when you're running your containers, if you have a isolation boundary around each workload, and the way we see it is that you should not have a shared kernel state. So we also isolate the kernel, um, that allows you to then not worry about the blast radius at all. And so it really gives the power back to people running a secure infrastructure, um, themselves.

So it's, it's pretty powerful technology. And again, like you said earlier, overdue. So You raise the 15 million, um, I'm assuming you bought everybody at least one beer and but what, what from here?

Yeah. I mean, yeah, vir, the virtual beer, but we'll, we'll come together and celebrate soon. Yeah.

Um, we actually, so, um, we, we closed the series A, um, recently, like I said, with Microsoft. We also had some other investors coming on, um, with Inq Tel as well as, um, mantis Venture funds. And then we also had the, our existing venture investors from our seed, um, in the Act six per five FPV come back in we act, we actually s only raised our, our se our seed, um, three months prior to closing the series A.

Um, the reason I mentioned that is because I think that there's just a lot of, um, recognition that this is a huge area for opportunity and making things easier. So really what we're focusing on now is our AI product. Um, it's not AI in the way that it runs, it secures AI workloads.

And so really what our focus is with this money is putting into the further and increased development or, or pace in which we're developing our G-P-U-T-P-U and DPU security offering. So when we're talking about kind of isolation of workloads and them being important holistically, um, over 65% of people are using Kubernetes and containers in their AI ML workloads already. And we already know that the isolation primitives that exist aren't there.

And so we're really here trying to push that forward as fast as we can to make sure that the amount of AI workloads that are being processed now have the same security guarantees with GPUs as, as we want to do with the holistic container environment. You know, I love to get your opinion, but we talk a lot about DevSecOps over the years, and we make, you know, some progress, but not as much as we would hope. And I have to wonder how much of that is just kinda something we're doing to make up for a lack of a capability in the core platform itself.

So, um, if we can isolate the workloads, can we just have better DevSecOps workflows based on how we deploy the software in the first place? Yeah, I would agree with that. You know, there's incredibly smart people out there trying to do things themselves, but it's with the, with the inability to do something at the base, like at the actual infrastructure level, we will always be in a reactive state.

You know, I think we've talked a lot about, um, or, or the industry has been talking a lot about the proactive measures of security versus the reactive measures of security. And we're putting a lot of DevSecOps teams in a reactive stance, and we really need to do better for them so they could spend time doing more important thing. I not to say it's not important, but they're, if we can actually stop it at the source, then we'd be able to enable them to do a lot better work.

So, yes, I think that, you know, we haven't really gone down deep to solve the hard problems that's really changing the way computing works, which is really our, our ultimate goal. Um, because we, you can't just keep stacking like the Jenga tower eventually will fall. And, you know, what we wanna do is be able to like, put the foundation back together again so that we don't have that problem where I, I think there's a misconception that it's too far gone and it, we don't believe that that's the case at all.

And yet if I look around, the bad guys seem to be just sitting around taking advantage of the way we built everything in the past and almost daring us to go fix it. Right. I agree.

I agree. And we are taking that challenge over here. Uh, and, and it's a hard one.

We know, we, we, you know, we recognize the, the depth at which you have to kinda change the way of thinking. You know, in some ways the industry has gotten comfortable with this idea that, you know, well, we have this alert dashboard, at least I know what's going on, all these alerts. But you can't actually then stop them before they start.

And so we're really working to shift kinda that mindset of we don't need to rely on this dashboard. We, it, it should still exist, but we should have context like what's important, why should we care, um, what's actually at day, you know, at risk. And we don't need to give any sort of attackers any easier way to get in than we already do.

And, and we do believe that we wanna empower the industry with the ability to keep their infrastructure safe from the start. So when you talk about this with customers, what's the part that's the most challenging to help them get their heads around? I think the idea that this is possible, we, we call it kind of the, uh, 15 minute skeptic effect.

And I think it's because we've been in this industry so long to assume that it's not something you can fix, uh, and not do it in, in a way that's not performance inhibitive. 'cause there have been other open source technologies who have tried to do this, but when you try to run it, there's the, you know, 30, 40, 50% performance impact and it's just not a viable solution to use. Um, but most of what we get through is people being really, I can run this anywhere.

It's that simple. Um, because I think most people believe that to, to create something that really allows multi-tenancy, um, and to, to decrease costs in this way would somehow require some sort of major trade off. And that's been our big conversation starter here, is that we, we have intentionally architected it so that the trade off doesn't exist, um, because we don't believe that there should have to be one.

And thankfully, you know, I, I work with incredible technologists. We, you know, we've been really fortunate to be able to find a solution to this, this problem. And the other question we get is, how come nobody's thought of this before?

Uh, and I think it's, you know, again, you have to have a really deep knowledge of computer history meets the present day, need to be able to architect something like we've done. Now inertia is a powerful thing, and yet we are seeing the rise of these platform engineering teams. So is it easier to have this conversation now because so many people are kinda rethinking the way the platform functions?

Yes, I would say definitely. So, and, and also, you know, the, the relationship between platform teams and security is a really important one too. And we found that, uh, for many years it's, they've been somewhat at odds with each other because you're really trying to, you know, a lot of times security tools require this just very heavy, um, large kind of lift.

And so if things are slowing down and stuff like that, um, but when you're looking at platform teams, you know, they're really looking to simplify and they're really looking to do things optimally. And, um, we've been really fortunate as we've come out. We've, we've only been around since April of last year, but we've had great conversations with large enterprises, mostly the platform teams too, because they're looking for this solve and platform teams too are also starting to get the lift of certain compliance measures, like specifically Kubernetes container based things through FedRAMP and stuff like that.

So they have even more interest in trying to make sure that the infrastructure they run is inherently and end of its own right. Simplistic. Well, folks you heard in here, Hey, if you keep doing the same thing the same way over and over again expecting a different result, I call you crazy.

So that's all right to change the way we do this thing. Emily, thanks for being on the show. Thank you, Mike.

I appreciate it. Alright, And back to you guys in the studio. Hey everyone, it's Alan Shimmel, CEO founder at Techstrong, and welcome to my first adventure on LinkedIn Live here.

We're starting a new show and we call it Shimmy says, because it's me saying whatever I wanna talk about. But it's not just what I wanna talk about. I want to hear what you guys have to say as well.

Um, look, we're gonna aim for 10, 15, 17 minutes here, so it's not gonna be too long. But if you've got something you wanna ask me or a topic you want me to, you know, comment on, I'm happy to do it. If you're not familiar with what we do here at Techstrong, you know, we cover DevOps and cyber and cloud Native ai, I-I-T-S-M and everything else.

So that being said, I really wanted to talk today though about what, what seems to be capturing a lot of news cycles. And that's this Project Stargate that was announced yesterday by the Trump administration, along with in-person, uh, appearances by Sam Altman of open API of, uh, excuse me, chat, GPT Open ai, uh, Larry Ellison of Oracle and Maan of SoftBank. Now, there's a lot of people out here saying, holy mekel, $500 billion.

That's a lot of money. What a great thing. There's a lot of other people saying $500 billion.

Who are they getting all those companies together? Don't have $500 billion to invest in this. And even if they did, would they, when they would, they, when will they, what will come of it?

How are they, are they all gonna play nice? Because it's not just those three companies. There's Microsoft involved, and you could bet Google and Amazon and the usual cast of Tech High, uh, hyperscalers will be involved.

There's another group of people. And, and quite frankly, this was my initial reaction too, is no, that $500 billion isn't coming from commercial private investment. That's money that the Trump administration's gonna take out of the federal funds.

And it's kind of the payback to the tech bros who've invested all the money, all the money they have in the Trump campaign, and, you know, making gifts to the inaugural fund and so forth. So, you know, what, where does the truth lie here? So, first of all, let me say I'm a big fan of investing as much as we can into AI infrastructure.

I do think that AI is going to change the very fabric of civilization, much the way the internet has. As a matter of fact, I think AI is the biggest thing since the internet. So let, let's see what that has to, to stay on it.

Um, I do think that we are in a race for technology, much like the space race of the sixties, except this time it's trying or not, the Soviet Union. And we want to take as much, take down as much as we can, uh, here in the US to con continue our dominance and lead in technology and specifically in this AI field. But it's not just the us.

I think this is a game of the entire Western liberal, you know, modern liberal western world trying to do this. And I don't know how much they're gonna be willing to just abdicate it over to the US And this is a global game. Make, make no doubt about it, right?

You're gonna have investments from Japan, from friendly countries and people in the Middle East as well as Europe. I read an interesting point of view on it in Forbes today, which is really what they're looking to do is soak up as much of the venture capital that's being, you know, set aside for AI as possible before it makes its way to China. And you know, again, I I took a different view of that 'cause how much VC actually makes its way to China.

I think VCs have been burned. Western VCs, Western sources of funding have been burned investing in China because China follows a predictable path. They take your money, they make goods until they don't wanna make your your goods, or they don't wanna let you make your goods.

They'll make your goods themselves. You see it with cars, you've seen it with planes, you've seen it with toys and clothing and factories. This is what China does.

They take the money, they offer you promise to their, you know, huge market. And then they, they don't exactly open the kimono, so to speak to their market, and they wind up keeping it for themselves. So I don't know if western dollars are gonna be flowing to China for AI investment.

However, there are, there will be competitors for AI investment beyond the us. They'll be Canada, there'll be Western Europe, there'll be Israel, there'll be Eastern Europe as well. Um, it's a global market that we live in.

And even with that though, $500 billion, I don't see how, if that's a real number that we're gonna spend in four years, that's $125 billion a year. I just don't see us spending anywhere near that kind of money. 'cause we just, the, the capacity to do so is, is not there.

Um, how much of it will be government? Is it for every, you know, 1 billion in private, you're gonna have 10 billion in government money set aside to this? I don't know.

And, and let me say, I'm not against the government putting money into this, right? If you look at every million dollars that the US government spent at NASA during the space race, it probably returned 10 x in in private, uh, accomplishments. Either in new, new technologies, new products, new processes that really help the American economy boom, from the sixties into the seventies.

So this is, this is an amazing kind of thing. Um, I, so I'm, I'm not against the federal government paying into this and, and making it happen. I would like to make sure that it doesn't just end up in the hands of a few oligarchs, right?

I think this is, it will create a lot of jobs. It will be a defining moment for the rest of this century if American can really get behind this. But it has to be done right?

It can't, it can't wind up being like a, a Vladimir Putin and his and his, you know, oligarch friends, divvying up this big pie that we all put into. I see we've got a question. It's from our friend Paul, and he wants to know, what do you think about the plan $500 billion investment?

Well, I think I just told you my, my 2 cents on it, but I, I'd be interested to hear what you guys think. A lot of people, or not a lot, but some people say that, Hey, AI is relatively unproven. Frankly, we haven't seen the results in terms of business that we thought we would see up to this point.

Well, it's still early in the game. What is that $500 billion gonna go into? Well, they're talking primarily about data centers, but in order to have the data center, you have to have energy that feeds that data center.

So whether we're talking, I, you know, I'm not going out and saying, let's go frack drill, baby drill. But we need energy, whether it's compact, nuclear, hydroelectric, solar, wind, natural gas, some sort of clean, I would hope renewable sources as well. We need to figure out the energy formula.

Secondly, the, the, just the cooling and so forth for these chips. We need better technology, not just at the chip level. 'cause we need to make these chips.

Right now, these chips are basically all made in, in Taiwan. Daniel Newman, over at the Futurum group, of which we're part of. Put out a nice LinkedIn post today with a chart.

You know, the fact of the matter is when you look at foundry, uh, Taiwan semiconductor still has, I think 62% of the foundry market. We need to change that equation and have those foundries here in the US as well, I think. Um, so you've got chips, you've got energy and cooling you need, you're gonna need more networking, right?

Uh, there was a time I thought we had overbuilt. I think we all thought we had overbuilt fiber and so forth. But whether it's 5G or other resources, we're gonna need more of that.

Jody has a question. Will it create as many jobs as it potentially eliminates? There's not a doubt in my mind that AI will create more jobs than it eliminates.

And the jobs that it creates are gonna be higher paying jobs in the jobs it eliminates. 'cause I think at the first thing it, AI takes out lower paying, lower hanging fruit jobs that is sort of remedial. And the jobs that will create will be higher paying.

I think the bigger question for this operation Stargate is will it create net net new jobs? So it's not just replace one for everyone you lost. Does it create whole new classes of jobs?

And not just the AI jobs you're thinking about? Someone's gotta build these data centers, that's construction jobs and all that goes into constructions, architects, electricians, and plumbers. And people are gonna have, you know, these data centers will be staffed by people.

So you need facilities for those. You are going to need screens, you're going to need alarm systems. You need, you know, everything that goes along with a modern data data center.

So I think it create then you have the fact that the economics of the data center, the people who work there need to eat lunch every day. They need a health club to go to a gym. They need doctors, they need schools for their children around these data centers.

This kind of, and this is why I'm, I'm all for the government getting involved in it. This kind of investment is like planting a seed of which a whole town or a whole ecosystem grows up around it. There are plenty of studies that show for every dollar you invest in infrastructure, it throws off three to $10 in, in other kinds of economic investments supporting that infrastructure.

And I think the same is true here. Again, the, the same way, we don't want to concentrate this though into just, but a handful of oligarchs getting this money. We need to make sure that these data centers are geographically dispersed, right?

Maybe we don't put them in hub zones, as we used to call it when I was selling to the federal government, economically disadvantaged areas. I don't know if we need to do that. I, I know, for instance, there's a huge data center going up in Abilene, Texas where my son Bradley works and happy to I, having been to Abilene, I can only imagine what a huge data center will would do for that economy.

Um, but we need to spread 'em around. It shouldn't be just Texas. It shouldn't be just red states or blue states.

It shouldn't be just disadvantaged areas. That $500 billion has to find its way throughout the US if it's gonna be there. I mentioned earlier, Canada, Mexico, Western Europe, I don't, you know, they're not gonna sit on their hands, nor should they sit on their hands and let all this money flow into the us.

I think corresponding dollars will probably flow into locations where it makes sense there, right? I, I think capital goes like fluid to the lowest level where it makes the most sense. So I'm hoping we will, we'll see, you know, the, the, the repercussions and the, and the fallout from this will make its way even beyond the borders of the us.

Um, but make no mistake, we, in the US look, we, we invented the internet. We've been, you know, technology has, has been the linchpin of our economy now since the nineties as we move to a service economy, I think if we wanted to continue. So we need to be the kings of AI technology and we can't, uh, sit idly by and watch other countries out, maneuver us out, out, fundraise us out, technology us out, innovate us.

So, I'm, I'm, you know, when you add it all up, the pros and the cons, I'm a huge fan of Project Stargate. I, I think if it's done right and it doesn't become some big fat pork barrel for a couple of tech bros who supported the current administration, this could be a fantastic thing for America, for the West and, and for, and for the tech market, right? We've had a tough year in the tech market.

Last year was a tough year. I had a lot of friends looking for jobs. This really could ignite things.

And you know, I'm just really bullish on it. Another thing I wanted to mention is, because of all that, we're liable to see real innovation in techno, in AI capabilities, which can disrupt so many different fields and bring so many more jobs and opportunities to us. So I'm bullish on ai, I'm bullish on Project Stargate.

I'm bullish on investing. To me, this is sort of an infrastructure investment, which is something even, I mean, the Biden administration was in on with the CHIPS act and everything else. I was bullish on that.

I'm bullish on this. That's it for Shimmy. Says this week, we're gonna be back next Thursday, 2:30 PM Eastern time, and I'll talk about whatever, whatever is happening next week.

But until then, hey everyone, have a great day. Check us out on Textron Gang every day or any of our Textron properties. This is Alan Hummel.

We're out. Hello everyone and welcome to today's webinar. Reducing Fatigue While Keeping Your Suffer Supply Chi Insecure.

A look into Snyk K'S 2024 state of the open source report. Each year Snyk conducts a survey on the state of open source security gathering trends and insight from peers on securing open source software. Join us for a closer look today at some of the statistics and get insights into things like why over 50% of security teams are failing to meet vulnerability management goals and which way supply chain security practices are still immature, and how overtrust and AI generated code can lead to some pretty serious security concerns.

Hi, I am Richard, she staff product manager here at sny, and I'll be your presenter today and taking us through this, uh, insight into SNYs 2024 State of open source report. You know, we're going through a high level overview today of each of the sections of the report. I'm going to touch upon a couple of observations from each of the sections.

We'll then cover some key takeaways from that section and some talking points that can, you can use in your conversations. Uh, some overall background. You know, open source software is everywhere.

It helps organizations really build software faster by leveraging the open source community credit and manage software that it presides. Um, effective prioritization can leave fixed fatigue. One area will cover will be the concept of security or fixed fatigue, including how it will fit in with, uh, SLAs.

The software supply chain security challenge, open source is a key element in software supply chain security, but it's not the only element. Expanding automation and AI today are playing an increasing important role as well. Just, uh, an overview here of the, the 24 state of open source reports.

You can get it through the websites, through the PDF link as well. And we also have blog posts. Uh, we're going to go through a high, um, we surveyed over 450 technologists across application development and security.

We used many of the same questions we had asked in the 2023 state of open source security and compared the past results to this year's were applicable. And we mixed, you know, a number of yes and no questions, as well as thank ranking questions. Uh, we published this in December of 2024.

We'll run through the four uh, sections of that, uh, covering slowly expansion in the open source security efforts and signs of AppSec exhaustion covering supply chain security, uh, remains immature. They're gonna look into there. Uh, also looking at continued misplacement of confidence in the security of AI generated code and evidence that of general open source security progress, uh, is progressing.

But I'll start with a quick overview of the software supply chain and in particular where the coverage of the questions fit in sneak, because we're sny we, uh, put a, an a lot of emphasis on the developer. Um, there were questions around generative ai. You know, do you use it?

What about, uh, ga uh, AI concerns you? What impact are you seeing from it? We're also, uh, explored the open source ecosystem.

How libraries are choose are chosen, how they're chosen, and how often you make sure they're secure. We asked about the SEM checks and things like the C-I-C-D-A pipelines and commit and PR checks in your security practice. We also dug in on, you know, folks and what they're doing with SBOs software bill of materials.

We want to see where in the SDLC teams are building insecurity and what they're doing to make it happen. And let's take a look at those results today. The first sections slowly, uh, slowing expansion into open source security efforts and signs of OPSEC exhaustion.

There are signs of slowing in open source security efforts. And in the DevSecOps efforts more broadly across many questions about supply chain security. We saw either a little change year over year or surprisingly declines in adoption and usage.

Some background and insights into the how the teams work. Uh, we asked, uh, one of the questions how frequently organizations are releasing code today. Uh, and the code deployment frequency remained fairly consistent with the vast majority of our, uh, orgs, shipping at least monthly.

But when you look at this in the frequency of security scans, uh, we see that dropped with less than 50% actually auditing daily. So a shift to the lower test frequency is, uh, is a view that we saw. So let's zoom in that a little bit more in a detailed view of this.

We noticed that shift across the board compared to 2023, where the shift from the continuously or daily scanning to moving out to more of a weekly or monthly audits. With that, this is bad news for zero day vulnerabilities entering into your code base, uh, where they can enter in, uh, in between those frequencies. But for organizations, it's really about finding that balance between frequency of auditing and security testing and possible vulnerabilities entering the organization impact by the software supply chain or open source vulnerabilities coming in, you know, how's your org been impacted in the last year, uh, with these two areas?

And this was really a two-way question. How were you impacted and what did your organization do to try to make things better? If there was a decline in new tooling adoption as well as a, a drop in education, it's clear to see that a large number of organizations are impacted by vulnerabilities.

We saw there, uh, around 50% of organizations either with open source or the software supply chain have been impacted, but we must remain vigilant in the fight. Continued effort to really educate and train development is a key in our fight against security. We did see a mixed delta in security tool usage this year.

You know, we saw SCA went up a bit, uh, around nearly 70%, uh, but SaaS and everything else went down. The question, is this due to the economy or what's going on here? Um, we also saw a decline in license and security scanning.

These are really gaps that can be posed serious risks to an organization. Secrets obviously leaving, you know, it's like leaving your car keys on the seat in your sports car licenses on the other hand, may not be as obvious. Knowing which licenses and license types your applications and the dependencies use allows you to be proactively verify whether or not your applications carry on known license risks.

License compliance is still an important piece of the software. Supply chain dependency analysis was pretty much unchanged from a yes no standpoint, but with a nice shift on where the depend on which dependencies are being tracked. This slight shift in direct versus indirect dependency tracking is encouraging to see as well.

Tracking all your dependencies is key to fully understanding your risk from all angles, so you get a true insight into your security posture. Overall dependency analysis remain stable. We can see here.

Um, continuously, uh, testing and analyzing your package managers in an automated fashion is still very popular. Now when it comes to SLAs and missing vol fix SLAs, it's very, uh, we see that fairly strong SLAs are in place with organizations having a committed higher or greater severity fixes in under one week. However, when we see, uh, we see signs that meeting these SLAs is challenging though, for organizations with over 50% missing at least sometimes or more often, uh, than that in terms of frequency of missing SLAs, prioritization of vulnerabilities is important here to meeting those SLAs.

It's also a sign of vulnerability fixed fatigue creeping in when these SLAs are starting to be missed. Now, some key takeaways for our first section, you know, hints of AppSec fatigue are showing through. And some actions to take away from here is scan frequency can directly impact your ability to quickly react to zero day vulnerabilities.

Yeah, the reporting can help when you're, you know, which package is bad, but you need to know in order to have that, putting the insecurity gates through the SDLC encouraging developers to leverage IDE security checks or testing via s uh, CLI and training is also very important at this stage as well. Avoid or at least reduce security fatigue by prioritizing your best based on your business critical context applications. AppSec, you know, we need to keep up a good work here.

Keep up that good work, but don't get discouraged. Look towards your security champions to help you with this and educating new security champion, uh, program in place, maybe worthwhile looking into one and implement one for your organization. Section two, this section focuses on a bit on lessons learned and the software supply chain trends.

Okay, so admittedly this is a fairly broad set of technologies and there's no way to encapsulate a gauge for software supply chain in one question. This one was meant to be as much thought provoking or, you know, are you doing this since no single vendor out there can really secure your entire software supply chain? If they say they can, they either don't know what that actually means.

Or while they're, you know, lying to you. There are a few themes in this, knowing what's in the things you're running, making sure that you're right from a trusted source. And then making sure that people can change stuff that they're not, uh, cannot change stuff that, uh, they're not supposed to.

Just like there's no single vendor angle. You may not need to do everything here, but if you are doing one of the things you wanna ask you, whether, what should you be doing instead? So the SBO parts are good example of this.

You might not need to if you're monitoring everything through an SEA, but again, make sure that it's not a gap also in your organization. Some of the questions start to get into guidelines and specifications like the SLA, which helps organizations make sure that the processes are following good security practices. Roughly, um, two thirds of respondents are using SEA or sast static analysis security testing.

Unfortunately, we don't know what that overlap is. Also to note that there's also some level of error in these surveys. These numbers are slightly different than the way the question was phrased, but it's the same ballpark.

Just over half of the respondents are scanning IAC, maybe not everyone uses IAC. So that's a valid reason not to use it in your practice. Uh, slightly more are performing dast dynamic application security testing.

Think of this as an automated black box testing that checks your application from the outside, um, for the same types of vulnerabilities that SaaS does. Uh, just side note, you might have heard the slinks recent acquisition or probably is a DAS and API security testing company. So we'll be adding that to our portfolio as well.

So check that out. There's also a low rate of container testing. I'd really hope to see that, um, closer to the CM level as SEA honestly.

And a lot of the c vulnerabilities that you might find in open source projects still live in your, uh, containers. Hearing across the SED, uh, SDLC here, we get a good insight into where the companies are placing the security gates across their ides, across their build systems and to their ci cd pipelines. Uh, it's good to see the companies are applying security practices across the SDLC, attacking it from multiple perspectives.

Note that, um, the bars here do go to the right, it's a skill thing. No single one, uh, of these is more than 50%. If you note this is one of those, select all, um, apply all questions.

So I expect that there's, some of these are stacked. The first two that we look into are the bare minimum, uh, around CVSS, severity scoring, uh, and internal scoring systems. With that, it's better than no prioritization method at all, but this can be where a lot of fatigue comes in.

Spending time fixing vulnerabilities, they might not even matter. EPSS score and somewhat related exploit maturity start weighing in here. And those take into consideration a bit more of the likelihood, which is a nice progression, but we're still looking at static prioritization here.

Now reachability is where we start to get more personalized scoring. It can tell you when there appears to be a call path from your first party code to that particular vulnerability. It's a nice indicator, but it's not, uh, only definitive tell that when there is something in the path, it doesn't tell you for certain that there's not something in a path.

So it's a good metric. But also, you know, not every vulnerability has that function level details to perform reachability calculations either. And the last one around here is around business context and deployment status.

These are really the next gen prioritization tools. Do you really need to prioritize a vulnerability in the component that isn't even deployed? What if it is deployed but not directly exposed to the internet?

Sure, you probably wanna fix it, but maybe not fix it first. So, section two takeaways. Um, good trends.

Preventing monitoring may help offset the slow tool adoption, but relying on those static prioritization techniques can add fatigue and analysis paralysis with that. So my actions to take away here is give developers the tools they need to secure your, your apps before they check in, like in the ID or through CLI, and encourage them to learn how to use them as well as security best practices. Treat external ASBOs with the same scrutiny you would with your open source projects.

And finally, don't rely on just the traditional or static prioritization techniques. Look to those smarter fix, uh, advice and stick can help you with your prioritization, including a, a more robust risk score as well as those dynamic risk factors as well. Section three, continued misplacement confidence in the security of AI generated.

Code three, focused on the impact of automation and developers increasing usage of AI in their coding practices. We saw pretty similar results to the last year, and is this depe, uh, descriptions of the between expectations and reality. And even more folks using AI are more, are unsure if they are or not orgs fail or maybe hope the generator of AI is helping developers write more secure code.

The stats show that that's not simply the case, even if you drop the very few here in this me. Um, question more than half the respondents said that it increased by at least a monitor amount. So this is the first party code, uh, vulnerabilities.

Things like SQL injections, cross-site scripting. Really AI is not, uh, securing as well as you think it is. So it's a concern for risks introduced by j uh, gen AI might be also suggesting codes that requires new open source libraries.

And if the libraries for those libraries aren't compatible with your RX policies, there could be an issue. There could also be hidden issues. What data sets were the backing AI model trained on?

If it's trained on code with restrictive licenses, it could generate, might be violating copyrights as well. You just don't know. And here's, uh, where I always say with a gen ai, it's simply, uh, this certainly is taking the place for trust, but verify, make sure you're testing all the code paths, whether it be open source software or gen ai, code generated code section three takeaways, automation and AI risks, opportunities that disconnect between expeditions and real world experiences.

Some of the actions to take away here, devs are likely going to be using gen ai. Make sure they know your rules. If you don't have these rules defined, maybe come up with some guidelines for your development organization, GNA.

I can introduce some efforts of security risks that handle, uh, the risks that handwritten code can, but likely must, uh, much more faster into your organization and really educate your developers on ai, both the pros and the cons. Sns deep, deep code AI doesn't use off the shelf engines, but rather we use multiple AI models that are security aware. But you also need to think about the s uh, SEA side of it to check the open source as well as the first party code.

And again, educating developers on AI along with general security, uh, practices is really key and important here. Section four, uh, looks at some high level trends and the overall health of open source ecosystem with respect to fixing vulnerabilities across the board. The overall, uh, total time to fix for open source community has dropped for critical or high severity vulnerabilities.

We've seen that across the years, and if we're looking at, you know, open source community is still out. Pieing proprietary code fixes for the total time to fix for high-end critical. Uh, we see this across the years from 2019 to today, 2024, where shorter is better and we see that over time that the fixes is getting implemented faster.

So overall, it does look like the open source communities are stepping up, taking more responsibility and responsiveness to the impact vulnerabilities really have on their projects. So some of the takeaways for, uh, section four, the open source community is really becoming even more responsible, uh, responsive and responsible for fixing critical vulnerabilities. And priority teams seem like, uh, they're slowing down a little bit.

Prioritization smarter is key here. Open source mat, uh, maintainers are fixing vulnerabilities faster, which means that you can remediate even sooner. Checks for vulnerabilities earlier in the SDLC is key, uh, blocking a merge or using pre-commit checks or grid, but remediating these vulnerabilities before they even hit the SAM is even better.

Take advantage of automa, uh, automated fixed prs here and check everywhere and your SDLC, uh, that you can continuously check your existing projects for new zero days and scan containers before you push and before you deploy. So, report, uh, conclusions. Now these findings suggest that the industry must find new ways to balance security requirements with team capacity while maintain vigilance against emerging trends, including those potentially introduced by the over reliance on AI tools without addressing these challenges and adjusting attitudes towards AI generated code security and organizations risk falling further behind in the security posture as threats continue to evolve.

So first step, um, is really assess your approach to the security to prevent burnout and ensure sustainable practices in your organization. Second step is to improve prioritization in your vulnerability management and other software supply chain risk management tasks. With that, thirdly, prioritize the adoption of fundamental supply chain security measures and deploy newer supply chain security measures to improve your security posture overall.

Fourthly, include more holistic risk analysis as part of the SLA determination to ensure security teams can focus more time on the risks that really matter. And fifth, lastly, take a more cautious and measured approach to AI generated code implementing rigorous security reviews rather than ensuring the inherent security of gen AI is important. And again, education of your development organization is key ongoing practice for your security practice and your security posture.

Now that brings us to the end. Uh, don't forget to download your full report. You can get it at the available link from that and we'd be help, uh, happy to enter and a or ask answer any additional questions that you may have on the 2024 state of open source report from sny.

Okay, thank you. And, uh, have a good day. Hey everyone, I'm Alan Shimmel of Text Drug tv and welcome to another episode of the Last Great Cloud Transformation.

You know, uh, we've been doing this show for months now and we hope you've caught some of the previous episodes, but if you're not clear on what it is we do here, you know, we're, we're seeing, we call it the last great cloud transformation, but what we're really referring to is that this next wave of cloud migration, if we could call it that, is a little different than what we've seen before for the last almost 20 years, 18 years, something like that. For many people, cloud migration meant moving from a private data center, whether it was a private cloud or, or just a, you know, posted in a private data center up to one of the public clouds, the hyperscale, cloud hyperscale, you know, provider clouds. And, and a lot of times it was just a shift in lift from, from private to public.

Other times there was some transformation maybe moving to a cloud native microservice architecture or something like that. Um, but what we've seen over the last three years, five years, may, let's say, since covid types, right, is a migration not only from the private data center to the hyperscaler public cloud, but from there to the edge, from the edge to the endpoint in some cases from the public hyperscaler cloud back to the private data data center or private cloud running things like Kubernetes on bare metal and so forth, right? And so really our cloud infrastructure is everywhere.

And so in many ways, this latest wave is the last great cloud transformation. Our partner for this show is our friend, our friends at CloudFlare Cloud CloudFlare, which look, I think 22% or something like that of the internet travels over its network, right? CloudFlare has come up with a solution, a, a aid in this last great cloud transformation.

And they call it the connectivity cloud because what they have found is look, when you have a little bit of something everywhere, right? You get some assets in the public cloud, I'm in the private cloud, some on the edge, some exist on endpoints. Everywhere you need something that connects all of them.

And, and in connecting all of them, you're dealing with several key issues. Latency, security, huge, right? And some sort of intelligence, I'm not going to use the AI word per se, but some sort of intelligence that knows where to go when and what to put, what where, right?

Does this is, is the edge the the right place for this? Is the core the right place for it? Is the private?

Is this, should this be on a, an endpoint? So that's what we're talking about when we talk about the last great cloud transformation. I hope that makes sense to you.

Let me, um, introduce you to our panel today as we're gonna discuss just a, a small slice of this. We're gonna focus in on securing the API economy within the context of this last great cloud transformation. Joining me today, first of all, from CloudFlare.

I went through all that time. I hope I get his name right. S Krishna Chari.

Am I close? Very close. I'm s Krishna Chaley.

Thank you Alan for the introduction. Uh, product marketing at CloudFlare, been in the security space for a decade now. I actually, uh, started off in application security and now back to the API and application economy.

So excited to talk to all of you. Absolutely. And Cy Christian, it's great to have you on here.

Joining Cy Krishna and myself, though is my co-host of the last great cloud transformation. Uh, him and I co-host a whole bunch of things and we like to do things together for a long time now, he's a, uh, fu VP for DevOps analyst, Mitch Ashley. Hey Mitchell, how are you man?

Good to be there. And I'm glad I'm buttoned down in my cold little bunker here in Colorado. We're getting some snow this week in cold weather, so you all Might see a little bit later on The East Coast, so hang in There.

Absolutely. Alright, let's, um, let's turn to the issue at hand, gentlemen, right. Securing the API economy, before we talk about securing the API economy, I think that we probably need to define what we mean by the API economy, right?

Yep. And you know, it's a term that's, I've, I've seen the term used probably for 10 years already, right? Eight years.

And, and really what it is, is so much turns so much of our economy, so much of our e-commerce, so much of our online digital presence turns on API to API communication, right? In fact, I I'm actually doing an interview with Grant, is it Baz? Bazookas Berser, yeah.

From CloudFlare, uh, on this, and I've done in the past with him on this, a majority of all the traffic on the internet today is actually API to API traffic. It's a majority of all the traffic on the internet. So when we talk about the API economy, we're talking about a majority of every bit that gets pushed over the internet.

So, I mean, that's, that's the scale of this thing, but peeling that off, what do we, you know, what is this API to API traffic? So, Krishna Mitchell, do you want to expand on that? Sure, sure.

So actually I, I wanna do a quick overview of, uh, APIs itself, because I think the API economy is a, um, maturation of how we have been using APIs. Uh, and one of the things that APIs compared to web apps or mobile apps, you're touching them every day. You're using them as a consumer, even as a, a business user, et cetera.

But APIs, you don't think about that happen behind the scenes, and they're meant to be behind the scenes. The, the value of APIs is that they can enable one system to talk to another system, exchange data, and do that in an automated fashion. And so all the automation that we talk about in the world out there is happening via APIs that are between applications, whether they are APIs in the, you know, software defined JSON format, or whether they're in older school formats, or whether they're specific to an industry.

It actually, when you think about APIs, they've always existed inside of applications not to the, to the public world, um, when they were service buses. But since then, and especially when we think about the first big push with mobile phones and mobile apps, especially the, when Steve Jobs talked about the app store, um, and then Google, Android store, et cetera, the Play Store, what it meant was all of those apps were being run behind the scenes via APIs. So mo the mobile economy provided a huge boost to APIs.

Second, we saw that, um, the social and e-commerce space became a huge area whereby when you are just a very active uploading fo photos from your phone to the cloud, um, to back it up or put it on Instagram, et cetera, was all via APIs. And so that provided another second boost, uh, with the consumers coming in to play. And then what we are seeing in today's world, you know, uh, organizations trying to reimagine how their applications are built, uh, as you talked about Alan, with the re-architecting of applications, that was that microservices element behind the scenes to make sure they break down their applications, to talk to each other and talk each service talking to each other using APIs.

And the, the fourth one that we are living in today that everybody is familiar with, generative ai, I know you didn't want to use that word, but I brought it in. Um, It is being run while a lot of us are using it via web apps, behind the scenes. It is all being run via APIs.

And that is how this API economy is continuing to explode, um, whereby organizations are now making money just like open ais and the other AI models, um, making money based on how much their API is being used and being integrated into other systems. So when you talk about the API economy, it has many tentacles and it is continuing to grow, uh, in importance. You know, side Krishna, uh, excellent, uh, description, I think of how the match registration of AI have taken place.

So I'll just, I'll just add to what you said and, uh, kind of build from it. One is, as APIs have gone from sort of the exception to being the rule, the exception was those are the few things we exposed to other applications outside the organization, outside the firewall. Um, maybe you mentioned message bus, but boy, I had a, I had a flashback there for a moment, going back to so architectures and things.

Um, but, um, but it's evolved even even beyond that to the point where we now think of, uh, AI a IS products. Many services on the net only are offered via API, that that's how you use it. You consume it, you might stick a front end to it, a web interface or some mobile phone, but, uh, the service may be only APIs.

So you think about that as your storefront for your service is other pieces of code talking to your services through APIs. Another, another aspect that's changed, which is kind of how it's manifest, which you talk about in that, that fourth wave is, is what's called API first, where essentially applications are built around the fact that everything is an API, and it will all talk to each, each component, whether it's the user interface or some backend service, front end microservice, whatever it is, everything will talk via APIs. And what's interesting about that from a networking perspective is, you know, sometimes software and software architecture is a bit of a head scratcher for a network security person or maybe even a network person.

It's really a network inside the application that's talking to itself over T-C-P-I-P, whatever we're using, whatever graph, GraphQL or restful interfaces, fancy words for different kinds of APIs. Um, so it's, it's, we've really gone from it being the exception to being how everything works. And that's the, that's why you see all this traffic, whether it's over the internet and the cloud providers or inside your own networks.

That's why it's all happening over APIs. Agreed. I, um, Mitch, because when we talk about that last great, uh, cloud transformation, it's again, back to the fact that the, at the app layer, you're exposing all of these APIs, but coordinating them mm-hmm.

Maintaining them, making sure the performance is optimal, is all part of the cloud transformation that is so critical, even before you get to security. And obviously security is a critical portion. Good point.

Very good point. Yeah. I want to turn to security and specifically around securing all this, but before we do, you know, so Krishna, you opened up the, the, the, the Pandora's box with the AI stuff we warned yet, right?

It's gonna happen at some point in every cover. Yeah, yeah. So look, this, this, this is a whole different ballgame, quite frankly right now, especially with the onset of, of agentic ai, right?

Who do you think these, all of these AI agents are gonna be talking to people? No, they're gonna talk to APIs. So if we think that a majority of the internet traffic now is API to API, how much of it is gonna be agentic AI to API?

Some may say that really what is, you know, a good chunk of the very essence of what an AI agent is, is some sort of AI bridge, API bridge, right? It, it it's an API that lets you plug into everything or that plugs into other things. So I think, you know, we're just at the beginning of the API economy and, and how much of it, or how much of the total digital world is gonna be riding on that, right?

But let's, as I said, let's turn to security. Well, before we do, just wanna mention this. Go ahead.

This is so pervasive that my granddaughter told me she wants to dress up as an API for her Halloween costume this year. That's how pervasive this is really. I'm kidding, of course.

Oh, okay. Getting you're cheese wired, dude. I'm just security.

Not just security though. So look, if something's this important, you know, it's the law of why we can't have nice things, it becomes a target. There's a bull bullseye on its back, so to speak, right?

Of, of how can that be disruptive? How can you know, how can it be disrupted? Excuse me.

How can people exploit it, hack it, make something out of it? And therein lies the problem. Therein lies the issue, right?

How do we, how do we secure this gigantic monster of API to API or API to agent communication? So, Christian, I know CloudFlare, I mean, you guys have put a lot of resources into this very issue. Let, let's talk about some of the things, you know, some of the ways and things that you guys have come up with.

Yeah. So we've done a bit of research into what are we seeing in terms of threats. So we'll, we break this down into what are the threats we are seeing live, and then what are the problems around API security to do API security well in an organization.

Um, so in terms of threats, let's just kind of break it down. The, the actually most common threat that you see on, in, uh, kind of realtime traffic is business logic or DD distributed Nile of service attacks that are just hitting their APIs to try and either exhaust resources or to try and get into a service and then figure out what is a, what is behind that service at the end of the day, you know, an API is mostly a communication mechanism, and therefore they're trying to figure out what is that API talking to in the backend. Um, and that's something that we are seeing a lot of constant traffic, uh, around that.

Beyond that, when we think about actual data breaches, what's unfortunately very clear is that we hadn't fully thought through what needs to be behind a authentication mechanism. And then, you know, we're still, we're still trying to figure out what is the authorization mechanisms and methods that we go through. But even authentication, putting basic authentication is not something that was, uh, has been very common.

And therefore we have seen a lot of public major data, uh, breaches that have an API that's just openly accessible. So that's the second part. Now on that, when you're talking about leakage, you're essentially leaking data and the most important, uh, types of data that what we are seeing is attackers using that to do reconnaissance, to then use that in other attacks that are a bit more targeted in nature, um, because they found all these public APIs just spewing a lot and lot of data, um, that can be used in other places.

So it may not be necessarily sensitive on its own, but it's a piece in the larger, uh, targeted attacks that we are seeing. And then lastly, what we also see is just like with, uh, applications, APIs at the end of the day are also code. And so they can be vulnerabilities in that zero day attacks that we zero day exploits that we are seeing, just like with applications that can happen with APIs as well.

Just because an API does not have a front end does not mean that it will not have the, the code level vulnerabilities, um, given they may be written in similar languages to, um, the, the, uh, web application, uh, code that is, or the, uh, the, um, code behind the web applications, uh, that we all use. And so being able to protect against that helps you protect against, as we think about, as Mitch has talked about the economy and Alan talking about how the economy will continue to grow, so well fraud, and we're gonna see fraudsters trying to go after the APIs to get access to money, to get access to, um, credentials, et cetera. And so that's the next area that we're, we're really seeing growth in, unfortunately.

Yeah. Mitch, thoughts? You know, I was just thinking about, um, not to bring AI back into the conversation, there's a lot of discussion about how did deep seek train its models, and it's done through something called reinforcement learning.

And of course, um, the other aspect of it was as trained on open AI's models or other people's models kind of ing models, control models, that that's a great example of where automation comes in, where something you couldn't do on a large scale through any other way other than through automated API calls, uh, into applications or models or whatever it might be. So it's, it'd probably be shocking to, to just the average user or maybe us that has a little more technical background of how much of what's happening inside an app or looks like it's inside an app. It's actually touring through API calls and how our apps wouldn't function at all without it.

I mean, some of 'em wouldn't even start up right. Couldn't present a user interface to you. So I'm, I'm curious, uh, aside, Christian, as, as you think about from a cloud perspective, when so much of the traffic is APIs rather than, you know, h TT B calls over web browsers and, and email types of things, protocols, you know, the old, the old internet protocols, right?

That, that built the internet. Uh, how, how does that make you think about the cloud differently? Especially because customers like myself, we are a customer of CloudFlare, by the way.

Um, wanna put parts of our apps in the cloud, not only at at the Edge, but also in multiple places across your cloud instead of us trying to figure out how to deploy it to some point past the cloud. Yeah, I think this gets to some of the, uh, big problems with trying to secure your APIs. So there is two parts to this broadly.

One is, at the end of the day, APIs are written as code, just like web applications are. And there is a portion of it, which is that typical vulnerabilities that, um, the pause or open web application security, uh, project has, uh, kind of outlined as the top 10, uh, kind of risks are very similar between web applications and um, APIs. So being able to protect against those so that they don't even reach your API servers, um, wherever they may be, is going to be super critical.

The second is making sure that when you are, when you are looking at, uh, APIs unique part about APIs is they should have some sort of augmentation and authorization on them. And exceptions should be those that are unauthenticated, that should be the exception. Whereas with web applications, a vast majority of the traffic maybe are not authenticated because they're just looking at, um, and reading data.

But with, with, um, with APIs, that should be an exception. And so being able to put that in place and then being able to enforce it function that developers don't have to come up with it, come up with the authentication mechanism every single time they're creating a new API, which, which is just so very common in organization, which, which just as an aside, forces developers to become security experts. And while we want developers to know something about security, security expertise is not gonna be the first thing on that plate.

Um, and therefore being able to standardize that and push that to, to the edge is gonna be so very critical. Um, on, on the authentication side, and the last part is, as a security team, you're constantly thinking about governance. What is happening in, in my estate of APIs, applications, other assets that might be there?

What are, how are they being configured? Because once you have, you know, coded an application or an API and then you have, um, put it into a release cycle and it's out there, there're gonna be multiple ways that it's being deployed, run, configured for different, uh, use cases. And so all of those can have misconfigurations.

And we see that all the time today. In fact, one of the things that we see is the, uh, problem of PI is leaking sensitive data because once they, when they were first, um, released, they were very pristine, well done over time. You keep adding a bit of fun functionality.

And over time that leads to things where just for that one use case, you will, you are, uh, uh, you know, able to kind of expose a bit of data. But now in another context, it is leaking sensitive data. So, um, that is something that you need to be able to constantly be able to monitor and where appropriate without having to burden the development teams be able to put in place, uh, protections in real time at the edge so that, again, there's much less burden on developers and those that malicious traffic is not reaching your, um, your, your, um, API servers themselves.

And the way that connectivity cloud really helps in this context is to make sure that all of those protections, you don't have to put them in place at each of your data centers on each of your APIs separately. You can push, you know, rules into a, uh, common engine and then make sure that they're propagated at all locations that you are, that you are serving, uh, from which you're serving your applications on in what we call an edge or a connectivity cloud edge. Excellent.

Excellent. You know, Mitch, I, I was listening to what you said and then what, say Krishna came with, I, I think one of the things I said earlier really is, I mean it complicates thing, but it's so true of what, what, what applications look like today, right? Our applications are dispersed, they're microservice based applications.

And you know, when people think of APIs, they may think of, I'm a user of an application and I, and that's the A PII interface with that internal to external or external to internal, if you will. But in the microservice cloud native kind of world that we live in now, right? Something like 70% of greenfield applications are built in a cloud native, uh, architecture, much more than that.

External to internal. API is the internal to internal API, it's one container talking to another container. It's one function of an application going out to SaaS based API coming back in talking to another piece of the internal, right?

Internally an API to API thing. As you know, our applications are sort of little Frankenstein's, if you will, right? We're all stitched, they're all stitched together.

And what's, and what is the thread? What is those stitches? It's, it's APIs.

And so I, I'm going to guess that there's probably four x five x internal API calls for every internal or external API call, and they have their own security requirements. And that's, those security requirements have to be orchestrated, governed. What have you managed, you know, whether it's at that COBE level, the orchestrator level, or the mesh level, right?

Of how these things are, are talking to each other. But that's a, you know, and, and they're all, you know, let me add one more little complicator in there. They're all over the place.

They're in the edge, they're in the core, they're in the data center, they're on the endpoint. Mm-hmm. It's enough to make you go crazy, right?

Because that, now that's a job, right? If you could secure all that, that's a job. I don't Know if it's a good analogy, but it's kinda like an air traffic control system of multiple Land.

Yeah. Really, it's Whether, whether you're international travel, continental, you know, local, et cetera. It's 3D 360 degrees, right?

You Mentioned cobe, Kubernetes, you know, and then the cluster has an API gateway and that does security for APIs. What can talk to what within that and other, other Kubernetes clusters. And of course things go outside of that.

And then service providers have API gateways and firewalls and things that control, uh, both security and authentication, uh, as well as traffic of those APIs. So it, it is, it's, it's kind of a cellular system almost, if you want to think of it that way, of multiple layers of, uh, how APIs work. And, and the good thing is the APIs give you a lot of autonomy in code and in design.

'cause I can create a, a microservice that just specialize in pulling data from Salesforce because I need these customer records for my application to process an order or to go get, uh, background information from, you know, say a science database that's got, uh, medical information in what I'm gonna occlude in some deliverable to a end user, some product I'm producing, but that can be specialized. So lets us build autonomous pieces of code, not, maybe it's a agent AI agents at some point not too far down the road that can go do, do its thing and not worry about the rest of the world of all the software and the APIs happening. It also lets developers go, eh, nail, okay, I, I know, I know where those API calls happen, or I know how to trace it down using observability tools and things like that around tracing.

Um, but it, it, it's a different world. It's a very different world than the days of I will talk over a SOA bus, um, or a monolith application. Um, but it's like everything, it's just a different mindset has advantages, brings with it other challenges and, but the advantages outweigh the negatives.

And I think, Mitch, you mentioned, um, something around, uh, agenda AI agents, but that touches back to Alan's point, which is, you know, Alan, you were talking about there'll be one, um, a one API call between the, or many fewer API calls between external and internal boundaries. Um, then there'll be a lot on the internal side. Totally agree on the internal side, but the unique part now is there's an even more blurring with agent AI agents of what is internal and external.

When you, you're calling AI models to do things as a step in your application. And so you are, uh, a service may actually be calling, not the application, the application that everybody's touching, but a service that is trying to do some data analysis, trying to pull the latest information so that it can be passed to a user may actually just call on its own an AI model of, of some sort that has to do some data analysis and then be brought back to the application. And now what is happening is when in the old world you had an understanding of, okay, here are things that are exposed to the internet, everything that the developers are doing behind the scenes, I, I don't really have to really care about that.

Now you need to be thinking about all of those services as well because those could be exposed. And when you are talking to another, um, AI models that are open source, you know, by third party commercial one, or whether it is sitting in some other location that you, you own, you are building your own, um, it just makes the, that world of API traffic even more complicated. And one of the things that we are finding is, um, in the past, even just pre pre covid, think the pre covid days when APIs were still, uh, quite common, um, not as common as today.

One of the thing, one of the things that customers struggled with was identifying what are all the APIs that my organizations have exposed? Because the security team is not everywhere and talking to every development team, now this problem has multiplied. Now it is not just what are the APIs but developers, what are the AI models you're u using?

'cause almost always those are being discussed or, or that's being communicated with through APIs. And we need to think about what is the data not just coming out of the API, but what is the data I'm putting into the, uh, into the API that is going into an AI model, whether it could be PO for poisoning purposes or leaking your organization's sensitive information. So I think those two things, especially with the world of agent AI, have become a lot more critical, uh, for organizations to deal with.

That is the cutting edge of what we think of API security today. You know, there's another dimension to this too, and that is, um, what, what goes hand in hand with API first software architecture is also stateless, which means, you know, we used to make calls, meaning I open a connection to this, whatever it is on the other side, I do things across, you know, whatever that connection, the socket or whatever it was back then. Um, and then close the connection.

It's kind of the difference between TP and UDP, right? You know, am I doing a connection and open I close or am I just sending it and it will happen? That's a lot of how software in order to scale and, and have that independence of microservices or whatever that function is that is providing or requesting the service, that's a lot of what scales this up.

So that also increases not only the security, but also the manageability of those applications because I can't take like freeze point time of the state of the machine and I can go see where everything is at. No. You know, that that same process that requested that might have been updated two minutes ago or might have scaled from one to 53 instances of that microservice across the network that's distributed.

So that's why we're able to get such high performance out of systems because we can distribute 'em through that stateless architecture as well as APIs and networks. I, I think that, I just wanna mention one thing on that, on the stateless point, because it's so very critical in, and it, it applies to cybersecurity in the sense that the CIA triad one part, one leg of that stool is availability and the importance of a stateless architecture, um, that can be ideally based, uh, edge, uh, you know, post to the edge, um, especially some things that are, can be provided by our connectivity cloud enable cold starts to be diminished because you can't be waiting when you're thinking about being very dynamic providing data. And this is amount of data we're talking about, especially with AI models and AI agents, that difference between a bit of latency is very significant to the user, uh, at the end of the day.

And so minimizing cold starts, and that is something that, you know, only in a, a provider and a that has been thinking about stateless architecture at the edge can, can really provide. Um, and that's something that we have definitely been, uh, seeing with a lot of customers, um, that they need, that those cold starts to be reduced so that whenever they call a function and it is on up, the instances on up, they're ready to take, uh, workloads. You had to mention cold starts.

It was 11 degrees when I woke up here this morning. So thanks for that reminder there, like Christian. Alright.

All right guys, we're about outta time. Sa Krishna for people want to get more information about connectivity cloud, securing their APIs and so forth on CloudFlare, where, where's the best place for them to go? com has very in-depth technical analysis on the latest cybersecurity threats and API performance and security conversations.

Thank you. Thanks Krishna. Thank you for coming on here today.

What a great conversation, man. Mitchell. Good work.

I, I enjoyed, I learned a little too, which is always a good thing. It's gonna wrap up though this episode of the last great Cloud transformation. Stay tuned.

I think our next one might be a live round table again. So if you watching this, you enjoyed it, you want to be involved in the next one, it's live. You could come in and chat your questions and comments and we will incorporate those into the show.

But until then, on behalf of CloudFlare Dextro Mitchell, Ashley s Krishna, help me Val, Val Shival. I always think give it a little French there at the end. Shival and myself, I hope you've enjoyed this episode.

Take care. We're out.