Techstrong TV July 1, 2025

Hey, everyone. The HPE Juniper Networks merger is on. You're watching Textron Gang.

Hi everyone, it's Alan Shimel for Textron Gang. Welcome to our Tuesday show. We've got some great stories to cover today.

I mentioned the HPE Juniper merger. We're gonna be talking a little bit about OpenTelemetry and the infinite workday. We've got a All Star panel, an epic panel to go over to talk about this today.

Let me introduce you to them, um, as is our custom, our written, you know, panel members who've been here before. We're not gonna spend a lot of time introducing them, but real quickly, we've got Stephen Foskett, JP Morgenthal, Mitchell, Ashley, Bonnie Schneider. Let's call out the new guy.

It's his first time on Techron Gang. He is Futurum, COO friend of ours, Dan o Dan O'Brien. Dan, welcome to the Gang.

It's great to have you on here, man. Yeah, great to be here. Thanks, Alan.

Appreciate you having me on. My pleasure. Hey, Dan, be being, it's your first time.

Just real quick, if you could give people a little bit of your background so they know where, where you're coming from. Yeah, absolutely. Yeah.

I've spent my whole career in tech, uh, spent about a decade in semiconductors, um, semiconductor industry, uh, about five years on Wall Street. Most recently. Spent about seven years running the Annals Relations Organization at IBM and joined in January as, uh, future and group President and COO.

Excellent. Hey, man, it's great to have you on Dan L. All right, let's jump into things.

So, Ian know this wasn't a surprise to me. I knew they were going to somehow settle it. I just didn't know how, but Mike, HPE and Juniper are a go.

What's the deal? Yeah. And as these things go, this one's a little more peculiar than most.

Apparently there's some licensing of source code from the AI stuff that HPE built, and then they're gonna get rid of a business unit that seems to be just basically hanging off the edge of HP as it is. But Steven, you track all this a little more closely than I do. What's your take?

Well, it's an interesting, uh, situation, as you said, because of all of those reasons. I mean, the big news, and I think the thing that we should really focus on is that this is a big victory for HPE and in proposes a significant, uh, challenge to Cisco. Finally, uh, Cisco is the undisputed 800 pound gorilla of the networking space.

They have fought hard, uh, whenever there has been a new networking, uh, opportunity, market opportunity that has appeared, uh, lately, they've been really battling in the AI networking space, both in terms of networking for AI and using AI to manage networks. Now, one of the big competitors for, uh, the, the latter there especially is, uh, Juniper with their incredible missed AI operations AIOps, uh, software. And that is one of the angles that has been, uh, taken on by the DOJ here.

So, so first off, um, what does this mean to, to HPE? Well, it means that HPE is gonna be a credible competitor to Cisco at the high end of the market, which is good for the market, it's good for customers. It's certainly good for HPE, and frankly, it'll probably be good for Cisco long term as well, because, you know, everybody benefits from strong and healthy competition.

But what is the cost? Well, apart from, uh, what is it, $14 billion? The cost is that, uh, HPE will have to offload a couple of elements in order to make the DOJ happy.

One of those elements, as you mentioned, is the instant on Aruba networking, uh, platform, which, you know, that's sort of an interesting thing That is a small, uh, product for small businesses. It's an interesting one. It's a good one.

It's one I've actually personally used, and frankly, I think that it will be a, um, a useful acquisition for some competitor in that space. Um, though pretty much everybody in that space already has something going on there. Uh, but I think that, I think that it'll be scooped up pretty quickly.

The big thing that's got my head scratching is the AIOps offload. So a as you said, the agreement says that HPE has to offload, um, or not really, uh, partially offload enable other companies to use mist AIOps source code. Essentially, they're gonna have an auction where the DOJ will allow up to three competitors, uh, that they are allowed to veto, to bid on access to the Mist AIOps source code, and access to some key engineers who developed it.

Now, they won't actually take it over. They're gonna allow two buyers that will be actually able to take that source code and solicit and, and hire those engineers, but they won't get the missed name. And HPE will also be able to continue with this as well.

So essentially what we're seeing here, if this goes the way that, that it might go, I is that Juniper missed, AIOps might become the defacto AIOps software in networking, uh, if let's say a company like Cisco or Arista was to be the winning bidders on those licenses. But I guess the question is why would they want it if it's not exclusive? I, I guess, uh, the only thing that they're really getting here, apart from the source code, is the access to those key engineers.

But there again, they actually have to hire them. They actually have to attract them and bring them in. So it's a bit of a head scratcher.

Yeah, it, it, it's definitely unusual. So Steven, I have a slightly different take. I don't think this was as much about making HP compat competitive with Cisco as it, from the DOJs point of view, as it is setting up a market where it's HPE and Cisco and just HPE and Cisco.

There's the who you mentioned, Arista. I mean, I think between these two companies, they probably glom up 70 to 80% of the market. That's a two company market in my mind.

No, because the leader in AI networking is a company you may have heard of called nvidia, and frankly, all of these companies leverage Broadcom's switching silicon. So I think there is a competitive market, and, and Arista is a lot more powerful than you might guess In terms of market share. Where are they?

Um, distant. I guess it depends on the market, but, uh, yeah, they're, they're a solid competitor, uh, but they're not near Cisco. Okay.

Then the other thing is, though, I'm sorry, go ahead. Wouldn't Cisco and Arista be an automatic veto or, you know, are, are they allowed to get that source code? 'cause at the very least, they, they got it.

They would just slow HPE down like crazy. Well, it from the sound of it, well, this is another weird thing. It sounds like it has to be two, it can't be one buyer and it can't be three buyers.

It has to be exactly two buyers, which makes me think they know which two those are. And I suggest that it's gonna be Cisco and Ata. To me, it's such an unnatural act though.

Why not just open source it and give it to a foundation In a way they almost are open. So like they, they're, they're going to, you know, kind of pseudo open source it by getting these other folks in, and it's gonna be like a fork, right? Where you're gonna have, you know, everybody's starting from the same place and then the, the buyers will all take it, and they're kind of, Well, not everybody, just the three companies, if they open source it, that opens it to a whole new, anyone can go in and try to do something.

Couple first projects were, you know, there are two or three main contributors and not a lot else going on. Maybe they don't want Chinese companies to take it either. So as part of That and that, that, you know, what, that very well may be the case, Mike, right?

That that is, and I, I think that's what the veto is all about, is to make sure that Huawei is not the company that takes it Or bite dance. Just kidding. Just kidding.

Um, so when does this deal close? And it's unclear. I don't think they actually have a hard date on it yet.

Steven, did you see a hard date? I'm scratching my head. I don't know.

I think it's gonna close pretty quickly though. My contacts with the folks at HPE, well, first they are excited. They are happy, they are ready to go.

And so I think the answer is as soon as humanly possible, because HPE wants to run with this. Well, I'm sure they will hopeful announce it last week at Discover. Let me ask this question though.

So I've been looking at this, you know, we're gonna kick Cisco's butt for the last two decades plus, and Juniper couldn't do it, and HPE couldn't do it. And what makes you think that Juniper plus HPE is gonna make a fundamental difference, Steven? Well, I think that it will make a solid difference simply because of, um, the fact that Juniper already has a really good products and really good customers, and the HPE will automatically get product and customer access like they've dreamed of for years.

I think that, that this, there's so much synergy here. There's actually surprisingly little overlap considering how strong HPE is in sort of the broader picture of networking. When you look at the networking verticals where Juniper plays and the networking verticals where HPE plays, there really isn't as much overlap as you might think.

And I think that is gonna be hugely additive. I think HPE made a really good deal here. You know, speaking of a good deal, I remember a time, Dan, you were on Wall Street, right?

$14 billion. That's a big deal, man. 14 billion in today's world, eh?

It's 14 billion. It's not like, it's not like, uh, Maan is building a new city in Arizona or something. Yeah, Yeah.

Uh, it's not a big number anymore. I mean, you've seen, uh, you know, VMware, you know, Google, you know, and their acquisition for Wiz, I mean, uh, the IBM Red Hat deal. I mean, there's been a lot of deals that have gone north of that.

Nothing north of a hundred yet. Um, maybe that's the ceiling, uh, the kind of new ceiling at this point, but, uh, maybe, yeah, more of a mid-size acquisition for tech these days. But doesn't it, I look, I'm a child of my age, right?

com, you know, bubble came on the scene, Juniper was the greatest thing since sliced bread. Seeing it go for 14, a mere $14 billion seems like a bargain to me. I Think, doesn't it really also, you know, go to the state of, uh, movement to the cloud as a whole in general, away from data center, I mean, infrastructure build out, uh, you know, where companies were spending a lot of that money on building, what, what did we lose after COVID?

We lost people going to offices and we lost build out of data centers, right? With the cloud. So you see a diminishing number of, you know, enterprise buyers for this technology at this point in time.

And you have companies who are now owning that technology for themselves that own the entire supply chain that do build out data centers. So, I I, you know, it's not, it's not like Juju did anything wrong. I think the market changed on them and they just, their buyer is dissipating.

It's true. That's true. com bubble, I mean, the amount of money pledged to these, whatever you want to call AI data centers, is, is staggering.

Is there a place, is there a place for Cisco, HP and Juniper? DHP Juniper, I assume say h hp. Cisco's already In there.

Cisco's already in there as a partner for a lot of these, but a and like I said, you know, the Amazon and the Google, they have their, they, they're their own supplier, right? They own their supply Chain. Yes.

They own for a lot of, they on Broadcom silicon, as Steven mentioned, certainly. And hey, networking and the enterprise isn't going away, and that's, that's HB strength. But also you get the wireless, you get the core networking outta Juniper.

It's a great match. I think it bolsters up. I mean, HP is acquired who Threecom and, you know, Meraki untold number of, uh, companies And don't think that, um, you know, Juniper was asleep at the wheel here.

They're not some lumbering giant who missed the phase. They are really competitive in the AI data center. And, and as I said at the top, Juniper's missed, AI Ops is probably the best AI ops platform in the industry, and they have some of the greatest engineers.

Juniper has really been running forward to try to move into new markets. And that's all HPE now. Um, I think this is just incredible.

I think that's the bigger picture, Steven, you know, take a step back. This, this is a good deal. It's made sense for a long time.

You know, it's great to see some of the roadblocks cleared, but, uh, you know, the competition for these companies are the biggest companies in tech and, you know, getting to a size and scale and a portfolio breadth, uh, that could be competitive with Hyperscalers and Nvidia. Uh, I mean, you know, certainly I think as we've seen the AI data data center build out, networking has in many ways become kind of a critical bottleneck. And, you know, bringing the compute side together with storage on the HP side now with a more enhanced networking portfolio, uh, I mean, you certainly, if you look at what HPE was talking about last week at Discover, you know, it was all about networking, AI data center.

Uh, let's not forget AP HP's acquisition of Cray in the high performance computing space. I mean, all of these things really do build a more compelling portfolio out. I think the big question for them is, you know, how much of the AI processing and networking is gonna happen, you know, in the cloud versus not in the cloud.

You know, that, that's really kind of the big question for this combined entity going forward. Yeah, I agree. Let me bring up another thing that it's something a hark back to something I said right off to, to Steven, happy for HP and Juniper and I, and Steven, you're right, a good, a good competitor is gonna bring out the best in Cisco.

Part of the DOJs antitrust mission is to make sure we have markets that are open and allow for new competitors with ai, especially with these kinds of deals and the kinds of money being invested, the capital requirements here. Is this, is this just a big boys game? Is this in, you know, the gen, the new version of the gentleman's clubs where it's gonna be impossible for up in commerce to break in?

Are we, are we setting ourselves up for that? I think you look at all the big markets where CapEx is really the name of the game, Foundry hyperscale data centers, they've all really gravitated to, you know, one dominant player with a couple other strong competitors, right? Um, you know, at the level of spend, um, that, you know, these, these things require, I think it is gonna be, you know, you know, some sort of oligopoly type market setup And that, that's actually the word.

Dan on oligarchy kind of, you know, Steve, I think you're on mute, Steven. Sorry about that. I, I'll just point out right now, in terms of the AI networking market, it is Nvidia that is the dominant player, even in ethernet.

Nvidia rules, the AI interconnect. So they've got ethernet and InfiniBand, um, everybody is gunning for them. Cisco is, uh, HPE is Dell is, that's another company we haven't mentioned.

Dell is really trying to sell into that AI data center market. I think there's an opportunity to have some real competition there, and there's huge amounts of money being invested there, not just on GPUs, but on networking hardware. I think the proof in pudding, proof in the pudding is gonna be whether or not prices actually move.

Because so much of what we see among these cloud infrastructure providers is the prices don't move all that much. And it's a fine line between what Dan's calling and oligarchy and what other people might Oligopoly, oligopoly Oli. Okay.

So he's combining a, I think there's another part of this networking. The, the real boom in networking in data centers is EastWest traffic, GPU to GPU, and, uh, there's a lot of, well, That's where Nvidia shines. Yeah, that's where Nvidia, there's a lot of interesting startups there in, um, Juniper, I believe it's their ex series.

They've got some, some devices that are specialized in East West. I'm not sure if they're that heavy into GPU traffic or not, but that could be an opening for them as well in the data center business. Listen, the Advent Center, Nvidia has become so dominant that, you know, the big problem I think we have in the market is that we really need one good, good alternative.

And I think right now we've got a large number of kind of, so-so alternatives and, you know, this deal and, you know, similar deals to it, it, I think are really good for the market because ultimately we need a good NVIDIA competitor. And there's probably not gonna be a market where we end up with 10 good NVIDIA competitors. A market where we end up with one or two is probably the best that we could hope for.

And if you're interested in the technical aspects of this, I'll just put in a quick buzz. Um, we've actually had all these companies present IT networking and AI infrastructure field day. We've had, you know, uh, Nvidia, HPE, Juniper, Arista, Broadcom, Dell, they've all given their pitch.

Cisco Too. Steven, Cisco, I'm sorry, I I'm sorry I missed it. It's so many.

Yes. And, and, and if you look at those videos, you'll see the apps, the aspects of each of those products. They're all available on Techstrong tv.

All right, that's our plug right there. Hey, let's break on this sec. On this, uh, block, we're gonna come back and talk about OpenTelemetry consumption, energy consumption, and resource consumption.

You know, someone's gotta pay for it. You're watching techron Gang, 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 Techron Group. Welcome back to the Techron Gang.

We are talking about energy use and in the past of our ecotech Insight segments, we've been talking about AI and green it, but here's something we haven't really dug deep into observability and took a closer look at Dynatrace and what they're doing to improve the modification of energy consumption for OpenTelemetry, uh, particularly based on a talk that they they had at CubeCon in Europe. And you'll see a little bit of that as well as a closer look at the analysis behind this. New idea.

Tools meant to monitor system efficiency are now being scrutinized for their own environmental cost. OpenTelemetry widely used for observability is emitting more than just data. It's consuming energy, memory and compute at a scale that's prompting a second look at CubeCon Europe.

Dynatrace's, Adriana Veia presented benchmarking results using Kepler, a tool that tracks energy output in Kubernetes pods. Her findings, custom built OpenTelemetry collectors used less memory and less power than standard versions according to the CMCF. This type of observability framework has more than 500 active contributors.

With adoption increasing, the focus is shifting to its own operational overhead. Framing performance around emissions resonates more with developers than cost metrics telling a team their app emits as much CO2 as 30 cars due in traffic. Well, that gets more traction than citing cloud costs.

Dynatrace is also leveraging Cube Green, a time-based auto-scaling tool that lets Kubernetes pods sleep during off hours. They've integrated it into internal observability pipelines without relying on Prometheus to cut back on processing overhead and reduce overnight idle usage. As telemetry infrastructure becomes more embedded in critical systems, its own performance characteristics are attracting greater scrutiny.

The focus is shifting from what observability tools deliver to how efficiently they operate. So it's an exciting movement with a Dynatrace and the efforts that they're doing. And they, um, also shared some other information at CubeCon.

And Mitch Ashley was actually there, and he's the person who, uh, told me all about this. So Mitch, I'd be curious to see, um, and hear about your thoughts on it. Yeah, no, the Dynatrace folks, well, and Adriana Vila who gave the presentation there, uh, fantastic speaker as well.

It's interesting. OpenTelemetry has become sort of the Swiss Army knife of, of not just monitoring, but metrics and measuring and collecting, and then presenting that into whatever tool, uh, substrate that you want to use that in. And, and it can be anything from what are the effects of the user experience, what is the performance of servers?

Now we're talking about energy consumption. So the OpenTelemetry, open source environment has, I don't know what the total number of companies now. It's well over a hundred that are contributing to that and are part of it.

It's one of the most healthiest open source projects I think that we have. And they've started to really focus on the sustainability factor of it. 'cause there's a great place to take both existing telemetry data, but also take in new sustainability, uh, telemetry data from tools like things like Kepler, they can integrate with, uh, with OpenTelemetry or Tel and really give you a better picture.

There's things that they've added into, uh, Kubernetes, for example, turning down clusters during off period of hours that it may not already be configured for. You can, you can just imagine the number of places that we could save money, uh, by turning things off or, or putting into more of a, a standby mode. They're also working on some of the semantics that they have in their model, their data model of how they represent this information.

There's a lot of really good foundational work going on, and I think it's very much in line with where companies are looking to, how do we measure the results of what we're doing in sustainability and kind of demonstrate the actual value of those efforts. And, uh, Tel has a big role to play there. Alan, is Alan, is this too much of a good thing?

And I'm laughing 'cause I'm kind of like thinking back for the last decade or more, banging a drum about let's instrument more applications, instrument more applications so we can do DevOps. Well, now we have, yeah, because it's open. So two, there's two lessons there, Mike.

I'm gonna hit 'em both. But Mitch, to your point, OpenTelemetry is actually the second largest project in the CNCF, which has over 200 projects, right? It's behind only Kubernetes itself.

Yeah. Right? That, that gives you an idea of how OpenTelemetry has, has cut in.

But to me, this is, OpenTelemetry is a poster child of the, just because we can, doesn't mean we should school of thought, right? All of a sudden we can measure everything. We could monitor everything, we could log everything, right?

The Splunk School of Thought, and no one really thought about, well, what does that really entail from a cost point of view, right? Well, in Splunk, the money, how much did you pay for storing all that data? That very quickly became a thing.

But with OpenTelemetry, putting all these collectors all over, no one really thought about the con energy consumptions and the cost behind it. We were so enamored with just being able to do it, right? So it reminds me of the old security adage, right?

That I've learned a long time ago is people don't care. Vendors don't care about security until their customers do. Vendors won't care about their OpenTelemetry consumption kind of graph until their customers doing, until someone says, oh my God, look how much I'm paying.

You know, I, I, someone shows me how much I'm paying for it, and I do something about it. And I, I think from, you know, this report an excellent video, Bonnie, from it, we're, we're starting to see, at least Dynatrace has gotten the religion right. They realize there's an opportunity here.

Kudos to Dynatrace of saying, Hey, someone should be measuring this. Someone should be measuring what we're doing around energy consumption all along with our infrastructure. Because even though we're, you know, rushing headlong into building these AI data centers with hundreds of billions of dollars, someone's gotta pay this bill month in and month out for what you're using.

That's the model. And well, is It that the costs are, are the problem, Alan? Or is it that we're not getting enough value from what we're getting for those costs, right?

I mean, you know, collecting all the data is great. Maybe we're not doing enough with it. I mean, I, I do feel like, you know, the complexity of these, you know, enterprise infrastructure estates has gotten to the point where, you know, the only way really to optimize it is gonna be through automation and ai, you know, and, you know, getting these data points really allows us to, you know, take our a PM data, our observability data, our cloud, you know, carbon footprint data, our finops data, and really get to a point where we can kind of define for any given workload, what is kind of the optimum mix of all these trade-offs we make across performance and cost and security.

And I, I think it's kind of a double helix where, okay, this is what I get out of it. This is the good right? That, that comes out of it.

This is the cost, and someone's gotta make that determination is the good worth the cost. So I, I, I worked with a, uh, I worked with a client, I developed their, uh, observability strategy guide for them. They're a, a platform company.

And, you know, this was really right before AI became mainstream, which oddly to say was 2023. So I'm writing this in 2023, and nobody's saying, Hey, let's throw a chat GPT at this yet, right? So it, that's how, that's how early on in this game and how quickly this is really erupted, right?

Um, and you know, the reason why that guide was important is because for the operations team, they were turn, they, they were using Datadog and they're turning on all these sensors. But the truth of the matter is, before you turn on a sensor, you really need to think about what are the important metrics and what do I, and the, and the reality is that for a brand new platform, nobody knows exactly what the right metrics are. You know, I, I'm using 22 different components and I have distributed computing going on, I have networking, I have dynamic load balancing, I have Kubernetes spinning stuff up and eating up memory.

I have physical memory, you know, physical constraints. I have logical constraints, right? What, you know, for most humans, this rapidly expands beyond their capability to comprehend.

Now we take that data, like you were saying, Dan, and we hand it to ai, ai, you know, the first thing AI can do is kind of just give you a direction. Say, I I am looking at your platform and I'm understanding the types of components that you're using, and here are the top five metrics that you probably wanna look at initially for health, right? And then you, you start with these, and if you have an outage, you may want to expand to these, it'll do that for you.

I think that's important, right? That's the thing that AI can do that humans aren't able to do today, is take 44 variables and consolidate it down into a operational direction. Something that a human can actually look at and go, yep, yep, I get this.

Okay, I can comprehend this. And it's a, it's a way to minimize all of that energy waste, right? I'm not gonna turn on all the sensors in the entire factory and see, and 'cause you're gonna get noise.

Your signal to noise ratio is gonna be unbearable, right? This is a way using the, using humans and AI together, that you can work as a coupling to say, what's the right things to look at? What do I turn on?

And I do it from a bottom up versus a top down. And right now, I think a lot of people who are in operations approach observability from a top down perspective trying to figure out, well, I've got all this data, let me see you, let me see what I can learn from it, what I can glean from it. And the truth of the matter is, that's not the right approach to, to take.

You don't have a baseline. So you're, you don't know what you're gleaning. Even AI doesn't, You know, I'm actually working on a, a, um, a future of observability paper right now for futurum.

And one of the key factors that we don't off often talk enough, kind of to your point too, JP, is it's because we can do something doesn't mean it's gonna get used either, right? And I think the companies who are really good at not just, let's take this data and put it to use, or let's find a use for this data. The next step is, well then let's find the people who would actually use it and will they use it.

And since Dynatrace gave this, the, this talk, and that's one of the, the several companies that I've talked to in the last 30 days, uh, getting updates on their strategies is Dynatrace has done a really good job. I think it's a good model for other observability companies of moving observability to a different place in the organization. They've done a great job of instrumenting Kubernetes and getting it to platform engineers and getting it to the IT ops team.

They've done a great job of moving observability upstream into use by developers. So it both can be used during development, but also to better instrument their code. And we'll see, I sus and they're also, by the way, I think doing a great job in the ai, uh, observability space too, and which is, you know, new for them, like it is for everybody.

But we'll see how that develops. So to the degree, I think to your point, Bonnie, that they can align with who in the organization that determine drives those value from that, and those, those metrics have resulted in, you know, bottom line dollars or KPIs or whatever it might be that has been achieved. I think that will help be that segment of observability, identify that it's successful or not, Did not strike you as kind of odd that every time we seem to be talking about anything these days, it all comes back to storage and networking.

And at the end of the day, a lot of the data that we are collecting is, as they say in Scotland, crap. Well, it's all about storage, isn't it? It's all about storage.

Um, now I, I would, I just wanna say first off, uh, that as somebody who's been in it for my entire career, and that is a few decades now, uh, one of the biggest challenges was the fact that, that most of the telemetry data, we didn't really call it that, but you know, it is telemetry. Most of that was siloed. And thanks to OpenTelemetry, it's not.

And I just, you know, I, one of the reasons this product, this project has been so successful has, is because it's right there in the name OpenTelemetry. In fact, uh, last year at Share, we had Broadcom talking about, um, exporting, uh, mainframe data through OpenTelemetry to many of these same systems and really integrating that kind of data. Now, if you can have everything from the mainframe to the cloud to on-prem to the edge, all bringing data in, it is exciting, as JP was saying, to think about what AI can do and not chat bots, as you said, ai, you know, large language models or specialty models trained to do, sort of find the needle in the haystack.

But I do wanna bring in one interesting factoid. Now, I was doing some research on this story ahead of this, and in the future of intelligence, uh, uh, platform, I looked up to see what the deployment of, of telemetry data is. And, and shockingly, it, it's interesting, there's a pattern here.

Um, it's just under 70% for public cloud, uh, 66%, like two thirds for on-prem. Um, but it's only 38% for edge and only 10% for co-location. In other words, there's still an opportunity to bring more data and more applications online.

And I, I think this shows that maybe we're drowning in data, maybe we're gonna have it gonna run outta storage. Maybe we're gonna run outta energy, but there's still more to do in the telemetry space. There'll be a little something extra in your stocking this year.

Thank you Steven, for that mention. But let me, let me, let me put on my green hat for a second. Yes.

We could talk about the value of the data versus the cost of the energy to, to produce it, store it, use it, and, and that's a very, that's meth. It's meth, right? Kilowatt hours, however you want to do it.

Bigger issue, Steven, and I'm surprised you're not on your stool about this. One is, guys, we've got to do something in this world about the energy consumption. We can't just keep saying, we're gonna spend trillions of dollars building out AI data centers in cities and all of these things without fundamentally changing the equation on making this energy that we use for it renewable recyclable cleaner better, because drill, you know, just drilling more and spending and burning more fossil fuels so that we could collect more log data is probably forget our little world that we live in here.

We're all it geeks. Our children and their children have to live in a planet where we need to do something about this. And, you know, how do we, how do we make that part of it?

Steven, I, I know you are the, you're a solar GU guru, right? Don't we need to really look at it from that angle? Uh, you know, I would love to see the real energy impact of telemetry data compared to literally everything else we're doing.

And maybe, maybe it's true. Maybe telemetry is taking up a huge amount of resources that was the subject of this Dynatrace presentation that kicked all this off from CubeCon, which by the way, looks like is online now. So if you, if you missed CubeCon, um, I think that you can find that on YouTube.

Um, I wasn't able to watch it yet, so I wasn't able to see their data. Um, did, did they talk about what the real impact is in terms of, you know, hard numbers? Yeah, I believe so.

And they, they showed the platform and there's other, um, additional lectures on YouTube that they've previously done and webinars. So there's, there's a lot of data on those as well. Let's go check them out now.

You know, let's Compare it to the number of TikTok videos that are completely mindless and brainless that are produced Over again. Agreed. Agreed.

Right. Let, let's pick our fights where they make sense, right? There is a lot of energy consumed on mindless.

Yes. I'll leave it at that. All right, anything else on this?

Otherwise, we're gonna take a break, Bonnie. Great. Great story, by the way.

Thank you. All right. And as usual, you can get Bonnie's videos again on Textron tv, on our O OTT channel.

com. That's right. Absolutely.

Thank you. Alright, we're gonna take a break here on the gang. We're coming back for a C block and it's infinite workdays.

I think we've all been there. 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. Hello, we're back.

And we're talking about this new study that Microsoft put out called The Infinite Workday. It's a little ironic maybe that Microsoft's the author of this thing, but we'll jump into that in a minute. But the premise of this thing, let's start with JP, is that we're overwhelmed with too much information and we're being inundated with various messages all day, and we don't have enough time to answer them all.

And who knows, maybe AI's making that better or worse. We'll see how that comes out in a minute, I'm sure. But jp, what's your take here?

So, I don't know where everybody else has been. I've been living this for 15, 20 years now. Um, sometimes it feels like PTSD and I think that there's a cultural aspect to this as well, where there's a certain shaming that one feels if they don't respond right.

Am am I letting a team down? Am I, are people gonna think that I'm lazy? Is, you know, are people not gonna take me seriously as a professional if I'm not there when they need me?

And how do you professionally shut people down without worrying about, you know, how you are perceived, right? So it is a lot behind this. It's cultural.

Now the question is, you know, how all these new AI assistants play? How are they gonna participate and what's gonna be acceptable to everyone else? We've seen a lot of people sending note, the joke, I should say, the meme where people are sending their note takers to meetings instead of themselves.

And it's just one person speaking in a room full of note takers. Um, is, is that the future? Is that the right way to go?

Meeting's a waste of time. Um, and if I have something important to say, I'll glean it and then set up some time to discuss it further. Uh, but these are the, this is a reality that we face and I do think that it needs to be attacked, uh, you know, from a, from a cultural perspective, not just a technological perspective.

Agreed. I mean, look to me, you know, the adv, I wish I had it with me, but I don't even, I don't have my phone with me. I can't believe it.

But, you know, the, the advent of the cell phone was the ultimate tether. It tethered us all. And we all thought we were so smart.

You know, what independence does this give us? We can communicate whoever we want, whenever we want, whenever we want, but really it tethered us to our jobs for most of us, right? It tethered us to our jobs.

We were in constant communication. Now, jp, like you, I've led this life also for 20, 25 plus years. In my case, I didn't think of it as work, right?

Bond. My wife's watching a chick flick, no big deal. I'm going on Slack or whatever.

I'll, I'll look at, you know, I'm doing some work stuff. It's just what I do. But the, uh, there was a crucial point during c when the work from Home Revolution really became mainstream.

And I realized it. 'cause in talking to people, people didn't know there was an off button. There was an off button.

And most people that I, especially younger people, and I'm not, you know, disparaging anyone, they have a hard time finding the off button and everyone needs an off button, otherwise, you get burned out. And I thought about you this morning on my walk, Alan, you Thought about me. Yeah, I I thought about Alan all the time.

Thank you. I, I, well, usually when I'm walking, the first thing I do is I pick, um, a podcast or YouTube to listen to while I'm walking. And I read something this weekend, so I decided to try it where, just turn everything.

It's your off time. Don't add anything. Just, you know, do your walk bike.

So I was thinking, what do you do when you bike? Do you listen to stuff or is that your escape time? Is that your off time?

I, I'm gonna tell you, I'm glad you asked me. So there was a time where I used to listen to podcasts while I'm biking. I cut that out because it was taking away from my, my exercise, the endorphin stimulation.

I listen to Apple Music, classic rock station. I, I, I will advertise it here. And, but I will tell you, my mind expands like I'm on microdosing or something while I'm bicycling.

'cause I wind up spending a lot of time thinking about work stuff. But in a very non-structured, free, forming, creative way that works a hundred times better than listening to some podcasts or checking my email or messages or slacks or whatever. And so I, you know, There are other podcasts in the world that don't have anything to do with technology, right?

You're, you get that right? I heard there are, you know, there's a whole nother aspect to this. And that is, yes, it's the devices, it's also the software.

How much are we inundated by? It wasn't just email anymore. Yeah.

That, that's an ungodly base beast. We still haven't tamed, but we've added to that every app on our device wants to send us notifications and it's binary, all of them or nothing. And you, you total that up.

And even with, you know, new things like apple's done with summarizing notification, I just get more summaries than it's still way too much stuff. And I don't know what those summaries mean. This would be a great place for better product design and really understanding what, what are the notifications that matter to me?

I don't really care about 99% of those. And what are the ways that I can fine tune those or AI could fine tune that for me better. I think hopefully we can be smart about how we apply AI to this, but I don't want the software folks to get off for free on this.

This is, they're just as guilty as everybody owning three devices and, and watching all three screens and not talking to their family. I think there's also the cultural aspect of it too that, uh, was mentioned earlier that an email, it's okay, you can respond in in due time, but when someone sends you a text and it could be, you know, a work colleague, you really do feel obligated. I better respond within due time because they can see you read it, they know that you have your phone with you at all times.

So there's that cultural pressure as well. Absolutely. Yeah.

O' Brian, what's your take on how this is gonna play out in the age of ai? Because I've already noticed that it's a lot easier for PR people or whoever to create a message. And so there's more crap being created than ever, but the ability of the people than the cognitive load of the people who received that has not increased.

So it feels like there's an imbalance in the system. There is. Yeah.

I mean, a few thoughts for you, Mike. I mean, as we talk about, uh, I guess kind of the nine to five becoming kind of the five to nine, you know, 5:00 AM to 9:00 PM we do still need to sleep. Um, but you know, I, I think, you know, my big thought here is, I think we all know this from leading teams, but you know, when you ask people to do more, you, you also need to ask that question, what are we gonna stop doing?

Right? And I think that's kind of the big challenge is we've added all of this, you know, kind of extracurricular outside of kind of the, you know, kinda set workday where we're proactively working, where we're doing a lot of reactive work kind of in the off hours. Um, you know, I I think at some point you gotta ask, what are we gonna stop doing?

And maybe that's, you know, uh, blowing up the construct of, you know, I'm at my desk for eight, for eight hours straight. You know, we maybe need more flexibility, you know, kind of during, uh, you know, during kind of that, that typical on time, uh, to give people the balance that they want. But I, I really worry about the AI side of this, Mike.

I mean, I, I I, I feel like we're heading into a world where somebody uses AI to write a report. Somebody uses AI to summarize that report. Somebody uses AI to, you know, synthesize the notes from the summary of that report and nobody's actually writing it.

Nobody's actually reading anything anymore. Um, you know, we've just got our AI kind of flowing back and forth and, you know, how how do people actually consume information in a meaningful way where it sticks, it registers, it's got context. Um, and we've actually got, you know, kind of an agreement between the parties within these communications, what we're actually saying, what we're actually committing to.

I need that email with five bullet points and I'd be happy. Right? Well, may or maybe you like, don't use Slack, just kidding, Mike.

But, um, we've had that argument. Let me, let me, let me, I want to emphasize something though, and I, 'cause I don't want us to overlook it. I wanna make sure we hit on this, the Microsoft study called it a crisis, a crisis engulfing Modern Employees.

And that crisis is not that we're doing more work or that we are tethered like this. The crisis goes to burnout. Burnout is real.

It's, it's, it's a recognized condition now by the World Health Organization. Uh, it's something my friend Jean Kim has explored a lot in the, in the DevOps enterprise summits and whatever he calls them now, um, I've, I've interviewed several experts in it over the years. Burnout is real.

And, and it's getting worse because I'm telling you, people don't know how to shut off. And Dan, I wish it was just five tonight, but I'll tell you the truth, I've been on with you past nine o'clock at night. I've been on with you, Mitchell, Mike, past nine o'clock at night.

I know as a team leader, when when stuff happens, I reach out and it's, I'm almost glad sometimes that people are on the West coast. 'cause I pick up three hours, right? So it may be 11 or 12 my time, but it's still semi-okay to reach out to them.

It's before nine. Um, but, you know, do we expect this as employers? Do we acquiesce to it as employees?

And what, how do we recognize when we've crossed that line into burnout? And it's, and it's, you know, it's detrimental to our health and not only to our individual health, but to the functioning of our company. I, if I can jump in on this some, you know, some practical things that I've learned about this.

Um, number one, um, I agree with, with all of what y'all are saying, uh, you know, it it, it pains me as somebody who's worked from home and worked in an office to see people, uh, just sort of unequivocally saying working from home is better because, better for who, better for you really. Um, are you sure it's better for you? Um, you know, if you can't proactively manage your time while working from home, you never leave work.

I, I think that's the thing that, that, that, that really challenges some people. I think that whole commute and going into the office and being in a different place, I think that helps people organize their time. On the flip side, I think as you know, Dan was just saying, I think there's also a lot of value in those of us who've worked from home effectively to changing the nature of that nine to five workday.

And, and frankly, I feel like the the biggest thing that we have to do to avoid this crisis, because I agree it is a crisis. I see it, I see it with people that we work with internally at Futureum. I see it with, with my customers and I see it with my friends.

We have to proactively manage this ourselves, each of us individually. Like, you know, one of the, one of the easy, easiest and most effective methods that I've been known to do is, is schedule things on my calendar for myself. You know, I have, uh, the suggestion of my wife a uh, an hour for lunch scheduled on my calendar every day.

It's not like, I don't know what time lunch is, but it helps to make sure that I've got some time to eat. You know, and similarly, you know, Dan asked me to work on a, a project. I scheduled blocks of time on my own calendar for myself to work on that project because I knew I needed to get it done.

And I knew the only way to get it done was to the Microsoft, uh, report was to not have calls interrupting me every 30 minutes. Uh, during that time that I'm trying to get something done, I need some time to focus. And those of us who've worked effectively from home realize as well that it's okay to schedule dog walking time.

It's okay to schedule, you know, time for a, a visit to the coffee shop or whatever. And it, and it's okay to work into the night if that's what works for you. It just is a matter of, of being more proactive in owning and managing our own time and recognizing that if we don't have on time and off time, we will never have off time.

So you have to have specific on time and specific off time, and you have to manage yourself as much as you're managing other people and, and your customers and, and coworkers. So, Steven, I, I've, okay, I got a i I like you. I've also set aside time.

I have a 45 minute lunch break. But what I find, as soon as something comes up that I feel like I have to do or should be done, that is the first time that I sacrifice. Oh yeah, me too.

Totally. So there's a little discipline I think that has to go with that. Yeah.

I'm not an expert at it, but I do think that it comes to, you know, you have to manage yourself and you have to reflect on this. And, and I'll just say out there if, if some of you who are finding challenges of this, maybe it would benefit you to go to a coworking space or something like that because then you feel like you're kind of have on time and off time. At the very least, you have to have an like a home office with a door that you can close and, and not try to do this while your life is revolving around you.

You have to have space. Hey, I would just remind you of an old joke that says, you know, when you're married and you have a full-time job and a couple of kids, what's the definition of quality time? It's the drive to and from work.

There was a time I used to take the Long Island Railroad into New York, right. And you'd, you'd actually read a newspaper. Yeah.

You remember those days. JP Dan, you work from home. How do you, how do you deal it?

How do you deal with it? Yeah, I mean, we've all heard the term work-life balance, right? And I feel like it's, it's probably not the right mental framework for that because it really kind of puts the two at odds where one is a trade off versus the other.

I've, I've heard the phrase, uh, before called work-life harmony. And I think that's kind of what we're describing here is that, you know, it's a, it's a proactive stance. You've gotta really take a personal responsibility on it yourself, uh, to draw those boundaries, right?

I mean, me personally, I carry two phones. Um, when I'm getting good quality family time, I can leave my business phone in the drawer, right? And I know I've got no interruptions.

Um, I tend to do my work, you know, kind of only from my home office here and don't let that bleed into the rest of the house. Um, you know, I, I prioritize sleep. I've got, you know, kinda some limits as far as how late I'll go and, you know, back at it when I wake up in the morning.

So, uh, those are at least some of the things that work for me. But to me it's much more about that kind of work li life harmony, drawing some kind of clear boundaries and you know, kind of that set of personal responsibility to make sure that you're taking care of your own wellness and mental health and, you know, making sure you're getting everything done on the job as well. Agreed.

I'm gonna give you the last word on that one. Hey, I think it's time we get a little work life harmony 'cause we've already done enough of our tech storm gang today. We're over time.

What a great discussion panel today. Thank you all. Steven, jp, Mitch, Mike, Bonnie.

Thank you, Dan. Now you've done this once. We we're expecting you on regularly, right?

Alright, I'll be happy to be a recurring guest. Thanks. All righty.

Thank you. Thank you for watching again. Hey, we've got a full day of Techstrong.

Well, not a full day, but we've got another three, four hours of Tech Drunk TV coming at you immediately following the gang. You could watch this as well on demand on Tech Drunk TV or our Text Drunk tv YouTube channel or the OTT, uh, channel as well. Just search Text Drunk tv.

I think we've deconstructed the gang too, where you could actually just watch individual segments of the gang. Not all three. So you've got no excuse.

But until tomorrow everyone, thanks for joining us on behalf of our gang, have a great day. We're outta here. Hey everyone, welcome back here to Tech Drunk tv.

I wanna introduce you to Carl Froggett. Carl is the CIO for a company called Deep Instinct. Hey Carl, welcome to Tech Drunk tv.

It's great to have you on. Hey Alan, good to see you, and thank you for having me. Look forward to having my pleasure having little chat today.

My pleasure. Absolutely. So, Carl, I, I mentioned you're the CIO at Deep Instinct, but you know, there are, there are different flavors of CIOs if, if just like there are CTOs, right?

Some are very engineering. I, well, they're all IT focused, but some are more outbound, outward facing, inward facing, really serving at the executive level and filtering down. Some are filtering up, some are doing both.

What kind, how do you consider your role as the CIO and, and maybe, you know, how has your personal journey kind of shaped that? That's an interesting question. Uh, Alan.

So I'm probably one who does a little bit of both, uh, filtering down, making sure that the, uh, the teams understand what I need them to do at Deep Instinct. Uh, I also run customer support, uh, uh, deep instinct. So it helps having that technical background, although I'll profess that, uh, my time is more on that upward executive and communication, which is a really important part of, uh, of leadership.

And that's because of my background coming from financial, uh, background in Citi and, and providing their security solutions for the 27 years that I was there prior to joining Deep Instinct, you have no choice but to be, uh, technical, but to get buy-in, you have to communicate, you have to put, you have to talk to the business. Ultimately, I'm serving the business here at Deep Instinct, just like I was at Citi. So the role of a CIO is, is is both generally, Alan?

Absolutely. Absolutely. You know, I had, uh, had the pleasure of knowing at one time the Citi, actually, it was probably Citibank or Citigroup that had three global CIOs.

I don't know if it was like that when you were there. I would imagine I was three, Well, there were three Globals back then. One of them was a gentleman named Peter Fisher.

I don't know if you ever knew Peter during your time. I know Peter. Yep.

Yep. I mean, I, I had the pleasure of meeting and dealing with Peter from a, a company I had co-founded. And, um, what a gentleman.

I mean, he had smart, I, I learned a lot from Peter, a lot of respect for what he did over at City. What, what a, I mean, the whole city operation was. Yep.

Yeah. I, I met Peter, um, quite a, quite a few times. I was quite young at the time, I'll say 27 years.

It, it was definitely, uh, the late nineties, early two thousands. Uh, we, we were building, I, you know, I, in the early two thousands Yeah. We were building, uh, Canary Wharf, um, uh, the city group center at Canary Wharf, which was the Europe became the European headquarters.

And, uh, Peter and Rich Brunick was another one. Sure. Uh, that came with Peter and yeah.

Had to present the whole, uh, cybersecurity element. It was called security at the time, not cyber. That's, uh, yeah.

We, We, we called it InfoSec, right? Yeah. Security.

Yeah. Yeah. So I, I remember, you know, uh, presenting to, uh, Peter and, and Rich and, and getting grilled and coming out with a pat on the back and relatively unscathed.

So, yeah. But for you, it's those kind of interactions, um, really, yeah. At the time, you, you're almost just pleased to get out alive.

Um, but those experiences are, are what I've managed to bring into deep instinct, uh, you know, today because dealing with such titans and, and certainly there's many others, um, in such a high pressure environment, like one of the world's largest banks, um, you know, it, it's, it's an experience that, that Pew get to have. And so I'm really grateful for, for my whole time there. Absolutely.

We'll talk more about that as we go on, but Deep instinct. Talk to me, or actually don't even talk to me, talk to them. A lot of folks out here are not familiar with Deep Instinct.

What, uh, how would you describe it? Sure. So I joined Deep Instinct three years ago, and we prevent known and unknown threats, and we do that leveraging a advanced AI called Deep Learning.

Hence, hence the name, which is the learning, uh, the, the chat GPTs and LLMs of the World are built on. Uh, the company was founded several years ago, and, uh, lane Bess, uh, he was the CEO of Palo Alto Networks when they were, I know, I know Lane too. And then, and then he went to Zscaler, that little company He did.

And he has a huge boat down here in Miami. He does Alan. Yeah.

And, um, and, uh, yeah. So yeah, he's our CEO and I've known Lane since the Palo Alto Days. Oh, I didn't realize.

Okay. Yeah, yeah, yeah. So, uh, he was one reason.

But, you know, we, uh, at, at c uh, what we were seeing was threats were evading the more machine learning and signature legacy based approaches. 'cause that's what the threat actors do. And so we ended up evaluating and purchasing deep instinct and, and putting it in our applications and in the storage to prevent, and here's the thing, to prevent against threats that have not yet been invented.

And that's a huge claim, but it stands up, which is why we have financials and other big customers today. But our core is deep learning. That's what we bring to the table, and we're the only cybersecurity company that that does that.

So that's what we do and that's what makes us fascinating. The classic story of the customer who loved the product so much, he went to work for them. Exactly.

Yeah. Yeah. Yeah.

Not raise a Blades. Great story, Carl. No, no.

Not raise a Blades. Good for You. No, sir.

Um, so, alright, just real quickly, deep instincts website. Yeah. com.

It's right there. Okay. And, uh, the audience, you, I'm on LinkedIn.

You can hit me up if you, uh, have any questions or any follow ups that you need through today. Fantastic. Carl, I wanna turn to our topic of discussion today, which is SecOps teams and burning, and burning and burnout, even with AI and everything, agentic ai.

And supposedly, you know, it's gonna make our jobs easier. It's gonna make us 10 x more effective. It's gonna do a lot of the tedious work.

We're gonna have nirvana and heaven on Earth and cue the angels playing the trumpets, right? Yep. But yet, we're still suffering from burnout.

Now, Carl, you and I are of an age, right? Um, Is it the gray hair, Allen? Is that what gave It away?

Well, at least you have hair. It's all good. Um, you know, but we're of an age where we didn't really talk about burnout in the late nineties and the early two thousands.

You know, I, and there are some people who say, is burnout real or is this part of the participation trophy generation? But, you know, I, I've had the chance to interview, and I forget her name. She's a profess PhD professor, probably one of the most foremost authorities on burnout in the world.

Both her and her husband actually, and I'm drawing a blank, I apologize. She, I, she's always used to talk at Jean Kim's DevOps Enterprise Summit. Mm-hmm.

Um, but anyway, I remember, you know, her telling me and teaching me that burnout is now recognized by the World Health Council or the World Health Organization, WHO. Yep. As a, as a bonafide diagnosis.

As, as a real, it's real. It's not just people's, you know, saying, oh, we're being overworked or whatever. Burnout is real.

And it's lethal. It's lethal. It affects, affects your mental health and your physical wellbeing.

Um, but I, you know, why, why in this age of AI and automation are sec, cyber cyber warriors, we'll call them, right? Let's make 'em feel good. Why are our security operations teams suffering more than ever from burnout?

I think, I think it's a nuanced, uh, kind of question. Uh, so we, we did the voice of the, uh, SecOps, uh, which is available from the website, uh, go and download it. And, and that is, uh, responses from the frontline.

So this, this is something that we, we publish, but the, the results are from those warriors that you talk about who are on the frontline, Alan. And it's, it literally an interpretation is non marketing. Uh, my background, I have a good in, uh, high integrity for making sure that the deep instinct, you know, produces, uh, quality research like this.

And I think the burnout's got a few things having run security operations, right? So I not only did the engineering and the architecture, but I also was, uh, ultimately accountable, uh, for security operations. And the context, I feel that, that the response of burnout, which it was 69%, it was a, you know, two thirds, more than two thirds said that, uh, it, uh, introduction of AI created burnout.

So why is that? I think there's a couple of nuances. One is there's been this mad rush, right?

So the bad actors have been leveraging, uh, you know, LLMs and DAF AI as Gartner called it, to, to create more sophisticated threats on a scale that we've never seen before. And we'll get to that. So, so what that means is that there's more going on, right?

And you can look at pretty much any statistic of phishing, ransomware, ransomware fines, right? We're spending all this money, Alan, and yet the bad guys are still winning, right? That's what the statistics show and the breaches show.

So if you put yourself as a, as a warrior in, in, in SecOps, you now have these new ais, but really they're not, they're not addressing the problem. So security operations are, are inundated with a vast amount of telemetry data because it's detect and respond, right? And that volume just keeps going up.

And so, get this, Alan, you are paying for, for whoever's product to send you all that data so that you can respond as a security operations person. But there's a couple of things there. More data doesn't necessarily make it better.

And there's a lot of false positives. So you end up, you end up spending a lot of time chasing down and ultimately finding that something was a false positive. So you, you didn't actually do anything in chasing that event.

So you feel very disheartened, right? But the vendors who are sending you all this telemetry are now selling you an AI to help you sift through and figure the telemetry out. They're not addressing the root cause of the problem, right?

If they fix their products with a more advanced ai, like deep learning, they would be able to prevent the threat from overwhelming the SOC in the first place. But, um, you know, uh, AI's everywhere as, as you know, Alan. So they've implemented an AI to try and help security operations per se, but it's not having the effect.

And what we do is we actually prevent the noise and the threat in the first place. That's the fundamental difference about what we do. We now have a prevention first approach, not a detect and respond approach.

And ultimately, security operations is very stressful. Uh, like any operations role, but security operations is constant, is 20, you know, those bad actors don't go to sleep. Some of the other operation roles, you have stability and you have calmness, uh, un until something breaks.

But security operations is, is constant. There's always something to do. And I feel that the burnout is a, a multitude of chasing false positives, not getting anywhere, implementation of all these random ad hoki that are not addressing the root cause of the problem, which is to stop the threats in the first place, right?

And then your, the security operation, they've also gotta learn and use all these new tools, right? As well as do their day job. So I think there's a whole bunch of factors that ultimately just lead to a, a lot of overwhelming stress and a, and a significant dip in job satisfaction.

'cause they're not actually preventing the threat from happening. They're responding to it all the time. And that ultimately, you know, just leads to a very demoralizing situation for an individual, which is why they feel burnout.

So I, I think that's two other things to the equation we need to add, Carl. Number one, you know, almost by design, right? Our SecOps teams are playing from behind.

You know, whether you're a football, soccer fan or American football, or a baseball or basketball hockey, when you are playing from behind, you're down a goal coming into the third period or the second half, or you know, you're down three runs, you only got two at bats, left it. That pressure builds it's constant and, and security, it seems, you know, as I say by design, almost, we, we are one step behind. It's this cat and mouse game where we're the cat, right?

We're waiting to see a hundred Percent In what clever way the mouse is going to come at us. Now, secondly, yes, we have these wonderful ais to use, and whether they're the right AI or the wrong ai, I don't think we have enough experience with the ais to really know which is good, bad, or indifferent. We're still learning.

I think it's an emerging kind of, uh, uh, emerging sort of, uh, expertise to pick the right ai. But we don't have a monopoly on ai on the good guy side. Those bad guys, look, they're clever sobs, right?

And, and they, yeah, they're using AI too, and they're making our life miserable with these ais, right? Phishing is so much better than it used to be. You used to be able to spot most phishing attempts because, you know, English is a second language and all of that.

Yep. Today's phishing are beautiful, right? The the whole, I mean, they're using AI throughout the whole battlefield, if you will.

And, and make no mistake, I, I think that that's another reason, Carl, is that the battlefield, if you will, the, the attack, uh, The attack surface, The attack surface is, is expanding every single day. There's, you know, there's a new, yep, a new vector, a new thing we're worrying about. It's not, I mean, it's, it, it's not fun sometimes being a, a SecOps guy, right?

No. And I, it's, um, it's not, it, it's not fun. Um, uh, but you get the satisfaction when you know that you did something More than something, right?

Then You forwarded Something. And that's another issue in security, right? When nothing happens, you did your job, at least to the outside world, right?

You know, inside, man, You, well, unless any, any operational role, if the phone doesn't ring, like it's a good day in the office, right? I'm, I'm It's a Used a good day. Exactly.

Exactly. But yeah, just to, uh, yeah, I, I think you're right on the, uh, on the ai, now the bad guys have advantages, then the big advantage they have is that they generally don't follow any laws, any rules, or any regulations. So they, um, uh, the University of Indiana did a good study, uh, in 2023, I think, of, uh, the 15,000 or so at dark AI is what Gartner coined LLMs, um, that have no morality and guardrails, right?

So you can ask them to do whatever they need to do, and they, they'll do it. That's where the bad guys operated more than three years ago. So this is the explosion of AI from a bad actor perspective, because they just literally stopped almost overnight using their old methods because they don't care.

They're leveraging their most current technology, which was lms, um, you know, ultimately to, to make their objective. And most objective is to make money through extortion or whatever. Nation state, obviously, and activists have, uh, different motivations, but they kind of use the same, the same technique.

So they, they al they always have that first mover advantage. Now, what we haven't had as cyber professionals, uh, honestly, Alan, I probably deployed machine learning, I don't know, 15 plus years ago. Um, and it was great at the time.

Uh, but most things ERO erode after 15 years. And, and, you know, cyber's constant waves and, and the dark ai, the LLMs have just really empowered the bad actors. And if we think about the kill chain, so it, phishing, you mentioned phishing when chat GPT came out, phishing spiked over 1300%.

Why? 'cause they're trying it, right? Mm-hmm.

And yeah, like I say, they're very fast to do it. But that's, that's delivery, that's exploitation. They're now using ai, uh, um, advanced AI to make zero day threats.

Zero day attacks. So what used to take experts, uh, you know, in, in and taken days and weeks, is now, uh, done through an ai. And the way I like to describe it is, you no longer need expertise.

You no longer need to go and recruit a whole bunch of bad actors who are good at coding or good at finding vulnerabilities. You just need intent. And you tell the ai, the bad ai, the dark ai, what you want to do, and it will create you those super realistic, uh, phishing emails, those deepfake audio deepfake videos.

It will, uh, Google just recently announced that they've used AI defined zero day vulnerabilities that we normally take a long time to find years in some cases, right? And so, if you think about the steps a bad actor needs to do, the only one that I can't point to an article or research or statistics is reconnaissance. And that's where they're gathering information and why kind of point to something.

Because it, they, you know, they don't need to tell you that they're doing reconnaissance, but almost certainly they are. So they're, they're not only weaponizing the whole kill chain using dark ai, they're automating it end to end. So you are gonna get, well, we already see you're gonna get zero day threats, zero day vulnerabilities, zero day attacks, zero day attacks out of velocity and a volume.

'cause this is, this is cheap for them, and they're gonna overwhelm. They're already overwhelming. The things that stood as well for the last 15 or so years are already starting to crumble.

So we need to pivot, um, and, and use this more, you know, fight AI with AI is a tagline we use here at Deep Instinct. That's why we have deep learning, the most advanced AI that you can get today. And we're the only cybersecurity company that does it.

But it has some unique characteristics that it can predictively, prevent zero day attacks without any updates, without any new training. So some of our biggest customers, ministry of Defense and shipping companies, um, yeah, they're actually offline, right? They're not connected to the internet.

So we don't have the limitations that machine learning has when it comes to preventing threats, um, including the unknown. And it's the unknown that is totally shifting the landscape right now. Absolutely.

Carl, I wish we had an an hour to sit and talk about this. 'cause I, I, I feel like we barely scratched the surface. I'd love, I'd love to understand more about what makes deep instinct better.

What what gives us a little bit of peace of mind and takes the knife away before I cut my wrist because of this dark AI stuff. Right? Maybe we'll have to have you back on and continue that discussion.

Uh, that'd be awesome. Alan, This recent, uh, data about 69% of security professionals contributing to burnout. Is that a study you guys have published that we can point to on the website?

A hundred percent. It's on the, it is on the website. It's called Voice of the SecOps, and it is downloadable, uh, to anybody who, uh, uh, signs up.

Fantastic. In the meantime, we will continue this discussion. Um, not sure if it'll be in person or on here, but we will do our best.

I think we have A-A-U-R-L if I could read it. Um, no, I can't read it from here. We'll, but we'll take this URL and we'll put it into the notes of, of this interview, Carl.

Yeah. Paid, paid for the, uh, the SEC op report. URL and I actually live in Boca Raton, Alan, so I'll see you in Miami as well.

So I live, I live in Highland Beach. Oh, wow. Okay.

So I'll see you before Miami, but we'll, we'll make, I'll, we'll talk. Thanks for being on text drunk tv. We're gonna take a break.

We'll be right back. I, Hey everybody, welcome back to the Open Source Summit in Denver. We're here with Brian Fox, who's CTO for Sonatype, and we're talking about well, responsible use of open source software and responsible consumption, because after all, gluttony is still a sin.

Brian, welcome to Show. Yeah, thanks for having me. So, it's clear there are lots of folks using more open source software than ever, and a lot of that resides on infrastructure that somebody has to support, but that's not free.

So how do we kind of come up with an economic model that works in a way that, um, enables people to enjoy the fruits of the labor, but not take advantage of all the kindness? Yeah, I, if I had the answer to that question, I, I, I would certainly solve it for everybody, but I, I think, you know, part of it starts with just responsible consumption of, of what's out there. And I think, you know, if, if we, if we go back quite a ways to, when I first got into open source, you know, the, the, the thing that needed to be donated was your time, because you were largely using computers.

You already had, you're already paying your power and internet bill. They weren't really incremental costs for you to contribute to open source other than just your time. Right?

But fast forward to 2025, and you know, it's generally frowned upon if you release an important project from your own personal computer because it might be, might be hacked, right? You, you don't know to trust it. So we've, we've modernized our practices to the point where all of these open source projects, everything is dependent upon, you know, CI/CD in the cloud, right?

And GitHub actions, GitHub, you know, sponsors lots and lots of machine and compute time for, for GitHub projects to run their builds. And lots of other companies do it to, you know, Sonatype. We run the Maven Central repository.

We, we pay for the bandwidth and all these things. But I think people have, they don't recognize the underlying cost because all these companies are bearing that, that burden, right? And so it, it's led to this sort of sort of, uh, mentality, you know, the gluttony mentality of it's all free.

And so I'm just gonna run my build as many times as I possibly can, every commit. I'm gonna run a, a pretend release. And, and so what I'm, what I'm seeing when I really look at this is I'm seeing really just frankly, irresponsible consumption by, by, uh, individuals and, and companies, big trillion dollar companies that really should know better, right?

And are just eating up all of the resources that are causing every company that has to donate this stuff, um, to have to put in more to, you know, I'm worried that eventually it, it all comes coming, uh, comes crashing down because the, the costs become prohibitive. Don't those costs kind of like an insurance company eventually get passed on to the end customer anyway, somehow? It's just not, it's an in an indirect cost that we all pay for.

I I mean, in, in theory to the, to the extent that those companies are carrying that burden on their balance sheet, yes. Ultimately, um, everybody's paying it, but the people that are consuming it may not be the ones that are paying it. Right.

You know, if, if, um, if an organization is out there, I mean, I've been doing a lot of work understanding why, uh, why the consumption around Maven Central has just been going through the roof lately. And what I'm finding is, you know, trillion dollar companies downloading 10,000 different components 500,000 times each every month when those components don't change. And it's been an accepted best practice for decades that you have a caching proxy repository manager.

And so because it's free, there's no cost for these companies to do it. They may not be customers of sonotype, they may not be customers of GitHub. And so the, the costs are being passed on to a different set of people, right.

So that it, it's not well aligned for sure. And, and that certainly leads to the problem, but I'm seeing at, I'm at least taking the tack for the moment, that awareness is part of the challenge that most of these organizations, they might have a repository manager in place, they just don't realize that all their builds are bypassing it. Right?

Now, if you actually pull that thread a little bit more, I mean, we've talked about this before with malicious open source components. Like if your developers and all your builds are bypassing your, your repository manager, you're wide open to accidentally grabbing malicious components, right? That's, that's something you should be aware of.

But also your builds are taking longer. Like if you downloaded it from something on the same network, it's gonna be infinitely faster than fetching those same things over the internet. Um, and so you're paying for that CI machine time somewhere somehow, um, your developers are waiting for it, right?

So it's sort of this weird situation where it's gotten so easy to consume things somewhat irresponsibly, the costs are piling up in other areas. And I think I'm, I'm trying to get people to understand that better. Back in the battle days of it, I seen you remember there was a concept called chargebacks, and that's evolved into show backs.

Mm-hmm. Show backs, you don't really charge back. You just give people the information that say, this is how much this service that you're consuming costs.

So maybe it's time to apply showback as a concept to customers. So at least they are the users of these things so that yeah, they're at least aware of what's, what the cost is. I mean, I've been looking at some of those things, frankly, to try to try to see it.

It's, it's very difficult because in the open source world, everybody's used to everything being free. And so, you know, if there's a repository of things to download, you know, who are you to tell me I can't download it over and over and over again. Right.

You know, and, and, and, and that's the thing that has to change because the, the cost of the all of this is just gonna keep growing, you know, geometrically to the point where it becomes really unsustainable. Um, but I think it doesn't have to be that way. If people can think, uh, better about it.

I was, I was engaging with one person who is a publisher to Maven Central and, um, you know, they had a problem with a release once years ago. And so they set their entire pipeline up to basically do a mock release, every single commit, just because it was easy for him to do, and it didn't have any downside. And I looked at that and I was like, listen, you're wasting bandwidth.

You're wasting my bandwidth. You're wasting a whole bunch of my machine time doing validations on your stuff, which is computationally expensive, and then you're gonna throw it away. You're gonna do that a thousand times for each release.

And I said, like, listen, if, if you don't care about wasting GitHub's money and sonatype's money, at least be a better carbon burner, like you're wasting energy, you're wasting resources for all of us if you don't care about my money. At least care about that. It turns out this person was a professor and he was like, wow, that's really interesting.

Can I quote you back to my students to help educate them around, uh, being better, you know, uh, consumers of this, which is kind of what got me thinking about maybe, maybe this is the message that needs to be spread a little bit. We talk about a lot about who contributes to the community and whatever, and we've kind of beat that horse to death. But a lot of the enterprises, they don't have people who necessarily gonna contribute code, but maybe they can contribute money to support the infrastructure to the project.

They certainly could. And, and trying to get that conversation going can be very difficult yet. Um, but that would go a long ways to solving the problem.

When you've got huge organizations where, you know, sponsoring this is a rounding error. Um, you know, the, the challenges when we reach out to these organizations and try to point out, um, you know, the, the behavioral changes, um, many of those, those folks are lower level in the organization. They don't have the power to decide to say, you know what, maybe we should sponsor it.

Right? And so there's a, there's a big disconnect in, in the people that have the control over what's actually happening versus the people with the budget, you know? So that's why I said at the beginning, if I had the answer to this, I would certainly be doing it.

But I, I'm, I'm just now scratching at the, the problem at the moment. Do you think that the various open source consortiums might wanna take a more active role in this conversation because they are encouraging the adoption of open source, but there is this hidden infrastructure cost? Yeah, I mean, to to, to the extent that they can help raise awareness, of course.

You know, um, a a lot of the focus has been on how consumers consuming organizations can adopt best practices to make themselves more secure. I think the thing I'm pushing on is, can those same people maybe tweak their practices to be more aware of the pressure they're putting on the rest of the ecosystem? And that, that's, that's not something that we've really pushed on, uh, very much.

A lot of these organizations also have their own internal systems that they're using, and they would be more cognizant of those costs. And we hear conversations about finops and we hear conversations about, um, we need to be more responsible about the consumption of that infrastructure. Why do you think it only kind of sits internally, but they don't look outside their organization and apply the same philosophy and the same best practices that they're kind using the control costs internally?

Yeah. Um, because they don't get the bill. It, it's, it's the same reason as like, why is it, why, why do organizations, you know, do things that, you know, burn so much carbon?

Because there's no, there's no cost to doing that. That's the whole, uh, concept behind cap and tax, right? Cap your exp expense.

Until you, until you actually see the money value of what you're actually consuming in this, this other dimension, you're not gonna do anything about it. So I do think some of these resources, there's a lot of analogies to like the carbon carbon trading stuff and thinking about that clean energy. And because it's the same problem.

These are finite resources. Companies are not gonna pour infinite money into infrastructure to allow other large companies to just abuse the heck out of it. That that is going to come to an end at some point.

So the more we recognize that and the more we adapt, the easier it will be. Does this wind up being an exercise in shaming people into the right behavior? Or is there some more altruistic way of doing this?

I mean, I would say at this point, all things are on the table. That wouldn't be my first move. But, um, but, uh, but yeah, I think, I think raising the awareness, starting the conversation like I'm trying to do here, I think that's part of it.

It's just, it's a missing dimension from the sustainability. When we, we talk about making open source sustainable, where we tend to think only about supporting the people writing the code, but the missing part of that is all of the infrastructure that goes behind it. I think we take that for granted because it's just, you know, every big company gives away services for free, for open source projects and, and largely for open source consumers.

Um, but that free part and that disconnected part is, is a challenge here. There are other maintainers of various open source projects. Are they having the same conversation?

Are you starting to talk to them about the same issues? Um, it's, it's, I'm seeing it pop up in a lot of different places. I don't think it's a cohesive conversation yet.

You know, um, to the extent that, that the donations keep coming, I think it's easy for them to ignore. Um, but you know, the tin cup, as we all know with the foundations, you know, it doesn't last forever, right? And, and that's kind of the point that I'm trying to make.

If we can make the amount of investment we're getting already able to support more and do more, then we're already better. We don't have to keep going out and trying to raise more mon money, infinitely. Some people would say, well, won't the infrastructure get better and we'll just, you know, be able to do more with less?

Or is that kinda, you know, the end of the day we're just, the amount of data is out weighing the bond, even the advances in the infrastructure. I mean, uh, all of those things can be true. And if, if big companies stop downloading the same thing half a million times a month, we could do more with what we had.

We could make it even even better. We could put more of that resource into, into, you know, making the infrastructure better instead of just sending the money to telecom providers or to machine providers, right? Mm-hmm.

They're the only ones that win in this, too. The, the people that are actually getting paid underneath the hood to, to actually burn the carbon. They're, they're the ones that are, that are winning with all of this abuse And among some of the most ardent advocates of open source software.

'cause they see the consumption model, right? Right. That's right.

Um, so last question. What is, you know, if you, if you had to give somebody a, a to-do list or a set of best practices to become a more responsible consumer of open source, what would you tell 'em to do? Well, I would, I would take a close look at my pipelines.

I mean, clear, uh, you know, close to my heart is looking at, you know, the Maven consumption. Um, you know, and I would, I would say that you should look at all of the repos, not just Maven, but you know, if you don't have a caching proxy or repository manager in place, why not? Like why, why these files don't change.

It's gonna make your builds faster, more, more secure, and, um, more, you're more productive and you're gonna lower your impact on the rest of the ecosystem. So I would start there, um, you know, make sure those things are configured properly so that they do things intelligently. Like hit the internal repository before you go to the ones outside, because the cost of doing that is basically null before you go and hit external ones.

So think intelligently about how you're sequencing. This is just best practice around how you optimize network. Like you're doing this for other parts of your business already.

Pay attention to it as you're doing it for the o uh, the open source side of it. I would also further take that and think about, you know, we've been pushing continuous everything for like a decade at this point. Maybe it's time to start thinking about that.

Do we really have to run everything on every single commit? Do we have to pretend we're gonna do a release if we don't, if we know we're not actually going to do it? What is the sensible trade off between running these things often enough to give feedback and versus just running them for the sake of running them and wasting the resources?

Right? And I, and I think those two big things, if people took a closer look at that, um, I think it would make more sense. And I was just talking to, um, you know, a friend of mine at another big company who said the same thing.

He said, I see it, it shows up in their cloud bill where some, some project had one problem one time. And the way they fixed it is they run this test, they run this really expensive ping test basically every 12 hours and it shows up as a $50,000 cloud bill at the end of the month, right? So it's like, yeah, it was great.

You made this whole thing continuous, awesome. Now you just cost your company a whole bunch of money. They fixed that because they got the bill, but people are doing the same damn thing with all these other ones and, and, uh, you know, hammering these public repos, right?

So, um, so that's what I would say start with that. Look at, look at how you're using it and how often you're running these things and, and, and rationalize it a little bit better. All right, folks, I think you're hurting here.

The truth of the matter is, we've just all got a little lazy and it's time to be a better open source citizen. Hey brother, thanks for coming by. Thank you.

Thanks For having me. All right. And we'll be back in a minute.

Hey everybody. We're back at the open source summit in Denver with Tracy Ragan and Kate Scarcella, and we're talking about Arties, which is a project they have underway to kind of help us find neuro vulnerabilities and remediate them. And there's a lot of work to be done within DevSecOps flows and continuous integration CDs platforms.

And so if you don't mind, let's start with you. But give us an update on this project. 'cause I think we talk about it all the time on Textron Gang, but I'm not sure everybody knows what it is exactly.

And I also know you wrote an article about LLMs and security, so put it all together for me. Right? So I came back from a sabbatical, and to me it was Groundhog's Day, meaning I stuffed into exactly what I left off.

And although it was just bigger and faster and I thought we are in serious trouble. So it was from there that I started thinking about what was so cool is this group called TIUs. And the reason why is when I started thinking about the Renaissance and how can we make not only cybersecurity, um, consumable because right now it's not, but also make it interesting for people, make it fun, make it, um, just really fascinating.

0. 0 that was kicked off in 2020. 0.

So how do I bring this all together? Well, this really cool group called orus, which from Abraham orus was one of the first, um, you know, scientists really to bring all these different other, like a geographer and a cartographer and everything else together and really did sharing, which from a cybersecurity perspective, we are horrible at sharing. We do the antithesis of sharing.

Um, but the bad guys don't, the threat actors, I mean, they share, there's like, Hey, I have this malware, you know, $3,000, 24 by seven support for us. It's like we, we, we sort of tighten our reins. We make it really as a cybersecurity architect, we make it super hard for, um, for people to do their jobs and let's, we wanna change that up.

We talk about Orillia, but we never explain what it is to people. I talk about Orillia, we're gonna send that to you as like one of the things we should talk about In The future Case meetings. Yes, absolutely.

So explain for the folks watching this, exactly, what is this Thing? So Orillia is an evidence store that sits on top of the CI/CD pipeline. And we gather two real, we gather a lot of different types of data, but two very specific pieces that help us solve the problem that Kate's referring to.

We, we take an sbo, a software bill of material report. We version it as soon as it gets created. If it's not there, we generate one using sift, then we go and we watch the deployment.

And when the deployment occurs, we're gonna pull information from the log files and say, these are the end points it's being installed to With that information. Then we constantly synchronize with OSV Dev and we say, Hey developer, you may have found vulnerabilities pre-deployment, but now you have them post-deployment. So we're identifying the threat landscape of post-deployment vulnerabilities.

And what we're beginning to work on is going from that reporting to auto remediation. Where what we do is we say we know exactly where the repo is. 'cause that's one of the things we gather.

And we can have one vulnerability that's impacting 500 repos, which means there's probably 500 package managers that have to have an update to the pinning of the version of the package that they need to consume to remediate. We wanna go out and find all of those packages, remediate them, and create a pull request for critical and high risk vulnerabilities running post-deployment. Who is actually approving the remediation in that model?

'cause there's been this long running debate and um, you know, the security people are like, we could just automate the fix ourselves. And when developers are like, no, you're gonna break my app and we are in this infinite loop. So is it the developers that are gonna go back and auto remediate the situation or who's gonna step up and kind of and own it responsible?

Yeah, We were just talking about that actually. Well, right now the developers go and open up every single one of those package managers and eventually they have to fix it and then they create a pull request. Yeah.

So we just wanna get rid of that toil. And the other problem is, is noise. We have a lot of noise right now coming through in, in vulnerabilities like tools like depend bot, it'll tell you there's new vulnerabilities.

It may have been in an SBO that you've had, and it's gonna report on all of them. There's gonna be 40,000 of those. There's a hundred vulnerabilities a day and nobody really knows if it's actually running or not.

It's just in an SBO that's in your repo, it may be deployed. So we wanna cut the noise down and just focus on this high risk. So explain to me this little bit though.

'cause you were talking about it and saying, well, the developer may have discovered these vulnerabilities, but then they showed up again in a repo or later in the, in the lifecycle. Why does that happen? And how do I kinda get in front of that a little bit so that when I do ship left, I'm actually fixing things and it goes all the way through the lifecycle Because they're discovered new every day?

Yeah. And the same exact stuff that you just scan. So it's a difference between dynamics, uh, detection and point in time detection.

When it's in the, when it's in the CI/CD pipeline, you do a, you do a static analysis and oftentimes you'll do a dynamic analysis at testing. So it's all good, everything's perfect with the world. Tomorrow you deployed today and tomorrow you found that something now new was discovered in that particular package that you just deployed.

That's what we wanna focus on because that's where it matters most. That's where the threat is the most, is when it's actually running and we don't know about it. So these are all new quote unquote zero day vulnerabilities.

They Are zero day vulnerabilities. Got it. But they have a but, but we're gonna go look for the mitigation and we're gonna either create a pull request to push it through, or we're gonna create an issue that says this has got, uh, breaking changes.

So you're gonna have to fix your code. So we'll create an issue to say it's here, it's critical. It's actually running in your environment.

Either you have a fixed palm file or you have a issue that says these are the mitigation steps you have to take. And That comes back to the issue where developers are always telling security people, you know, no, that's not internet facing, or it's not in my code, or it's not running. And then they stop listening to the security people 'cause they're like, It's just too much noise.

I don't think that they purposely wanna stop listening. There's just so many. And you know, most of the policies now say you should have zero vulnerabilities.

We're not gonna, we're not gonna achieve it. Let me come back to you when you're talking about LLMs and I cannot help but wonder if we're, are we as just incapable of learning? 'cause it seems like with LLMs we're making all the same mistakes over again that we made earlier.

We are, I mean, the exact same vulnerabilities, right? I mean, we're poisoning. We can po poison the, the models just like we can poison, uh, the database.

And, and we are, and that's what is so concerning. What I see, and I feel like we really need to, to look at the tools that we have, which is something that we're doing within our sig, um, is actually looking at this, you know, which tools are really showing the vulnerabilities that are there. And at the same time, I almost believe that we need to, to take a pause.

And I know that that seems like absolutely crazy. Like how do we take a pause? But I was really thinking about like, what type of analogy would be good about this?

And right now I feel like if we're looking at baseball and a heavy hitter comes to the plate, we are all in the infield. And you know, and, and we're not even like we're chasing the ball. We should be able to position ourselves when we see a heavy hitter and we may not be able to catch the ball, but we should be able to understand that it's coming.

And I would like us to fix that. And I think that that's one of the things that I'm doing with, with Tracy and the people at ORs, uh, is really looking at trying to get ahead of this threat. Because I mean, they're taking LLMs and making them literally these attack vectors.

Can you imagine that? You know, this, you know, and, And the problem is that that leads to an AI agent and now I can take over the entire a EI agent, which is a workflow, right? It's not just like a small little vulnerability And how do you feel that loop?

It's really hard to kill the loop. Like if it gets in the loop, I mean, to to stop it, it's a hard thing, right? So, you know, we need to really think about this as a person who's already been through this.

It's, um, we're almost repeating the same things. We're we're getting some, some differences. Like when we're thinking about how we're, we're looking at getting rid of the noise so important because I feel like we are chasing, we're just chasing we're we're not being strategic.

And I think with this, we're, we're taking a step back saying, okay, let's not chase everything. Let's go after what's critical and, and address it so that you know that we can be more secure. Right?

Do we have it in our heads that the, the thing that the data scientist is building is somehow different than what a software developer does. And as such, we're creating like yet another gap in our little happy ecosystem. But it actually is the same.

It's code at the end of the day. It Is. And if you look at the threats, it's the same threats that we've had.

It's like literally the exact same, same vulnerabilities, same back doors. You know, we had back doors back, you know, 20 years ago. We still have back doors, you know, so it really is it, to me it is the same thing.

And I, I really am hoping that we can, you know, first number one, let's invite people to our sig at, you know, that we have happening. Um, And she's talking about the CI/CD cybersecurity sig, not the ortel open source project. Yeah.

So, which is within the Continuous Delivery Foundation. But they both work nicely Together. They work, yes, they Do.

Yeah. In tandem. I mean it's really, it, it's So, so follow that up.

How do I actually get involved with that? Because more often than not, I talk to people all the time and they're like, yeah, I'd be interested. But then they have no idea where to begin.

And then, you know, they roll over and go back to bed. So Yeah, we have a, we have a page, um, Go out to the link, go out to the cd CD foundation, I go to the SIGs and you'll see the ci, cyber security sig and you can join the list, which means you'll get all the meeting notifications and eventually we will release the website. We are, the team is working now on the website.

And what we're doing is we're going through all of the secure software development framework, S two DF, and we're associating every, we're looking through every task. This is a hard, it's a, it's actually a hard project to do. You go through, we're looking through every task and we're identifying within those tasks, if it can be solved through the DevOps pipeline, using an an open source tool.

That's what we're working on. Can we maybe use AI to help cure our problems a little bit here? I mean, Well that's what we're, that's what certainly we would love to do.

And you know, on that other question you had, there are now AI SBOs, so AI SBOs, we, we orillia will need to start consuming those as well. 'cause it has what I think is a very important part of the puzzle, which is the version of the LLM because it's the version of the LLM that's gonna allow us to detect that that version has a vulnerability in it in the same way as an open source package. Right?

So it's all parts is parts. Yeah, parts is parts. And what we do is we assemble the parts together.

We create what Steve likes to call a digital twin in a, in a database environment so that we can, we can, we can report on what's happening in real time on those end points. 0 human machine teaming, we've come a far away, we've come far, we've, we've advanced, we've done well sure. Do we still have some of the same things happening?

We do, but we're learning, you know, and, and we understand. We literally understand what we see. We've seen it before.

Now I think instead of chasing this, we can step back and say, okay, we've seen this before. We know what's coming now let's actually do this. Right?

So set up a play, we're gonna set up a play for it. So depending on the day, the glass is either half full or half empty. Yeah.

And in the sense that it's half empty, it's, oh my God, there's a lot more at risk here for LLMs on the half full side. More people seem to be talking about this and we're having these conversations earlier. Maybe It's, it's phenomenal, right?

We're not putting our heads in the sand. We say, well, gosh, you know what? We have the same threats we do, but we have faced these threats before we know them.

So thus we can, we can combat. We, we have the, we have tools, you know, we just have to implement them. Smart.

And we also have to take things off. I, I mean, you know, we can, everything is not on the developer, right? I mean, it shouldn't be, not everything should be on, on, on that.

The data scientists. We need to be more collaborative, which is also one of the things that we're trying to do with our group. I mean, we can't just shift everything left and take the fix.

No, because they can't do what they, they're not psychic. Mm-hmm. This is the problem.

Developers are not psychic, so they don't know the vulnerabilities that haven't been reported yet. This is true. And it looks like the bad guys are spending more time trying to crack these LLMs.

Right. A lot more research. There's a lot more vulnerabilities popping up.

Yeah. That are new. And differentness somebody talking about a new novel technique almost every other day, 40,000 is predicted for this year alone.

Wow. But I don't feel like they are new and novel. I mean, I almost feel like they're doing the same thing.

It's like, it's really like rinse and repeat. And so we understand it now. We just have to do it right this time.

I don't call it new and novel. No one will pay attention. They'll be like, Hey, I found the same old problem again in another Yeah.

Or in the same package. Just edit it out in a different way with Machines of humans. Yeah.

Well, let me ask you this stuff. It still feels like it's gonna take some sort of crisis involving an LLM and a security breach and some event to get everybody kinda squirrelly focused on this. And is that just the nature of the game?

And you Know, we, you know what? We, it logged for Jay, we woke us up and we all went back to sleep. Right?

We're gonna still work on it though. And you know, we, it, it just needs to be automated. Some of this stuff just has to be automated through the DevOps pipeline.

It, it, we have to have a better conversation between security and DevOps is why I'm so glad that she's on the, the Orillia team because she's a security professional talking to a bunch of DevOps geeks. But we need to automate it so that it, when we do find ways to fix these pieces, we're making sure that the correct tooling is in the DevOps pipeline. So it's DevSecOps and, you know, I'm all, I'm all about, you know, disruption and I totally believe that we are at a point in time that we need to disrupt how we do CI/CD so that we can more easily add SBOs, for example.

Uh, less than 50% of companies even have an sbam generation step, which means that they're, we are way far behind the eight ball when it comes to being able to actively find these issues that are running in production if they don't even have an SBOM. So we got, we have a long way to go. And I believe that the way we write CI/CD pipelines with scripts, and you know how much I hate scripts mm-hmm.

Totally stops us from evolving the DevOps pipeline to be a DevSecOps pipeline. She's gonna have a new nickname called Script Killer, but that's not, they know that's an entirely different show. Anyway, guys, thanks for coming by.

Hey, we've been talking about bridging the divide between security and application development for as long as I can remember. And you know what? It's happening right here.

Live in front of your eyes. We'll be back in a minute. Hey everyone, I'm Alan Shimel of Techstrong and welcome to episode one of Control Alt Deploy.

Control. Alt Deploy is one of our newest shows exploring, uh, cutting edge and everyday topics in DevOps. It is, uh, sponsored by our very good friends at OpenText and we're very happy for their sponsorship and participation.

Today's episode is Agen AI in DevOps the next stage or just more hype? Well, that's a loaded topic and we're gonna have a lot of fun. Our, our panel for today is myself.

And then let me introduce you to our guest, first of all, joining us from Ottawa, where she just got back from, I think being in Europe. She's one of the, uh, leaders of the Canadian DevOps community and known in DevOps communities around the world. My friend Garima Boal.

Hi Garima, how are you? Hello. I'm good, how are you?

Very good, thanks Karima for being here and then joining us from Israel today. Uh, she's from open tech. She can tell you a little bit more about what she does there.

Tali Levy, Joseph. Hey Tali, how are you? Hey, how are you?

Thank you. I'm very excited to be here and talk about iGen AI in DevOps. So Absolutely Tali.

Just quickly, uh, tell people kinda where, what do you do at, uh, OpenText? So I'm heading product and engineering within OpenText within the, uh, application delivery management, so-called DevOps business unit. Very good.

Okay, let's jump into it ladies. So, you know, you can't walk five feet in tech without tripping over AI Today. Everybody has an AI story.

Everything is being influenced by ai, disrupted by ai, or at least, so the story goes, I don't, you know, there's, I think there's definitely a gap between the story and reality a little bit. I think reality will catch up eventually, but certainly the story seems to be way out in front. Um, first it was generative ai, but you know, certainly this year the buzzword is agentic ai.

Everybody's making agents and everybody wants to manage all these agents. And, uh, how is agentic ai, you know, uh, influencing or or disrupting DevOps? Karima, I'm gonna ask you if you don't mind to kick off, what's your take?

Is it just a lot of hype at this point where, where's rubber meet the road? So as you know, I start from the basics and the fundamentals, right? So where, what is our DevOps story history to mindsets that DevOps is about flow, feedback and experimentation, right?

So what we are doing at this stage with, you know, agent take AI is experimentation, a lot of experimentation, which will result in flow improvement. And we will get feedback, and then we will probably have more systematic overview of, you know, agent take AI systems. And again, we can talk about what agent take AI means in terms of DevOps, what capabilities we could like expect in the experimentation phase and how it'll improve the flow and feedback for the community.

But I mean, again, as you said that it can, it could be perceived as a next step towards, you know, uh, the injection of agent tech AI systems in DevOps, which is more promising than generative ai, to be honest. So I'm looking forward for that. And tally, I think I would look for your comments because you are coming from product and engineering domain, probably you have a lot to say here.

Yeah. A a and I think, you know, if we look at ai, right? You know, all the, all of the hype we've experienced so far, you know, it's about, like, I look at it from several dimension.

One is the experience and the way we interact with applications, right? And this is more on, you know, instead of in, you know, I would say clicks. Now you have conversation with data.

So this is one thing. The other thing is automation. And I think automation was, uh, especially in the first early days, was about we define a task and we identify and basically build an agent to perform this task.

But it was very, I would say, goal oriented thing, right? And I think with identical ai, we take it to the next level because it's the ability, you talked about flow, this is exactly it. It's not just about one task, but it's more of an ab abstracting, I would say, goal that we give to, you know, uh, to the system.

Um, like, you know, identify risk and basically generate the tasks that are, you know, that should mitigate the risk of the code we just committed or of this release. So it involves several tasks and several areas where you should kind of, not just automate, but operate, you know, some kind of flow and thinking. And that's the ability for agents to interact with each other and to operate whatever needs for a certain, you know, task or I would say value to be, uh, delivered.

So I think that really takes us to the next level. And I think the sky's the limit because, you know, when we talk about digital workers, you know it because it's always about dev to ops and the wall between them. I think in the future, it will all be, you know, digital workers that will interact with each other, right?

And human will kind of architect this, you know, help to architect the flow. But, but yeah. Fascinating.

I totally agree. Experimenting, we're still experimenting. Yeah.

That, and I think that's the important thing. If we're gonna have one theme for today's show, Garima, I think you hit it right off the bat, which is, we're still in the experimental phase. Talia, I don't disagree with you in the future, I think all of those things are possible, doable and will be done.

As I sit here today, I see a lot of experiments. But I, I'll tell you something. I read an article over the weekend, uh, uh, mark Benioff from Salesforce, and granted Salesforce, you know, with their agent force and everything else, is trying to be one of the leaders of this move to Agen ai, right?

But he's claiming, you know, something like 50% of the work being done in Salesforce now is being done by agents and AI that AI is writing, you know, half of the code they're using AI is checking for the quality and security and testing using agents and stuff. Now, I'm, I'm not saying he's lying, and maybe, maybe, maybe that is really the case in Salesforce, though. I think if you press them on it, he'll say, that was for very distinct experiments, not necessarily across the board, but I don't think we're there yet.

I think for most people watching this show, it very much is still aspirational, inspirational, even, but not real today. Karima, you, you talk to people all over the world with this, what do you think? So I would suggest, uh, this like two-way conversation that from an enterprise perspective, what are the positive value add?

And I start with that because I'm a community leader. I kind of, you know, think about, you know, what agent AI is contributing to this ecosystem of DevOps. So the first and the foremost thing is that it's building collaboration with data scientists, mops engineers, you know, they bringing data into the mainstream, right?

So that is one of the biggest value add you would see when we talk about agent care systems, right? Then comes, you know, system thinking. You know, we are talking about agents working together.

So there is agent, there is environment, there is protocols, right? So these agents will work together. So there is a larger need for community to come together for systemizing this kind of, you know, agent tech or, you know, uh, system architecture for example, right?

And, um, if you think about how these agents will communicate with each other, so it will also largely depend on how standardization of CI/CD walkthrough will happen. How standardization of OpenTelemetry or telemetry would happen, right? In the system, and so on and so forth.

So there is a lot of, you know, positive value add from how we see the DevOps, you know, evolution happening at as we speak. I also would also, so like to highlight that integration of AI aware observability, for example, is a greater, you know, value add when you think about agent tech AI assistance, right? So there's a lot of, you know, work which needs to be done, and community is striving for that work.

And there's a large change, which will happen from an observability domain perspective, because if you think about systemizing or productizing this AI agent systems in real time, then you would need common language, common protocol standardization. You need, uh, uh, semantics. You need a lot of, uh, quality data, right?

How do you build feedback loop as well as you would need telemetry, right? So these are all positive side of it. Now, when we talk about challenges, and you know, obviously, uh, you know, uh, these claims, which you, we are talking about, there are two sides of the coin, right?

So if you have a large legacy, for example, so I cannot claim that, you know, agent A care systems would help be helpful, and I would be able to automate 50% of my workload because I have to deal with legacy systems, right? If you're an AI native organization, for sure, you know, you have an advantage. So that is another thing which we have to look at.

Then o other challenges, like we have seen the debate in the community about MCP and IT way, right? It's not new. So this also needs a lot of, you know, evolutionary thinking and community to come together.

Maybe there's no one way of, you know, having a protocol or semantic language, all those kind of challenges needs to be nailed down. And I can go on, uh, with other challenges, but I think I, I also want to hear from tally, like what the, Yeah, no, I wanna hear from Tali too, because tally, not to throw it on you, but you, you, you are helping to run a product team here, right? Engineering, what, did Gerima laid it out?

What does it mean to you? I need a lot more than few minutes, but Yeah, I'll try to, but, but, but I wanna relate to what Karima was saying about the data. This is so important because the inputs or outputs depends how you look at it that you get from AI are as good as your data.

And in DevOps, we have a lot of fragmented systems, right? You know, uh, sometimes an average DevOps could, could, you know, include something like 36, you know, uh, either homegrown or commercial tools. So I think the first thing, if you really want to, um, extract the positive out of AI in general, and iGen AI for sure is the data, right?

You have to make sure that the data is standardized and consistent in a way, like you call it data lake you, but that you can extract the value, right? Um, so, so this is a very important thing. And there's, you know, one thing I wanna say about, like, it's very important if, I know a lot of, you know, numbers are thrown into the air, you know, of the, the productivity and, but it's very important that companies would, you know, make sure to define what they want to achieve, right?

What are the business goals? Is it to improve engineering productivity, shorten cycle drive, higher quality and control risk governance? I mean, there are a lot of, you know, I would say business values.

And to apply or deploy iGen, you have to understand what you really wanna get out of it, right? And by the way, there is a whole conversation about how you measure, right? And you probably know it, Karima, what are productivity metrics and may maybe in a, in another episode.

But, um, but the one thing that is very, um, certain focused first on area. So for example, in our product, uh, we focus, um, you know, the first bit that we've released is basically on quality of and testing, understand the risk of a current release based on historical, right? But also try to predict from historical patterns to the future.

But also, you know, we have a whole, you know, parameters that you can identify which test you need to run or which test you need to generate based on the code that was changed, or the feature that should be tested. Um, and then, you know, you can say, and then you, it's, it's easier to, um, to basically measure this. So I would say, you know, conquer the world, probably not, definitely in the first few phases.

Focus, identify the flows or the areas you would like to, uh, um, you know, uh, deliver value on. And basically, you know, uh, define the flow. And of course, you know, the prompt engineering everything, the whole communication between agents to agents, and then be able to measure, because this is, I think, the important thing so you can scale, um, otherwise you will end up in a chaotic environment of agents that you don't have any control of what you basically deliver.

And I think that's the, that's the big fear of, of a lot of company and the trust, you know, circle that needs to be created here. I i, I wanna jump in here real quick. So, Tyler, you said something, Garima mentioned it too, about agent to agent.

So there are protocols that are growing up before our very eyes around this, right? MPC, all of a sudden, you never heard of MP C3, four months ago. It seems the last three, four months, that's, it's become like a defacto standard MPC.

Now, last week at the open source summit, the Linux Foundation, AMA announced a new project called, I think it's called agent to agent, right? Eight two A, Google, Google, uh, uh, contributed their to a protocol. Microsoft's involved, lot of big, lot of big companies involved in it.

So the fight is on, not the fight the competition is on for what is the standard for agent to agent communication protocols here, right? How, you know, for me, I could stand on the sidelines and watch and see who wins. Ali, you've gotta make a bet.

You bet on them all. How, you know what, and I don't mean to put you on the spot, but what is OpenText? Are they looking at MPC?

Have you looked at this agent to agent, right? What, how do, I mean, to me, this is more like APIs talking to each other. Exactly.

Yeah. Yeah. And, and, and I think, I'm not going to touch on specific, you know, frameworks, but I think there are many out there.

But I think it goes back to what I said before, it's understand what you wanna do and how you wanna do, and what you need to deliver to your clients. And based on that, you decide on the framework. You have to be flexible though, right?

Um, and I think that's the, that's the big thing. You have to build it in an agnostic as possible way, because the, the, the environment is very, or the reality is very dynamic, and all of a sudden you get frameworks that can do this and can do that, and you have the other frameworks. So, you know, everything we do, um, we do in a way that we can, I wouldn't say plug and play like LLM, but, you know, build it in a way dependent as possible so we can switch and be agnostic to the frameworks.

Um, but yeah, we're, we're experimenting as well, by the way, and we're working with our customers, um, on, on the different use cases to be able to understand. And of course, we're working with vendors like SAP and Salesforce and Oracle to be able to connect with what they're using, whereby the way in our product we integrate with, uh, copilot, right? So I, I think, you know, uh, you have to be, I would say, embraced of the ecosystem and use as I would say, generic agnostic way as possible.

So you can, I would say, talk and interact with, uh, with the ecosystem. Garima. What, what if, you know, you, you get to talk to more vendors, Garima right in here.

Is it a good thing if the industry sort of comes around to MPC as the, you know, the, the, the framework of choice, the, the protocol of choice, or, you know, something the Linux Foundation backs, or what? I mean, in my mind, it's always better to have a standard than many standards. So how standards are created, I mean, uh, we go to the basics, right?

So standards are created by community, right? So how well this is received by the community and the community, what it looks for is like the operational control, right? So if you are having a communication protocol for multi-agent deployment, and you know what important things is, how observable your protocol is, how standard data definitions you have, what kind of, uh, community backed, you know, uh, proposals you have, because, you know, uh, tally also mentioned that remaining flexible, right?

So how do you embed flexibility into your standard protocols is by in inviting community contributions, right? So I am like an open source advocate as well. So I lean towards, you know, if, uh, there is, uh, there is room for discussion and there is room for standardization, involve the community, right?

Involve the community from the, uh, the very first aspect of data semantics. How do you exchange, uh, you know, communication, uh, multi-agent protocols? And most, so one, one of the most important aspect is security controls, right?

So how your protocol, uh, you know, addresses security concerns. Because think about this, in a multi-agent system, you would have, uh, intent driven, you know, uh, uh, decision making. Now, these intents should not conflict with each other.

So there has to be guardrails, right? So all this needs to be kind of, uh, developed, or these kind of things needs to be kind of, uh, sim ified, right? So these are things which, uh, would lead to standardization.

So history reminds us OpenTelemetry, Kubernetes, how they become like the de facto standards, you know, through com, community contribution, right? So I would say that, you know, there is a lot to be done in the coming months, and I feel that, you know, there might be a situation where you will make some decisions in the community that you, this is the, the standard way forward, or this is outlook. I mean, I, I see a lot of vendors embedding MPC server into their bro, into their product.

But to your point, garima, look, if something, like someone like the Linux Foundation's gonna get behind a to a, that's a place where companies like an OpenText and an SAP and a Microsoft and a Google, and, you know, name the big company, they could all Cooper cooperation, if you will, right? But cooperate for the good of everyone running low on time. I, I wanna come back to a, a, a topic and, and make sure we we're crystal clear on it.

com in 2 20 13, 12, 12 years ago. One of the founding principles of DevOps, not founding principle, but one of the big pluses with DevOps was automation. We're gonna automate so we can do faster, take humans out of the loop, go faster.

To me, the absolute distinction between just, let's call that regular automation and agent AI is not the automation that's table stakes. It's the autonomy. Yes.

Right? The ability to make decisions and do things in, in an automated fashion without a human in that loop. Now, my experience in technology over 30 plus years is some people that scares people.

That scares people. And, and then there's an adjustment before they'll, you know, kind of, they, they, they make their heads so tight that their fingernails dig into their palms. You know what I mean?

'cause they're holding on for dear life. When do you, do you think we're ready? Are humans ready for that?

Kareem, are you deal with humans, the humans of DevOps, are they ready? If we pragmatically decide to onboard to these technologies, yes, we are ready. Because, you know, we'll have to think about, you know, how much we can expose our system at this point in time.

This technology is unsubstantiated to a certain extent, right? So if you think about C-I-H-C-D workflows, if you wanna inject this, this kind of a technology into that, pick and choose the non-critical systems, you know, make your goals in a way which, uh, which ensures that you have return of investment for these kind of technologies. As Tally mentioned, you know, uh, productivity, what is your strategic goal?

You know, if application productivity is, or efficiency is one of your, like, leading goals, or, you know, you, you only hit on testing cycles, you know, you wanna cut down the lead time on testing cycles, make sure that you, you have like pragmatic goals, have systematic onboarding, ensure observability is in the system, and you have security controls if that is there. And of course not human not, not human in the loop, human in the lead. Because at experimental stages, you need to have like these people who can ensure that this experiment, from this experiment, we learn and we take this technology forward.

Holly, what do you think? What are you hearing? So, so I wanna add to what Grima was, was speaking about, I think for any change, and we saw it through the years, it's not just the technology.

I think the technology is more than ready to be implemented and deployed. And of course, you know, we have the validation points and everything, but a lot of it is the people, and people are still resist. I, we see it.

I don't know if it's like hesitation because okay, prove it to us, right? It's a, you know, trust issue, or it's also, you know, I would say in a way, resisting, resisting a change and such a big change because what it'll mean to my job, right? Um, if I was, that's, You just hit the nail on the head.

What Does it mean? Nobody like to mean To my job? Nobody want likes to talk about it because everybody's are saying we're embracing it.

We do it in a lot, in, in many aspects, the management is like, okay, do it. Do it. We wanna, uh, we, we wanna see cost reductions and all of that.

But, so I think, I think humans okay, people, it's culture and it's mindset. And I, I don't think it's about replacing humans. I think you said it, Karima.

I think it's about taking it to a higher level in terms of what we can do and what we can leverage the humans for, right? And humans, yeah, they're not no longer, I would say maybe like manual testers or even, you know, the ones that write automation, but they will architect, you know, the flow. They will be, maybe this is like the engineering aspects.

So we all talked about it, but in the past, but then we became, you know, um, doing this and doing that and doing that. So I think that it'll open, uh, their minds to do other things and to be able to improve in other areas. I, I will, I mean, there are, you know, specific things that yes, you know, AI will, will do things, but again, it's about, I would say adjusting, not just replacing.

Um, but, but I think you're right. Um, we see a lot of resistance there, and I think we have to overcome. So it's a lot of, I would say the psychological aspect of this revolution.

Uh, we now see, and That, that's gonna take time. You, you can't rush that Right? Credibility, uh, to, uh, and, and to, and to say we're safe, okay?

The good people, the ones that you know, have the, the, the business context, the data that, you know, human will have a major role in this revolution. This is what I think. It's just, but There's always the imposter syndrome, right?

People, they don't want to admit it, but you feel like, am I one of the good ones? Yeah. Am I, am I safe?

Anyway, It'll get, it'll get us to higher bars, right? To, to, to, I hope I believe that everything I've never seen, that's how it works. But it, it can be scary.

Look, I'd love to, we're going to talk about this more, but unfortunately, we're outta time for today's episode. Tali Garima will bring it back. We'll bring some more friends that we'll talk more about this, because this is gonna be the story of not just the rest of this year.

I have a feeling this is gonna be the story of the next couple years and, and it's gonna be something we need to talk about. But we hope you've enjoyed this first episode, a peak into what we're gonna do at Control Alt Deploy. Stay with us.

We have more episodes coming. G Vital, thanks for joining us. Thank you to fintex their sponsorship.

This Allen Shimo for Techstrong. We're out. Hey everyone.

Alan Shimel. We're back here live at Platform Con Day in New York City. Of course, this is just the in-person day of a week long virtual event that's going on.

com. I forgot how many speakers and sessions there are, but there's a lot. And I encourage you to do so.

Let me introduce you to our next guest. His name is Sivan. Achi.

Yes. You got this right. A neighbor of mine from Fort Lauderdale.

We're both up here in New York. Um, Silvan, welcome to Tech Drunk tv. It's nice to have you on here.

Thank You, Ann. Um, not everyone watching this is gonna know who you are. Tell them a little bit about yourself.

Yeah, so, um, um, I'm a former software engineer, was an SRE for nearly 10 years. Um, then I was an entrepreneur, got an education training software engineer, and now I'm, uh, heading the root AI labs. Um, so for this, we don't know, rootly is an incident management and on-call platform.

So we're competition to PagerDuty, uh, okay. Which, you know, I think you probably heard of. So we help businesses to manage their incident, and we are used by, um, you know, small companies and large businesses like Nvidia, Figma, Cisco, LinkedIn, and so on, right?

So we, we help, uh, large, uh, large company, um, and their operation team to make sure that their incidents are, um, handled smoothly. And my role, uh, truly, uh, truthfully, uh, is to lead these AI labs. And the AI lab is a community led initiative where we, uh, work with team of fellows.

So, um, we have people who are tech leader in the industry. We have, as the head of platform engineering at Venmo, the former head of ai, Twilio and research students. And we work with these folks to really understand what can AI bring to the world of readability.

And it's applied ai. So we build prototypes, open source tools, we run, um, research, and we write report, and we share all of this open source, um, on our GitHub with the community. So really the goal of this lab is like, how do you use AI for SRE or platform people?

Excellent. So this then probably is a good audience for you. Yes, It is.

It is. Um, you mentioned you were on a, uh, a panel this morning. Yeah, So we were on the panel with, um, Google search work, um, and, uh, Nvidia.

And the goal was really to discuss, um, what's, uh, what's hyped with AI and what's reality applied to platform engineering, right? Like, uh, I think we hear a lot from, uh, the executive and CEOs from, uh, uh, model providers who are selling a GI or fully autonomous system. I think we all agree that we're not there.

And, um, I think especially for practitioner, which I think today is a lot of practitioner, they really want to understand what's true, what's maybe not there yet, and how can they really apply this in the, in their day to day job. Yeah. I, Savannah I think one of the big problems, especially for practitioners is every day it seems there's a new news story that some big tech company is doing a layoff and they're laying people off 'cause they're replacing them with ai.

Yeah. I think as we sit here today, very few people are actually being replaced with ai. Correct?

I think what it really is, is that these companies overhired Yeah. During COVID and before, correct. And they need to cut back.

They have too many people. And rather than just saying that, they kind of blame it on ai. Yeah.

And so AI gets this thing of, oh, it's taking right. These people's jobs. Yeah, Yeah, yeah, Yeah.

You know, New York State is now setting up a tracker, jobs lost to ai, you know, and, and, and so you talk about separating reality from a hype. Yeah. To me, that's a big, a big issue here.

Now, I'm not saying that AI may replace people's jobs someday. I'm not saying that AI can help us or cannot help us. Uh, to me today, AI is more of a copilot than a pilot.

Mm-hmm. Does that make sense? Yeah, it does.

And, and so I wonder, now on the other hand, I'm talking to you, you run an AI lab. Yeah. What do you see?

What do you think? Yeah, so, you know, I think there are different type of AI labs. Uh, if you look at, you know, the large stakes who are building these, uh, models, you know, these are like more like research, uh, researcher and PhD, and people who are like building all these LMS at ru we are really taking, um, a different stand where it's like really applied ai.

So we use this tool to see how we can empower current practitioner, augment themselves, do their job better, and, uh, faster. And yeah, I agree with you. It's like any tech new technology or tools, eventually it may replace some jobs, but maybe it's for the good.

You know, like let's say before electricity, you had people going in the street and lighting the candle, uh, you know, for, for Street Lightning. Like, we don't use this anymore, but maybe that's a good thing. Um, so for instance, um, as shortly we are really focusing on incident management, right?

That's, uh, what we are about. And what we found is that you can really use the AI to help, uh, operation team to spend less time on managing incident because that's not something you want to do. Right?

Um, so I will share two main use cases where we saw, um, uh, you know, how this technology can help. One of them is incident, uh, triage and filtering, right? You have all this alerts coming from a lot of tools, and you don't want human to be looking at this, right?

So here, LLMs can do a great job at like helping to filter and cut through the nose. And the second thing is, uh, root cause analysis. So when you have an incident and you need to understand what's happening, what's wrong, a human may take 10 to 20 minutes to like, gather all the graph, look at GitHub to see what were the last commit, maybe go on Slack and see what conversation they were perhaps on the project.

With LLM, you can reduce this by like 80 to 90%. So instead of spending 10 to 20 minutes investigating an incident, it can be done in like one to two minutes. And that's a huge, that's, that's a factor of 10, right?

It is. And, and I think that is, at least in the interim, that 10 x is the goal. It is 10 ai, 10 x you.

Yes. And we've been speaking about this 10 x engineer for A long Time. A long time.

It's finally coming. Absolutely. Absolutely.

So, and it's finally coming through. You know what we didn't mention Rootly. What's the website?

com. com. Yeah.

And, uh, the, the platform helps you. Basically, we sit at the center of your incident response, um, uh, efforts. So you connect all your monitoring and logging, logging tools, uh, to our platform.

So your Datadog and Sentry. And, and we will help help your three team to orchestrate a response to that. So we will create for you, um, a team or Slack channel, uh, spun up a Google meet or Zoom room so people can, uh, share.

And then we embedded, um, a bunch of features that will help you to, uh, do the job faster. For instance, we have a bot that will listen to the conversation on Slack and audio, you know, and then if someone join an incident, you have a bot that you can ask, Hey, what's happening? Can you gimme an update?

Um, once an incident is solved, you have to write a postmortem or incident report. No ones likes to do this, so we automated this for you. Um, so yeah, it's like a very, like, basically when somethings breaks, SREs go to I love it.

Ban. It was a quick 15 minutes. It was quick.

Indeed. Thank, Thank you, Alan, thank for telling us this. Maybe we'll get together in person in Lauderdale, come into our studio.

Yeah, I'm down. All righty. Thank you.

We're live a platform, ka, we've got a lot more coming your way. Stay tuned. We'll be back in a moment.

Hey guys, thanks for the throwaway here with Cristian Rodriguez, who's field CTO for the Americas for CrowdStrike. And we're talking about the current state of AI security, which on the one hand, we're a lot more aware of these issues. On the other hand, we might not be doing enough about it soon enough.

Christian, welcome the show. Hey, Thanks for having me again, Mike. Every time there's a new technology, we always seem to be chasing after it from a security perspective, and I guess that's just the nature of the beast, but sometimes we're better at it than others.

What's your current feeling of where are we on this journey with this stuff? Because I, I feel like we're talking about it more. I'm not sure anybody's doing more.

So, AI in general is, is driving a lot of innovation across a lot of different enterprises. Uh, but it's simultaneously expanding the attack surface that these organizations are faced with protecting, right? And so, um, a lot of companies are embracing large language models and ai, they're rapidly deploying them, uh, inter uh, inference engines, for example.

And they're, they're, they're setting up these training pipelines in the cloud, but they're often overlooking things like, um, how these workloads are introducing risk tied to like identities and even, uh, API exposure, right? And so, uh, in the field specifically, what we're seeing is kind of the standard, uh, you know, uh, approach to the way that you, um, you know, secure identities, right? We're seeing they're, they're misconfigured and they're being abused by adversaries to access different like models and different logics and training data.

We're seeing a lot of exposed large language models that don't have anything, uh, tied to authentication. There's very limited monitoring. Uh, we're seeing adversaries leverage access to these models to then move from the cloud back onto on-premise.

And so, you know, everyone's kind of rushing to get into, uh, you know, their large language models into production, but most of these organizations are, are facing these blind spots when it comes to, uh, how they're exposed, uh, what type of risk they introduce into the environment and, and even the identities that are tied to these models. Um, and so I think what we've done here at K CrowdStrike is we've, we've, we've really doubled down on innovation to help secure and get better visibility into, you know, all the services that surround those models, uh, and the, the identities as well. I think a lot of folks are just overwhelmed by all the parts here with ai, and they're not quite sure where to get started in terms of securing it.

Um, what's your best advice to folks about all this when they look at this? 'cause I mean, there's a million things that you gotta think about, but what's the most important to get right first? Um, I'd say, you know, first and foremost, you know, runtime is kind of the new battleground, right?

Understanding what's happening in real time outside of just scanning the model, uh, while it's in development. Uh, a lot of the real risk is happening after these models are deployed. So think of, uh, like your inference model or your endpoint, you know, as a production system.

It's, it's just running continuously. And it has to accept, uh, both trusted and untrusted inputs. It all often gives, uh, access or holds access to sensitive data.

Um, and that's essentially making these systems a very big target. And so, uh, we're very big proponents of monitoring in, you know, real time, right? Their runtime behavior of these models, understanding who accesses or who has access to the model themselves, um, what prompts are being sent, and then what type of outputs are coming out of the model.

So that's a very big component of understanding in real time, right? What that runtime activity is. Uh, and that runtime telemetry gives you, you know, that, that in, in the moment attack perspective, right?

And that analysis. And so without that information, without the runtime behavior in real time, you really, you can't respond in real time. And if you're only scanning these models pre-deployment, then you're not really securing ai.

What you're doing is you're securing code when the risk itself is what's happening, you know, at runtime. And so we're, we're, we're huge proponents of, of ensuring that the, your approach is inclusive of, uh, good hygiene around identities, but also understanding what's happening in real time as you're launching these models within these different cloud services. Is the nature of the cybersecurity game changing, therefore, because everything is, seems to be now moving more in real time, and we were stressed out a few years ago, but that may seem downright leisurely compared to what we gotta do now in terms of responding.

Yeah, I think, I think that there are some very fundamental approaches to, um, security as a whole that, that are very relevant now as they were relevant, you know, five, 10 years ago, right? And I think identity has always played as the number one blind spot, and it's very, uh, applicable to ai, right? Most AI workloads rely on cloud-based identities, like service accounts, for example, or, you know, other configurations within your IM roles.

And the, they're often times over permission that a lot of times we see that, um, you know, attackers are exploiting that, that excessive permission or those rights that these these accounts have. Um, and they're rarely monitored, right? And they have control, like as I mentioned earlier, to the models themselves, and they have access to, uh, these repositories of training data.

Some of that data is being commingled with sensitive or unclassified data. And then naturally, the services that surround these AM models around, you know, the, the CSP, the cloud service provider themselves, right? That cloud compute access is also tied to those IM roles or those identities.

And so we've seen attackers use those cloud roles to silently query sensitive models and, and exfiltrate data. They've escalated their privileges and they've, uh, you know, leveraged into abused things like unsecured infrastructure as code, and they've abused federated identities to pivot between the cloud. And on-premise, we've, we actually saw that type of activity from groups like Scattered Spider, for example, uh, you know, over the past couple of years moving from the cloud back onto on-premise.

And so in these AI environments, uh, you know, if we look at cyber as a whole, specific to how AI becomes kind of the new focal point, identity is often a malleable point, right? And the easiest path in is for those attackers to, to take advantage of those identities. It also seems like the attackers are more subtle and they are actually trying to, um, insert data AKA data poisoning into the LLM that would change the outputs in ways that might be hard to identify.

So how sophisticated are the bad guys getting, You know, again, so they're not hacking in, as I mentioned, right? They're just logging in, right? And so once they have access, depending on the type of models that you're using, um, and the type of system, like for example, like rag, right?

Being, being a system where you can start to poison, uh, various repos with data that may not be accurate if you're trying to leverage, um, you know, data poisoning as your, as your intent or as your objective as a, as a bad guy or as an actor. And so that's one approach. The other side of that is, uh, you know, the, the, the impact of AI for an exfiltration point, right?

Ai, AI is kind of the new insider risk if you think about the way that an, that an attacker could take advantage of things like misconfigurations or those identities that I mentioned earlier. And so, um, you know, on our side, we specifically are getting into securing AI and production environments where, um, you know, we can secure any of those critical workloads or, uh, add protection or capabilities that are focused on, you know, the, the amalgamation, if you will, of all of the different services that are dependent, or AI is dependent on these services rather, that surround the cloud, the identities, the workloads themselves. Um, and, and that gives better visibility into things like, um, ai, SPM.

So it's a security posture management component of AI analysis. So looking for things like surface misconfigurations, the packages that are being used by the AI model itself, uh, looking at things like, uh, you know, those permissions that I mentioned, right? That are tied to the model and whether or not it's, it, it's exposed.

So that's one major area where, um, it's so multifaceted where AI itself can be used, as you mentioned, for a nefarious purpose of I can poison the data, but then you can also use AI for exfil treating data, uh, as, as an attacker that's trying to steal something, uh, that's confidential or ip. Um, and then you also have, you know, an, a shadow AI approach, right? It, it, again, it's so multifaceted where, where shadow AI detection, um, helps identify things like unsanctioned or unmonitored models that someone has deployed internally, or if someone's even accessing the more commercially available large language models that can also act or serve as, uh, an exfiltration point for sensitive data, even if it's inadvertent, right?

So think of someone just trying to get their job done or be a little more efficient at their job, and they're uploading some sensitive documents to maybe summarize, uh, you know, some notes from a meeting or some type of financial records in a model like that, shadow ai, uh, while innocent the use of it, and that's very specific use case, it can absolutely act as a point where that sensitive data is gone, right? And if it's a third party model, the data is out there in an ether, if you will. Um, and so having that visibility in this kind of multifaceted view of understanding how you're using these AI models internally, I think is extremely important in addition to the way that even external models are interfacing with your sensitive data, right?

From kind of an outside in approach is also, uh, important, right? So again, runtime protection, you know, for those inference points, um, uh, even having adversary informed prioritization based upon what attackers are using for actively exploiting models, I think is also extremely important to, you know, if, if we have a full visibility and a full view, which is what we offer here at CrowdStrike, is this kind of full AI lifecycle, uh, perspective from code to cloud with visibility across that identity footprint, you know, the way that end users are using AI models, the way that cloud is being configured around the models themselves, and naturally what's happening on the end point, we start to get a better picture on what does risk truly mean to your organization in terms of both AI adoption internally and AI adoption from an employee basis. You know, one of the funnier conversations I've had with folks over the last couple weeks is everybody's kind of cognizant of the need to protect the data, and they're relatively cognizant of there might be some malware that gets injected, but, um, so much of this feels like people are talking about protecting something that's inside their car without realizing that the car can be stolen.

People wanna steal the entire AI model, and they don't really have anything to protect the model itself. They're kind of obsessed about the access points, but the bad guys, these are realize that these models are some of the most important intellectual property any organization has. Yeah, absolutely.

But I, I, I do think though, to, to your point, I think it, it definitely goes back to the data itself, right? Because the model is essentially referencing this body of knowledge and it's, it's, it's doing pattern matching and it's basically creating, uh, using these, these neural networks. It's trying to understand, you know, the relationships between different data sets, right?

Very effectively. And so these models, whether they're something open, usually they're a black box that you introduce into your environments, and then you have to put data into it. And like the model is only as strong as the data that it has access to, and it continuously learns and grows, and you can train it.

And so I think what we're seeing is the lack of proper classification and categorization of data once they go into those models. Or again, there's this co-mingling, there's usually rarely apol, uh, apologize for, uh, there's usually rarely a, uh, a, uh, a policy that describes things like data governance, or we see a lot of enterprises now just getting into data gov, data governance, where they're, they're analyzing where their data is classifying it, and then creating a policy that dictates this is the data that's approved to go into these models. Or they're working with models that automatically, um, exfiltrate or rather automatically hide sensitive data, you know, to prevent things like exfiltration.

And then the other side of that is also saying, well, if we are gonna put sensitive data into a large language model, because let's just say that we're in the pharmaceutical business, then we need to put very, uh, specific research and, uh, patient information into these models so that we can figure out if there's something new we can develop, uh, in terms of like, you know, something medicinal, for example. Um, then you start to, now, now you have to put in controls to ensure that these models, uh, aren't accessible from the outside, that you have proper IM policies that they're, they're almost, you almost have to have a data fencing approach to the way that those models can be accessed and what type of data they have access to, and then, you know, purging that data once you get your outputs, right? So I think there, there's a, there's a multitude of approaches to ensuring that that adoption doesn't lead to data exposure or increase your risk.

And it, it, it goes back to good old, you know, fashion hygiene, right? And ensuring that access is, is properly managed and data is being classified. Who's in charge of all this?

And I'm asking the question, going back to your real time comment, because theoretically, the data science team created the model, the security team is observing it to see if it's being attacked. And if there is an attack observed, then they gotta go back to the data science team to fix it. Well, that takes time, and we don't have all that kind of time.

So is there some other way to think about the way we are organized to defend these things? Yeah, I mean, so, so naturally crosscheck, I'll have to, you know, plug what we're doing with even companies like Nvidia, right? Our partnership with NVIDIA is a really good example of how you can secure, uh, AI at scale, right?

So we, we integrate with Nvidia name and, and NEMO guardrails to deliver this kind of full lifecycle protection, you know, scanning, understanding telemetry, doing the runtime, you know, protection as you mentioned. Um, and so that's all part of the platform. So from build to runtime to the posture management, you know, we built this really great, uh, lifecycle to understanding how to secure AI at every stage, right?

Of, of, of that innovation effort. However, to your point, like who's actually doing this, right? I think a lot of, a lot of these organizations that we're working with have hired, uh, almost like a chief AI officer, right?

Or someone that focuses on understanding the implications of introducing a large language model into your enterprise. And that could be inclusive of someone that helps dictate those data governance policies, for example. Or, uh, helping to, you know, uh, further on, uh, data classification initiatives, um, or even in real time having the ability, as I mentioned, with a platform on CrowdStrike, for example, to say, you know, we're going to, we're gonna take this model offline because it's referencing a package that has these types of vulnerabilities.

So, so the visibility is extremely important. So that, you know, as your data government governance and your chief AI officer starts to create policies and workflows and procedures, they can start to dictate, uh, workflows that say, whenever we see a container, an image with an AI model that has been, I identified within your cloud assets, you know, spun up with a very specific package that is susceptible to vulnerability, or we've seen these IM policies that have been misconfigured, this is the workflow that we introduced to, to mitigate this as quickly as possible, remove that system from being accessible and then, you know, kind of following student to remediation, uh, uh, um, you know, response program. So, so it's, it's, it is a multifaceted, uh, kind of everyone's on board efforts, especially as enterprises start to introduce more AI into their organization.

We, of course, are also all obsessed these days with AI agents, and as far as I can tell, that's just another form of a non-human identity that's being added, but it will be added into the tune of the thousands. So, uh, are we prepared to secure all those AI agents? 'cause it seems like we can barely secure what we are currently trying to secure.

Yeah. Yeah. I mean, it's, it's always a race, right?

I think innovation is, is is very fluid, and everyone is always trying to, you know, embrace the, the next best thing, uh, in terms of innovation. There's, there's so many different business outcomes that, you know, large language models and AI will, will, will emphasize, especially for anything that's revenue generating. But I think it goes back to my earlier comment on let's not ignore, uh, those, you know, kind of standard approaches to securing, you know, the, the fundamentals, right?

Of, you know, your identities and doing continuous hygiene assessments or doing real-time analysis on the fact that a service account that is being used by this model can also be abused by a third party, even programmatically, right? Another application. And so understanding the hygiene of your environment, that same approach that a lot of organizations have today, uh, hopefully right, of understanding the way that their identities and their, the, the posture behind their identities, um, the impact to systems that, that, that include authentications and authorizations into applications like that approach, think of, of that as, as, as the same thing, but putting AI at the center of that, right?

And so, uh, I think it's really widening, widening the aperture of what is good today needs to simply be widened to accommodate the use of ai. And understanding things like identities, the services that are used around cloud compute, uh, you know, the configurations themselves around the cloud services, and then naturally, you know, the data that's being accessed. Those are all very fundamental approaches to the way that you secure ai.

But AI is sitting at the center of, of, of kind of that, that, that traditional paradigm people process technology, right? So, um, so, you know, I, I think you don't wanna change too much, just ensure that you know, you have a good, a good program today and ensure that you're, you're mapping that to, to the AI models that you're adopting. We've been banging the drum now about taking a risk-based approach to security investments for quite a while now.

And I can't help but wonder everything touching ai, it seems to me the risk levels are exponentially much higher now. So is this a whole other level of thinking about what risk is gonna be, or is one wag one said to me, it's one thing to be wrong, it's another thing to be wrong at scale, and well, a lot can go wrong here. Yeah.

Yeah, absolutely. I think your risk-based approach is always a great thing. Understanding, um, you know, even doing things like predictive analysis and, um, you know, CrowdStrike, we've even deployed a, uh, a red teaming program that's focused on just ai.

I think that's extremely important to run through emulations, uh, to understand like real world attack emulations, including things like prompt injection, as I mentioned earlier, uh, output drift, which is a very big, uh, concern or risk that organizations are considering, right? So what, what is my model spitting out and does that start to inadvertently expose sensitive data or some, some type of information that could impact the business if it's leaked? Um, you know, identity chaining.

So again, as I mentioned, can I use this identity to access this model and it's something else resource-wise in the environment, um, those are all going to drive a better understanding of what type of risk these models are bringing into your organization. And I think, you know, having a service like that come in, uh, and give you an objective output on what that risk is, I think is pretty important as well. We know I get the skills and the expertise to do this because we're already shorthanded on the cybersecurity side, and anybody who knows anything about AI is working on something other than security.

So where do I go find somebody who actually knows both AI and security? Yeah, I think, again, I i I, it goes into hiring, uh, an organization that gives you kind of full visibility into the entire life cycle. First, I think once you start to understand that the same investments that you've made into, uh, moving, for example, applications into the cloud and understanding that the services that manage the applications are susceptible to misconfigurations and Im policy issues and excessive permissions and, uh, you know, data that could be orphaned and inadvertently exposed.

I think ensuring that you have the expertise of someone that understands those fundamentals and can apply them to AI as well, I think that's actually pretty tremendous. Uh, and it, it, it puts you at an advantage already for any type of other organization that may have a bit of an immature offering, um, around, you know, that, that standard, you know, identity cloud and, and and point type of visibility. And then from there, it's, you know, hiring, uh, again, consulting, uh, firms or, you know, an ai, red teaming organization to come in, do the assessments, um, hiring someone that can even help manage your cloud and identity and endpoint stack, uh, that's pretty important as well, right?

'cause now you're getting a 24 7 hands-on perspective into what's happening in your env in your environment where there is drift, where there are outliers, what type of behaviors are essentially going to impact the business negatively. And then ultimately, how does AI fit into, you know, that risk model and, you know, how do you start to secure those, the, the, the, the adoption of ai, uh, with within your own environment? And there's some, there's some organizations that we've met with that have a little bit, have been a bit apprehensive on using AI internally just because of the fear of exposing sensitive data.

But there's also this kind of uncontrollable approach to, you know, we have employees that are using, again, the very commercially available AI models that are out there to make their jobs easier. And some companies are shutting it down and some companies are putting guardrails around things like, uh, stripping sensitive data away. So I think, again, even with, uh, in environments that are strapped for resources or they lack resources for, you know, uh, for, for embracing ai, uh, I think that there's a, a, a wide range of businesses out there, including CrowdStrike, that can help you understand what the impact is to your business by introducing different AI models.

And, you know, ai, red teaming service is a really good example of that as well. All right folks. Well, like it or not, the attack surface is gonna expand in the age of AI because, well, the genie's out of the bottle.

I think the only question now is well, might be time for a good old fashioned gut check. 'cause if you're gonna do this by yourself, it may not turn out the way you hope. Hey Christian, thanks for being with Share.

You got it. Thanks for having me again. See you.

Alright, And back to you guys in the studio. Hey folks, thanks for the throne. We're here today with Sean Tyer, who's director of Global Cloud Engineering for Mondelez International, and we're talking about how they are making use of AI in their software engineering workflows.

Sean, welcome to the show. Thanks Mike. It's great to be here with you today.

I'm looking forward to talking about all the fun things we're doing at Mondelez. So I'm not sure everybody knows who you guys are, and yet you are a household name, it's just that nobody knows it under the name of Mondelez, but explain to us a little bit the background of the company and what you guys are all about. Sure.

So we're Actually a, a very old company in many ways under a very new name. Uh, we've been known as Mondelez for about the last 12 years. And all you have to do is walk down the snack food aisle at your local grocery store and you'll encounter many of the brands that you know and love.

We make Oreo, we make chips, soho, all of the Nabisco brand treats everything from Lorna Dunes and Animal Crackers. And we also have a, a widespread chocolate business in other parts of the world, um, operating as, uh, Cadbury in the rest of the world and milk of chocolates. Um, so pretty much, uh, a wide range of snacks and we've even gotten into some active healthy brands like, uh, cliff Bar over the last few years as well as part of our acquisition strategy.

Alright. Every one of those brands is in my house, by the way. I know exactly where they're Well, we thank you for your business.

You are also working closely with AWS around AI agents and Amazon Q developer and a lot of folks are trying to figure out, well, where does this AI agent fit within my DevOps and software engineering workflows? So what did have you seen or experienced so far? How did you guys get started and, and how far along are you on the journey?

Yeah, it's a, it's a great journey that we've been on with AWS we actually have been partnered with AWS for a little over three years now as part of our strategic cloud transformation. Um, I think it's a lot of people are surprised to realize that the company makes, that, makes Oreos does a lot of software engineering and cloud engineering. But I really don't think you can run a, a global business like we do without having a pretty large IT footprint and be looking for opportunities to be innovative.

And AI is a part of that strategy. Um, like many other companies our size and larger and smaller, um, the ai, uh, transformation that's been occurring over the last three years has been pretty exciting in terms of the, the possibilities and a little bit scary in some of the other possibilities. So as we were looking to move forward in AI and make our our progress, we, um, were very interested in a WSQ developer.

And I think when we started with it, it was branded as Code Whisperer. Um, but one of the things we really liked about it was that it gave us the ability to control a lot more of our AI usage, especially with our developer teams and control the, the data that we have within our space, especially the source code and the configuration that we possess on the cloud engineering team could be considered sensitive information. So we started about a year and a half ago bringing that, um, Amazon queue developer capability to our software engineers.

And since then, gone pretty far with it all the way to the point of developing some of our own, um, MCP interfaces for, um, for interacting with Amazon Queue developer and some of our internal systems. And some of my developers right now are working on some Amazon bedrock implementations, um, to tie into some of our other systems and build some, um, some chat models that they can use across the rest of the organization. So in, in terms of our journey, we started off small and and experimental and have looked to grow it over the course of the last 18 months or so into something that we can now turn around and offer to the rest of the company in a smart, secure and powerful sort of way.

Everybody's talking about what are the implications for the future of application developers. And, um, on the one hand, some people will say it's just gonna make the developers more efficient and they'll still be with us, but they'll be in a different kind of role, more of an architect, and more, and much more of the code might be written by a machine and others are saying, you know, eventually the machine does everything, but where are you on that spectrum? I think I'm probably leaning more towards the, we're always going to need people who are really good problem solvers and are able to define problems in a way that they can be solved effectively and securely and efficiently.

Um, the actual work of a software developer or cloud engineer on my team has already begun to change, where we're relying on AI agents and assistants to do more of the work with us and for us. And I think for me, in many ways, I'm seeing my team use these tools to help automate kind of the boring, tedious work, right? Reapply the things that we've already learned.

It's hard to predict. I don't think anyone can, where this is going to go in the future, but I'm leaning more towards the, uh, uh, side of I'm always going to need engineers. I'm always gonna need people who know how to solve problems, how to define them well, and regardless of the tools that they're employing and I'm providing them with, I'm gonna still need those kinds of individuals in my organization.

Are you or have you seen your organization actually not just writing more code, but building more applications and deploying more applications because of AI and maybe doing that in a way that doesn't require a huge army of people? I think where it's probably the most apparent to me because our, our organization has been through a period of growth over the last three years where we've scaled up from a handful of senior engineers to now more than 30 engineers around the world. It's kind of hard to separate how much of our productivity is coming from the growth of our organization versus the growth of ai.

What I can tell you with, you know, a hundred percent confidence is that onboarding that many engineers in that short of a time and having them come up to speed as quickly as they are wouldn't be possible without an AI assistant like Amazon queue because it, in addition to writing code, we're seeing our engineers use this as almost like a a an assistant or a tutor that can answer questions for them. So whereas five years ago they might've gone to Stack Overflow, now they're popping over to the side window of their IDE and asking, uh, q questions about how do I do this thing or explain this AWS service to me. And that level of interaction, that kind of fast loop that we've created of, I need to figure out how to do something and I have the answer for how to do it, is shortening, and that is improving their ability to onboard into our code base and to be effective faster.

So I'm seeing, uh, engineers become productive, contributing members of our team within a matter of days or weeks rather than months, uh, uh, as it was before. Do you think the overall level of burnout will be reduced as well? Because one of the dirty little secrets of software engineering is, is still a lot of tedious stuff that people do, and over time it just kinda, they, they get tired of it and they want to do something else.

I don't know that it's going to be alleviated tremendously. I think burnout still requires the recognition that these are human beings, right? That, that are, they're not, they're not components in a, in a big machine.

They have limits and they have things going on outside of work. And I think you still need to build that sense of culture, um, and community and support for one another that helps prevent that burnout. Um, it may like the ability to hand off some of the tedious, boring work to an AI agent may help, um, relieve some of that pressure, but I think the real solution is, is better management and better support for one another in the workplace, Otherwise known as empathy, right?

Um, yeah. Yep. As you kinda look at this, we're all obsessed with the technology, but I happen to wonder these days, maybe the bigger issue as we go along here isn't gonna be the technology, but it's the cultural issues and the change management issues.

And so how did you approach that? Yeah, it's, it's a really good question. I mean, in a prior life before I was an engineer, um, at Mondelez, I was actually teaching middle school computer science and robotics, and we talked a lot about the ethics of software development, the ethics of AI and machine learning.

And I, I think one of the things that I took away from that, um, being a teacher and expecting and, and having accountability from my students was that the work that they turned in was their own, they were accountable for it, right? And I think one of the things that is especially important in an AI driven engineering organization, uh, or AI assisted engineering organization more accurately is that there's still that same level or even a higher level of accountability for the code that you generate and, and contribute, right? So when, when we think about, you know, this, this culture and we think about what we're creating, I have the same or higher level expectation of my engineers that the work that they're doing is secure, it's safe, it's efficient that what we're generating actually does what it intends to do because we're running an enterprise grade IT organization, right?

It can't be any less than that. So things like change management become especially important as you mentioned, because we have to make sure that we don't generate thousands of lines of code that actually take us backwards instead of forwards. There are a lot of AI coding tools out there, but how did you wind up with Amazon Queue developer and or prior to that code whisper?

What was that decision like? So it was, it was interesting. We looked at a handful of tools and I think about 18 months ago and when, when we were looking at this, it really came down to copilot, built into, you know, GitHub and Microsoft suite of tools, especially with VS code.

Um, we tend to be a very heavy vs code sort of shop where that's our primary ID for most of our engineers. Um, we looked at Q developer and it wasn't one that was particularly, you know, it didn't show up on a lot of people's hype lists of like, these are the best, you know, uh, coding agents. What attracted us to it was the fact that we have an AI review board that we go through at Mondelez to ensure that every bit of AI technology we bring in is compliant with our policies.

It protects our data, it's, it's handling all of the things in a secure, uh, way so that we're not exposing data, especially in those early days of ai. When I looked at, at Q1 of the things that was appealing was the fact that it was another AWS service. Everything lived within my account.

I could provide my own customer managed key to encrypt all the data. So when I went through that process of the review board and looked at all of the different criteria that they had for accepting AI into our organization, Q checked all of the boxes and the conversation was, yeah, that makes sense. I, I see how that works and it, it meets our needs.

Let's move on to the next question. And that to me was appealing because it meant that I could be compliant and I could get it implemented quickly, which meant that my developers could get their hands on it faster. So what do you know now that you kind of wish you knew 18 months ago when you started this whole adventure?

I would say the, the biggest thing is to move as fast as the technology is. Like, there's been a number of times in this process over the last 18 months where I realized I was three to six months behind what the latest capabilities were. And, you know, turning that on and enabling it caused the organization to jump forward even faster, right?

So MCP built into the, um, the command line, right, where you can talk to our Terraform module repository and get the exact template for generating some code is amazing. Now, uh, we're looking to add some features with our observability platforms where you can ask questions about the infrastructure and see if it's performing, if there's a health outage, all those things. So it means that, again, sort of that same, you know, idea that I had before about the developer going to stack overflow a few years ago and now they're going to their, um, to their AI assistant.

If they want to find out if their service is up and running, they can ask their queue agent, you know, or their CLI, Hey, is this service up and running? Instead of having to jump to a different system and log into, you know, another portal to see if the, the metrics are there. So that part of being up to speed with everything that's happening and being current and staying with, or, or as much as possible ahead of the curve is something I wish I had done a little bit more of early on so that we could continue to evolve this faster.

The other thing I'm finding that I wish I had done was do more training and more knowledge sharing with the team because we're all finding and discovering new capabilities of the, of the AI platforms that we're using in the AI tools, and that knowledge isn't evenly distributed. Some people know really well how to use an MCP server, how to build one other ones, didn't even know that that was a, a possibility that you could work with. So that knowledge sharing and and poll cross pollination, I think would've been really helpful to do maybe six months ago, and we would've been farther ahead than we are now.

One of the issues that keeps coming up is there's concern that, um, a lot of the entry level tasks will soon be automated by AI and we won't have the next generation of developers 'cause the old guard is now using AI instead of assigning that out to the younger developers per se. Although, but you know, conversely, you hear arguments that says, you know, younger developers now can do a lot more because they're using AI agents and it maybe benefits them more, but how do you see this kind of playing out? Are, are we, are we gonna have a, a generation of developers that are kinda lost?

I don't know about lost. I think each generation is going to use the tools that are there when they came aboard, right? Like when I was learning how to code back in the late nineties and early two thousands, it was even before Google, right?

So my, I still prefer learning how to, how to code a new language or a new technology from a hardcover book laid out on the desk next to me with a cup of coffee, right? But I, I, I think what's going to, what we're going to see over time is that our, our newer generation of developers is going to become extremely proficient using AI as part of their workflows, and they're going to be the ones that are the most likely to come up with innovative and creative solutions, just like each generation of developers has done before them. What I do worry about is there's no shortcut for that struggle of acquiring new information, right?

That struggle is real. That's when you really get into, I know some things because I've got the scars to prove it, right? Every engineer or developer that has that tale of the time that I brought down production or the time that I, I dropped the database table, right?

I think the opportunities for those are still there with ai, right? There's still the, the opportunities for painful learning by our new generation of engineers. What I worry about is that sometimes they can make such quantum leaps with what they can do with AI agents and a AI coding that they skip over a lot of that valuable learning in the middle.

Like sometimes they miss the opportunities to have those painful but important lessons in becoming a fully fledged grownup software engineer. There's many leaders of software engineering teams such as yourself that are kind of trying to find their way through this transition. So what's your best advice to them?

'cause they're trying to figure out how to pull all these teams together and insert maybe AI agents and sometimes they augment teams and sometimes they're gonna be members of the teams. And how do you kind of manage all that? I mean, for me, and, and the only experience I have is my own, for me it was getting involved in getting my hands dirty, right?

Get in there and be the one to set it up. Learn everything you can about it so that you know where the edges are, right? Where the rough parts are, what doesn't work.

It doesn't mean that you have to be the, you know, the Spock supporting it forever, but be the person who really knows it well and start small with your implementation. Start your ambition small, start your, your deployment small. Get with a group of people that you can, you can talk through all the, the experiences together with and learn it together.

And then as you learn that, start scaling it up and scale fast. Because as I, as I mentioned before, the one thing I wish I had done was scale faster and share that knowledge earlier so that more people had the ability to use it and, and learn from it. All right, folks.

Hey, you're hearing it here? There's no substitute for for leaning from the front, right? Yep.

Get right in there. I mean, you've got a keyboard and a mouse. Go use them.

Alright. There you go. Sean, thanks for being on the chat, Mike, it's been a pleasure.

Thank you very much. All right. And back to you guys in the studio.