Techstrong TV December 9, 2025

It looks like IBM had $11 billion laying around, burning a hole in their pocket. You are watching Textron Gang. Hi everyone.

Happy Tuesday. It's Alan Hummel. I am back in the Boca Studios here for Techstrong, and I am damn glad to be home, to tell you the truth, after my AWS reinvent, uh, excursion.

Mitch, you were there with me, Mike Ard, you were there with me. It was, it was a full week of a lot of good stuff. We've got a ton of content.

If you check on Text Trunk TV and on all the various websites, you'll see it. But we're here today to talk about some fresh stuff, fresh news for this fine Tuesday. We got fine people to talk about it with.

I'm happy to see her here. I, I didn't see her at AWS my friend Hope Lynch. I hope Steven FoST.

He's about to jet off to New York City. He's such a jet setter, that FoST, but happy to have him here, Steven. And then, as I mentioned before, Mitch and Mike, good to see you both.

Not in Vegas. 'cause you know what happened there. Stayed there.

Anyway, Mike, we've got a busy day. Philanthropic is, you know, well, I have my own views on this, but I want to hear what you guys have to say. Mike, why don't you kick it off?

Anthropics been really busy. They acquired an outfit called BUN to get a new application development tool. They signed a deal with Snowflake for a partnership for connecting data to various LLMs.

And there's now rumors. There'll be an IPO in 2026. But Mitch, what's your take on what's going on with philanthropic here?

'cause they always felt a little bit like, you know, the, the alternative to open ai. But, you know, are they starting to maybe emerge as a bigger, more powerful force with a little hope from our friends over there at AWS that we talked to last week? Well, they're certainly beefing up the development space right there.

5 as a really strong, maybe the best of the models for generating software, orchestrating some of those processes. And BUN brings a probably not well known by a lot of people, but Fund brings a runtime job environment. So I imagine what they're doing is kind of using this to create sandboxes, maybe production environments, things like that.

Just accelerate the process of using the software that you're generating. Maybe they have other designs as well. We'll see what they have.

They didn't disclose an amount, so it's only, uh, 20, I think it's 2022 when the company started. So it's pretty young. Um, they'll get folded in and assimilated, but I think it's, I think it's anthropic positioning very strongly.

Go after the developer market. I, I, I think clearly Anthropic has set their sights on being the developer's AI tool of choice for coding, right? You hear this over and over again.

0, but the Anthropic and Mitch, is it Sonic? Claude, I forget now. 5, Right?

Yeah. 5. 5.

Mitch. Yeah, four, four Is the new one. It just came out.

5 has been considered the best, I should say. Mm-hmm. Mm-hmm.

I, I think, but, you know, every new one is, is the best one. But it is. Every new one is the best one.

There's a, there's a meme on the internet that shows, uh, open AI with Gemini, with Claude, and there's an arrow. And every time someone releases a new model, there's a little bubble over it that says, now we have the best one right. Until the next one.

Right? Right. But clearly they made this, their, this is the, the beach.

They, or, you know, the hill they're gonna attack here, right? Hamburger Hill and, and power to them. The other thing I'll say though is this, you know, it's the lesson.

I've said it here before, Brad Feld taught us this, Mitch be in the top three. You don't always, I mean, number one gets a good share of the money, but so is number two. And I think they've clearly enunciated or, or, you know, a number two space though.

Look, Google Gemini is, is a powerhouse, and they've got Google behind them. So there's an interesting race, and there are others. There's, there's X and, uh, and, you know, and, and others that are coming out.

But clearly Anthropic has staked their claim here. The deal with Snowflake, again, it goes right into their developer sweet spot, data management. Um, and, you know, as far as an IPO goes, I think that'll depend on the broader market conditions.

Does is this bubble keep, you know, if you've seen Wicked, does Glenda keep hitting the, the pedal that makes the bubble grow? Or does poof, the bubble burst? Hey, hope, do you think that we're gonna see some bifurcation where maybe open AI and Google, or the AI platforms of choice for the consumers?

And anthropic is more of the corporate AI platform? I actually think we already see it, honestly. Um, most of anthropics growth has been with enterprise customers.

Most of open AI's growth, even if you just count, um, monthly active users, right, has been with consumers. But if you look at the revenue, both of them have, um, I think philanthropic is now at $7 billion in revenue hitting what, a a billion in six months. But OpenAI is two and a half times that.

But they are counting on converting non-paying users, which a lot of people I know who aren't paying, uh, don't, don't plan to start paying the money is in the enterprise. So Anthropic definitely has already diverged. Um, but then we have the other smaller players like, uh, meta, you know, they're saying, well, we're gonna give it away for free.

Maybe that's gonna make people adopt. But really, the, the horse race, to Alan's point, it's between Google, uh, open AI and Anthropic, but the divergence is already there. Agreed.

Agreed. One more thing I'd like to add on that point too, is the difference in fundraising here. So Anthropic, uh, by all accounts, has raised a little under half as much as OpenAI.

Uh, they're looking at an IPO, uh, as you mentioned, they seem to be aiming at enterprise customers. I think this is part of a strategy from Anthropic to be more of a, I don't know, like a relevant Yeah, like, like, like they're trying to build a company that has more traditional, yeah, more traditional appeal to Wall Street, more traditional appeal to business. And I think that's a good strategy for 'em, at least.

It's a good differentiator from open ai. Yeah. No, they haven't pledged one and a half trillion dollars that they're going to spend on AI data centers and chips and so forth.

You know, not to be left out of the discussion, AWS is announced Nova Nova two. So they're doing their own model now to, you know, so they aren't entirely dependent upon the anthropics and open ais of the world. So the, the market is, is expanding.

I think a, I think AWS's strategy is Nova's kind of their default for their preferred customers. And then Anthropic is choice number two. And then everybody else is are, are you really?

Do you really want that? Or you short? Well, but, you know, but that's the ai, that's the AWS model, right?

We'll give you our in-house thing, 80% of the functionality, 20% of the price, or you could use best of breed, but you're gonna pay for it. And, and then, you know, and then there's Switzerland with Bedrock, it plugs into anything Leveraging those train chips, right? Yep.

Yep. Anyway, But one more, one more quick point on Anthropic, um, not to be overlooked is what they are doing. What they're actually doing, in my opinion, is vertical integration, right?

So they're saying we own the model, we are embedding it into enterprise data platforms through Snowflake, and now they own the runtime infrastructure. So for me, this is a little bit like, um, apple when they said, you know what, we're gonna, we're gonna build our own ships, Google, we're gonna build our own ships, Tesla, we're gonna make our own batteries. So they are eliminating more dependencies, but trying to make themselves more valuable to the enterprise.

I, the, the problem there, hope is, I think they vertical integration in the AI stack and Frontier model, Google, Google is, uh, in a power powerful position there. They really are, No doubt. All right, if we don't have anything else on this one, it's big news.

We'll keep our eyes on our friends at, uh, Claude Sonnet Anthropic, and, uh, see what happens. Congratulations to the folks from BUN though, by the way. Uh, we're gonna come back and we're gonna talk a, a little more m and a activity from Big Blue.

You're watching Textron Gang, You've Earned it. The spotlight, the responsibility, the weight of teams, companies, and entire industries fall on your shoulders. Lives depend on your decisions, your home life included that work.

You are protected physically and digitally. Nothing gets through your team without a fight. But in a globally connected world, everyone sees you, including those who mean to cause you and your organization harm.

And now home your sanctuary attackers see an opportunity. Your digital front door is wide open. And what compromises your home can breach your boardroom.

Because the Devil's greatest trick isn't targeting your workplace firewall. It's convincing you that your personal life isn't at risk. Black Club, digital Executive protection, defending the new attack surface your personal life.

Hey folks, we're back. And as Alan alluded to at the top of the show, IBM is spending an inordinate amount of money to buy Confluent a provider of a managed service around Kafka, which is a streaming data processing platform, open source originally developed by LinkedIn, and is now widely used to drive a lot of data in real time to where it needs to be. And of course, that has a lot of implications for ai.

But Alan, I know you've been looking lately into IBM and having some thoughts about them in general, but this is the latest in a series of acquisitions. And so, uh, to, to quote the new old book there by, uh, uh, Franz Kafka. No, I'm sorry, yeah.

Is it Kafka? Yeah. Um, metamorphosis where I guess basically he thinks he's turning into a cockroach.

But what is IBM becoming in all of this? You know what IBM is a cutting edge software provider. I, I think you gotta look at, yes, I-B-M-I-B-M always makes a lot of acquisitions, right?

Growing by acquisitions is near and dear to them. Not that they don't grow organically, but to me, you, you take Red Hat, you take HashiCorp, and now Confluent and you have a, a modern software stack, um, that is open source friendly. IBM's gotta be, you know, there's a claim to be made that they're the most open source friendly of the, of the large tech companies out there, right?

Look, think about all of the all, you know, red Hat Hashi. Yeah, Hashi changed their license a little, but they're still big on open. And, and now Confluence, I, Apache, Kafka, uh, Kafka, um, it's, I think it's a great move by IBM is $11 billion a lot of money.

You know what I've learned sitting at this desk the day we announced the deal, it sounds extraordinarily expensive a year or two down the road, you know, with the hindsight, eh, it was a bargain, Right? Yeah. What did they pay?

What did they pay for Red Hat? A Few years? 34 and a half billion, I believe.

Right? So still One of the largest software deals ever. HashiCorp, they picked up for a song in a dance compared comparatively, but Hope, Hope, I think they also bought, uh, is it Databricks?

Is that one they Got? No, they don't know Databricks Data Stacks. It's one of, I remember.

So yeah, red Hat Hashi, because then they got Terraform, they bought Vault for sequence management. Well, vault That comes Withm. Yeah, well, Vault Data, stacks Vault.

Um, but yeah, in cofluent, so, you know, for the real time data backbone, but yeah, That's right. They, they bought data stacks to clarify that they, okay, there we go. Which is a NoSQL Vector database.

So I think that, to me, I read this as to say that IBM's trying to make a play for the data, less for the AI models. And if I can own all the data and all the pipelines, maybe I will dominate this thing. Steven, what do you think?

This data King? Oh, data is king and Kafka is excellent. I gotta say, this is a pretty exciting move in my mind for IBM.

Um, they, as you said, I mean, they've acquired so many companies in especially the, um, this classic open source model of developing real open source software and then offering enterprise level support and, uh, managed services around it. Uh, that is exactly what they're doing here with this acquisition. And what they've acquired here is one of the leading companies.

If you go to, uh, talk to data people, you know, there's a lot of talk about all of them, incredible uses that you can make for Apache Kafka. Um, and also it would be important to mention that they don't just, um, you know, confluent didn't just make Kafka. They also are responsible.

And, and of course they're managed services cloud, but also Apache Flink or Flink. Uh, I like saying Flink because it sounds like a sound like, I dunno, a lemur would make or something like that. Flink Flink, uh, which is a stream processing and batch processing framework.

Um, if I told you that IBM acquired batch processing and data, and you know, you'd be like, oh, yeah, oh yeah, like the Kool-Aid man. That's what IBM's all about. Um, good acquisition looks like a good amount of money for both sides, and I think they're really gonna make hay from this.

I Got a quick question. How would you know what kind of noise a lemur would make? I love lemurs.

Um, I actually have, um, on the wall of my office, a giant painting of lemurs. And, um, it turns out that they only say things like flank to their friends. Oh, Okay.

That's probably why I've never heard it. Wasn't there a show about a lemur my kids watched when they were little bufu bufu? Yes, that was it.

That's what I thought you were gonna tell me, Steven. That Zafu said Flink. Alright, so have you to, we're a LE Center center In North Carolina.

Let's, I'm sorry about Here. You're The best. Yes.

Donate to the Duke University Lemur Center. Excellent. Go Jumping in on this.

That's, I'm glad we went down that road. Go ahead, Mitch. I don't have any lemurs.

I'm sorry. No lemur stories. You know, this, this compliments what, uh, HashiCorp announced with their infograph earlier this summer, uh, graph database around the infrastructure through this contextual information for AI to use as part of its processing.

Now you add this real live, live streaming, you know, high volume data for data pipelines, both going into AI and traditional software, and they're, they're doing a good job of beefing up the, their data platform, if you will. I wouldn't be surprised to see more acquisitions in the data space for IBMI Think you're spot on. 'cause I think when I look at all this AI stuff, at the end of the day, it comes down to the right data's gotta be in the right place at the right time.

And that's easier said than done hope. But, you know, is what's your sense? Are we moving away from kind of this batching mindset that joining a mindset that Steven mentioned, and are we shifting over everything in the near real time?

I think that's, that's the goal. That's what, uh, a lot of people want. Um, and right now that is what people are hoping, hoping that they're, they're able to do so.

Um, and if, and if people don't know, you know, this streaming data is like a, like the nervous system for the applications we have now. So bank transactions, when you swipe your credit card and it comes back and says yes, um, you click on a website, you have sensors with flowing data, um, those, those things matter. So with that cloud native engine, hopefully handling gigabytes of data per second, um, yes, that becomes more and more of a reality and, you know, no lag.

And I think even what we consider fast today, maybe in a few years, we will feel as slow. And if anybody remembers, I do the days of trying to download something and, you know, you'd be lucky if you could get 10 megabytes overnight, whereas now you can download a gig in a few seconds, I think, um, someday, right? Hopefully we can scale to that point where we can look back and see those big differences.

Well, Steven, I think that sound you heard was actually Watson X giving a big sigh of relief as it took a big go of data coming its way. Well, Yeah, absolutely. I, I, and I think there's another method to the madness here of IBM.

You know, I, I put up an article yesterday, I believe Ron Tech strong AI about I-B-M-C-E-O, uh, Arvin Krishna did an interview where he, he called out the industry on the, on the AI data center, uh, model. And, and quite frankly, you know, quoting Bill Clinton, it's just arithmetic folks. It's just old arithmetic.

And, and according to Arvin Krishna, the arithmetic doesn't work for AI data centers at under the current guise of things. So I think knowing that, and you gotta assume that the people at IBM and Armand themself, they got a couple, they've got some experience in this space in data centers and economics of it and all of that. So I think that deliberately here, making a bet, how did they ride this AI wave without exposing themselves to the GPU waves and bubbles and so forth, being the data kinks, right?

They'll run the data management, they'll run the underlying clouds and, and security and, and these things, right? Without actually being exposed to, uh, an AI bubble, just throwing it out there. So I agree on Kafka, but I'm not entirely sure that, you know, it's open source, right?

So IBM buys a company that provides managed services, okay? But there are other companies that can provide managed services around Kafka. So it basically comes down to them acquiring the, the talent and the expertise to manage Kafka, which other people can get.

So when I look at this a little bit, I'm kind of like, well, okay, but can you hold onto that expertise or are you just adding to the IBM services portfolio and a bunch of consultants? But, you know, what is the thing that you bought? Because, well, Kafka has freed everybody, You know, I think it's more than Kafka.

You're right about that. 'cause a lot, it is the most popular platform for streaming data. But it, it's, I think it's an integration strategy of how they tie this into their other products, uh, uh, you know, as well as the acquisitions Red Hat and HashiCorp.

But, you know, things like, um, stream sets, e even going back, you said, we mentioned data stack, web methods. I mean, they have so many platforms that can benefit from a streaming data platform. I think this is kind of a universal win.

So, so I should look for that Red Hat OpenShift Kafka slash DataStax bundle any day now. Absolutely. But, you know, a little bigger, But that joke is also that you just made actually points to one of the challenges that IBM has ahead of them, right?

So integration, this is a lot. This is a lot of technology to integrate and make sure it all plays well together, and that whoever is in sales for IBM, when they're out in the field, they cannot, they can make it make sense. Mm-hmm.

And people aren't, uh, you know, building their own Frankenstein monster. You know, I think the key is making one plus one plus one equals seven, right? Because otherwise, yeah, you could go get the open source Kafka, or you could get someone else who gives you a managed Kafka, and you could get Susa or a different Linux over here and, and, and, and, you know, rancher for your cloud native, and, and you open tofu for the HASI stuff.

It's how, it's the one plus one equals four model that IBM has to perfect and sell here. And there's Three words. Enterprise.

Enterprise, enterprise. Yep. Yeah, yeah.

And you look at, You look at the success of Red Hat, and, um, and this is a model that is working. It's a model that's working for IBM. It's a model that's working for their customers.

I don't hear a lot of people complaining about Red Hat. I hear a lot of people that are really happy with that product and with the products that they're getting from IBM. Um, so yeah, I think that that's exactly how they make this work.

Their pattern is to leave it alone for a couple years, then, then start to integrate it. Well, They, they've got a little experience doing acquisitions, Mitch. Yeah.

Yeah, they do. You, you're right about that. I think somebody looks at this and starts to conclude that maybe, you know, the big winners in all of this are the providers of the storage and the networking platforms on which that day is gonna be moving around.

This is the open source community. It's the open source community. Because once again, open is the future.

No one wants lock in. No one wants to be locked in. We gotta take a break though and come back.

We got our third block coming up here. A little green story about carbon capture. You're watching Textron Gang, Discover Textron Group, the epicenter of tech innovation.

We are your go-to for reaching IT, leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more.

Join our satisfied clients. Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group.

Hey, folks, we're back. And on Tuesday, especially in the C block, we like to talk about climate ecology and all the things that go with that involving it. And today is no exception.

Google is talking about a way to capture carbon from data centers, and that's how we're gonna solve a lot of these AI issues. Steven, what do you think? Is this a viable approach?

And is this gonna make more sense than, I don't know, putting a windmill in everybody's backyard? Uh, no, but it's a, it's better than a kick in the head, that's for sure. Um, but only moderately.

Uh, so Google, yeah. So what's going on here is, uh, there's this, uh, broad wing energy center that's being built in Illinois. Um, they're pitching it with very, very, very green, uh, looking, uh, prose and photos.

You know, they got, they got pictures of leaves, they even got pictures of solar panels in this thing. But this thing is a natural gas fired power plant. It don't, don't be fooled.

It is a hundred percent a natural gas fired power plant. The green-ish aspect of it is that they're using carbon capture technology that was developed by a, uh, little, uh, company. I believe that this is using, uh, ADMs, uh, carbon capture.

Essentially what they're gonna be doing is as they burn the natural gas, they're gonna capture the CO2 and sequester it on site, uh, to keep it from getting out into the atmosphere, which, like I said, better than a kick in the head, but really not of all that green, because this is still a fossil fuel powered car, uh, plant. And what's happening here is that this broad wing, they, they were building this 400 megawatt plant in Illinois, um, to essentially take advantage of the fact that there's a lot of Midwest natural gas available, and there's a demand for power. And they think they were kind of hoping, you know, if you build it, they will come in the old cornfield here.

And, um, and they did come, in fact, Google is, uh, committed to basically absorbing pretty much all the output from this plant. So, uh, those of, uh, local folks or whatever, who thought that maybe this was gonna be something that was gonna benefit the, uh, local, uh, you know, uh, it is gonna benefit the local economy. But if they thought it was gonna benefit them in terms of, uh, power supply and stuff, well, not as much as you might think, because Google's gonna buy most of the output.

But what this does, uh, you know, again, to be a little bit more optimistic is it is a stamp of approval on carbon capture, which is, again, better, you know, than not. It is a, uh, money that's gonna go into this process that's gonna help develop it and perhaps allow us to see more of it, uh, rolled out in other places, which would be good. Um, and of course, it means that Google is going to use a little less carbon producing fossil, uh, fuel power in addition to the many other eco-friendly power sources that they're using.

So it's not bad, it's just not all that green. It's sort of a, a pale gray, greenish color. What would we call that?

I don't know. Puke green. I always call the puke green.

Steven. Yeah. So, so explain this to me.

'cause I'm not up on my carbon capture thing, but I'm assuming I'm gonna look out behind my data center somewhere and there's, I don't know, 10 acres, and am I like quite literally, like capturing carbon and just keep digging the hole in the ground until I No, no, that not what they're doing here. My understanding is they're converting the carbon into CO2. So combining it with O2 right.

And pumping it into underground aquifers, which the middle of the US is riddled with. What could go wrong. Yeah.

Or, and that's exactly it. So, so a DM has been basically producing ethanol, which produces CO2 as well. And, uh, they're the big corn company.

Uh, they, they, you know, they're, they're big Corn arch isn't ADM very corn arch, you Daniel Mills that always gets sued for it, kind of environmental disasters. Oh, I don't what You're talking about. They're fine.

So, so, so let me make sure I understand what you're saying here. So at some point, do I have to like, call the septic truck people and they come and pump all this out just like, you know, all those houses on Long Island, or how does this work? I mean, where does it, you see Long Island there, Mr.

You'll Hear a giant, you'll hear a giant burp coming out of the Midwest just to periodically to expel that gas. We gotta hope there won't be. Uh, yeah.

The idea is that you pump it as, as Alan said, you pump it underground into limestone formations and depleted oil fields, that sort of thing. And you leave it there, and hopefully over time, either it'll stay there or it will, uh, combine with the shale and so on, that will keep it sort of, um, dissolved. And not, not not tech chemically, but sort of it'll keep it in place.

Yeah. It'll, and we better hope that there's not a carbon capture burp a hundred years from now, because if there is, that's a lot of carbon that's gonna suddenly get up into the atmosphere. But wait, there's more.

But wait, there's more. The cost of liquid gas powered energy combined with the cost of the carbon capture and storage makes it far more expensive then solar or wind powered energy. Oh, but there's tax credits.

Yes. It is far more expensive. It will be far more expensive.

And at the same time that we're doing this, China just rolled out a solar field the size of Chicago that is producing way more energy than this and is gonna produce no carbon that we have to store at about half Price. You know what one of my favorite sounds in the world is? It's the sound of that can, as it gets kicked down the road.

But to your point, um, so Google isn't just betting on this, right? So they signed, uh, the corporate agreement for those small modular reactors with Kairos power. Mm-hmm.

Um, and they are saying, what that's gonna be online by 2030, but really operating by 2035. So they, they are betting on both of these and what they are doing, um, for carbon capture that might be offline in 25 years. Right.

So really, this is, you know, in my opinion yeah. All about the tax credits so That Then it's about the tax credit and it's about currying favor with the Don. Not, not to send Steven over the edge, but you know, this is the same Google who's now talking about building data centers in space with other people too.

But, you know Mm-hmm. Mm-hmm. It's, it's true, true.

What Hopey And Google Is doing a lot of different things. Yes. They're, they're trying to support small modular nuclear reactors and whether those will work, who knows?

They're also, for example, they have a new geothermal project that they're working on, uh, in Nevada, I believe. Uh, they've got, uh, energy storage with a company called Energy Dome, which actually uses CO2 to, uh, store energy, uh, produced by, uh, actual renewables like wind and solar. Uh, so Google isn't the bad guy here.

In fact, as I said, Google is probably, this is the positive side of the equation, but I really do think that this is all about politics. It's about, you know, ha making the current, uh, administration, you know, kind of working with them in their framework in terms of what they'll accept in terms of power and what they'll accept. Uh, a, uh, natural gas powered power plant sounds exactly like what they'll accept.

It's supporting a fossil fuels future. I don't know. I think triples, I think they'll take, that's, they'll take the CO2, turn it into rocket fuel, and then that's how we'll get the data center in space.

See, there you go. Yeah. It's all sick here.

And, and, and one more, one more point. And, you know, I'm, I'm not being completely down on this, believe me, but the contrarian in me comes out for this story. So carbon capture, um, it's been around for something like 50 years, right?

They've been developing carbon capture and storage that long. And over all of that time, they've captured and stored less than 2%. 1% of the annual global CO2 emissions, right?

It feels to me we are solving the wrong problem. Not that people don't know that, but the wrong problem is being solved. You know, you're catching everything after it's out versus the, the preventative measures that you could take.

Agreed. It's politics Absolutely endorse that. Yep.

And to me, it reminds me a little bit of like post-consumer recycling, which again, is, um, is a feel good measure that really only affects a very small, um, a amount of the waste and, uh, you know, disposal of things that could be recycled. It, it's about, um, you know, making people feel good about contributing to the solution, which they are. I mean, 1% is better than 0%.

You know, 5% is better than 0%, but it's really not gonna solve the problem. You know, Stephen, down here in Florida, a lot of the municipalities have stopped the recycling because they have so much they don't know what to do with it, which is kind of ridiculous. But it is Florida.

Yeah. So claim low carbon power while you enable high carbon infrastructure. Anyway, soon.

Soon enough though, when you get your ai, you'll be able to check that box that says, do you want car? You know, do carbon credits with it, but who knows? So We're, so we're just handing out climate pinkies to everybody that we can just kind of maybe put some branded logos on.

Is that where we're going? I think that was the goal of the last administration. This administration wants to ban those, You know, we'll give everyone a participation trophy from fifa.

Um, all right. That's a good place to end today's show. Hope.

Steven, Mitch, Mike, thanks for joining us. Thank you for joining us. Hey, do go check out all our reinvent, uh, uh, content from last week.

There's some great stuff up there, Steven. We, it's good to see you. We'll see you next week.

Hope. Always a pleasure. Take care, everyone, until tomorrow.

I'm Alan Hummel. We're out. Hey, everyone.

We're back here on Text Drunk tv. Welcome. I'm, this is a part two.

If you didn't catch our part one, I encourage you to go back and check it out. But I'm talking with Priya Doty, and Priya is, uh, with B-M-C-A-M-I. And if you wanna understand Priya's background in B-M-C-A-M, I go do check out, uh, part one of this interview.

I don't wanna rehash it 'cause we got a lot of good stuff to cover here. So, Priya, welcome back and thanks for joining me again. Hey, Thanks Alan.

So, Priya, we left off, we were talking about the, uh, knowledge expert that's now being built into the BMC software. And, you know, we were analogizing it to kind of the, uh, uh, AI we're seeing built into developer IDs. Yeah.

Yeah. Right. And, and, and I will tell you that's a great use of it, by the way.

But we're also seeing the same sort of thing, the AI built into software testing, right? That's right. Testers now have this little bug in their ear mm-hmm.

Telling them this is the test run, or that's not the test run, or there's a mistake here and what, what have you. I think we're gonna see the same thing coming to the ops people, right? A hundred percent.

Yeah. So how, how is that manifesting itself in, in the BMC suite? Yeah, absolutely.

Well, so on the BMC side, I mean, AI ops is a, a known quantity for us, but, but the thing that's really changing right now is we just announced the knowledge expert in October. And what that lets you do with BMC Amy assistant is actually start to interact with a chat interface, ask questions as you're doing your daily workflow as a, an operations person, right? And that's, that's a big step forward because just like you said, like on the IDE side, we've started that journey about a year ago.

Um, on the ops side, we're now continuing to add functionality. And this is like very pervasive, right? Anybody who's using the ops ui, uh, can now leverage this, this kind of chat within it, within it.

So great for any team where they have, you know, different levels of resources, different levels of skills, uh, to be able to kind of harmonize across. Um, so we're pretty excited about it. We have, uh, lots of customers testing it out, uh, giving us feedback.

Uh, and it's been, it's been pretty cool to watch. You know, what I love about it, this kind of thing. Priya is on a team, team wide level.

It is fantastic, right? 'cause now everyone on the team has, has that same level of access to the knowledge base to the expertise. Yes.

But it's not just access in that, you know, and this was going back to the ar I told you about the article I wrote about the difference between people using AI versus Google search. Yes, Yes. Yeah.

To some extent, we always had that access, right? There were people using Google internally who put a knowledge base together that you could search. But when we have it as an AI sort of chatbot or generative AI like this, it's so much, it, it's, it's just a lot closer.

It seems it's a lot easier to put your hand and finger on. It's always, it's like having an assistant with you, a coworker. So call a digital worker right there with you all the time who is suggesting these things and can make these changes with you.

And, you know what I mean? It, it's, it's, it's heads and tails above just having a knowledge base with a search bar. Oh, indeed.

And I mean, I think you look at BMC, we have the entire software stack. So what we're doing is we're saying we're entering with chat, and we're letting you start to type things in and ask questions as an operations person. But what we're quickly gonna start to do is let you ask questions, you know, uh, how much am I spending?

How can I pull back on this? Where might my problematic issues be? And starting to cross domains.

So you men mentioned a team. It's almost like you would recreate a, your environment in that, you know, digital sort of GPT context and ask questions that cross boundaries into the data space, into the ops space, or the storage or, uh, you know, wherever it might be. And that's, I think that's what's the really exciting thing is this is the, you know, this is like one of the first steps towards that.

And of course, that absolutely, that's always gonna lead us towards the, the discussion on ENTs, right? Because that's the, the Other big thing. But before we got to Agen, there's one more point I want to make on this one.

Clear. Yeah. You know, we mentioned before a lot of people are afraid about AI taking their job, costing them their job.

Yes. This sort of knowledge base here, knowledge expert, uh, chat and so forth. This is not meant to replace people as valuable as it is on a team wide basis.

This gives every single person on the team the ability to be a superstar because they have the entire knowledge base of everything they want easier at literally at their fingertips, and in some cases even automated to pop in there. And this is why, you know, when they say you're not gonna lose your job to ai, you're gonna lose your job to someone who works AI better than you. Absolutely.

If you're an individual, learn to use this. And, and I, I think it's the great paradox, right? You know, the, the theory is we're gonna be simpler because of gen ai.

The reality is it's actually gonna be more complex. Yeah. But so what's gonna happen is if you're using those AI tools, you'll be able to master complexity faster and get to that higher order challenge faster.

And so we're all gonna have to push ourselves harder. Maybe that's why our brains are rotting. I don't know.

Or, or videos. But, um, Could could be that too. That too.

But yeah, I, I think there is a very valid point. I mean, we're not designing anything to replace anyone's job. We're, you know, we're designing things that help people with the workflows they already have today.

You know, that's, I think that's the other interesting thing about AI is so far we haven't developed any net new workflows. It's leveraging the existing processes and workflows and then trying to improve upon them. But you, the beauty of it, you know what, someone, so all the venture backed companies I ever helped co-found were funded by my friend Brad was pretty well known in in the VC world.

Yeah. Brad always used to tell me, 99% of tech is evolutionary not revolutionary. And AI is a little revolutionary.

I won't deny it, but the way we use these knowledge, uh, basis and the way we interact it is, it's an evolution of us getting better, of us being able to use them more of, uh, of them being more useful to us. And it represents the future. It's not some far out star trekky or Star Wars kind of future.

This is a future you could put your hands on right now. BMC is rolling this out as you're watching this in essence, right? Indeed.

Indeed. And so I, I, I think people need to remember that. I'll tell you something else.

I, I was at, I've been at a bunch of conferences the last couple weeks prior, and I was talking to someone a little younger than me who, who said, we were talking about this kind of stuff around generative chat bots and so forth, and they said, oh, cha generative AI was last year. This is the year of Ag Agent ai. Oh, it sure is.

Yeah. But I feel like generative ai, I hardly got to know you, but, you know, boom. That's how quick we're going.

So, yep. Hey, we had our two, three years now. Now we're, now we're at Ag K, so now we're at AG AgTech ai and Priya, what is, you know, what does that mean?

What does that mean for BM mc in the mainframe world? Yeah, I mean, look, it's, it's, again, it's an early, everyone's talking agen X it's early days, and there's emerging standards. We're focused on the MCP standard.

I know there's others that are out there. I'm sure there will be more in the future, but the way we're thinking about it is a kind of a step process. You know, we started, we're starting with embedding the functionality of Gen AI into our products.

Like we've just been talking about in the ops domain and the devex domain. We're then looking at how do we turn them into agents, meaning autonomous, you know, either purely autonomous, but more likely to be, you know, sort of guided in a way, um, agents that can actually execute tasks. And then the, you know, the ultimate goal is, uh, a workflow chain where you can have, uh, you know, an agentic workflow.

And we already have some prototypes built of agentic workflows in the dev space, uh, you know, and things like that where it's chaining together different tools. I think one of the, um, biggest value propositions right now for, especially for the MCP, is just connecting all the different dev tools you might have, or connecting all the different ops tools you might have in the average day. So I think that's probably gonna be use case number one.

Um, and then use case number two will be sort of starting to automate some of those more repetitive tasks. Going back to the spectrum of trust, where people feel they can turn it over. Um, as excited as customers are about a agentic ai, and the, the term I hear the most commonly is they want self-healing systems, but by the same token, they're still very concerned about how much they're turning over to that self-healing system.

And then how much, like if there's a challenge with their SLA, who's responsible for it, right? Is it, is it the IT operator? Is it the software provider?

You know, so there's a lot of questions like that. You know, we, this was a similar experience when cloud first came on the scene. Yeah, right.

Anytime, you know, you know, the old saying, you know, how you get stuff out of a cis ops hands, you gotta un un unopen his cold, stiff, dead hand to get it out of there. Right? That's right.

It, it's the same, you know, there, there is gonna be, I think this period where people are a little nervous about giving up control, about turning it over, automating it, letting a a, an agent kind of run full speed. But if you're not gonna let the agent run full speed, you know what I mean? That's kind of defeating the purpose too.

So I do think we're gonna have a, a period of, of trust building and then, you know, learning, learning to just let it go and, and see where this, you know, how far and fast it can go. Yeah, for sure. And, and I think it's, you know, keeping the human in the loop, but it's also being realistic.

Like, if there is an outage, if there is a problem, human's gonna have to be involved, right? Yeah. Well, but you know, you, you look at, let me analogize it to another really like the, our electric grid.

Yeah. Right? Like, so I live in south Florida, right?

The, we get hurricanes. The electric grid really needs to be resilient. It needs to be automated, it needs to be able to, you know, uh, a a transformer goes out, a substation goes out, oh yeah.

Reroute all of this. That that's a world that's made for this kind of stuff, right? And, and mainframes in a similar vein, right, in a similar vein, I, I really think, I really think mainframes are, are made for this, right?

And, and, and ai, and this is where it's like a little chocolate and peanut butter. I think the agentic AI running in the mainframe environment has, has a lot of potential and a lot of, uh, you know, space to do, to get stuff done. Yeah.

Stuff done with disaster recovery, automated failover, those kinds of things. Yeah. Especially for that, all of These Things.

Yeah. As long, absolutely. As long as you manage the ransomware element of it, because, you know, there's always that fear of, um, that's something that BMC does a little bit with too, is, you know, around you don't want, um, you, you do need an immutable copy of your data somewhere, right?

Yeah. That has to be physically and logically separated from everything else. So that's the one, one place.

But yeah, I agree with you. There's a lot of automation built Sure. Is to these systems to, you know, drive the resiliency that they have.

Yeah. No. And so you're gonna take what's probably the most resilient system in existence right now, and make it even more, uh, resilient with, with these a a AI agents, excuse me.

Um, I gotta ask you the, the, the $64 billion question, or maybe it's the $3 trillion question. That's how many data centers we're building? Oh my gosh.

What does this get real Priya? Oh, that's a very good question. Um, To a certain extent, it's real now, right?

I mean, especially the generative stuff. I Mean, it's real now. It's real.

Now I think every customer is at least, let put it this way, many customers are in the evaluation phase. In some, some state in the evaluation phase. There are a few that are further out, uh, that are further adopted.

But we put in front of our customers in a, a maturity model, kind of a four step maturity model. Most of them kind of fell between one and two in the, in the levels. And they're, they're evaluating, they're testing, they're piloting, they're looking at different solutions.

That's kind of where they're at. Um, I think the next phase is gonna be proof of value, proof of concept. Yes.

And in my opinion, I think we're about probably one to two, maybe two to three years away from full production level activities. But it's a journey. It doesn't happen overnight.

Nobody's gonna put this stuff into market overnight. So they're, you know, they've gotta take, take the steps to do that. You know, if it takes 12 to 18 months to put a typical change into market in production on the mainframe environment for, you know, for big changes, not the code which is dropped frequently, um, then just think about AI and how much testing, how much piloting, how much, you know, you've gotta do around accuracy, governance and all those things.

So yeah, I mean, it's 2025 now. I think by this time in two years, we're gonna start to see some real significant implementations in production happening. Um, but I'll say like, even now, I mean, we have customers using our solutions to do that code, explain, you know, throughout their organizations.

And so the, the earlier adopters have started. Absolutely. You know, my experience with these kinds of things, I, I don't know if I've ever seen anything, this AI is the world unto itself, but my experience with technological innovation like this there, you know, there's no flag raised on the day it happens.

There's not a button you pressed or, yeah. You know, I I, I was talking to a quantum expert about this a couple months ago. When is Q Day gonna come?

Right? He said, you probably won't know until six months or a year after, and you'll realize it came. Yeah.

And it, and it may be the same sort of thing here where, because this is gonna sneak up on us because it's not an all at one thing. It's a gradual building up of these things. Yeah.

And then one day you're gonna turn around and say, oh my goodness. The whole, the whole thing is, you know, these, these agents are running, they're doing it. Yeah.

Um, so I think, and, and also I think this is just accelerating at such a pace. If I was a betting man, and I'm not, I, I think two, three years might be far out there. I wouldn't be surprised to see a sizable, you know how they do the crossing the chasm model, right?

Yeah. You have 15% early adopters. Yeah.

35% early mainframe. I wouldn't, that's 50%. I bet you were at that 50% mark in 18 months.

Alright, we'll have to come back. And shim, Shimmy said it here. I'm on tape doing it.

Come back and we'll, we'll, uh, we'll Come back. We'll, it, we'll come back. Compare notes.

Absolutely. Absolutely. Hey, this has been a great discussion.

Um, I, I just want to end it with sort of a, a generalized mainframe kind of observation, right? Look, this has the, the potential to modernize the mainframe. I think in ways even beyond the, the, the most ardent mainframe modernization people were clamoring for.

Um, do you think that it'll, is it gonna satisfy the mass, not the masses, 'cause the mainframe is what it is, but do you think this is what the people, are they gonna be satisfied, I guess is my question? Or what more do they want? What more do they want on the mainframe platform you mean?

Yeah. Um, No, I think this, this has the potential to really help the customer that says, these are the things that I need to keep on this platform. And Gartner says, now, I mean, they're saying that this platform is going to be very significant around whatever, for the next 25 years, if not longer.

So I think that, you know, the, the, um, the name of the game for the customer is strategic flexibility. If I can have flexibility in my code base, if I can link to these other processes, if my people are using all the latest and greatest ai, then I'm just gonna keep increasing my productivity and I'm reducing the risk. And that's really what it comes down to for the customer.

So I think there's a lot of promise and AI driven transformation for customers. And I don't think you can assume that it's all about moving off. It's also about improving what you have in place.

And that's increasingly what I hear from the customer base is, is, you know, how do I do that? How do I, how do I make this platform the foundation for the innovation I have to do for my company and, and do it faster and more efficiently and, and with happier people? Fantastic.

Priya, I've taken way more than of your time than I, I know you went way over, but did I apologize? Yeah, but you know, it was, it was worthwhile. I think.

I hope you out there enjoyed it. Uh, we'll continue. We have a lot more, uh, information coming with BMC and some of their announcements coming out.

So stay tuned for that. And we have a lot of content here on Textron that we worked in partnership with our friends at BMC. We, including, I think we have a couple of webinars and articles and all kinds of great content.

So stay tuned for that. But for now, this is Alan Shimmel for Text on tv. Thanks for watching everyone.

Hello and welcome to the latest edition of the Techstrong AI Leadership Series. We're here with Sini sw, who is managing director for data and AI at Tech Systems Global Services. And we're having a little chat about, well, the future of large language models, a k, a LLMs, and, well, I don't think this is the end of the story, and maybe it's probably just the beginning of this journey, but Serini, welcome to show.

Thank you so much, Mike. Bye Mihir. So walk us through here.

I mean, right now when I look at LLMs, there seems to be, ma most of the focus is on these massive general purpose ones, but I feel like there's other use cases, and I don't know, maybe there's even something beyond an LLM, but your assessment, where are we? See, I think, uh, last 24 months, it has been, uh, a whole, uh, ride off innovation, you know, and new ways of doing things. Uh, when mankind was kind of introduced to this next token, you know, prediction capability that large language models really brought to the table.

Um, every organization is evaluating their AI journey. And when we work from tech systems, when we work with customers and chalk out a roadmap, uh, having an ai uh, driven efficiency is part of that roadmap. But then LLMs are just one step into providing that efficiency gains.

Uh, there are several advantages to what LLMs can bring purely in the form of, uh, ability to predict, uh, almost human-like, uh, but then there are also a lot of drawbacks, including, you know, what you're hearing when something goes down such as an infrastructure or, or a cloud operations. You know, the, the AI system kind of goes down. So how can we make sure organizations tap into this AI innovation while also, uh, enabling their own workforce that has become the talk of the town, and more importantly, the way we are engaging with our customers.

Mm-hmm. So how do I get there? Because to your point, the models are probabilistic and, uh, so it's kind of, you know, the next best guess and it's to, you know, we've trained it and some say it's a, you know, an advanced form of mimicry and whatever you want to call it, that's fine.

But, um, sometimes you know it's right and sometimes it's not. And we have all these processes that are deterministic where we kinda want them to be done a certain way almost every time. And the last thing an LLM ever does is the same thing twice.

So, um, how do we kind meld these things together to get what we're trying to get to the end point here? Yeah, That's a, uh, interesting point, Mike. The, the key aspect of a large language model, um, is predicting what's going to, you know, be told next, right?

So it's, it uses, its its own, um, rich training dataset on which it has been trained. So that's why LLMs are not going to give you the same answer twice when you, you know, even when you press the enter twice in two seconds, you're going to get two different responses because, uh, the way the training data has been set up, the way the context window has been set up, the way the past historical conversations that needs to be retained for it to be able to answer again, has been set up. So these are all hyper parameters and are tuned, uh, configuration settings that can vary from model to model to model.

And that's why there is, uh, this whole raise of, uh, you know, which model is the best kind of, uh, you know, argument going on right now. However, the, if you look at the big picture, it's not just about a language based translation that's not just, uh, what AI is all about, right? AI needs to, uh, uh, think from a causation standpoint, it needs to think not just amongst the language.

Our human brain can achieve so much of, uh, such intelligence, you know, by consuming low amounts of power. Whereas we are actually hearing all these large language models with billions of parameters, tons of GPUs, you know, to really make a simple prediction the next token generation work. So there is still a long way to go, but definitely the LLMs have opened up, uh, an innovation mindset among the humanity.

And we want to see where this entire AI journey can take us forward as a humankind, primarily because there are certain jobs. You know, we cannot ignore the fact that there are certain tasks that essentially can be repetitive in nature and can be translated. For example, high tech systems.

Uh, we have built a solution called Intelligent document Processing. What it does is you have these tons of paper documents that needs to be digitized, that needs to be, you know, text needs to be extracted from it. And simple questions can be answered from that extracted text, which you, which you can basically achieve using the current technology layers of large language models.

The moment you talk about making decisions, unbiased decisions, and setting it through a workflow such that these autonomous, you know, ingestion as well as decision making becomes a part of a process flow, that's when our security guardrails need to be tightened up. Because today, in today's context, hallucination is real. Uh, I'm not sure if you're following, there are.

There is a, uh, there is a, a interesting effort where, uh, five different large language models have been given $10,000 each and asked to invest on crypto. And we are seeing one model at a $3,000 portfolio value and another one at $12,000 portfolio value as we speak. And it still continues to go up and down.

So what it says is, even if you define exactly the same prompt amongst these five big LLMs, the way they make decisions and the way they actually, you know, respond back to that real time scenario, still has a long way to go. And that's what I think we have to be careful of. Not starting any conversation with just, uh, you know, uh, essentially pressuring into taking up AI stories, but rather look for the use case, look for the fitment, see what's the security guardrails, see if there is any risks that we are unnecessarily introducing, and then appropriately handling ai, you know, uh, uh, adoption into that organization.

Mm-hmm. Um, do we just also maybe need to focus a little more on narrow training some of these LLMs for specific tasks using, um, examples of something that is vetted better? 'cause Right.

It seems like to me, one of the issues with the hallucinations is that we've trained these things, their general purpose. We kinda grabbed everything and anything we could find. And you know, like in the case of code for example, that is flawed, there's gonna be vulnerabilities in it that were created by humans that are now being replicated by the LLM, not necessarily the LL m's fault, but, um, maybe we need to just take a step back and figure out a different approach to training, maybe smaller.

Right. I absolutely agree. I think LLMs do really well when you have a clearly defined guardrails and a boundary box that you can set up for, for example, just expanding that I intelligent document processing example, if I train the model, let's say, to process Medicare claims, just in terms of expanding the text, understanding what documents are needed for this claim to be processed faster, and then reaching out with the communication to the customer and getting those specific documents such as healthcare benefits or a driving license or whatnot, you know, in terms of identification.

So preserving that guardrail. Or in another use case, you can also think like processing those invoice forms, right? Uh, essentially when I have an invoice, I need to be paid automating the process of text-based digital process where this AI and large language model solutions can come in.

They are well-defined guardrails, the prompts and context windows are capable, uh, to as assess that particular business process and take care of it. I think that's where you get a large lot of ROI, because at this point, customers and executives are asking, I don't want, uh, an AI solution just for the sake of it. Show me the business value and the return on my investment.

And to get to that return on investment at this point, because of all the hallucinations and the general purpose, not really yielding the required success criteria, defining a business process, setting up guardrails. And then obviously we are no longer just talking about ai, uh, and LLMs. We are also talking about agent ai wherein you can actually connect a multitude of small defined focus points and then connecting them together to form a business process seems to be yielding a better results at this point.

Mm-hmm. So are we just maybe a little bit on the too ambitious side and we need to kind of play a little small ball to figure out where to get the ROI on this stuff sooner than later? Absolutely.

I think because again, we're talking of these large language models, um, even if they're available, uh, you know, for millions of tokens at, uh, cents and dollars still, as I said, the hallucination and the effectivity largely determines the outcome. And if you do not set up the right guardrails, garbage in, garbage out, so you essentially are not going to be able to make decisions out of what predictions, you know, these LLMs are going to come in. So defining your guardrails, making sure, uh, understanding the risk reward scenario, and then feeding in the right data set to be able for the LLM to give you good prediction in spite of giving a good prediction, having the right human in the loop, you know, checkpoints so that you are not quickly veering yourself off into biases.

I think it's all, these are all critical equations when we are implementing an AI solution at this point. Mm-hmm. Um, what's your best advice to folks then?

Because I think a lot of them are trying to navigate this whole, um, expectation, shall we say, and there's some irrational exuberance maybe, and then there's folks who are actually trying to do some things and they quickly come up to the limitations of ai, and then there's kind of this, uh, awkward moment between reality and expectation. That's, that's, uh, fair. I think at item minimum, uh, simplifying, for example, a meeting happens, notes are taken, you know, action items are given, uh, but then you might forget by the time you reassemble the next week, right?

So how can you utilize some of these, uh, you know, innovations like co-pilots of the world, the meeting transcriptor, the summarization to prod you into making sure you are not, uh, you know, putting things off the plate, right? And making sure the key priorities are addressed. So start small.

That's what I would say for any customer who is venturing into, you know, the AI world, let's make sure where are the pain points in your business processes, where the LLM is rightly fit for solving those pain points. So that could be a lot of language driven, like what I just explained, right? Like the, the invoice processing in a digital world setup or meeting transcription or even media processing, for instance.

We are not just talking about just the language as a text. We are also, you know, we can identify a shop floors CCTV footage and then look for scenarios where there could be a safety hazard. So even that can be, uh, you know, the, the prediction around even media processing has tremendously improved.

Where you are able to ask, um, services like Amazon Bedrock or, uh, you know, Google's, uh, own, uh, AI engines, you're able to ask questions on, uh, is this a safety scenario valid or are there certain violations you're seeing in this particular image frame? And there are good responses that these large language models are giving. So as long as you define a use case, apply a technical architecture specific for that use case surrounded with guardrails that will ensure that it doesn't go off in a tangential manner.

I think that's one step at a time to really get to that ROI that organizations are looking for. Mm-hmm. Do you think, um, we are about to maybe build more software than we have in the last decade, in the next two years?

Some people would say, and I guess I also wonder, uh, what the quality of that software may be, and then how relevant is that quality? Because maybe a lot of these apps are more, shall we say, disposable Actually, that's very much, uh, you know, my, my mind thinks as an app developer myself, uh, uh, you know, the, the whatever we have developed in the, let's say it used to take three months, can now be done within five to seven days. You know, that's for a fact.

You know, with the, with the coding engine, the, uh, the, you know, developer, uh, uh, ai, uh, suite that we are all getting now, uh, auto complete of code, uh, you know, certain frameworks, UI frameworks, for example, you know, that you are not expert of. Now, suddenly you are equipped where you want to adopt a certain UI framework and then build your application. It's possible now.

So as you said, the development time itself has started really, really coming down. But then the validation and making sure the business process doesn't, you know, these are all like the graphical engine, right? So it could take a straight line path, which is your, let's say, uh, a success path, but the success path could also be taken through another seven or eight different directions.

So what will happen when a user navigates through a workflow and, you know, workflow number seven is kind of taken up. What exactly will be the impact? What's the user experience?

So there's a lot more emphasis, I would say, on, um, on, on the guardrail setup, on the user experience and the effect eff efficacy of the results more than the coding itself. That's how I'm seeing that the whole landscape to be evolved. Uh, you know, less time on coding, because you should take advantage of AI when it can, when it can autofill code for you in, in a, in almost, uh, you know, using the right best practices, but at the same time, keep a, keep a Sherlock Holmes eye, you know, that you are looking for, uh, looking for certain, you know, the, the rails.

I mean, the guardrails is such a beautiful word, because if the train flies off the rails, you know, you are, you are going to have a crash. So make sure those guardrails is extremely critical for you. Mm-hmm.

Um, and yet you will hear people talk about, uh, token sticker shock where they're building the software and they suddenly wake up and they go, wow, all these inputs and outputs are costing me a small fortune. And to add a little insult to injury, once the app is built, they deploy it. And because it's so verbose, it consumes more infrastructure resources than ever, and people are suddenly noticing that their cloud costs are a lot higher.

Absolutely. I think, uh, it is information overdose. You know, when, when, particularly when AI tries to be true to itself and tries to tell you how beautifully it has understood your question, and, uh, you know, tries to expl explain it in a verbose manner, uh, it it kind of, while it is good to see such a detailed answer, sometimes the actionable part goes, you know, missing.

Right? And that's why I think it's important to associate that use case as to what do you really want to see? Uh, I would always advocate for explainable ai, which basically tells why I have chosen this decision for you, uh, rather than just saying, you know, a a 200, uh, lines of what it could all mean for it, right?

So essentially make your AI systems pointed decision oriented, because ultimately when you make these small components that are decision oriented, you can connect them easily into that agent AI platform, right? So that's how you are, you should start thinking, uh, of finding, how can I get to that decision oriented yes, no flag, probably as simple as that, but more importantly, it's able to explain why did it tell as in yes or a no flag, uh, you know, when you want to know about it. So, so that way the sticker shock could be well controlled, uh, have an architecture that really looks for decision making criteria, make sure the guardrails are followed and an explainability is constantly tracked upon.

Mm-hmm. So is there something beyond the LLM, I mean, you know, I kind of feel like in a certain level, a lot of the tech in the LLM is well, amazing, is, you know, we've kind of been around for a long time and we've just basically threw a lot of horsepower at it. And I wonder if, you know, there's some other a AI innovation down the road that may supplant that, or is it just a question of kind of fine tuning LLMs from here on out?

I think, uh, definitely LLMs have provoked our thought process. I would say I definitely, LLMs are not the end game. They are just the beginning, because again, humans interact in language.

So the naturally the language based model, uh, was immediately, uh, I would say we were, we were able to retrofit how it could be useful for us, such as the notes taker or a transcript summarizer, and so on and so forth. However, our human brain, as a, uh, mentioned at the beginning, it's extremely complex, right? And it does all of those work at fractions of a compute power that these LLMs are unable to replicate purely by just prediction engines.

So there are innovations going on as, uh, as I understand, uh, you know, from all these, uh, while there is always AI race as to who will really control that AI operating system, right? Which basically can do, uh, all that you're thinking of, um, it's going to take few cycles. Uh, at this point, I would say in 2025, agentic AI has taken that next leap towards performing some form of automation and not just giving a verbose overload of information.

Uh, but then there are, uh, still, you know, lot more innovations going on in that recurring neural network, you know, beyond just language. Uh, I'm, I'm excited to see what's on the other side. Uh, but one thing I would say is, uh, LLMs where, uh, where the first, I would say to open the gate, but then the castle is still few, few meters away.

All right, folks. Well, you heard it here, LLMs. It's just the opening act and all kinds of great things are starting to happen.

And buckle in. It's gonna be quite a ride. Serene, thanks for being on the show.

No, it was great talking to you, Mike. Thank you. All right.

And thank you all for watching the latest episode of the Techstrong AI Leadership Insight series. You can find this episode and others on our website. We invite you to check all those out.

Until then, we'll see you next time. Hey, everyone, welcome back to our Tech Drug TV coverage of AWS Reinvent 2025, sponsored by our good friends at suse. You know, we've been doing a couple of panels.

I love doing the panels 'cause we get a lot of points of view, and we've got some really, really smart people that I, I enjoy learning from. Let me introduce you to our smart panel for today. I'm gonna start on the far right with Rick, and I'm gonna let each of them introduce themselves because I'm not smart enough to remember all their names and titles.

But Rick, why don't you go first? Sure. My name's Rick.

I'm the general manager of the Linux team at suse. Wonderful, Excellent. Uh, manup, I lead all of our business and Linux application partnerships at AWS And Margaret Dawson.

I also love Linux, but it's not in my job title. And I'm the Chief Marketing Officer at suse. Excellent.

Thank you all. Rick. The other two folks gave their last name.

I'm gonna call you out. Sure. My name is Rick Spencer.

That's what we want to hear, Rick. 'cause there's someone at home who says, that's my dad, my husband, my someone. I Think I kids', mom, my kids probably know my name, but name, if you wanna find me online, I'm Rick Spencer.

Three, all one word on all my social media. There we go. Who's Rick Spencer?

One and Two. My grandfather and my father. Oh, that's Cool.

Okay. Really? Yeah.

Very cool. Well be that as it may though, we're here to talk about something really important today. You know, I wanted to start this conversation off with, I, I've been been a user and, uh, a my name is Alan.

I am an AWS user, um, for a long time. And you know, it's funny, when you start, you first start, I don't know how many of you have been on, I assume you have, have done on your own AWS journey, but you whip out your credit card, you open your first instance, it's easy peasy. Mm-hmm.

Right? Pick. I'll go with the default Linux, and I click that.

I'll click one of these, eh, gimme two of those. And, and it's very simple, but these things have a way of, of like being like rabbits where they breed and they, and, and, and at each level it becomes more complex and more complex. And then your, your cohort at work, he's on his own journey and she's on her own journey.

And then someone says, how many instances of AWS are we running on this table? Everyone gives the face. I don't know.

It becomes a complex kind of thing because maybe you didn't pick the same Linux I'm running. Maybe you didn't pick the same configuration manager mm-hmm. Program mano, I'm sure at AWS you guys know this journey well, where one day you wake up, you know, and then give, gave rice the whole finops movement as well.

Right? It was part of it. Yeah.

Right. What do I, my goodness, what am I managing here? What do we got?

How do I know what we have? How do we, how do we bring order to this chaos? Right?

And it, it's a problem. It's a real problem, right? For, for most organizations, especially at the enterprise level.

Rick, I don't know, do you see this problem OnPrem as much at suse? Like, 'cause SUSE has a lot of on-prem enterprises as well? Or is this kind of a, a cloud specific?

Um, I would say it's not cloud specific. So what we see is that in a typical enterprise, they're abs absolutely managing a multi Linux estate as we, as we put it. And, um, there's different reasons that lead to that.

As, as you mentioned, like the ease on a cloud provider for like, you know, picking a workload, launching it without, you know, giving thought to what you know, what you're gonna do in two days when there's time to apply updates and et cetera. Um, also, um, you know, different, uh, different ways of running workloads. One company might acquire another company and that company had standardized in a different way.

Uh, so this is one of the reasons that our multi Linux manager tool is so popular. 'cause that allows you to manage any Linux anywhere at any scale. That's very useful in AWS environments.

'cause you know, EC2 customers may be managing, you know, workloads from, with all different, um, oss, not just suse, of course, Amazon, Linux, you know, other, other, other linuxes. And so that's, uh, a really good option for if you're an EC2 customer, you want to get like a pane of glass that'll help you make sure things are being up to date. Multi Linux manager will help you apply, uh, policies.

It'll help you mirror repositories so that you can, um, you know, operate with the utmost safety, et cetera. I think this goes to some things we've talked about a lot this week already, where an AWS and SUSE are very aligned in providing that choice. I mean, people may not realize that when they spin up an instance in AWS you can choose from a multitude of different linuxes or, or Kubernetes.

I know we're gonna move to that in a minute. But, um, I think the importance is that we're now very, very focused on how do you help people understand those different environments? How do you help people manage those different environments?

Have more of a, you know, single control plane. I don't actually believe in a single pane of glass. I don't think we can even do that.

But like, we can help you have better visibility. How do we understand the cost better? How do you integrate finops different things?

So that's really where we are today. And then, you know, part of that is then how we integrate ai, because that's helping you automate, helping you do things more easily. So I think the original demand and ease of use that came out of AWS, you know, initially that allowed developers to spin all that up and have that choice.

Now people want a little bit more control, a little bit more management, a little bit more visibility while still giving developers, while still having choice, correct. While still having choice. They're not giving choice up.

That's correct. And still, and ease of use. Developers wanna build an app, they wanna build cool things.

So how do we not take away any of the ease of use? We don't wanna add friction, but for the ops people, for the management, for all the other people that are leveraging, um, that incredible cloud infrastructure, how do we give them more visibility and more management, more control? And I think a part, a part of coming here at Reinvent with all the 60,000 developers and, you know, people who are part of the A Ws ecosystem, I think it's also to put a flag, not, uh, right now, but like what's gonna happen over the next 12 months.

And I think a part of this conversation of managing complexity is also, you know, some of the stuff that, uh, Matt shared yesterday in the keynote around the work that we are doing with our Frontier models. Yeah. And I think that, uh, that the whole idea is that we are trying to abstract the complexity of it.

Mm-hmm. So there is a level of, you know, abstraction, the complexity that is happening, what Rick mentioned, uh, at the, uh, the Linux manager level. Mm-hmm.

But as we progress over the next 12 months, I think we need to talk about how we are bringing the MCP servers as part of this conversation. How do we bring the, you know, the, the big announcement yesterday was around Quick Suite. Yes.

So I think the, the thinking here is that yes, we are having this, uh, SUSE Linux manager that is going to manage lot of the, what is your security posture? What's your packages? What is the profile?

That stuff is, you know, that's beautiful. Now from a developer who just getting started, you know, the people who are doing one servers or two servers, they're not really super sophisticated into the nuts and bolts of the Linux, or as well as for the AWS for that matter. I think we are moving to this natural language processing interface, like a chat bot.

You know, you talk to the machine and the response back. So I think that's where it is very exciting over the next 12 months. I think where we see is integration of the SUSE manager with Quick Suite.

So customers can actually just speak or, you know, in natural language discuss, Hey, what is, you know, how is my overall Linux distribution? What is my cost? How do I manage it?

What my security posture? And I think that really makes it much more accessible and democratizes, and then also gives you more control and you have more control, more choice as well, right? Yeah.

And it also brings in like the Agentic capabilities. And so in some ways, I look at the Quick Suite as like, sort of almost an, an agentic orchestrator. And so you need the primitives there, which are those MPC servers.

For instance, the, you know, right now you can go get multi Linux manager, you can install the MCP server, try it out. Right now, you can go spin up SLES 16. Our, our latest release we released a few weeks ago install the MCP server, of course rancher, um, install rancher, get your Kubernetes clusters in control mm-hmm.

And saw your MCP server, which is great, but Quick Suite really can like help you take it to a next level by allowing you to, you know, run Agentic jobs, which may be, you know, if it detects an issue, the LLM can like make some decisions about maybe I need to log a ticket, maybe I need to use, you know, the other services that are available as part of Quick Suite. Maybe enhance the information with some other things that Quick Suite would know, like, you know, who owns that server in your organization. Mm-hmm.

Is it mission critical? Or is this something that can go down? And those kinds of things.

So I think the combination of like the SUSE infrastructure, uh, using EC2 and EKS and Quick Suite is going to, it'll just be totally different in 12 months how people are managing their infrastructure at scale. And there'll be like more uptime, more efficiency. Um, I'm, I'm really excited to see what, uh, happens over the next 12 months.

You know, scale's a funny word, right? Your scale may be different than my scale. Yes.

Right? And, and so it's relative, but you know, they don't call a WSA hyperscaler for nothing. Right.

Some of this, the scale of, of the, of the install base right. Of, of, of enterprises on AWS is truly massive, massive scale. Mm-hmm.

And to me, it seems like this is a perfect use case for a AI and agent AI and MPC servers, right? Because how else are we going to get our hands around this? I mean, and, and when you think about why do we really want to use ai, right?

It's, it's to do things that, the mundane things, yes. But it's to do things that we, we can't not easily get our hands around. Mm-hmm.

And, and so I, I think it's important. Now, we spoke in the last panel about the strategic nature of the relationship now mm-hmm. Between Linux, uh, between, excuse me, between s and a and AWS.

They're around Linux, around rancher and around Kubernetes and all of this. But I don't think you can mention those three or four things without now mentioning AI as well, because this is an AI assisted model. Mm-hmm.

We've seen a lot, as you mentioned, man, there was a lot of, uh, announcements around AgTech and a AgTech AI and AI in general yesterday. Rick, I'm gonna throw it to you and then we bounce it around the panel here. How, you know, 'cause this is a 12 month roadmap, let's say, but who knows?

This goes real quick. How quickly do you see suse, you know, taking what was announced this week, internalizing it, if you will, and, and reflecting it on what's available in the marketplace? Well, I, I would argue it's happening right now.

And that SUSE is uniquely positioned for this. I think only SUSE has a multi Linux management tool. Only SUSE has a multi Kubernetes management tool.

Um, only SUSE also has a, a Linux distribution that's made to work with that. Um, now, um, if I may, I, I would caution people to think about, like, if you're just grabbing an MCP server, hooking it up to your LLM and letting it, like, do what it wants to do, that's probably not a good idea. Because if, you know, if you just take the approach of just exposing the API to an LLM, we've all read the tragedies of like, LLMs deleting production databases and stuff like that.

So the thing I would say is that, you know, if you look at SUSE's history over the last, what, 25 years, you know, we've been really focused on like security, safety, compliance. So we're very carefully building those agentic capabilities so that they fit into a real, real world workflow, you know? And, um, and I, I think we're probably the most trustworthy company to actually like, bring all of the, uh, power of the quick suite and all that agentic orchestration that people are doing, like, into the operation space.

I Think it's gonna call. Thanks, Rick. I think I wanna call back to your point about scale.

Like a, a company scale is different from B'S companies. I wanna highlight, uh, that SUSE and AWS have been partnering for two decades now. Mm-hmm.

And so we have thousands of customers that are running mission critical workloads, both on the SUSE rancher offering as well as stress. And these are, you know, company, you know, workload, like high Performance Computing, SAP. So, so customers are really, they love the fact that the two companies have been working together.

There's a level of trust and we are supporting mission critical workloads for a long time. So I think Agen is just the next chapter in this partnership. I think we spoke already about managing the complexity of Linux, which is distributed across AWS and across your multiple, uh, multi-cloud environments as well as on premises.

How do we bring this back into, um, you know, a quick, uh, suite view, and then we can actually do real time analytics on that? We spoke about that. I think that then this entire narrative of abstracting complexity mm-hmm.

Then extends to container workflow. So with, you know, the, the rancher manager, the SaaS application that underlie underneath uses, um, uh, bedrock. So then, again, similar to what we discussed in the next, in a natural language interface, customers can say, Hey, what's the status of my clusters?

Uh, what is the cost associated with it as you discussed? That's a big, uh, that's a big concern as well. And then, uh, how do I manage it?

And so I think, again, it's all about democratizing, making it easy, uh, for our customer. Then, you know, we have a track record of doing it for two decades, and, uh, we just going, this is the next evolution of, I think there's one other piece of this strategic relationship is that we're doing this, you know, we talked about choice across very heterogeneous environments in terms of multi Kubernetes, multi Linux. Like, we're kind of embracing that together.

What the AI does is take all of those, you know, very, um, disparate sources almost of data, and is does such a great job of bringing that together, just like we make it easier to manage all those disparate, you know, flavors of Kubernetes and Linux. So it, you know, there's these kind of thematic ideas that both companies are embracing, and it is about lack of complexity, but it's also about ease of use, ease of management. Um, and then I think the other piece that SUSE brings is that open source heritage into AWS that came with the supplemental packages on Amazon Linux.

So it comes back to whether you're using SUSE Linux or Amazon Linux, how does SUSE support that and make it even better, bring you the technologies and tools you want as you're using Amazon. You know, how does Amazon allow you to have a choice around that? And I think that is a very unique and differentiating, um, partnership.

Yeah. Right? Because we're bringing you the stability, the security, the scale.

Nobody scales like Amazon, right? Nobody brings open source technologies in a secure, more stable way. And then we're also giving that choice and control of heterogeneous, heterogeneous environment.

So I, I think that combination of all those things is really powerful for the customer. Absolutely. I, I, I couldn't have said it better, Margaret.

We spoke MPC service. Yeah. Everybody has an MPC server today, it seems.

Right? How many MPC server do M-C-P-M-C-P, excuse me. Mm-hmm.

I forgot what MPC thinks. I don't know. We should make something Multi players gaming.

It's, it's a multiplayer console. That's what I'm saying. That's what, well, that's where my head's at.

Bring out the Xbox. Okay. Yep.

But you know, the, the problem I like, in my mind, I'd like to see Amazon come out with an open source version of the server that everyone could standardize on. And then souse, you could build your special sauce on top of this. In other words, how many different, like right now, how many MCP, right?

Yeah. Mm-hmm. Now you have me questioning myself.

Um, how many MCP services? So I think one of the things we discussed, um, so first all, I think the standard spec for CP is, is open source. Yes.

It's Similar with A two A in terms of how the agents think open source, um, more than, uh, you know, we launched this CP server slash agent tech slash AI marketplace back at the New York Summit in July. So we have thousands of ISV as well as products that are listed. So I think now, at this point in time, um, the customers are really transitioning from piloting over the last year.

I think that's our, our thesis is over 2025. A lot of the piloting, a lot of testing, and 2026 customers are really going into production around that. So I think, uh, so everything that Rick and we discussed in terms of exposing the capability of, for example, the thing we discussed about either rancher, uh, um, you know, manager, or whether the SUSE Linux manager, the MCP is just like, you know, uh, is just an interface into managing that.

Uh, you know, and how does it talk to an LLM? Mm-hmm. And then we bring that all of that, integrate that into Quick Suite.

So that's where the customer is, customers actually doing a natural language conversation with quick suite. Either it is text or it is voice. And then, uh, we abstract the complexity way or through the MCP server in the MCP client in the background, all of that insights, whether it is the state of your Linux operating system, whether it is how your Kubernetes cluster is doing, what is the security, what is the posture, the cost, all of that comes and says, Hey, I, can you give me, and for example, a question would be, can you tell me how many Linux distributions that I'm using across my state here?

Mm-hmm. What is the status of my Kubernetes? Just gimme an overall view.

How is the cost trending over the last three months, six months, nine months? Just gimme a and what can I do to optimize? Those are really powerful things right now would take, you know, days and weeks for somebody to pull that entire view together.

I think we are in the next 12 months where we are heading is to consolidate the view to one. I, I would like to, um, well, first of all, if I may, if there's any viewers who are like, what is exactly MCP and how it's working. So think of it as basically like a shim between like any tool and an LLM.

Mm-hmm. And there's two main parts to think about. And the first part is like context, right?

You tell the MCP server tells the LLM how to ask for context, right? So how do you query for logs and that kind of thing. And then the other part is tools or tasks that the MCP ser that the LLM can actually take, right?

You, you tell it, you tell the LLM, you can actually go do these things through the MCP server. Mm-hmm. And, um, so it's actually relatively trivial to stand up an MCP server in the same way it's tri trivial to stand up a, a website.

Mm-hmm. Right? However, designing one that is usable in production in the way that we're talking about is non-trivial.

And so, um, that's why, uh, we're like really excited to be working with Amazon to expose like our very careful painstaking work to like, you know, bring those natural language queries and those automated actions, like into the operations and administration space. And then exposing that back up to, to the, the quick suite where it can bring in other contexts that, you know, were are not being provided by our tools and other actions that, you know, are, are exposed to other tools. Like think of something as simple as like logging a ticket in your Atlassian or whatever mm-hmm.

Your GitHub or et cetera, right? So it can like, ask our tools for, you know, is everything looking okay? And it might say it's looking okay, but a little shaky.

Let me log a ticket so that when your admin wakes up in the morning or it's looking really bad, let me use your PagerDuty and wake something, somebody up. You know, these are the kinds of like very trivial examples of the kind of workflows that people are gonna be able to build in their, um, you know, using the, the, uh, quick suite along with our MCP servers for our management tools. So mm-hmm.

Mm-hmm. I wanna return to money. So it's always on top of everyone's money.

Ronnie, you mentioned a little bit, we, we can actually through Quick Suite ask the ai what can we do to optimize, you know, you wanna call it thin ops or whatever you wanna call it, but optimize spend cost. Um, how, I mean, it's one thing to ask and get some suggestions. It's another thing to say, okay, you gotta close this, move that, do this, do that.

How close are we to automating that? Like, so for instance, when I write something with ai, right? It says, do you, would you like me to do this?

Yes. Mm-hmm. And it does it, right?

That's, to me, that's the money shot, right? Can we do that now with, with the Linux, with this relationship and, and with what we have there? I mean Sure.

Like, Do you want to though, is question. Yeah. So the way that we actually have implemented, like our, our logic is like, you wouldn't let an LLM do something, right?

That you wouldn't let a team member do, right? Like no sane SRE team let somebody just like log in and make a massive change without a code review, right? So if you look at some of our demos and, you know, come to our booth, we can show you, you know, for it can, you know, write the recipes and scripts, check it in for you, start the code review process, you know, which is what you would expect a human to do.

The only thing is it can be done a lot faster with a lot more context. You know, the LLM handles complexity in a different way than a human does. But, um, that's to go back to what I was saying before, like that's really why I think you wanna partner with a company like suse.

'cause we take that very, very seriously. Like, you know, making sure that your, uh, infrastructure is protected and compliant and following all your compliance guidelines, while also giving you all the efficiency gains that, you know, admin teams are so hungry. I think like absolutely, I think in the enterprise setting, this is still, uh, it's still a, uh, A problem that everybody's working on.

Mm-hmm. I think if you saw, again, Matt's a keynote yesterday. He talked about everything that we are doing around guardrails and policies.

Mm-hmm. So I think there is a lot of active work that we are doing both at the LM level as well as through quick suite in terms of how do we manage and police, uh, you know, the, the actions that the LL m's taking on behalf of the customer. I think have we, are we there fully?

I think to Rick's point, um, you know, we can create guardrails. We can train data. There is already like LLM looking at the LLM to make sure that, uh, you know, we are in the state and narrow here.

Uh, and I think that's where we, we discussed like 2025 was a lot about experimenting. If we have to get to the scale in 2026, get into production, this is probably the most critical, uh, thing that we have to, you know, cross the chasm as they say, uh, to get, to make, uh, enterprises comfortable with, you know, taking that leap. Yeah.

I think the question is when do you want the LLM to take that action versus you still want a human in the loop, right? And I don't think we're done with that conversation, right? There's still gonna be times where you want a human to push the button, so to speak.

Um, you're not gonna give the LLM access to your source code necessarily, right? Um, even if you want it to help you develop in your way. So I, I think there's still some, um, ongoing discussion and of where the human in the loop is, um, even with all the guardrails and all the, the, the governance that happens.

But I think the more you can automate all of those things and bring us intelligence faster, better, cheaper, right, then we can make better decisions. Yeah. I mean, I mean, we all agree though.

There's a massive push to get into that direction. I think the, the value and the opportunity is, is tremendous. Mm-hmm.

Yeah. And so that's why everybody's just, uh, you know, kind of run, you know, running for, well, I, you know, so you ask yourself why, why, why, why must there be a human in the loop? Well, there's two reasons.

Number one, is the underlying technology good enough where I could tr I i, because it comes down a matter of trust, right? Mm-hmm. Can I trust it by itself?

You know, I, I was driving my car on the highway a couple weeks ago going to the airport and it said, Hey, why don't try our, it's A-B-M-W-B-M-W assisted driving. I said, all right, let me try it. I'm by myself.

No one will yell at me. I, I, I hit the button and it started driving it, it take your hands off the wheel, take your feet off the pedal, just sit back and watch. And I, I, I found myself like this.

Yeah. Right. Sitting wait, ready to pounce on that wheel.

And you know what? I never had to, it, it took the turns. It, if I put on my signal to switch, if there's a car there, it tells me no, if there's no car, it speeds up in switches.

It's a very similar experience to trusting the, the LLM, the, the AI to do these things. It, it's gonna take time until you take your hands away from the steering wheel and put 'em on your lap. And, but we'll get there one day I think, I don't know if I'll be here, but we'll get there.

And, um, it's, it's, it's coming for sure. Like, there's no doubt in my mind this is the way of where we're headed. I mean, I think it depends on how you look at it, right?

Because if you think of like the driving analogy being that, um, the LLM is changing your infrastructure like directly, like that makes sense. But if you think about the way people actually manage their infrastructure through like Ansible and Salt and other tools, like we're there right now, like the absolutely can generate like perfectly serviceable Ansible scripts that can go into your, into your whole GI ops workflow. And people can, can, you know, your other GI ops team members can look it over, other LLMs can look it over and make sure, like, does this meet our security compliance and et cetera.

So, um, I, um, I think the technology is there as they want said on a TV show. We have the technology. Yeah.

But do we have, I like a lot to explain a lot of that is deterministic in the sense, we know there's like A to B2C, everything is free track. I think the LLMs is non-deterministic, some part of it. Uh, so I think like once the technology's there, there's already a pattern here that, you know, the customers trust and you know, yes.

This, they're already deploying mission critical workloads through, you know, salts scripts and such. I think the, I think the, the LLM in itself has to, has to evolve to get there, right? And I think right to Margaret's point, we are still, I think for 2026, we still foresee the human in the loop.

It's gonna play a very critical, uh, thing. Yeah. Critical role.

Yeah. Agree. I mean, there are, there are patterns in like in for instance, Kubernetes, you can set it to like auto scale and different things.

Mm-hmm. So like, I think, um, a lot of it is like what RAC, what role-based access controls do you give the LLM? And this is already a very common pattern, right?

Like a lot of platform teams will say like, Hey, our ops team is allowed to scale out, but they can't scale down. Or similar things like that. And so I think we'll see over the course of just literally the next 12 months, like patterns like that being brought into like this is a tool that we can give the LLM to just go ahead and do it.

'cause they can't do much damage. Like they could create a new table, but they can't delete a table. I think the question is like, do you use, does ZLM put out patches to all the unpatched systems?

And you're sitting like, do you trust it enough to do that or not? Do you let it roll back a feature update or not? Right?

So I think there's like a level of specificity or Certain kinds of patches, right, exactly. Maybe. Yeah, exactly.

Or not, right? Yeah. And I think just one last point in the race to get to that determination, like, you know, the best state here where we can start trusting the LLM apart, a lot of it is actually training and what data that we are training the LLM on.

And in fact, and in fact that, you know, just SUSE has decades of, uh, data in terms of how customers are using both their Linux and the Kubernetes distributions for AWS You know, what Matt discussed yesterday are the frontier models around developing code on deploying code and running security. So we are running as you know, as said, hyperscale, right? So we have like tons of, you know, supporting millions of customers, uh, over a couple of decades now.

So that data, and then what is the learning that we have done as a function of that, that informing some of the, the new AI or the new elements we are developing, specifically what that specific workload, I think that is probably the path to getting our customers more comfortable into deploying it and production use cases. I think that seems like the, the road to get there. Mm-hmm.

So there's been a great discussion, but you, you know what I'm worried about people looking at home. If they're watching this, they're probably not here. How can we get them started?

How do we, these are all great things that we spoke about, right? Really kind of job changing. If you're a, a Linux administrator or an AWS administrator, Rick, I'm gonna start with you.

Where do people go? How did they get started? Where's the on-ramp here?

Sure. So, um, I would say for a call to action, if you want to get involved, go to the marketplace. You can get multi Linux manager there.

You can get SLES 16 there. Go ahead and install the tech previews for the MCP servers, start giving us feedback, you know, what's working for you, what's not working for you. That's exactly why we put it out in, uh, in as a tech preview so that we can iterate quickly with the user base.

Mm-hmm. And same is true for a rancher. And, uh, my call to action is do everything what Rick is.

That's an easy one. Plus, uh, uh, you know, try out the new keto, uh, software developer platform, uh, that is becoming now generally available. Also, go look at, uh, you know, some of the new stuff that we are doing here with, uh, the frontier models, both on the DevOps side as well, security side.

I think that is really gonna start, uh, pulling the story together in terms of what, you know, Rick is talking and then yeah. And no coincidence. Those are the three A agents that were announced yesterday, right?

The kiro agent and security agent And the DevOps agent. And the DevOps agent. Yeah.

So you get all of those. Margaret, I wanted to give you the last word. Wow, I don't see this.

Now you've got me speechless. No, I think I'm just really No, no, no, I That down. I was just gonna say that, that last two days, which feels a lot longer than two days, but there is just so much energy in this show.

There's so much energy around Amazon, around ai, around just how to collaborate. And, and again, I'm gonna go back to, I know this is becoming a repetitive theme, but, you know, continuing to look at the ecosystem around AWS and I would say it is our ecosystem and AWS's ecosystem and the power of how all these companies and all these technologies are coming together to help people, you know, build applications that are better, faster, smarter, more secure, um, and, and deploy them, you know, what works best for them. So I, it's just exciting.

Like there's just a lot of enthusiasm, great tech At, at at great scale too. At great scale and great technology. Rick, Manu.

Margaret, thank you so much for joining us on our Tech Trunk TV coverage. We're gonna take a break here on Textron tv. We've got lots more coming at you today and tomorrow, so stay tuned, but we'll be right back.

Hey everyone, welcome back. We're here at AWS reinventing our suite up at the wind, continuing our coverage of this year's event. This gentleman on my right, I actually, I think the last time I saw him was at Reinvent.

I don't even think it was last year. Evan, I think might been two years, was the year before. Yeah.

What a great, but he's a, a wealth of information and, you know, there's six degrees of separation in tech. He's probably his three degrees of separation with this guy. He, everyone I know knows Evan Kaplan.

Oh, geez. You run in some bad circles. Yeah, I guess I get that's maybe what it means.

All right. Evan, of course is the longtime CEO of Influx database. If you don't know influx database, shame on you, but we'll, we'll tell you about 'em in a second.

Evan, it's good to see you first of all, man. Nice. Alan, thanks for having me.

A pleasure. Um, you know what, let's start with Influx database. I, look, I'm going to guess 80, 85% of our audience may even be using influx at some point, if not now, Some high percentage.

Yeah. Well it's, you know, our people are your people. They're, they're, they're tech people, right?

So, but for those who maybe aren't, they don't, they've never heard the word Time series database even Explain to them, if you can, what, what we're talking about. Sure, Sure. So first of all, InfluxDB is an open source time series database really is the first open source time series database.

And, and by all external measures of leader by big margin in the space. Mm-hmm. 4 plus million people who run it daily million sites run it daily from the largest corporation down to, you know, down to people using it at home and that sort of stuff.

Mm-hmm. And so our, our primary, let's call it invention or innovation, was by my partner Paul Dix, who in 2013 made the first commit. He had worked on Wall Street and had built a number of time series databases on top of other platforms, HBase, sql, things like that.

And, and it turns out that there's enough difference, enough handling enough optimizations that are available, um, when you're working with this kind of data that it made sense for it to be one of those categorical databases like search, like document like graph. Mm-hmm. And so he's generally considered the person who sort of invented this space, a modern version.

The first version of the product was written in Go, it had collectors now a project called Telegraph, which is actually more, more popular than the database. Really? Yeah.

There are about 400 different collectors for virtually every system out there, physical and virtual you can imagine. And so it's a super vibrant community. We've stayed with a promiscuous MIT Apache license model, so anybody could use that.

You use it and do. Yeah. Yeah.

And if it's worth, I just as a refresher for the audience why, what, what, what time series is, why is it, what do we mean, right? Why is it? And so really it's quite simple idea, which is anytime your primary tag, anytime your primary index is gonna be based on time, you can be incredibly efficient at handling large volumes at super fast.

Um, actual real time kind of, um, kind of, um, querying and ingesting and things like that. And so if, you know, you're gonna have that kind of application, IOT physical AI network telemetry, where you're gonna need that kind of speed, this kind of huge ingest, you start by building on the crime series specific platform. So you get away from these very discreet indexes that take time.

You get away from these, these latencies associated with queries that have to be, you know, aggregated in different fashions. You also have to do a bunch of things. You wouldn't, you have to downsample you start with high resolution, maybe even millisecond resolution, and maybe you wanna downsample to a minute.

You have to evict a lot of data. So just a bunch of stuff that you would do that a normal database doesn't do. So the category has really emerged strongly.

So we're not the only player. We have good competitors. Azure offers something now Amazon offers us, like, so it's a market has taken off.

All that's too long. But no, no, it's not too long. You know what, for people who don't know what a time series database is that I think it's necessary.

Look, for me personally, when I hear time series, I think influx. I think because you had the open source model and, and the commercial offering, I, you know, there, I know there are other time series ones, but other time series databases. But, you know, the database market isn't what the database market was when I was much younger, right.

And, and we do have, we have graph databases and vectors and this, but when, when Paul Dixon did this in 20 20 13, made his first commit, He wasn't thinking about, well, how's this gonna work with generator of ai? Right. He did have, his background was in machine learning, really.

He wasn't completely blind to it, but no, he wasn't thinking that. And correct me if I'm wrong though, this is really the, the whole AI thing. Well, AI's helped a lot of the data, data collection, data storage, you know, access data's a big part of it, but it, it's been a particular boon for, for time series as well though, right?

There's some real use cases. Yeah. A certain, a certain, a certain kind.

So, um, if you just sort of, you know, you break the world into, and it's increasingly become apparent, you have generative ai, which is largely the scraping of the digital world. Yep. So anything, you know, and now we've scraped pretty much everything that's available and every day we scrape it again.

And so there is a real shortage of digital, digital data, images, all that sort of stuff, because most of it's been scraped in some sort of way, scraped clean, and it's, and it's, and it gets, and it gets indexed every, you know, every day. That is not. And so the issue on, on the generative side is you have to create synthetic data in order to build these models.

We're gonna to make, make it more sophisticated and that sort of stuff. But the opposite is true on the physical side, right? If you think about the physical world, the amount of data available to index is, is, is infinite.

Right? It's just a question of what resolution you want to capture it, how often you want to capture it, and that sort of stuff. And so what what we're most excited about is, you know, as 'cause of our iot orientation is the physical AI world.

Because, you know, the, the notion in physical ai, the idea is I want to get a near perfect picture of the physical world to build my models around and to act on that world, right? To build my intelligence around. And so the only way you get that is by willing to take sample measurements that are really, really Close, like time intervals.

Yeah. Yeah. So our default, our default timestamp is nanosecond.

Really? Yeah. And so we have some customers in quantum world who use that, but most, most, you know, you're not nanoseconds.

No, But you know what, there was, I forget his name right now, I apologize, but he was like the chief AI scientist or one of the chief guys at Meta who just left I, John Lako. Yes. Yeah.

And he said, because we're probably coming to it, I don't wanna say a dead end, but, uh, uh, diminishing returns because of the problem you you've outlined here, right? Yeah. Which is we scrape, there's not much left to scrape.

And that the LLM model only works. It, it, it can't imagine a sphere in open space and how it's gonna fall with gravity. Well, let's say right?

Where it, so he calls them world models, right? Not LL m's. And they try to model digital models, the physical world.

Yeah. And, and that's the kind of database, you know, data collection. That's gonna be Huge.

I mean, that's a really, that's what we're most excited about. And if you think about, you know, LLMs are probabilistic models, right? Yep.

Right. And so, and they're brilliantly probabilistic, right? They're actually really amazing.

Um, but you, you know, when you, when you're operating in the physical world, you think of a robot, a self-driving car, a satellite in space, you need deterministic. You cannot live with probabilistic. The chance of your robot, you know, accidentally vacuuming your cat away is just not something you will, you wanna live with, is not something you wanna live With.

That's not, that's not risk I can manage. And so, and you said this, so the notion of deterministic versus is probabilistic is important. And so collecting this data, building your models on really rich physical data, and then being able to act in a control system in a meaningful way, that's the future.

Absolutely. So, hey, we could talk more about that if you want, but I, I gotta bring us back to today if it's okay. Um, so there is the open source, then there's the commercial version you guys offer like a SaaS Yep.

Version of it? Well, We have a couple of cloud versions. Yep.

And we have you, you can run it OnPrem or run it in your own instance, And you could run it in the cloud. I know you've had a longstanding relationship with Amazon with AWS, but you guys recently did an announcement, maybe it was a month or two ago already. Yeah, yeah, yeah.

We have, um, credit to AWS we have a, um, we have a very unique relationship with a, so we were always a marketplace kind of. Yes, you could, you could purchase influx. We run our own cloud services, our serverless platform on Amazon.

Mm-hmm. And so we've always lived in that ecosystem. We've always worked in that ecosystem.

Um, but what's unique is about two years ago, they reached out to us and, um, they were getting a lot of requests because they have all these open source influx TV to run influx on their platform. And so, you know, immediately I was like, you know, that doesn't sound great. We're an open source player.

They could just take the code. Well, it would, And it's not like it hadn't happened before. I was just gonna say there is a reputation there, but go ahead.

And so, so I was, I was a little bit like, okay, let's, let's, let's build some trust here. And, um, and the relationship we have is the first time they've, they've ever done this is they licensed our open source code. Really?

They run our open source code, and then we build the value added enterprise features on top of it. And we monetize that, not in marketplace, but in console. So when a customer configures, I Love it.

A certain configuration, we get revenue AWS So you'd ask why would AWS do that? Um, you'd have to get Brad, which I'm sure you could, who runs, runs those businesses mm-hmm. On, but, but a couple of things.

One is they saw the emergence of time series data, and they do have a platform, but it's, it's of a, it's a pretty, it's a narrower use case than influx. And they were getting a lot. And so just recently they didn't, they stopped taking new customers for that platform.

Oh. Their end of life. So Their primary time series is gonna be time stream for InfluxDB.

And so in their world, that's a one P product. It's a product, their product, it's not influx is product. It's not, it's their Product.

It's based, they we Work with and we are close with them. And we, we work hand in glove on those deals. And we're more than happy when customers wanna, wanna purchase that, go Through through AWS That works for us.

It works for Them. It's a great channel. All that sort of stuff.

Let me stop you Yeah. For a Second. For my people watching this at home.

I, if you are not in this side of the business, if you're a, a consumer of this Yeah, sounds great. They got a good relationship for people on this side of the road though. I, I bet you could count those kinds of relationships with AWS on one hand, You can't even count on one.

I think we're the only one now. I think they will, I think they will do more because it's worked well with us, right. Because they don't wanna work This stuff.

And unique Yeah. You had a unique situation where, hey, they don't want to use your good luck. Go use what you want.

You know what I mean? And, and there was no choice. Right?

Uh, influx is the bomb as they, you know, the shizzle. Oh, I'd like to think we have that kind of market power. I don't think we do.

Oh, I, there are, but I'll tell you, as someone who sits here, I don't have a voice in this race. Okay. I appreciate that.

It's kind of like secretary, we certainly don't Operate, we certainly don't operate without Mindset. Don't let it go to your head. Stay humble.

Stay humble. But when I see, I mean, it's few and far between that we hear of another time series. The hyperscalers have their in-house one, but you know, that's the old 80 20 rule.

Yeah. It's 80 20 rule. That's exactly Right.

80% of the function, 20% price. They're good if you wanna hit the easy button. And so if you decide you really wanna Build something, but if you're serious about time series data.

Yeah. I, I get it. I guess, though, it begs the question, question, what about the other hyperscalers?

What about some of the other providers? Well, it's, um, we still run, we run our serverless platform on Azure and Google. Okay.

So those are available, um, it's likely what the announcement of last week was, not the, the relationship, it was the, the introduction of our version three into the Amazon. Oh, okay. So that happened a month and a half ago.

And that's what we're most excited about. That's our canonical version. Now, that's where over time we'd love everybody to land on this version three, which is a almost a complete rewrite of, is it?

Of all, yeah. Of everything we've learned over the past 10 years. Let's, let's hear about some of the, Yeah.

So version three, Killer features here. Yeah. So version three, um, we just ran into a number of issues as, as customers scaled on our older versions.

One is cardinality, and I know you're familiar with this, but maybe your listeners aren't. When you get, you know, when you get the exponential, you know, the number of tags and the number of descriptors exploding, it can really choke off a time series database. It doesn't, it's not much of a problem in observability world.

But in iot world, it's a pretty big problem because you can have tremendous variations. Sure. And so cardinality started to choke off on older databases on that model.

Um, compute and storage were linked together. So that was expensive as you scaled, right? Most, and most databases are that way.

But, but, um, unlinking them, we didn't support Native SQL before, really. We sorted influx ql, which was sql, like, so you could use it, but like all the business applications, the other stuff that WeQ Q SQL you added, And the tools that were built, built for SQL weren't, weren't, weren't optimal. Um, and so we, we ran into those problems.

And so we, we started writing this about four years ago. We wrote it in the open source, and we wrote it in Rust. Really, The original database was in Go, we, one of the early offering Docker And go, but we in Rust.

And, and Paul and the team had decided that Rust was gonna be a much stronger platform over the Future. More secure For memory, safe, more secure, just a better platform for running database. So that was a rewriting rust.

And then we built it on object storage as the data storage, which, so you could have long term retention without worrying about. That's great. And then we obviously started sql, and then we did some really other interesting things.

So we scaled it differently. We scaled it horizontally. We, we always scaled horizontally.

We just scaled it differently. So it was much easier to duplicate. Mm-hmm.

Um, and then mo probably most importantly, we built something, a processing engine directly into the database Right? In Into database. So there are probably six or seven triggers in the database that the processing engine can call.

And anybody can write a Python application script or anything to use those triggers. No kidding. So if you want ETL stuff on the fly, if you want to transform stuff, if you want to down sample stuff, if you wanna do anomaly detection, all, all of a sudden developers can write their own stuff and actually exercise it in real time at the same, at the same latency, the same performance that any database query would.

So this begs the question, can I set up like a Python script repo for influx for these things? We, We have a, we have one of that in GitHub, right? Okay.

We don't have an, well, what you'd see is a traditional app store, but in GitHub, we already have a repo and people are building stuff. I mean, it's pretty exciting. So the idea is that that helps us move up stack.

And so you want to do forecasting, you wanna do anomaly detection, you build it yourself. You want to do, have To buy third party, Right? In today's world, it's all about scale.

So you took a 2013 database and brought it into 20, 25. Painfully, just wanna say painfully, Well, none of you know, if, if it, if no pain, no gain. Well, It turns out, you know, one of the things, you know, I came from, um, from the networking and security world, not necessarily from the database world when I started here.

Uhhuh, one of the things you realize is like, you cannot accelerate the time it takes to mature a database. No. Like, you can't just say like, I'm gonna have a database built in a year and think that it's gonna be able to scale.

You're not gonna have gigantic. Like it has to run in the real world. So in some ways, now that you look at ai, we're, we're kind of the boring part of that infrastructure, which is fine, but we're the least disruptable part of that Infrastructure.

Right. And, and it's nuts and bolts kind of stuff. Unique thing here though is you have the open source.

How big a help was the community in this kinda re relaunch? There are places where the community was excuse, I don't wanna call it a relaunch, Evan, that's a big Word. Yeah, no thanks.

Yeah. Yeah. Just a, in this, in this, the version next gen, the next generation version, um, the community is super helpful in certain areas.

It's really hard for the community to be really helpful in the database. But, but here's the distinction. We built this based on a bunch of Apache standards, some of which we're the main committers.

So Apache Data Fusion is and Apache Arrow, the, the, the memory format. So we now commit to those and we use that in it. So we took advantage of the community.

And then data fusion, that's our, you know, that's a project where we're the PMC. It's a super popular, it competes with, you know, with with the query planners and engines that are in Databricks and, and in Apple's, proton, things like that. Mm-hmm.

And so that's a big part. So we leverage those. And then we're really also leveraged on the connectors.

Our community's constantly writing these telegraph plugins. And that's the bread and butter here, man. You gotta be connected.

Yeah. And you gotta be connected without ETL. Right.

And you can do that in time series. What about, uh, MCP servers, stuff like that. Yeah.

So we, Jack yeah, I mean, sort of check four months ago. We are now using it in version three, so that people can do natural language queries against, um, against, directly against the database without knowing SQL or that sort of stuff. Some customers are using it.

I think it's really important. It's just, it's not driving our business today. Yeah.

But it's really important. It is. Um, so I, I gotta imagine with Amazon's, with this deal with Amazon and version three out here, you, it must be attracting a decent, uh, amount of buzz at the show.

It's, you know, this show is Crazy. I know, but it is 60,000 people basically. I mean, this show is, yeah.

I don't know what was a decent buzz at the show? Their keynotes are what Casual buzz at Yeah. At the show.

But no, it's in general, it's, we're just in a really good time in the business, having the database out, it having, you know, the level of maturity that we finally need, Amazon coming in, it just feels like a bunch of forces are working. The narrative now in the community is really much stronger around physical ai. And people are paying a lot of attention to that kind of work.

And so, you know, but, but this event, it's, you know, I think, I dunno if you read the keynote, but, you know, I talked to people who were, it's like everything was about agent, agent Ai, it, that it was all agent, agent ai, all Database stuff and all the infrastructure, all the cloud stuff. They Didn't talk about data at all. Yeah.

Database. They didn't even talk about data used to come to, uh, to this show. They talk about S3 and, and Lambda and Serverless.

Yeah. I it's still there if you dig deep enough. Right.

It's not in the main keynote. Not in the keynote. And I get why No, I, I mean, I understand.

I I, so we've spoken about this on our shows. Look, I personally think they needed to show they can go head to toe to toe with Google at Microsoft on ai. 'cause Google has a good AI stack.

Yeah, a hundred percent. A hundred percent Right. The train and processors, all these things.

And For the last 10 years, the narrative is about cloud computing. And so, and now, you know, cloud computing's default now, Right? They don't even, it's mention cloud here.

Yeah. It's all, you're right, it is all ai. Um, I I, I had a question in my mind and I got stuck on this thing with you right here, but I'm sure it'll come to back to me in a second.

But let me ask you, actually, I do remember it. We have, you mentioned graph databases before. That's huge.

Bigger than it's ever been, right? Yep. Yep.

And, and, and the other thing, what's driving a lot of this data is this whole observability space. I mean, you know, it's hard 'cause AI sucks the oxygen out of every conversation we have. But you look at like observability, you look at, you know, the growth in graph databases.

I've spoken to a lot of end user organizations where they're using a time series database. They're also using graph, they're also using sql. Right?

It's, it's not a one database town no more. No. I mean, no.

In fact, you know, my take on this, and you, you and I are of a similar vintage is, you know, when we were growing up in the industry, at least in the early years, there were only two databases of matter. Yeah. It was, you know, Oracle and IBM PB two.

Yep. And so you just choose which one, you know, and then we saw the, the emergence of MySQL and the open source, and that, that stuff probably happened, started, you know, 18 years ago or so. And then you saw the, the taxonomy of dropping into these specialty databases.

Sql, Sql and all of the different No SQL graph and all that. And now those are pretty well-defined categories with, with large competitors. And so, you know, it really, and the ability to assemble the appropriate data models and do it are important.

But I think the important thing is, is the Oracle and IBM of this world that I foresee, you know, are the Databricks and the snowflakes. Yeah. And now the fabrics and the big queries and The, they, they are, Those are the databases, right?

Yeah. We are all, we are all live in that constellation. Our data, if done right, the models are built somewhere in Databricks or Snowflake, right?

Yeah. There, all the structured data, the unstructured data, it's all combined. The intelligence is built there.

And we view ourselves, and this is distinct, and most people don't dive in, not as an analytical database. Even though our analytics are great, we view ourselves as an operational database, really. Yeah.

We want people to build control systems. We wanna build, you know, dashboard, list monitoring systems. We wanna build automation.

We want people to use our stuff And integrate to be active the Right. Right. We don't, I mean, well, because it's Analytics Are there.

Yeah. No, I get it. I mean, you have to be, it's table stakes.

Yeah. But that's an, I never thought of it that way. That's actually a good, So you think about our customers, you know, whether it's Tesla trading energy from the ba, the power walls, whether it's, um, Utah sat, um, or kuper are doing, you know, the early satellite positioning and the change of positioning.

These are all things that are happening in somewhat real time. These are things that Lakehouse can't do. No.

Right. Their latency, the orientation, the cloud. Only half of our customers are three tier architectures where they have stuff OnPrem and in the cloud.

Like, you need, like, it's totally different. It's a very different world, Different thing. You know, it's this whole, the, the, the data, the age of the data scientists, right?

And, and this AI thing is giving them rocket fuel. Yeah. Yeah.

Right. com. So we're very big in platform, right?

Yeah. The biggest element joining that community data scientist, it don't make sense to me at some level, but data scientists are very interested in making sure they have this platform. So where, so This, as you say it that way, so what, what what we see going on, and it's early, is that there's emerging category called the, you know, that, that feeds the data scientists.

That feed these data engineers. Yes. Right?

Literally, they're not SREs, they're not Devon. No, No. SREs that they're Nothing.

Right. These are people who build these pipelines. So you have these distinct database, you have these flows.

They own the engineering. They're like, if you think of it, I mean, we used to talk about Plumbing. They own the platform.

They are the real plumbing. Right? They own the platform.

How does the data move across these applications? How are they made available to the model? Mm-hmm.

How do they operate in real time? That if I could train, you know, I have two college age kids, if I could train them to do a job that I thought would be future Proof, that might be it. com.

org 300,000 strong community. And I'm telling you, those are the two fastest growing elements in that community. Is data engineers and data and data scientists.

Yeah. Yeah. Because that's where the action is, at least right now anyway.

And going forward, it's Interesting. Now it's in the way we, you know, in the, in the late nineties, we the network engineers, right? Remember, remember how important those roles were.

They still are. Obviously. It's incredibly important.

That's how I got into computers playing with Word Perfect. And Novell. Novell, You're doing your IPX land.

Yeah. Remember I was, I don't ask. Anyway, Evan, it's been great catching up with you.

Let, let's, we gotta give some call to action. You know what? Okay, a good, a good marketing person I had here earlier said, you always gotta end with a call to action.

So the call to action is, is if folks are interested in anything, any resource associated with building our role is to make it super easy for developers to start with Time series. The database is super easy to use. Download available on GitHub on our site.

com or do your local chat, GPT search and see how we're doing on Geo. How are you doing on Geo? I Think we're doing pretty well.

I got a note today that a customer told one of our people, we found you. We did a, a search on chat, GPT for DevOps and SRE. Oh.

And you guys came And they, and they sent them to, yeah. That Was pretty cool. Yeah.

It's the world. That world has changed. You could do a whole show of that.

That's a Whole We do. Anyway, my friend, it's great seeing you. It's Good to see you.

All right. Thanks for having me. I think Kalin, he's thanks And thanks, uh, AUSA folks for sponsoring this.

Absolutely. Well, as a matter of fact, we have more Susa coming up later today, so stay tuned for that. Welcome to Security Boulevard, the cybersecurity podcast from the Futureum Group.

Each episode explores a variety of topics within cybersecurity and the technologies that drive it. com, security Boulevard, YouTube Channel Techstrong tv, and all your favorite podcast platforms. Before we begin today's episode, let's meet the panels, starting with Mitch.

Hey, good to be here. Mitch Ashley, I lead the software lifecycle engineering effort at, uh, practice at futurum. Awesome.

And Fernando, hello everybody. Fernando Montenegro. I lead the fiber security and resilience practice over at, uh, at Futuro.

And I have a distinct pleasure of working with both of you on a regular basis. Alright, well, as you can tell from the backgrounds of my two friends, uh, they are not in the office this week. They're actually out in Las Vegas because it is everyone's favorite post Thanksgiving activity that does involve taking an app.

It's Amazon reinvent everyone, it takes over the strip. There's lots of great excitement going on there, but there's also a lot of announcements, and usually they're something maybe innocuous, like S3 could be them driving a giant semi-truck out on stage, remember the infamous snowmobile. Uh, but we're really focused on cloud security.

So I think what we want to do for this episode is we wanna talk about the state of cloud security. We wanna see where we are, where we hope we can be and, and maybe kind of figure out what you need to know about how to make it work. Well, uh, yesterday I started my day shoveling snow.

Uh, so, uh, so I started my day shoveling snow, which is totally fine. So we had about, I don't know, three, four inches, whatever, right? And, um, but uh, my day ended in, in, uh, in a warmer climate.

I'm speaking to you all from, uh, Las Vegas, uh, where it is 7:47 AM And, uh, I'm here for, uh, AWS uh, reinvent. So I apologize about the, the, the, the recording. Uh, if that's the case, it's just that I'm speaking to you all from a, from a very, very nice hotel room.

It, it is the best lighting that you can get in a hotel room in Vegas. But you know that that's how it goes. And, and it's funny that it's, this week is reinvent.

For those of you who don't know, the, uh, the, the week after Thanksgiving is historically don't schedule anything in tech because Vegas is gonna get taken over by everyone from Amazon, uh, that's not currently selling online books. And we wanted to take a, uh, little bit of time today, uh, kind of talk about cloud security, because, you know, one of the things we always get a lot of at reinvent is a lot of announcements around a lot of new products. Uh, you know, it could be something innocuous like S3, it could be a giant semi-truck full of hard drives, the infamous snowmobile.

Uh, but we wanted to focus a little bit on the security aspect of things, uh, because, well, for better or for worse, cloud security has had a heck of a journey over the years from, uh, virtually non-existent to why don't we do this the way, this way in every, uh, enterprise that we work in. Uh, Fernando, what are some of the things that you've been seeing that kinda give you pause about cloud security, but maybe also give you a little bit of hope? So I'm, I'm optimistic about cloud security, uh, in the context that our conversations with stakeholders, whether they be vendors or, or, or buyers or investors, or we've sort of normalized what cloud security looks like.

If I go back, so, uh, let's go back just a few years, like five years or so, right? We were having a conversation whether things were going to be, um, you, you take the word cloud security, you take the expression cloud security, you could put the emphasis on the word cloud. So it would be cloud security, or you put the emphasis on the word security cloud security, right?

And this, it, it's a joke, but it, it does resonate in the context that where does cloud security reside? Does cloud security reside with the cloud team? Does cloud security reside with the security team?

Right? And, uh, you, you may remember we had the, the, the cloud centers of excellence, right? Where, uh, which were fine, right?

So other organizations are adapting and, um, but I think we've come, we've come to a, to a, to an agreement, uh, of where cloud security fits, right? And I would argue that the two, uh, we wrote about it earlier this year. Uh, there were, there were two major moves that, uh, well, there's Mitch Lovely, right?

Uh, there were two major moves that, uh, that, um, that had, uh, an impact on this. The first one I would say was when Palo Alto Networks moved a significant amount of cloud security functionality from Prisma Cloud into Cortex Cloud earlier this year. And then the other major thing, of course, was, uh, Google's announcement or alphabet announcement that it's, it's intent to acquire with, which is a transaction that is almost done, right?

I don't think it's, last time I checked it, I mean, it cleared the fuel regulations, but not all yet. And those two things signal to me that we've, we've been, we, we've sort of agreed that cloud security, or at least the, the detection and response part certainly be belongs with operations with, with, with the SecOps team. And then it's wonderful that Mitch just joined us because Mitch, of course, is our application security expert.

And, um, so there is this cooperation between okay, application security teams, you are, uh, creating infrastructure and business logic and whatnot that's running cloud environments. So there's stuff that you need to fix ahead of time. And then the, the security operations team is, look, you are now getting tele telemetry about cloud.

Do something about it, right? And, uh, um, so I'm, I'm optimistic. I love that you brought that up, Fernando, uh, back in your original point about the fact that there was this discussion about where should these functions reside?

Should they reside with a cloud team or with a security team? Because I deal with this a lot when I'm talking to people about field day. Well, where should we go to do our presentation?

Should we go to cloud field day, or should we go to another, uh, presentation? And, and I always look at it like, who are you trying to, who are, are you trying to convince, right? Are you trying to tell people that work on cloud every day about the importance of what security means to them in their organization?

Or are you trying to convince security people that there's a lot of things that we can do now in the cloud? I always look at it kind of like, uh, robot surgery, right? Like this idea of doing like telemedicine where you have a, a surgeon driving a robot that's doing this, this kind of surgery, who's the best person to do that?

Is it someone who can operate a robot well, or is it someone who knows how to do surgery? I think if it's you on the line, but, but I know for me, I'd rather have a doctor who's fumbling through figure out how to figure out how to run a robot than having a robot operator going, yeah, we don't need that pancreas. We can just throw that thing out.

Um, like I, I would rather have a subject matter expert who's being cross-trained on things rather than trying to bring someone who's not natively familiar with these tools and functions up to speed. And, and to your point, you know, Fernando, as you close it out, I still think that a lot of the things that we need to be able to move fast on really have to reside with the operations teams that are doing that thing day to day. I don't want the guys that are turning up route 53 to be the ones who are doing DFIR for my cloud instances, why?

That's not their job. Their job is to keep operations running. The SecOps people are the ones who are supposed to look at the logs and go, wait a minute, something doesn't feel right here.

And, and the thing is, and so this, this goes to the trends that, uh, that we follow and so on. And one of the major ones that we talk about in the context of SecOps is what we call the expansion of the attack surface. And what I mean here is that the attack surface or that, that some someone from SecOps now has to deal with, has significantly expanded by the expanded both in the number of things we're asking people to do, but also in the types of things that we're asking people to do.

Exactly. To your point. Now, if you are in SecOps, you should be able to be familiar enough with cloud to understand what Route 53 even means, right?

And, and, uh, uh, and yes, it's always DNF, and uh, but at the same time, what is the boundary between how you are handling an incident? So, uh, what is the handoff between SecOps and engineering, right? Uh, what is the, the, how do you even change the metrics for that SecOps team?

If I pass it off to engineering quickly, does that mean that, that we handle the problem and it's now resolved, or no, we have to do the regression. We have to make the fix and the regression testing and on and on and on. So how do you play the, the, the, my time, my time to, to, to bring up economics first?

Uh, how do you, how do you bring up, how do you align the incentives between those teams to make sure that things are flowing as they should? I think you hit a key point around flow, uh, Fernando, which is every time we expand the tax surface, which is only going to expand, right? It's not gonna shrink, is we have the potential for creating yet another silo, right?

Whether it's agents this time, or AI models tomorrow, or it's automations that we're putting in the business or in in operations or SecOps for that matter, it's very easy to, for startups to create a product or a tool targeted that, or even for a cloud provider to say, we now have this thing, right? We have Route 57 or whatever the next thing is that's gonna come along. And it, it is very easy for us to think about it as well, who is the group that administers that?

Well, there's probably a lot more to that, right? These are all interconnected systems. They don't stand alone.

Yes. DNS is part of the fabric of the infrastructure. Agents are part of the new kinds of way of, we're creating software and automations and, and doing business work.

So I, I think vendors have to look at this as a holistic sell, not, you don't get to, you don't, the days of being able to go to the architect in the cloud architect team and have them sign off on your product are over because you have to talk to the ciso, you have to talk to the security team, you have to talk to the infrastructure team. You have to talk to the SEC op team. That's who all who has to get involved in that.

And maybe you need to talk to the software architect also while you're at it, because that's all part of a system that they're all building, because signing, having one group sign off on it, is probably gonna lead to an isolated implementation, which is a failure in most cases. And I'll give you one more thing. I think that, um, there is an element here, you know, about the, the analogy of the, the, the drunk looking for their keys, right?

Uh, they look for the keys under the, the, the, the spotlight, because that's where it's, that's what they can see. But the keys may be somewhere else. I think about that, um, in the context of everything we're, we're talking about how are we capturing, are we sure we are capturing the right, uh, attack surface, right?

I was reading a paper this morning, uh, really interesting, uh, trying to formalize or trying to, to organize, uh, a discussion around how much of the actual attack surface you may not control, right? And the example that they were, they were using is the, the auth attacks via SalesLoft, right? And, and, and now, and, and now you have the, the, the, the shy Hulu, uh, uh, worm that, that's going through NPM and, and GitHub.

And it's a really important point for organizations. Like, like you said, it's important for the vendors to, to reach the right people within organizations. And it's important for organizations themselves to have a very clear view of what their attack surface is.

And the reality is, hey, I can do patching, I can do, uh, uh, I can do patching in, in, uh, operating systems. I can do patching in applications, right? Fine.

They are part of your problem, absolutely, but they're not the totality of it. So you, you need the broader view of cloud to bring back to the topic of cloud. You need a broader view of cloud security.

How does identity flow between the cloud environments you're at, right? Where is your, uh, um, where is your IDP, right? How, uh, how are you, how are you doing transitive trust between applications, right?

Are you monitoring the behavior of how your OAuth tokens may be used, right? We all, we, yeah. Anyway, go ahead.

No, no, no. We, we saw that today actually, as we're recording this, um, uh, there was an announcement that OpenAI had a data breach, but it turns out that OpenAI didn't get breached. It was actually a breach that occurred about a month ago with a company called Mixpanel, because there's an API integration between Mixpanel and O and OpenAI.

And so we're starting to see that kind of thing. To your point, Fernando, about how much of my attack surface do I control? More and more what we're seeing is, is that companies are being kind of breached secondarily because something got into a provider of theirs.

I mean, you know, remember when suddenly Ticketmaster's database got breached, and you're like, well, how did that happen? Well, it turned out it wasn't Ticketmaster's fault necessarily. It was something else that was breached because they didn't turn on two factor authentication.

And so we're, we're seeing these kinds of things where your, your attack surface can be very narrow on your side, but it may not be something you can completely close off, because in order for Mixpanel to operate with OpenAI, you know, they needed to have things like name, email address, operating system, referring websites, you know, things that the API needs to actually function. You cannot completely remove that, right? Like, there's no way for you to wall that off completely.

So you're always going to have to be a little bit open. And the only thing you can do from a security standpoint is figure out how you can limit your blast radius from that, you know, give them the minimum amount of information necessary, prevent inroads from being done, like you said, you know, are, does OAuth to this other system, allow me to do things on this, on my system that I would rather not have them do. And if you're not auditing things in that fine of a grain, you don't really understand the power of cloud because, you know, in the old days when all we had was perimeters, all I gotta do is stop the bad guys at the wall, right?

Keep the barbarians outside of the gate. Nobody ever asks what happens once the barbarians get into the gate, into the castle, because it usually doesn't end well, because it turns out that everything is soft on the inside. And, and cloud really does need to be like a series of, almost like pill boxes, right?

Where it's like you can breach one of them and, and maybe I lose that system or that, that zone, but you can't get any further without doing some massive, like, uh, you know, attack plan or something like that. In, in a way, you are creating more friction for attackers to have to overcome, hopefully making yourself a less enticing target. Absolutely.

And, and, and this is the thing where I'm, I'm optimistic because all major cloud providers give you several controls to do that, right? So for example, uh, I'm here we are at AWS, so in the AWS you have GP fees, right? So you can, you can limit the blast radius kind of to that GPC, and then you have organizations, uh, organizations and policies that there, there is the possibility of doing that.

Uh, well, the, the, the caution I would give is that, um, the cloud providers, they have two competing, uh, pressures on them on one, then on one hand, they are trying very hard to give you all of these controls that limit the blast radius, right? Uh, perhaps you implement something with the lambda as opposed to a vm, because now, hey, guess what? You don't have to worry about the, the patching that, that, uh, that VM anymore because hey, it's a lambda function.

Yes, there are trade offs. I understand. So on one hand, you have the cloud providers giving you that level of control that, that, that granularity and level of control.

On the other hand, you have organizational, uh, I don't, uh, organizational pressures from clients to make the cloud operating model be closer to their existing model. Oh, we used to have a data center where all the applications were, okay, great, we're gonna have one VPC that is our data center, where all the applications are going to run. That is, uh, a suboptimal cloud security architecture.

And I think that, uh, one of the big challenges for providers is to help clients educate themselves on this. And for clients, it's how do you make that transformation within your organization, right? Um, and, and that is a hard cultural problem.

You know, Fernando, I think there's one key question we can help the industry elevate, whether it's vendors. I know customers already asking this, which is, how is what you're offering me or you're telling me that I can use of your product, your cloud service or offering? How does it reduce complexity?

It isn't just about cycle time. It isn't just about, you know, preventing the next, the, that the SecOps team has to manage is, is another person. I gotta hire another process, another variant of, you know, variants.

Um, I remember talking with, uh, the, uh, former CTO of, of, uh, Twitter was Twitter at the time, and his, one of his key questions was, will, will your product or service require me to hire any more people? Because I don't, I don't have any budget to hire more people, more or less. That just increases the complexity, because if I'm, that means I'm taking on more work, not less work.

And I think we have to really ask ourselves as vendors to say, we might have a really great solution, but is it gonna make the lives and the budget as well of, of our customers better or worse? Because if it's worse, they're gonna, they're gonna try it, they're gonna walk away from it and say, I just can't take on one more thing. Absolutely.

Um, the, the, the flip side of that though is that have that organizational structure. Have those budgets been divine for a world we no longer live in, right? And for a world where security is that much more important, right?

To make a, a very bad analogy, right? Uh, why does NAFA need so many people, right? Uh, well, it needs many people because launching rockets into space is complicated.

Designing things are complicated, and it's always a push pull between, okay, how many people do we need? Well, uh, back when things started, they didn't need as many network engineers because the networks were much simpler back then. Well, the networks got more complex and they had to add more network engineers, right?

The same thing happens with every organization. Is your constraint on your security budget, right? Um, if it, does it match the reality of your operating environment?

Does it match the criticality of your, of security to your organization? And and importantly, does it match future state, right? Here we are 2026 and, and, or almost 2026, and we're looking into what's going on in the world, right?

Yes, of course, A gentech AI is the, the, the big thing for 26. And, and, uh, that is one of the things that's going to be very, uh, interesting to discuss here this week at reinvent. But more than that, what is the change in the regulatory profile, uh, coming, right?

If you look at the regulations, uh, in Europe for Dora, right? For, for resiliency, right? Yes.

Those regulations are primarily aimed at financial services companies right now, right? But they set the standard that we expect others to follow. And guess what?

Those regulations keep, keep raising the stakes of what you need to do in cloud security. They're, they're, they're coming. Dora Dora is coming for more than just for finance.

So, Yes. And, and, and we're going to need a map. See Dora map?

Horrible pun, horrible, horrible pun, right? Uh, uh, in order to, to, to fix the, no, we, we were, uh, sorry, Tom and I were chatting earlier about, uh, uh, kids shows and whatnot. So, so I'm sorry, I have ear warm Dora the Explorer right now.

Be careful of those green room discussions. But, uh, anyway, but the point is, I, I think you are right. Uh, and again, it's that push pull of how much do we change, right?

How much did the cloud security change over the past 10 years in terms of budgets, right? Hey, as we moved more workloads to cloud, hey, we need more cloud security budget. You know, I think there, there are people in the organization that think naturally about kind of what the next thing is, but most of the, most of the organization doesn't.

They're kind of on, I don't wanna say they're on autopilot, but they're, they're working on what they're working on, right? And I, I always see it as the number one of the number one jobs, because leaders have multiple number one jobs, which is why prioritizing is so easy. But one of the number one jobs is someone has to be looking forward, right?

Are we, are we equipping ourselves to fight the next war or the last war, right? We're in the middle of the current one, and the other, the next war is already not only on the doorstep, but it's here, it's happening through the rest of the organization. 'cause they're adopting whatever new technology, whether it's AI today or something else tomorrow.

And that who has, that's who has to fight the fight about the budget. And are we spending it on the right things? You know, it's not only going after the right amount of budget, it's also, yeah, do we really need to keep spending what we're spending on patch management?

There's a much simpler way to do that, or a much more economical way to do that. Or, or we, there's something we maybe don't have to do anymore. That's actually the easiest way to kind of save some money on the budget to say, how do we strike that out if it's not really providing value today?

It's easy to let things layer on top of layer on top of layer, just let the momentum continue and then unraveling it is nearly impossible unless someone takes the charge and grabs the helmet. It's, it's almost like you've described technical debt in a nutshell, Mitch. It's, it's, well, oh, isn't that what, wasn't that what this is about?

No, sorry, I took us down that green room topic. But, But it kind of goes back to what Fernando was saying about companies saying, well, I just wish you would do it the way that I'm used to without realizing that the reason why you've done it that way for so long is because it is a series of the best decision that I can make at the time, layered on top of each other, hoping that they would only, they were only gonna be temporary, which we all know is a lie, because there's nothing more permanent than a temporary decision. And when a model comes along that basically forces you to rethink things in a different way, you immediately recoil against it, because it's not the way that we do things, except it's the way you would do things if you had the benefit of doing them now as opposed to 10, 15, 25 years ago.

And so I think that that's why we're, we're still fighting these problems, right? Is a lot of companies believe that it has to look like this, or it has to, to be pushed along like this, otherwise it's quote unquote wrong. And, and our, our idea of security goes all the way back to, you know, something as, as crazy as, you know, like having a physical security guard, checking ID badges at the door, uh, creating man traps, uh, for people, you know, like you, you have to buzz through the second time.

Uh, you know, we, we have, we now have to look at the way that we do security and realize that a lot of those outdated ideas don't work anymore. Like, yes, there's some aspects of physical security that are still important, but when I'm sitting at home all the time, do I really need to pay to have security guards in a non-existent office building? Or should I be focused on using that kind of security budget to do better challenge response authentication or to, uh, you know, implement zero trust methodology so than the event that something happens in a coffee shop?

I, I don't have those problems. I can't have those conversations right now. But what I can do is I can tell the people that are having those conversations not to keep one foot stuck in the past hoping, well, if, if it looks like what I'm used to, then it must be right?

As opposed to, you know, throwing all your cards out on the table and saying, okay, what is the result? What are we looking for? We're looking for a, a, a, a faster, safer environment for our people to work in.

Well then let's cut away all of the things that don't provide that and get to a state where we are, and then look at what we have to have versus what we want to have. And, and I, I, I love how you framed the, the, the decisions at the time. I think that this is something that we are as analysts, uh, as, as vendors in industry, as as people and stakeholders in industry.

We need a healthy dose of humility and empathy as well, right? In the context that we don't know all of the constraints that were, that are in place or the constraints that were in place, right? And our best option, I think, to help people along is to, okay, baby steps or, or, or little experiments or, uh, let me show you something a little bit different, but, but we keep moving them along.

The challenge becomes when, uh, when people, like you said, they, they, they, they recoil, they default to what they know out of fear, out of, uh, uh, rather than as a, rather than as a, of a decision, uh, of an explicit decision to say, look, this thing that is new is not working. We're going to go back to, we're going to stay with something. And that is, again, a cultural conversation, right?

And it's the kind of thing that, again, is driven by economics and psychology, um, uh, so much, right? And to, to bring this, to bring this back to, to, to, to cloud security, right? It's very comfortable to look at the, at the, at the, at the diagram and see, oh, look, this VPC is connected to this VPC, here are the pa, here's the, the, the, the routes, and here's the, the nat gateway that the, uh, and, and here's the, the load balancer that wonderful, right?

But isn't there a layer of abstraction above about the identities that are being shared about the, the data flows themselves, about the, the, the exposure to, or, or how the API, the, the AWS or or other cloud provider, of course, APIs are being used, so we become more comfortable with, Hey, this is the little environment we're working on. Uh, it's a bigger world out there. I think we'll probably go ahead and wrap it there just because, uh, this, this is one of those evergreen conversations that we could probably come back to three reinvents from now.

Um, but, but the important thing is, is that we have to show that we're making progress in this, right? Like we, we can't just sit here, do nothing for the next 12 months, and then have this exact same podcast in a year. Because no matter how good our defenses are, the attackers are always sharpening their tools to be better at what we're, what they're doing against us.

So if we sit still, unfortunately, six months from now, a lot of people who are doing this job won't have jobs anymore. So yeah, it is what it's, and, and, and this is one of those, I, I agree with you, and this is one of the things where I encourage people to open their perspectives if they can. So for example, I'm looking at all the announcements from that are coming from AWS There are very interesting things, like just a few days ago, they released some magenta AI capability for security incident response, I thought was really cool, right?

They are in, in, uh, increasing some support for post quantum cryptography on a couple of areas. That's really interesting. One area of deep interest to me is the, the evolution of the sovereign cloud, uh, options, right?

To go back to regulations and so on. But the thing that struck me is that as I was going through the, the, the, the announcement so far and we're expecting a lot more coming up, right? But as I was looking through that, the, the sheer number of security relevant announcements that were not under security, right?

Uh, the fact that, uh, I, I, I don't think they are under security, but, uh, uh, the load balancers now support post quantum, uh, cryptography, key negotiation. I, I'm pretty sure that's not a security announcement. It's a, it's an application announcement.

There's another one about, uh, container, um, image signing that's not under security, but well, there's a clear security implication, right? So, uh, my suggestion to people is keep an open mind about where security capabilities are coming and how do you operationalize that capability in your security program. Maybe it's talking to your friendly, uh, engineering team and say, Hey, how are you doing image signing?

Or what can we do to help you with that? And, and stuff like that. Alright, well, like we said, this week is Amazon reinvent.

So Mitch, I think you're gonna be a busy man, as I can tell by the, uh, the wonderful hotel backdrop that you have. What have you got going on this week that people should be checking out? Well, other than diagnosing a few wifi issues, which is led to people late today, um, you know, there's a lot of, in interesting kind of jumping to the other end of the spectrum.

AWS launched, uh, KIRO, which is their IDE, uh, specialized in some areas that other IDs aren't. Um, I'll wait for the announcements to come out here about that. But along with that, there are several things to your point, um, Fernando, is there are a lot of security announcements that are happening that aren't part of security, like adding an observability into the agent framework, adding, um, identity into agents.

Okay? We don't talk about that in the security sessions necessarily, or we do, but it's also in the agent control plane. It's in the, uh, development IDE environments.

It's in the, uh, control and management configuration platform engineering section. So there are a lot of places that I think we're gonna see, uh, security announcements. I know we'll see security announcements that follow all the way up, uh, kind of further left into the, into the development spectrum.

Maybe that's something you and I can, can kind of figure out. Uh, Fernando is what's the best way to kind of paint that picture as opposed to here's the siloed announcements, right? Because that's what we're all trying to sort through of what does all this stuff mean.

I go back what Tom said earlier in the conversation, having a conversation about what you want to happen and then go from there. Perhaps that's the way we're gonna do this. Fernando, you're out in Vegas enjoying the not snow.

Uh, what have you got going on that people should check out? Uh, similar to Mitch, we have, uh, uh, uh, lots of, of, of meetings. My, my big thing, uh, a little siloed, my big thing for the week is there are two areas that I'm poking at, uh, around, um, around cloud security.

One of course is agentic. And I am expecting, hoping to have good conversations, hopefully deeper conversations about our level of trust in the reasoning engines on agents, right? At which point do, do we accept that we need a more neuros, symbolic approach of, uh, probabilistic LLMs plus, uh, rules or, or other types of formal logic?

So I'm hoping to go down that path a little bit also, uh, sovereign cloud, right? And, and, uh, the conversation in sovereign Cloud is interesting because they, they are related, right? In the context of we have the eu, uh, AI act, we have, uh, new things coming up in terms of, uh, what capabilities can you use in the cloud given the fact that it's regulated to be in that particular region and, and, and, and so on, so forth.

So I'm looking forward to that and roaming around the, the, the expo hall, like I love walking around the expo halls. It's a weird thing. Right?

Alright, well, we wanna thank everybody for listening to this episode of Security Boulevard podcast. If you enjoyed this conversation, please do us a favor, subscribe on YouTube or use your favorite podcast application. We don't want you to miss any episodes.

Don't forget to leave us a rating and a review that really helps out because people know what we're all about around here. com and Futurum Group. com, tech Strong TV website or the Techstrong TV app.

It's available on any platform where you can watch stuff. We also want you to follow Security Boulevard on socials, including x, Twitter and LinkedIn Security Boulevard s that's security BLVD, uh, if you wanna make sure you're following the right account. Uh, thanks for tuning in.

We will check you all out next week. Hello everyone. Welcome to this tech strong session about where AI meets cloud platforms meets a lot of the hype that's going on right now with a lot of the free market forces that we are used to navigating in the past decades.

My DAM has ram, I'm the chief evangelist at the Cloud Foundry Foundation, and today my session is about how much docker should a data scientist know. Now, the session should have actually been, how much should a data scientist actually care about? But I think, you know, we are going to go for the more demure version here.

So let's get started. A lot of the conversations around data science and containerization and ML and all of that feels a little bit like, you know, the parable of the blind men and the elephant. Um, people seem to know a lot about what they're talking about.

People seem to have, have very strong opinions about what they feel this whole thing should be, but also people are, you know, just trying to figure out what their niche is and carve a little piece of the whole data science and the ML and the ops puzzles for themselves. And so in this rather uncertain world, it feels like, uh, and I'm saying this with a lot of experience as an empathetic developer advocate, is that a lot of the data scientists don't want to hear about the ops overhead and they shy away from the cognitive overload of how certain artifacts get deployed in production and how they are served versus they love to focus on the technical aspects of here's how my ML workflow gets set up and here's how my ML workflow is actually working, and things like that. And so it's, it's not very difficult to imagine, is it?

So people who are deep in the field of data science want to specialize in focus on data science as their area of choice, whereas a lot of the work that actually needs to happen in order to serve any kind of useful working means for this stuff needs to go through a whole bunch of cloud platform internals and cloud platform specific work. So it, there's a, there's a very clear line, and this is not the first time something like this is happening. So we had the whole dev and ops and then the DevOps and all of that happen in, in like the past 10, 15 years.

And so this whole notion of cloud platforms and having specialized ML and specialized ops stuff that are rather independent skills of each other is not something new to the industry and is not something that the industry is going to hear for the last time either. No matter what new technology we come up with, there's always going to be a way in which these problems are bifurcated into to, uh, even if you think about something left field like marketing, there's always stuff about writing content and then making that content live and discoverable and then, um, you know, a whole lot of operations go into making a single piece of content become more visible to a lot of people and make it easier to be consumed. So machine learning and all of the data science work that's happening right now is no different.

And we've seen this with cloud platforms. In terms of a small history lesson, a lot of conversations began with what was known as the 12 factor application, and the reason the 12 factor application was even promoted as a thing was to make deployments to the cloud much simpler. So a lot of people before the 12 factor ideology came along were writing applications and deploying them to servers that they had control over, they had full control over.

However, once the cloud came along, and once a lot of changes happened in the infrastructure world, a lot changed in terms of how an application had to be designed in order for it to be made available on the cloud. So 12 factor came along, and then more recently we have what is known as the open application model, which is more of a cloud native thing. So if you're in the business of containers and Kubernetes, you're sure to come across the open application model.

Then for the AI world specifically, there's what is known as the model pack, which is a specification, and there is the cloud native AI model spec. So the model pack follows the specification called the cloud native AI model spec. And all of these aim to define how an application is structured in order for best deployment on the particular infrastructure of choice.

So all of these provide different ways in which you want to take your application, and then you want to make it available in production. Now, I like to think of this with a, with a tiny analogy. Here's the red color vehicle that I want to go to work in every day in the morning, however, here's the red color automobile that I'm going to be using in order to get to work every morning.

So there's a, there's a massive distinction between, uh, what I really want in terms of an experience going to work versus what the experience is like actually getting to my workplace. And so a lot of platforms have tried solving this problem in the past. For example, Heroku aimed to be the most sophisticated platform for deploying applications on the cloud.

And then Cloud Foundry came along, which aimed to replicate the experience of Heroku, but it provided an open source alternative for those who wanted the same kind of polished Heroku experience, but on their own infrastructure. And so there's a lot of work that has really gone into trying and defining what the experience is like. Now, if you looked at this entire ML ops workload as a stack, the the tiny slice that you see on top, that sliver there, thus that part is your entire ML ops or your ML workload.

And then this ML workload sits on top of so many layers of different operations and different orchestration and different infrastructure tools. It's hard to believe that the entire focus of the world is on a tiny slice that's almost microscopic contained compared to all of the other things that are contained beneath it. And it's very difficult to really put a finger on, oh, I just need to work on this tiny piece, or I'm just optimizing for a little bit in terms of what I'm trying to do with an, with, let's say, fine tuning an ML application.

But then there's a lot of supporting tools and there's a lot of supporting things that are actually present underneath it that make this possible and make it a reality. Now, what is developer experience in the world translates into what is the data scientist experience in the ML world? And so I'd like to spend a little time in trying to defining what this data scientist experience actually is so that there's a nicer transition in terms of, okay, here's what my data scientist expects and here's what I can provide for them.

Because a lot of times the conversation is about, Hey, I'm a data scientist and do I need to know the internals of what containerization actually is? Um, the conversations can be, Hey, I'm a data scientist. How well should I know to write a docker file?

Being a data scientist, you probably have the advantage of having a generative AI tool that can write your docker files for you more or less, but that's not the point. The idea is a data scientist must data or a data scientist must data science versus how much should a data scientist actually get into the weeds of when, where, and how to be able to deploy an application to production. So the two two pieces of this puzzle kind of are where does the work actually happen for the data scientists and where does the actual serving or the deployment happen?

And so there's so many times that we've seen how this happens, right? So a lot of times programmers write code and then they check it into version control, and that's about where their contract should end. But they always have to be concerned with, oh, here's my code, here's how it should be packaged into a container.

Here's how it gets deployed, here's how many instances I want during deployment, et cetera, et cetera, et cetera. And so whether or not programmers like it, they have to take on a little bit of the ops workload, which doesn't necessarily always have to be a bad thing in the sense that unless you know how your application is behaving in production, you won't be able to architect it or fine tune it better. Now, you could argue that making an application behave better in production may not necessarily be the work of a programmer.

But then again, that's a very opinionated, uh, path to take, right? So in the world of data science, we have a very similar paradigm. Where does a data science, uh, a data scientist actually work?

And where does the DS work happen versus where is it served and what is it served as it there? For example, there can be a Jupiter notebook in which a data scientist does a lot of work, whereas you need the, the end artifact is an is an LLM that gets deployed to production. And so how does it go from one stage to another?

And so that's really, and, and what are the steps that are required to go from this stage A to B? And how much of those internals should the data scientist actually care about developer experience or data scientist experience in this case is something that is core to what a lot of people are trying to achieve. And they're going after the fact that if data scientists are taken away from their core propositions, it's going to be a lot of toil for them, and that's not something that everybody wants.

And so let's get to the second part of this entire talk, which is to containerize or not to containerize, or rather to know the internals of containerization or not to know the internals of containerization. That's kind of the question here. And so let's spend a few minutes in making the case for deep diving into containers.

And as a data scientist, upskilling yourself into learning about containers, let's start with the most famous statement made about containers. It works on my machine, or rather it works on my inference stack, for example. So containers were born to solve this problem with compute where enormous amounts of inconsistencies and gaps can exist between where a particular artifact was built and first deployed versus where it needs to be.

So it's that here's where a data scientist works versus here's where it gets deployed. But for a programmer, here's where it gets tested versus here's where it gets deployed. So it might get tested on a local machine first, and then it gets deployed to staging, and then it was, it's tested there, and then it gets deployed to production where it's subjected to a little more testing.

And so it has to work everywhere. And containers helped formulate this method where people were able to get it working in all of these places in a very homogenous, very simple way without having to actually struggle through a lot of the steps that it takes to make a uniform deployment. And so because of that core proposition, if data scientists are actually struggling with things like, oh, I was able to get this working on my local stack, but it's for some reason not working in production, or it's not working in some other remote staging instance in exactly the same way, and you want to model the behavior in a more homogenous fashion, I think it's a good idea to learn containers and learn containers in a more deep fashion as opposed to just being very skin deep.

A lot of times what I've found is the better you are able to tune your application, the parameters and all of it, the less expensive it is for you to run them in an actual production environment. I'll give you an example. If you're, let's say, running an inference, workload and inference workloads we all know can be very expensive.

If you're running an inference workload and you want to optimize it, unless you know the internals of the process that goes from the start of your inference workload to the actual inference that happens, it's very hard for you to be able to contain it in a manner where it is not burning through your infrastructure, it's not costing you too much, and you're able to decide actively and positively with all of the situational awareness about how best can you optimize your workload for cost, and you're not going to be able to do it without sufficient knowledge of container internals. And finally, there's the idea that, you know, there's an information overload perennially that's happening. And the best way to avoid this information overload is by using containers and then taking containers as the best point of abstraction, as opposed to diving really deeper into what sets up the application stack and how it actually performs.

So this, you know, is, in my opinion, these are three very good reasons in order for you to do a deep dive and learn well about containers, even if you're a data scientist, and even, even if your job just involves creating certain ML workloads and not getting into the ops side of it. Now that being said, I also want to play a little bit of the devil's advocate here, and let's take a very quick look, uh, maybe not as deeply into why I would say that this feels a little bit unnecessary. Cognitive overload can strike anyone, and I'm sure despite having PhDs and despite knowing how to write like Python code, um, there, there is, there is a human element to what a data scientist can and cannot do.

And therefore trying to prevent a lot of the cognitive overhead is not that bad of an idea, to be honest. So you can still, if you can still get away with some sophisticated ops mechanisms and automation mechanism that, that you can set up u using the services of other ops people or other experienced people, I think it's useful to try and get away from, you know, learning darker learning containerization, learning infrastructure, learning, a lot of the cloud native pieces that come together and things like that. So there is the, the notion of cognitive overload and trying to avoid that as an active pursuit.

And so that is definitely a reason for not doing a deep dive into, uh, learning docker and containerization and all of these tools. Now let's take a look at some tools in some communities that are building a lot of things on which I've based this entire premise on. Now, this is not a problem that I've discovered.

This is not a problem that I claim to be the only one aware of and solving, but there's so many different tools that are doing a great job of trying to put up a better data scientist experience by abstracting or obfuscating a lot of the different workloads that can distract a data scientist. And let's take a quick look at one or two of these tools that, that do a good job of this and see how it can actually help. I'm going to pause for a minute 'cause the phone is ringing.

Got it. Three, two, one. So the first slide showcased all of the different techniques, and then like I said, we're going to look at all some of the tools that actually go into solving these problems.

And the first of the tools that I want to showcase is known as kit ops. Now, kit ops is, again, please be aware that all of the tools that I talk about in the rest of this talk are all open source and available for you to play around. org is an open source tool that largely concerns itself with some of the workflows that go into making and maintaining a lot of the model artifacts and a lot of the data sets and a lot of the different pieces of an ML workflow being a single easy container.

So Q tops is, um, borrowing from this world where we were able to package and define applications differently for different eras. So ktop sakes is approach that, you know, we had machine centric workloads before we moved to virtual machines later, and then containers dominated the scene. And now can we take all of these learnings and apply them to this new world of models without having to necessarily compromise and put data scientists down in a world of having to concern themselves with where do I store data?

How does it relate to the code? And which data and which code and which configuration actually go together and which is the model that is built using these data sets, et cetera. Uh, in order to illustrate this a little bit further, here's a slide.

On one side you have what looks like my desktop, but, uh, what is actually the spread of artifacts in a data scientist's life? Now, in that spaghetti is code that goes into creating a lot of the models, the artifacts, things like that, a lot of configuration that runs the code storage where all of the data sets, whether they're trained data sets or whether they're raw data meant to be cleansed and meant to be cleaned and meant to be used, or if it's a lot of the configuration that is required to manage these. And also the models that come out as the output of several training workflows.

Now, people just have to store them wherever they, you know, get space. They, they use tools like GitHub or GitLab for, for putting the code. They use S3 buckets.

They store configuration in Google Docs. Some code lives in Jupyter Notebooks because a data scientist is uses Jupyter native workflows. And, you know, some stuff can be living in some storage that they bought a long, long time ago that people tend to forget.

So people tend to, you know, over time accumulate a lot of technical debt in terms of where this happens. And so it's very hard for people to manage all of this in one place. So enter kops and Kops proposes this notion of a module kit where kit ops basically takes all of this hodgepodge and helps data scientists define them.

Now, it takes, uh, an approach that's very similar to what Docker does and what a Docker file does. They say, here's the kit ops file that you don't have to generate. One can be generated for you.

And so a kit file gets generated that stores all of the information that's present in a particular set of artifacts, and then it organizes all of these related artifacts into what is known as a model kit. And then you can transact with this module kit just as you would a container. And so for a data scientist, kops is designed to relieve huge amounts of toil when it comes to creating a lot of these places where you need to specifically design and store artifacts all in one place and architect them all to belong together.

They could all go in an OCI registry as a container, but the whole container notion does not apply when you're not going to run this individually. So Kit Tops takes an OCI artifact, it takes all of this content, addressable nature of an OCI artifact and puts all of these in different pigeon holes where they can be retrieved and used very conveniently. Now let's examine the different utilities of key tops, um, put in the form of questions.

Okay, so are you a data scientist who is managing, you know, library version conflicts and you have too many, you feel like you have too many projects and environments in order to accomplish the same kind of work? Then you know, kops can be a good for for your organization. Uh, are you having to deploy a lot of things?

And this is the core of this presentation where you don't necessarily have to understand containerization. You don't necessarily have to involve yourself with CICD pipelines and a lot of those things, but yet you would like to take advantage of all of the sophistication and automation that those can provide. If that's you, then kops can be a great fit for what you're trying to do.

Another thing that a lot of data scientists struggle with is what if you want to roll back to a version in production? How do you get to a previous version? It's not something that's easy for the ML ops folks to accomplish.

And so kops provides the simple way in order for people to be able to do that. And that's a very convenient workflow in the world of containers that you can borrow and make use of by you employing kit tops without having to get into container details. Now, if you are struggling with keeping all of the different assets in one place and unifying the stuff that needs to be together to work together, then you know, kops is great for you.

And finally, if there's, you know, a if there's no clear way in order for you to query individual pieces of an entire ML ops artifact kit, then you know, kit ops can be great. And what I mean by that is if you say, just want to look at the data set that has gone in, or if you want to just look at some of the configuration files that are present, if you want to only look, download a model and put it somewhere, then key tops can be very convenient for workflows such as these, all of which are accomplishable if you're using OCI artifacts and containers, but not as easily. So without having to dive really deep into OCI artifacts and containers, you can extract all a lot of the advantages of going that way provided you use a tool like kops.

So that's one of the tools that I've found that's very useful. A second tool that I'm going to talk about is meta flow. Meta flow again is open source.

Uh, it was open source stands in large due to the efforts that have happened at Netflix over the past many years in their AI and ML ops teams. And meta. The meta flow docs has a nice image that kind of is very representative of this talk and also, I guess in some way was very reflective of what it is that I wanted to showcase.

So it shows how a lot of the pieces that go into creating, uh, an application stack in the world of AI and ML involves infrastructure and knowledge of infrastructure and complete operational capabilities and skilling in terms of infrastructure and how much a data scientist actually cares about the different pieces and about the different ways in which infrastructure can play. So in order to really understand this, I guess meta flow is meant to simplify movement between stages. So if you have, I mean, not if you have, you obviously have local instances where you do a lot of the prototyping for an application, you throw it at a remote instance or a staging instance where you do a lot of the testing work and you make sure that, you know, stuff is prepared in order to be in the third stage or what is known as production.

And this is very common for a lot of web architecture and ML architecture is also the same. It follows kind of the same paradigm. And so it begs the question as a data scientist, can you move your workloads between these three stages without having to struggle?

Can you keep track of, you know, all of the pieces that are going from stage to stage so you can reproduce any of these pieces without any difficulty. Uh, there's also the question of how can you, you know, make sure that you know exactly which pieces, kind of like what we were looking with kops to where you can reproduce very specific, using very specific versions of data sets of models and things like that. And how can you structure something very complex without a lot of dependency conflicts?

And finally, you know how you can, you know, pass data between different stages of the projects and without having to actually manually undergo a lot of tile. And so meta flow helps in all of these pieces. Again, this is possible with a lot of automation.

This is possible with a lot of, um, you know, containerization and some of those things, but do you necessarily have to know all of that is the recurring question. And finally, I thought, you know, I'll, I'll make a mention of cloud native build packs, which have been great tools in like grassroots level containerization for ML workloads especially. org.

Do take a look, it's a spec for how you can create containers in a way that's not necessarily dockerized. So a more open, a more portable format and a more suitable format for custom ML ops workflows. And finally, just a quick mention about ML ops.

Uh, I love the tale of the blind man and the lame person sort of symbiotically and syner genetically helping each other out. And I think a lot of times DevOps workflows are like this. And now ML ops workflows are also taking this same shape and form.

So you remember that thing that we spoke about all of the different pieces that can arise in an ML stack. Well, it turns out even in the absence of containerization and Kubernetes, you still have a lot of the ops overhead intact, and there's very little that one can do just as a pure data scientist. Now you have to make sure that a lot of different pieces are available and working together.

And there is the definite necessity for PA paths in ML ops as there is in the world of cloud platforms. And so depending on what part of the ML ops workflow that you are a part of, there's a lot in terms of what a paved path can do for you. And maybe that's the next big thing that we will talk about next year, uh, in this same session.

But thank you so much for having me tech strong, and it was fun preparing and delivering this talk for you today. If you have opinions and if you have thoughts about how ML ops and ops workload should actually function, please feel free to use the social media handle that's there and reach out to me. I'm available on all leading social media platforms with the same handle.

And I'd love to hear from you about how you're tackling a lot of the ML ops workflows as a data scientist or as an ops person, how are you serving your data scientists? Once again, thanks for listening and hope to see you next year. Bye-bye.

AI coding tools are everywhere. In fact, AI tools are everywhere. Do you have the right tools to make your applications, your enterprise applications work?

Well, join me on the Tech Field Day podcast and we'll find out. Welcome To the Tech Field Day podcast, where we bring together a group of IT technical experts to discuss a single idea about key concepts in the industry. This podcast features a variety of perspectives from members of the Tech Field Day delegate community.

It's often recorded in association with one of our events. Tech Field Day is part of the Future Room Group, and this podcast is also published on our sister company Site Techstrong tv. On this episode, we'll be discussing how generative AI coding tools are making enterprise applications worse.

But before the discussion, let's meet who's on the panel today. I'm Calvin Hendricks Parker, I'm CTO and co-founder of Six Feet Up. I'm Jim Zarinsky, chief storyteller at Zero Defect Computing Incorporated, J Qal, chief Product Officer at Nexus Tech.

And Of course, I'm Esta Cook and event lead here at Tick Field Day. And I, uh, recognize this interesting topic for us about how generative AI coding tools are enabling a whole lot of applications to be built, vibe, coding of applications, and that some of the major software vendors have made statements about having large proportions of the code in their applications written by generative AI tools. Yet at the same time, some of those same organizations are commenting that these large applications that are full of AI generated code maybe don't work as well as they used to.

There've been some commentary on Windows 11 needing some rework, and it does lead me to wonder whether that rework is being required because the generative AI applications, while they're good at making small pieces of code, aren't necessarily very good at making enterprise code. I wonder, um, Kelvin, you get involved in some development projects at times. Do you think generative AI tools are good at small scale and not so good at big scale, at least for building applications?

I, I'll I'll preface that with, it depends. I think the, the, the tools themselves are, uh, Excel based on who's driving them and their level of expertise with managing the context. Um, I actually, I'm at reinvent, uh, Amazon's big conference this this week and they announced their, uh, three agents, uh, on day one's keynote.

And I think they're obviously trying to double down on, uh, AgTech with Kiro and, and some of the tooling that they're, they're releasing, uh, they have the AWS transform, uh, tool, which is supposed to be able to move you from a legacy code base to a, a more modern code base. Uh, I think they've seen success, but I think they've also been working very hard at, uh, generating some sound bites that are, uh, meant for keynote uh, consumption. I think there's still a lot of work behind the scenes that's gonna go into making this a true reality for most enterprises to pick up these tools and, and go, that's kind of my take on it to start with.

And that translation from one, uh, programming language to another, one framework to another is something that came up when, uh, we were at Kon and I was talking with, uh, Martin Reynolds of, of Harness, uh, he pointed me to some, some work that had been done about translating something that was written in, um, JavaScript and was being translated into Rust in order to make it a more maintainable. And these tools are really good at that part because it's well known what you're going to, and so you're just saying go find, go look up all the world's knowledge on the, on the technology you're moving to, given the context of what we're going from. That's, that's actually a, I think a straightforward use case for this.

The, in the enterprise tooling of let's go build brand new, uh, never before seen bespoke software is a different case. I mean, we've had success with it on small projects and some large projects, but it, again, it's that careful, the careful driving of it by a, I find very senior resources who understand and have been in the industry for a long time. It's hard to pass that knowledge of how to drive these tools down to more junior folks.

On a related question, if I could, uh, I, I, I have my theory on why BUN was acquired, but I'm wondering if there's gonna be a vertical integration that is part of the m and a strategy of some of these, uh, AI providers so that they can have relevance in what, uh, someone believes is the biggest market they can go after right now. And, and as a data point, why I think that is, you know, IBM clearly with their granite models and the stories that they brought with Watson X really made it, uh, very straightforward for people that have very strong in-depth COBOL legacy bases, uh, to bring those to more portable Java, uh, for your particular runtime. I'm sure they have a very specific runtime in mind for you, uh, for you to do that.

But it is interesting that BUN was acquired. So I'd, I'd like to get, uh, other, other input from folks on what they think about that. I think Bun Bun was a natural acquisition for them given Claude code, the fact that that was the, the, the two UI framework behind it.

So I dunno if I read too much more into the tea leaves on that one. I don't know if Jim has an opinion on that Since you mentioned IBMI also saw a story, I believe it was just this morning that the CEO of IBM was talking about where we are with, uh, ge uh, general AI intelligence, and he basically said there's about a 1% chance that it's gonna happen and it would require immense upscaling and all other kinds of things. So, um, I, I'd like how you put that Calvin, the meant, meant for keynote consumption.

I think there's a lot of that going on. And I'll speak personally this morning. I just did a presentation, uh, implementing a chatbot against some really sensitive crime data for the city of Chicago with a colleague of mine.

And, uh, it is not easy to implement complex stuff even with really good, uh, coding tools. Uh, the reason we have senior developers, right, is so that juniors can learn from them. And the, the person I was working with, she's been working with this particular tool for 25 years, and in five minutes she showed me more stuff about the tool I was using that I didn't even know about how to use it properly.

And, uh, so I, my concern a again, I consider myself to be one of the people that's down in the trenches here, and this all sounds awful pie in the sky to me. And I, I just don't know if organizations, you know, I, I imagine senior developers are rolling their eyes so hard that they're hitting the backs of their heads when they, they hear claims like this. Uh, AG agentic is one that really frightens me from the perspective of turning over that much control to tools that no one really understands underneath the covers what's happening.

Uh, so that's my take. I I thought the I IBM CEO's take, uh, was quite intriguing. Does, does it mean that we're looking at only incremental benefits in the, in the tooling that is used by the developer as compared to the onstage keynote promise of yeah, just, uh, write de declare what you want and then sit back and watch it.

You know, we go from vibe Kobe to like vibe, I don't know, audience. We we're, we're literally just watching. Uh, and and there's our, there are already memes going through this, right?

Where, you know, it's the, it's the picture of, you know, I think it's from, um, uh, the social network movie and Zuckerberg staring at his laptop with that dejected look on his face, and it's the, the caption is, you know, watching chat GB two do the job that I used to love. Um, and so, I mean, so, um, I'm, I'm, I'm a horrible Python developer, right? But, uh, I've shipped better quote, quality, uh, passing test code, uh, recently because I do use Gemini.

Um, and that that's my tool that I use. Um, I've even tried to use Gemini inside of, you know, uh, vs code, um, vs code, of course defaults to, Hey, you're gonna use copilot, right? You're gonna use copilot, right?

Um, so for me, I, I do see incremental benefits, but I don't, I don't know if I, I'm really ready to say wholesale turnover, you know, the whole design, uh, process of product engineering over to an AI quite yet. I wonder that if one of the challenges is that most of that information, most of the, this is how you build an enterprise application, this is how you build a good enterprise application, that that information doesn't exist anywhere that these ais have been trained. Mostly it, it exists inside people's heads and is transferred person to person as gym experienced, uh, not through documentation or, uh, books, white papers that could be scooped up and fed into a large language models training path.

I think possibly, uh, the challenges that information simply isn't easy to feed into an AI to a large language model in order to, to learn how to design enterprise software. I feel like, I feel like that's gonna change really fast. I feel like tools like Antigravity and, and Kiro, uh, from Amazon, they're going to be watching what the developers are doing and reacting and actually incorporating.

I think they're gonna start incorporating that into the, either the training, the fine tuning, the, that, some other, again, I'm, I'm, I'm a little Amazon biased this week because of where I'm sitting, uh, but there's, there's interesting things on the horizon. I think those things that they presented at the keynote are probably 12 months away still. Like the, they looked good.

They, they sounded amazing. But I think when it comes down to actual use cases, Amazon is probably getting that kind of improvements internally when they're saying they're migrating old versions of their services to do new versions of code going from old J dks and New J dks. Again, those are like best case scenarios.

They make great case studies, like the great white papers are gonna be of those things, but when they go to build the new things, I think that's, and, and I kind of wanted to touch back on the a GI comment that Jim made. Uh, I I think that's interesting. What got us here will not get us there is absolutely my take on it as well.

I, I think we're gonna see more putting together domain specific small language models that are highly specialized. Like you'll have a JavaScript model and a Python model and a, you know, Java model in your toolkit and a, and a orchestrator model sitting at the front end watching and, and kind of making these things all make the right kind of decisions. You're already seeing that today with some tools like Goose from Block.

Uh, that's one of my favorites that I, I talk about quite a bit. They've got their, um, kind of, um, uh, the, the director and, and the, the worker, uh, models that you can actually configure today to have a multi-model set up where one's watching the other's doing the work. Yeah, you, I, I watched your, uh, side by side where you were kind of like, uh, doing like a bakeoff, if you will.

Um, and please Pillsbury, uh, do, do not sue us for me using the term Bakeoff on this, uh, you know, podcast. But it, it is, it is interesting because effectively what you were doing was like a speed dating version of what I think is gonna have to happen in every single enterprise where they have some capacity to ship digital product. And if, and if they're doing that, and if, and if let's say that they're, you know, kicking the tires internally, you know, there might be, uh, they, they, they maybe start with the world of maybe what Alistair was referring to earlier.

It's just like that, that enterprise data, none of these companies have seen that before and it's just trained upon it. Um, so they may start with, uh, Hey, I'm gonna come up with some lightweight way of doing fabric a, a data fabric, and from that data fabric then someone says, ah, we should have a way to like, uh, materialize views and personalize and save and tie it to this line of business. And they may start with low code, no code within a vendor ecosystem of what would've been their business intelligence group.

But, but I do believe that there is going to be this appetite for, uh, to your point, Calvin, I wanna imagine something that never existed before. Um, and I, I just don't, I don't know where the connected tissue would come from for that. Uh, legacy enterprise specific, call it quirky, uh, you know, uh, uh, approach that Alistair's referring to of, well, that's the way we've always kind of done it here.

Uh, this is our data standard and format. So, um, that, that's that bake off that you did. I'm just trying to imagine like what's the, what's the toil in the enterprise setting knowing that your time probably has to be tracked somehow or tied to some cost?

How, how do, how does an enterprise have any chance of succeeding and does, does, uh, does this mean everything has to go to the, some like global systems generator, probably several of them on the floor at AWS saying, no, no, no, no, sweet summer trial. Don't try to do this. Let us help you.

Right? But the, the issue that I'm gonna see with the enterprise is they'll probably hamstring themselves by saying, you'll get to use one tool, it's gonna be co-pilot inside a VS code. Where I think the real advantage of like that bake off what it showed was given certain kinds of context, certain tools performed better.

They're obviously gonna converge over time, but you may still have sweet spots where certain agentic coding tools are just better at building the CI pipeline than another. Uh, I did that during the, the last tech field day, I built a blinky lights electron app, and sure enough, codex one shot at it built it up real quick. I was like, incredible.

Now let's make a CI pipeline that can build it in the cloud for me. I could not get Codex to do it for the life of me. I went and dropped over into Goose a one shot at CI pipeline, and then it started working, but I didn't spend a bunch of time trying to like force that square peg in the round hole.

I, I, I quickly defer to another tool because I think that either it's, you know, there's too much junk in the context window. The, the system prompts that are behind some of these tools just don't have my use case in mind. And so that's where some of these tools are very limited.

I think enterprises are gonna need to adopt some specializations. Like I could see there's the, you know, IBM version of this tool. com platform, those kinds of things.

And they'll be very specialized and understand what you want a lot better. And so one shot will be easier. Well, one thing I'm not hearing in all of these discussions, by the way, is, um, how secure is all this?

Uh, I just came across right on my Thanksgiving, Turkey reading was an article on the Atlantic about chatbots are becoming really good criminals, and they were describing how, and we just saw this recently, right? Where, uh, you know, state actors are using ai, generating AI to write really good code that penetrates from a thousand different directions, whatever it might be, right? And, uh, in fact, I was mentioning back to boots on the ground, you know, my topic today that I was working on with my colleague was about how do we lock down access to embeddings?

Because we don't wanna let everybody have access to the embeddings themselves because well, somebody may not know how to write Python to connect to say, a MySQL database to actually get at it, but an AI tool could, and, you know, what do people think about, well, you just, it's all vectorized, don't worry about it. But it ain't that hard to get an AI to look at vectors, you know? And so I'm just, this, this the headlong rush I'm not hearing about, you know, really we should make sure that the wheels are down before we land.

You know, that's like a really important thing. And maybe, uh, they're down and locked. And as, as a lifetime developer of 45 years, that's what concerns me.

I'm not saying we should stop, but do we have a checklist? Do we have a checklist to at least check that the AI is doing what we really said it should do? And are you hearing that I'd be interested from the AWS or IBM perspective, whatever you guys have heard, are people talking about that or, Uh, no.

Mean they actually are, that was a, a big impetus on the keynote on Tuesday was the security aspects of the various models, the new policy guardrails that they're releasing inside their agent, uh, uh, framework. But I, I, as I look at that, even like Google's anti-gravity tool that they released, what, a week and a half ago, it's been a week and a half maybe. And within two days of that releasing, there was an exfiltration, um, vulnerability discovered almost immediately because these agen tools have the ability to use tools like they, that's the, that's their key feature is also their key weakness.

You're gonna have to employ other techniques and be given that, like we're not only developers, like a lot of us on this call are also systems. People using tools like Ana Mac, uh, little snitch is like an absolute required, uh, I don't want, I wanna know if a process on my machine is making a connection I was not expecting. Uh, 'cause that's, that's May's the only surefire way to know and have it proactively block those kinds of things.

Uh, because I don't think you can write a bunch enough guardrails yet with these tools, they're still non-deterministic. They still can do things because it's statistically probable to do them. And if they've been trained with some nefarious, you know, materials, uh, baked into them, it's, you have no, you have no control of that.

You're not auditing or analyzing these models. Uh, you, you sometimes you don't know where they'll come from. Uh, that's a difficult piece, but you have to take other countermeasures, I think to, especially in the enterprise, the enterprise should absolutely be having, uh, watching their outgoing traffic like a hawk.

I, I assume they are. And I, I do it at my own desktop level. When, when you think about what it means for an enterprise to take on a net new creating of an application, uh, what's that joke in software?

Once you've started writing the software, now you have two problems or whatever, whatever that is. Um, so as they, as they create this new software, I am still left wondering the, the cho uh, the, the, the chores that need to be done. Uh, do we see any indication that if you know Jim, like your example, like is this thing gonna do das Rast and all the other things that need to happen on that stack to make sure it's secure and stay secure as it drifts through, like updates and changes.

But the other part of that is, is I'm wondering if, is there, is there any, is there anything we're seeing where, um, relief on the call it site reliability engineering side or the, or the platform engineering side, these, these teams have literally less toil on their plate as we ship new, you know, applications. So I'm, I'm, I'm kind of wondering about the full lifecycle, you know, setting aside like whether we can even get there or not, but let's say something lands, um, now what, um, day two is forever That's here. I mean the, well, it's announced again, keynote wear.

The other two agents other than the kiro application agent was a security agent and a DevOps agent, they were announced. Again, you can, you can recreate these on your own with your own sets of like cloud code or GOOSE or ER type tooling where you have system prompts that are geared toward these pieces. You have the right hooks into the event systems to, to hook into your CI pipelines and watch and, and and maintain.

And, but it's early days. I think these tools are still very early days. You can't, I don't think you can, should rely on them a hundred percent.

Um, but they're gonna, they're gonna definitely reduce the cognitive overhead that developers and operators and platform engineers have, and it's gonna make for better software down the line. It'll be so much. If I was a enterprise SaaS platform like A-S-A-P-A Salesforce, uh, you name some large SaaS platform, I would be worried because now these enterprises are gonna have the ability to not only build a, a replacement that does exactly what they want, but maintain it because they'll have agentic tools sitting in the, in the, in the sides making sure that these things stay patched, secure.

Uh, someone wants a new feature that can write up a spec. I, I think that's coming. I, I don't think we're far no one, I don't think anyone's safe from this.

I, I think if I wanted, because everyone would love to have exactly the software that fits their need, everyone settles for an 80 to 90% solution because it's already built and probably costs less than if you were to go build it yourself. Even with the prices that like a ServiceNow and a Salesforce, et cetera charge on their subscriptions is still cheaper than going in and probably building right now. Hmm.

Do you, do you, do you believe that, uh, AI firms are gonna start, uh, putting lobbyists into place to ensure that, um, there are more onerous, uh, uh, ways of saying like, oh, you gotta be, have these check boxes. 0 this, you gotta be lug per, you gotta, you have all these acronym soups, and is there gonna be an agent that keeps you closer to the acronym soup checkbox, you know, validation That, that exists today? That, I mean, there are open source tools like cloud custodian that can, you can build those checkbox checkers that are real time event driven in your inco system.

Those are, those exist today. And I think you're gonna see more of that because more folks are gonna wanna say they are compliant and they're actively staying compliant. Yeah, it's, it's interesting move from we're compliant at audit time to we are provably continuously compliant, uhhuh, we gotta get there.

That's absolutely vital. One of the other fun parts in this is operations. I was just on a call with, um, big Pando who have, uh, the, what we also saw at, at KU Con a lot, which is an AI that sits on top of all of the observability data that you are getting out of your applications combined with all the inventory data that you've got from, uh, from your configuration management systems, and then also bringing in all of the incident information, the tickets that are coming through ServiceNow and correlating all of that into some insights.

I thought that was a, a really useful thing because, uh, particularly when there's high criticality incidents going on, getting rapidly to what the actual root causes rather than getting rat hole in some symptom, uh, could be incredibly beneficial. And there's some really nice AI driven tools around making it easier to join an active incident or to identify possible resolutions. I thought there was some really good pieces in there, but we are straying away from our initial, uh, premise that was around how AI coding tools are either helping build better software or maybe not helping build better software.

Kelvin, you've used a bunch of them. Uh, your, your conclusion is that you, you like AI coding tools, but you still want a human involved. I I, I, I think human guided right now is still the way at some point, these age agentic coding tools are going to be building software that we as humans can't read.

Like it's written in a certain way currently because we still are in the loop and reading the software and analyzing what's going on and trying to code review the tools will become as ubiquitous as, or as, as, uh, useful or, uh, generally, um, capable as like a compiler at some point where you trust its output because the compiler has been well tested and, and build software that you trust, or does it, uh, it's been posited that the, the GCC compiler many, many years ago in the first iteration could have been, could have been compromised with a, a backdoor. We, we'd never know. And I, I think that's, that's an interesting element around at the moment, we want AI tools to write code that humans can maintain, but in the end that, that the end solution is not necessarily for humans to maintain that code.

It's for the AI to build tools that builds code that the AI can maintain over time. And that we take that observability process of just treat it as a black box. And when I send that this input, does it do the thing I want it to do?

Because fundamentally, we're just moving up the layouts, right? We're not caring about the individual layout and code calls. We're caring about the results that are being delivered.

And that's where AI tools and, and AI coding pipeline tools, well, it's not even gonna be, is it? What does, what does code quality at that point? Yeah, Uh, uh, uh, to go back to my entertainment example, like maybe we're just becoming just, you know, an audience, uh, for what's happening.

Um, there will probably be, uh, situations regulatory or otherwise where even if you did ship quote unquote, you know, bite code binary only or whatever, there's still gonna have to be the human readable compilable, uh, the old fashioned way version of something. So we may have, we have, may have that burden where you're actually doing, like you're doing a, uh, dual source, uh, uh, or, or, or whatever the, the, the, the requirement would be so that if, if, if for, gosh, you know, sakes, this thing did go sideways and it starts eating, you know, the hand that feeds it, we need to cut over to the human inspectable. Um, I think observability has always been, uh, this, this phrase getting constantly reinjected into the conversation.

And so conversation, I, I do think there probably is something to be said for, you know, being able to log in with Lang Smith and throw a decorator on something and see how long it took. Um, but how many people have been doing that when application performance management and monitoring, you know, for, for o well over, you know, decade or so and the original, like Mercury interactive stuff, going back to the older days of like just testing how you can hit or, or load test a web application. Um, these are the same and similar patterns.

But again, I go back to that same toil thing. When you, when you take the automated binary only machine, only talking to other machines when you have to put it to where the human can inspect it, when something goes sideways. I still think that observability part is, um, I'm, I'm still thinking like, how, how are we solving for the proliferation?

Because Calvin, you've convinced me this is gonna happen. I'm just thinking like, what's the operational impact proliferation wise, if we, to your point, we don't have more of these agents to come help us along the way. Yeah.

Well you, you see that today in the enterprise. This is a, this is like something that plagues them anyway, is that the proliferation of tools, the stack of tools and places you have to go. So we're gonna, I, I don't know if there'll be winners, but I think there'll be correlations.

Actually, what could be interesting is if you see more of, because of data gravity, because you, the way, you know, you've got logs in one spot and your database is in another, you don't want to bring those things together because it takes too long to then get to a conclusion or a, a root cause analysis you're gonna be having, uh, at Edge Compute sitting next to your data in, in these cases that are very specialized and understand what it's looking at. Yeah, I said the small language models people have been, uh, talking a little bit more about, which is where this is the specialist. It, it, it, it can't tell you the capital of Kansas, but boy does it know a lot about this particular log file and sequence.

Oh, yeah. I, they can run on very lightweight hardware. I mean, raspberry PIs, you know, running like, you know, 1 billion parameter models that are, you know, small and fast.

Like speed is gonna be part of the, the feature, right? It's, I, I feel like speed is a feature of tooling. Like when I'm programming in Python and we now in a new world and we've got tools like UV to install and manage Python install and manage my dependencies, I use it mostly because it's so freaking fast.

Um, and it makes my life as a developer so much easier. 'cause I, I, I'm, I'm not, you know, waiting, it kind of goes with my flow a lot easier. And I think these tools, these generative AI tools need to be in that same speed realm, which is why the smaller ones are gonna come to the forefront.

As usual, I opened a conversation that couldn't really fit in the space that was available for us. So thank you for joining us today at this Tech Field Day podcast. But before we go, we can, the audience, we can people connect with you and potentially carry this conversation on.

Yeah, absolutely. com/in/calvin hp I typically post quite a few things there. com.

I'm also on Blue Sky. That's that new thing all the kids have been talking about. com, because Mastodon was just way too much energy.

And as I, I converted to go to social. com and of course on LinkedIn, if you know, there's only gonna be one of me with that last name, Name, of course, you'll have to spell it correctly. And I seldom do.

Sorry, Jim. And of course, I'm Alistair Cook. You can find me on LinkedIn as well as across various tech strong and tech Field day sites.

Uh, just Google my name and avoid the cricketer. Uh, so thank you for listening to this episode of the Tech Field Day podcast. If you enjoyed this discussion, please subscribe on YouTube or your favorite podcast application so you can see far more of these discussions.

Consider us giving us a rating and a nice review so that other people get to consider it too. This podcast was brought to you by Tech Field Day, the home of IT experts from across the enterprise and a part of Theum Group For upcoming events, more episodes, head to tick field day com slash podcast. View us on text on tv.

And thanks for listening. We will see you next week. Looks like IBM had $11 billion laying around, burning a hole in their pocket.

You are watching Textron Gang. Hi everyone. Happy Tuesday.

It's Alan Hummel. I am back in the Boca Studios here for Techstrong, and I am damn glad to be home, to tell you the truth after my AWS reinvent, uh, excursion. Mitch, you were there with me, Mike Ard, you were there with me.

It was, it was a full week of a lot of good stuff. We've got a ton of content. If you check on Textron TV and on all the various websites, you'll see it.

But we're here today to talk about some fresh stuff, fresh news for this fine Tuesday. We got fine people to talk about it with. I'm happy to see her here.

I, I didn't see her at AWS my friend Hope Lynch. I hope Steven FoST. He's about to jet off to New York City.

He's such a jet setter that FoST, but happy to have him here, Steven. And then, as I mentioned before, Mitch and Mike, good to see you both not in Vegas. 'cause you know what happened there.

Stayed there. Anyway, Mike, we've got a busy day. Anthropic is, you know, well, I have my own views on this, but I want to hear what you guys have to say.

Mike, why don't you kick it off? Andros been really busy. They acquired an outfit called BUN to get a new application development tool.

They signed a deal with Snowflake for a partnership for connecting data to various LLMs. And there's now rumors. There'll be an IPO in 2026.

But Mitch, what's your take on what's going on with philanthropic here? 'cause they always felt a little bit like, you know, the, the alternative to open ai, but, you know, are they starting to maybe emerge as a bigger, more powerful force with a little hope from our friends over there at AWS that we talked to last week? Well, they're certainly beefing up the development space right there.

5 as a really strong, maybe the best of the models for generating software, orchestrating some of those processes. And BUN brings a probably not well known by a lot of people, but BUN brings a runtime job environment. So I imagine what they're doing is kind of using this to create sandboxes, maybe production environments, things like that just accelerate the process of using the software that you're generating.

Maybe they have other designs as well. We'll see what they have. They didn't disclose an amount, so it's only, uh, 20, I think it's 2022 when the company started.

So it's pretty young. Um, they'll get folded in and assimilated, but I think it's, I think it's anthropic positioning very strongly. Go after the developer market.

I I, I think clearly Andro has set their sights on being the developer's AI tool of choice for coding, right? You hear this over and over again. Yes, open AI's tried it with five one to do better and Gemini three.

Oh, but the Anthropic and Mitch, is it Sonic? Claude, I forget now. 5, right?

Yeah. They're actually up to 4, 4, 5. 5.

Mitch. Four four is the new one. It just came out.

5 has been considered the best, I should say. Mm, Mm-hmm. I, I think, but you know, every new one is, is the best one.

But it Is. Every new one is the best one. There's a, there's a meme on the internet that shows, uh, open AI with Gemini, with Claude, and there's an arrow.

And every time someone releases a new model, there's a little bubble over it that says, now we have the best one Right until the next one. Right? Right.

But clearly they made this, their, this is the, the beach. They, or you know, the hill they're gonna attack here, right? Hamburger Hill and, and power to them.

The other thing I'll say though is this, you know, it's the lesson. I've said it here before, Brad Feld taught us this, Mitch be in the top three. You don't always, I mean, number one gets a good share of the money, but so is number two.

And I think they've clearly enunciated or, or, you know, a number two space though. Look, Google Gemini is, is a powerhouse, and they've got Google behind them. So there's an interesting race, and there are others.

There's, there's x and, uh, and you know, and, and others that are coming out. But clearly philanthropic has staked their claim here. The deal with Snowflake, again, it goes right into their developer sweet spot data management.

Um, and you know, as far as an IPO goes, I think that'll depend on the broader market conditions. Does is this bubble keep, you know, if you've seen Wicked, does Glenda keep hitting the, the pedal that makes the bubble grow? Or does poof, the bubble burst?

Hey, hope, do you think that we're gonna see some bifurcation where maybe open AI and Google or the AI platforms of choice for the consumers and is more of the corporate AI platform? I actually think we already see it, honestly. Um, most of anthropics growth has been with enterprise customers.

Most of open AI's growth, even if you just count monthly active users, right, has been with consumers. But if you look at the revenue, both of them have, um, I think philanthropic is now at $7 billion in revenue hitting what, a a billion in six months. But OpenAI is two and a half times that.

But they are counting on converting non-paying users, which a lot of people I know who aren't paying, uh, don't, don't plan to start paying the money is in the enterprise. So Anthropic definitely has already diverged. Um, but then we have the other smaller players like, uh, meta, you know, they're saying, well, we're gonna give it away for free.

Maybe that's gonna make people adopt. But really, the the horse race to Alan's point, it's between Google, uh, open AI and Anthropic, but the divergence is already there. The Greek for Greek.

One more thing I'd like to add on that point too, is the difference in fundraising here. So Anthropic, uh, by all accounts, has raised a little under half as much as OpenAI. Uh, they're looking at an IPO, uh, as you mentioned, they seem to be aiming at enterprise customers.

I think this is part of a strategy from Anthropic to be more of a, I don't know, like a relevant Yeah, like, like, like they're trying to build a company that has more traditional, yeah, more traditional appeal to Wall Street, more traditional appeal to business. And I think that's a good strategy for 'em at least. It's a good differentiator from open ai.

Yeah, No, they have them pledged one and a half trillion dollars that they're going to spend on AI data centers and chips and so forth. You know, not to be left out of the discussion, AWS has announced Nova Nova two. So they're doing their own model now to, you know, so they aren't entirely dependent upon the philanthropics and open ais of the world.

So the, the market is, is expanding. I think a, I think AWS's strategy is Nova is kind of their default for their preferred customers. And then Anthropic is choice number two.

And then everybody else is are, are you really? You really want that? Or you short?

Well, but yeah, but that's the ai, that's the AWS model, right? We'll give you our in-house thing, 80% of the functionality, 20% of the price, or you could use best of breed, but you're gonna pay for it. And, and then, you know, and then there's Switzerland with Bedrock, it plugs into anything Leveraging those training chips, right?

Yep. Yep. Anyway, But one more, one more quick point on Anthropic, um, not to be overlooked is what they are doing.

What they're actually doing, in my opinion, is vertical integration, right? So they're saying we own the model, we are embedding it into enterprise data platforms through Snowflake, and now they own runtime infrastructure. So for me, this is a little bit like, um, apple when they said, you know what, we're gonna, we're gonna build our own ships, Google, we're gonna build our own ships, Tesla, we're gonna make our own batteries.

So they are eliminating more dependencies, but trying to make themselves more valuable to the enterprise. I, the, the problem there, hope is, I think they vertical integration in the AI stack and Frontier model, Google, Google is, uh, in a power powerful position there. They Really are, No doubt.

All right, if we don't have anything else on this one, it's big news. We'll keep our eyes on our friends at, uh, Claude Sonnet Anthropic and, uh, see what happens. Congratulations to the folks from BUN though, by the way.

Uh, we're gonna come back and we're gonna talk a little more m and a activity from Big Blue. You're watching Textron Gang, You've Earned it. The spotlight, the responsibility, the weight of teams, companies, and entire industries fall on your shoulders.

Lives depend on your decisions, your home life included that work. You are protected physically and digitally. Nothing gets through your team without a fight.

But in a globally connected world, everyone sees you, including those who mean to cause you and your organization harm. And now home your sanctuary attackers see an opportunity. Your digital front door is wide open.

And what compromises your home can breach your boardroom. Because the Devil's greatest trick isn't targeting your workplace firewall. It's convincing you that your personal life isn't at risk.

Black Clerk, digital executive protection, defending the new attack surface your personal life. Hey folks, we're back. And as Alan alluded to at the top of the show, IBM is spending an inordinate amount of money to buy Confluent a provider of a managed service around Kafka, which is a streaming data processing platform, open source originally developed by LinkedIn and is now widely used to drive a lot of data in real time to where it needs to be.

And of course that has a lot of implications for ai. But Alan, I know you've been looking lately into IBM and having some thoughts about them in general, but this is the latest in a series of acquisitions. And so, uh, to quote, to quote the new old book there by, uh, uh, Franz Kafka, no, I'm sorry, yeah.

Is it Kafka? Yeah. Um, metamorphosis where I guess basically he thinks he's turning into a cockroach.

But what is IBM becoming in all of this? You know what IBM is a cutting edge software provider. I, I think you gotta look at, yes, I-B-M-I-B-M always makes a lot of acquisitions, right?

Growing by acquisitions is near and dear to them. Not that they don't grow organically, but to me, you, you take Red Hat, you take Hashi Corp and now Confluent and you have a, a modern software stack, um, that is open source friendly. IBM's gotta be, you know, there's a claim to be made that they're the most open source friendly of the, of the large tech companies out there, right?

Look, think about all of the all, you know, red Hat Hashi. Yeah, Hashi changed their license a little, but they're still big on open and, and now Confluence, I, Apache, Kafka, uh, Kafka, um, it's, I think it's a great move by IBM is $11 billion a lot of money. You know what I've learned sitting at this desk the day we announced the deal, it sounds extraordinarily expensive.

A a year or two down the road, you know, with the, the hindsight, eh, it was a bargain, Right? Yeah. What did they pay?

What did they pay for Red Hat? A Few years? 34 and a half billion, I believe.

Right? So still One of the largest software deals ever. HashiCorp, they picked up for a song and a dance compared comparatively, but Hope, Hope, I think they also bought, uh, is it Databricks?

Is that one they Got? No, they don't know Databricks Data Stacks. It's one of them I remember.

So yeah, red Hat Hashi, because then they got Terraform, they bought Vault for sequence management. Well, vault Comes with Terraform. Yeah, Well, I think Vault Data Stack Vault.

Um, but yeah, in cofluent, so, you know, for the real time data backbone, but yeah, That's right. They, they bought data stacks to clarify that they vault, there we go. Which is a NoSQL vector database.

So I think that, to me, I read this as to say that IBM's trying to make a play for the data, less for the AI models. And if I can own all the data and all the pipelines, maybe I will dominate this thing. Steven, what do you think?

This data King? Oh, data is king and Kafka is excellent. I gotta say this is a pretty exciting move in my mind for IBM.

Um, they, as you said, I mean they've acquired so many companies in especially the, um, this classic open source model of developing real open source software and then offering enterprise level support and, uh, managed services around it. Uh, that is exactly what they're doing here with this acquisition. And what they've acquired here is one of the leading companies.

If you go to, uh, talk to data people, you know, there's a lot of talk about all of them, incredible uses that you can make for Apache Kafka. Um, and also it would be important to mention that they don't just, um, you know, confluent didn't just make Kafka. They also are responsible and, and of course they're managed services cloud, but also Apache Flink or Flink.

Uh, I like saying Flink because it sounds like a sound like, I dunno, a lemur would make or something like that. Flink Flink, uh, which is a stream processing and batch processing framework. Um, if I told you that IBM acquired batch processing and data and you know, you'd be like, oh yeah, oh yeah, like the Kool-Aid man.

That's what IBM's all about. Um, good acquisition looks like a good amount of money for both sides, and I think they're really gonna make hay from this. I got a quick question.

How would you know what kind of noise a lemur would make? I love lemurs. Um, I actually have, um, on the wall of my office, a giant painting of lemurs.

And, um, it turns out that they only say things like f flank to their friends. Oh, Okay. That's probably why I've never heard it.

Wasn't there a show about a lemur my kids watched when they were li little Bufu Zafu? Yes. That was it.

That's what I thought you were gonna tell me, Steven, that Bufu said Flink All. So have you been to, we're a le Center center In North Carolina. Let's, I'm sorry about Yes.

Here, you're The best. Yes. Donate to the Duke University Lemur Center.

Excellent. Jumping In on this. I'm glad we went down that road.

Go ahead, Mitch. I don't have any lemurs. I'm sorry.

No lemur stories. You know, this, this compliments what, uh, HashiCorp announced with their infograph earlier this summer, uh, graph database around the infrastructure through this contextual information for AI to use as part of its processing. Now you add this real live, live streaming, you know, high volume data for data pipelines, both going into AI and traditional software, and they're, they're doing a good job of beefing up the, their data platform, if you will.

I wouldn't be surprised to see more acquisitions in the data space for IBM And I think you're spot on. 'cause I think when I look at all this AI stuff, at the end of the day, it comes down to the right data's gotta be in the right place at the right time. And that's easier said than done hope.

But, you know, is what's your sense? Are we moving away from kind this batch joint and mindset that Steven mentioned? And are we shifting over everything in the near real time?

I think that's, that's the goal. That's what, uh, a lot of people want. Um, and right now that is what people are hoping, hoping that they're, they're able to do so.

Um, and if, and if people don't know, you know, this streaming data is like a, like the nervous system for the applications we have now. So think transactions when you swipe your credit card and it comes back and says yes, um, you click on a website, you have sensors with flowing data, um, those, those things matter. So with that cloud native engine, hopefully handling gigabytes of data per second, um, yes, that becomes more and more of a reality and, you know, no lag.

And I think even what we consider fast today, maybe in a few years, we will feel as slow. And if anybody remembers, I do the days of trying to download something and, you know, you'd be lucky if you could get 10 megabytes overnight, whereas now you can download a gig in a few seconds, I think, um, someday, right? Hopefully we can scale to that point where we can look back and see those big differences.

Well, Steven, I think that sound you heard was actually Watson X giving a big sigh of relief as it took a big go of data coming its way. Well, Yeah, absolutely. I, I, And I think there's another method to the madness here of IBM.

You know, I, I put up an article yesterday, I believe, on text Strong AI about I-B-M-C-E-O. Uh, Arvin Krishna did an interview where he, he called out the industry on the, on the AI data center, uh, model. And, and quite frankly, you know, quoting Bill Clinton, it's just arithmetic folks.

It's just old arithmetic. And, and according to Arvin Krishna, the arithmetic doesn't work for AI data centers at under the current guise of things. So I think knowing that, and you gotta assume that the people at IBM and Armand themself, they've got a couple, they've got some experience in this space in data centers and economics of it and all of that.

So I think they're deliberately here making a bet. How did they ride this AI wave without exposing themselves to the GPU waves and bubbles and so forth, being the data kinks, right? They'll run the data management, they'll run the underlying clouds and, and security and, and these things, right?

Without actually being exposed to, uh, an AI bubble, just throwing it out there. So I agree on Kafka, but I'm not entirely sure that, you know, it's open source, right? So IBM buys a company that provides managed services, okay?

But there are other companies that can provide managed services around Kafka. So it basically comes down to them acquiring the, the talent and the expertise to manage Kafka, which other people can get. So when I look at this a little bit, I'm kind of like, well, okay, but can you hold onto that expertise?

Are you just adding to the IBM services portfolio and a bunch of consultants? But, you know, what is the thing that you bought? Because, well, Kafka has freed everybody, You know, I think it's more than Kafka.

You're right about that. 'cause a lot, it is the most popular platform for streaming data. But it, it's, I think it's an integration strategy of how they tie this into the other products, uh, uh, you know, as well as the acquisitions Red Hat and HashiCorp.

But, you know, things like, um, stream sets, e even going back, you said, we mentioned data stack, web methods. I mean, they have so many platforms that can benefit from a streaming data platform. I think this is kind of a universal win.

So, so I should look for that Red Hat OpenShift Kafka slash DataStax bundle any day now. Absolutely. But, you know, a little bigger, But that joke is also that you've just made actually points to one of the challenges that IBM has ahead of them, right?

So integration, this is a lot. This is a lot of technology to integrate and make sure it all plays well together, and that whoever is in sales for IBM, when they're out in the field, they cannot, they can make it make sense. Mm-hmm.

And people aren't, uh, you know, building their own Frankenstein monster. You know, I think the key is making one plus one plus one equals seven, right? Because otherwise, yeah, you could go get the open source Kafka, or you could get someone else who gives you a managed Kafka, and you could get Susa or a different Linux over here and, and, and, and, you know, rancher for your cloud native and, and you open tofu for the HASI stuff.

It's how, it's the one plus one equals four model that IBM has to perfect and sell here. And there's Three words. Enterprise.

Enterprise, enterprise. Yep. Yeah.

And you look at, You look at the success of Red Hat and, um, and this is a model that is working. It's a model that's working for IBM. It's a model that's working for their customers.

I don't hear a lot of people complaining about Red Hat. I hear a lot of people that are really happy with that product and with the products that they're getting from IBM. Um, so yeah, I think that that's exactly how they make this work.

Their pattern is to leave it alone for a couple years, then, then start to integrate it. Well, they, they've got a little experience doing acquisitions, Mitch. Yeah, they do.

You, you're right about that. I think somebody looks at this and starts to conclude that maybe, you know, the big winners in all this are the providers of the storage and the networking platforms on which that data is gonna be moving around. It's the open source community.

It's the open source community. Because once again, open is the future. No one wants lock in.

No one wants to be locked in. We gotta take a break though and come back. We got our third block coming up here.

A little green story about carbon capture. You're watching Textron Gang, Discover Textron 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. Hey, folks, we're back.

And on Tuesday, especially in the C block, we like to talk about climate ecology and all the things that go with that involving it. And today is no exception. Google is talking about a way to capture carbon from data centers, and that's how we're gonna solve a lot of these AI issues.

Steven, what do you think? Is this a viable approach and is this gonna make more sense than, I don't know, putting a windmill in everybody's backyard? Uh, no, but it's a, it's better than a kick in the head, that's for sure.

Um, but only moderately. Uh, so Google, yeah. So what's going on here is, uh, there's this, uh, Broadwing energy center that's being built in Illinois.

Um, they're pitching it with very, very, very green, uh, looking, uh, prose and photos. You know, they got, they got pictures of leaves, they even got pictures of solar panels in this thing. But this thing is a natural gas fired power plant.

It don't, don't be fooled. It is a hundred percent a natural gas fired power plant. The greenish aspect of it is that they're using carbon capture technology that was developed to buy a, uh, little, uh, company.

I believe that this is using, uh, ADMs, uh, carbon capture. Essentially what they're gonna be doing is as they burn the natural gas, they're gonna capture the CO2 and sequester it on site, uh, to keep it from getting out into the atmosphere, which, like I said, better than a kick in the head, but really not all that green, because this is still a fossil fuel powered car, uh, plant. And what's happening here is that this broad wing, they, they were building this 400 megawatt plant in Illinois, um, to essentially take advantage of the fact that there's a lot of Midwest natural gas available, and there's a demand for power.

And they think they were kind of hoping, you know, if you build it, they will come in the old cornfield here. And, um, and they did come, in fact, Google is, uh, committed to basically absorbing pretty much all the output from this plant. So, uh, those of, uh, local folks or whatever, who thought that maybe this was gonna be something that was gonna benefit the, uh, local, uh, you know, uh, it is gonna benefit the local economy.

But if they thought it was gonna benefit them in terms of, uh, power supply and stuff, well, not as much as you might think because Google's gonna buy most of the output. But what this does, uh, you know, again, to be a little bit more optimistic is it is a stamp of approval on carbon capture, which is, again, better, you know, than not. It is a, uh, money that's gonna go into this process that's gonna help develop it and perhaps allow us to see more of it, uh, rolled out in other places, which would be good.

Um, and of course, it means that Google is going to use a little less carbon producing fossil, uh, fuel power in addition to the many other eco-friendly power sources that they're using. So it's not bad, it's just not all that green. It's sort of a, a pale gray, greenish color.

What would we call that? I don't know. Puke green.

I always call the puke green. Steven. So, so explain this to me.

'cause I'm not up on my carbon capture thing, but I'm assuming I'm gonna look out behind my data center somewhere and there's, I don't know, 10 acres, and am I like quite literally, like capturing carbon and just keep digging the hole in the ground until I No, no, that's not what they're doing here. My understanding is they're converting the carbon into CO2. So combining it with O2 right.

And pumping it into underground aquifers, which the middle of the US is riddled with what could go wrong. Yeah. And that's exactly it.

So, so a DM has been basically producing ethanol, which produces CO2 as well. And, uh, they're the big corn company. Uh, they, they, you know, they're, they're big corn Actually.

Isn't ADM Corn arch you, Daniel Mills that always gets sued for its kind of environmental disasters? Oh, I don't Know what you're talking about. They're fine.

So, so, so let me make sure I understand what you're saying here. So at some point, do I have to like, call the septic truck people and they come and pump all this out just like, you know, all those houses on Long Island? Or how does this work?

I mean, where does it On Long Island there, Mr. You'll Hear a giant, you'll hear a giant burp coming out of the Midwest just to periodically to expel that gas. We gotta hope there won't be.

Uh, yeah. The idea is that you pump it as, as Alan said, you pump it underground into limestone formations and depleted oil fields, that sort of thing. And you leave it there, and hopefully over time, either it'll stay there or it will, uh, combine with the shale and so on, that will keep it sort of, um, dissolved.

And not, not not tech chemically, but sort of it'll keep it in place. Yeah. It'll, and we better hope that there's not a carbon capture burp a hundred years from now, because if there is, that's a lot of carbon that's gonna suddenly get up into the atmosphere.

But wait, there's more. But wait, there's more. The cost of liquid gas powered energy combined with the cost of the carbon capture and storage makes it far more expensive than solar or wind powered energy.

Oh, but there's tax credits. Yes. It is far more expensive.

It will be far more expensive. And at the same time that we're doing this, China just rolled out a solar field the size of Chicago that is producing way more energy than this and is gonna produce no carbon that we have to store at about half price. You know what one of my favorite sounds in the world is?

It's the sound of that can, as it gets kicked down the road. But to your point, um, so Google isn't just betting on this, right? So they signed, uh, the corporate agreement for those small modular reactors with Kairos power.

Mm-hmm. Um, and they are saying, what that's gonna be online by 2030, but really operating by 2035. So they, they are betting on both of these and what they are doing, um, for carbon capture that might be offline in 25 years.

Right. So really, this is, you know, in my opinion yeah. All about the tax credits so That not, well Then its about the tax credit and it's about currying favor with the Don.

Not, not to send Steven over the edge, but, you know, this is the same Google who's now talking about building data centers in space with other people too. But, you know Mm-hmm. Mm-hmm.

It's, it's true what Hope. And Google, Google Is doing a lot of different things. Yes.

They're, they're trying to support small modular nuclear reactors and whether those will work, who knows? They're also, for example, they have a new geothermal project that they're working on, uh, in Nevada, I believe. Uh, they've got, uh, energy storage with a company called Energy Dome, which actually uses CO2 to, uh, store energy, uh, produced by, uh, actual renewables like wind and solar.

Uh, so Google isn't the bad guy here. In fact, as I said, Google is probably, this is the positive side of the equation, but I really do think that this is all about politics. It's about, you know, ha making the current, uh, administration, you know, kind of working with them in their framework in terms of what they'll accept in terms of power and what they'll accept.

Uh, a, uh, natural gas powered power plant sounds exactly like what they'll accept. It's Supporting a fossil fuels future. I know.

I think triples, I think they'll take, that's, they'll take the CO2, turn it into rocket fuel, and then that's how we'll get the data center in space. See, there you go. Yeah.

It's all, and, and, and one more, one more point. And, you know, I'm, I'm not being completely down on this, believe me, but the contrarian in me comes out for this story. So carbon capture, um, it's been around for something like 50 years, right?

They've been developing carbon capture and storage that long. And over all of that time, they've captured and stored less than 2%. 1% of the annual global CO2 emissions, right?

It feels to me we are solving the wrong problem. Not that people don't know that, but the wrong problem is being solved. You know, you're catching everything after it's out versus the, the preventative measures that you could take.

Agreed. It's politics Absolutely endorse that. Yep.

And to me, it reminds me a little bit of like post-consumer recycling, which again, is, um, is a feel good measure that really only affects a very small, um, a amount of the waste and, uh, you know, disposal of things that could be recycled. It, it's about, um, you know, making people feel good about contributing to the solution, which they are. I mean, 1% is better than 0%.

You know, 5% is better than 0%, but it's really not gonna solve the problem. You know, Stephen, down here in Florida, a lot of the municipalities have stopped the recycling because they have so much they don't know what to do with it, which is kind of ridiculous. But it is Florida.

Yeah. So claim low carbon power while you enable high carbon infrastructure. Anyway, soon.

Soon enough though, when you get your ai, you'll be able to check that box that says, do you want car? You know, do carbon credits with it, but who knows? So we're, So we're just handing out climate pinkies to everybody that we can just kind of maybe put some branded logos on.

Is that where we're going? I think that was the goal of the last administration. This administration wants to hand those, You know, we'll give everyone a participation trophy from fifa.

Um, all right. That's a good place to end today's show. Hope.

Steven, Mitch, Mike, thanks for joining us. Thank you for joining us. Hey, do go check out all our reinvent, uh, uh, content from last week.

There's some great stuff up there, Steven. We, it's good to see you. We'll see you next week.

Hope. Always a pleasure. Take care, everyone, until tomorrow.

I'm Alan Hummel, we're out. Hey everyone. We're back here on Tech Drunk tv.

Welcome. I'm, this is a part two. If you didn't catch our part one, I encourage you to go back and check it out.

But I'm talking with Priya Doty, and Priya is, uh, with B-M-C-A-M-I. And if you wanna understand Priya's background and B-M-C-A-M, I go do check out, uh, part one of this interview. I don't wanna rehash it 'cause we got a lot of good stuff to cover here.

So, Priya, welcome back and thanks for joining me again. Hey, thanks Alan. So, Priya, we left off, we were talking about the, uh, knowledge expert that's now being built into the BMC software.

You know, we were analogizing it to kind of the, uh, uh, AI we're seeing built into developer IDs. Yeah. Yeah.

Right. And, and, and I will tell you that's a great use of it, by the way. But we're also seeing the same sort of thing, the AI built into software testing, right?

That's right. Testers now have this little bug in their ear mm-hmm. Telling them this is the test to run, or that's not the test to run, or there's a mistake here and what, what have you.

I think we're gonna see the same thing coming to the ops people, right? Hundred percent. Yeah.

So how, how is that manifesting itself in, in the BMC suite? Yeah, absolutely. Well, so on the BMC side, I mean, AI ops is a, a known quantity for us, but, but the thing that's really changing right now is we just announced the knowledge expert in October.

And what that lets you do with BMC Amy assistant is actually start to interact with a chat interface, ask questions as you're doing your daily workflow as a, an operations person, right? And that's, that's a big step forward because just like you said, like on the IDE side, we've started that journey about a year ago. Um, on the ops side, we're now continuing to add functionality.

And this is like very pervasive, right? Anybody who's using the ops ui, uh, can now leverage this, this kind of chat within it, within it. So great for any team where they have, you know, different levels of resources, different levels of skills, uh, to be able to kind of harmonize across.

Um, so we're pretty excited about it. We have, uh, lots of customers testing it out, uh, giving us feedback. Uh, and it's been, it's been pretty cool to watch.

You know, what I love about it, this kind of thing. Priya is on a team, team wide level. It is fantastic, right?

Because now everyone on the team has, has that same level of access to the knowledge base to the expertise. Yes. But it's not just access in that, you know, and this was going back to the ar I told you about the article I wrote about the difference between people using AI versus Google search.

Yes, Yes. Yeah. To some extent we always had that access, right?

There were people using Google internally who put a knowledge base together that you could search. But when we have it as an AI sort of chatbot or generative AI like this, it's so much, it, it's, it's just a lot closer. It seems it's a lot easier to put your hand and finger on.

It's always, it's like having an assistant with you, a coworker, so I'm call it digital worker right there with you all the time, who is suggesting these things and can make these changes with you. And, you know what I mean? It, it's, it's, it's heads and tails above just having a knowledge base with a search bar.

Oh, indeed. And I mean, I think you look at BMC, we have the entire software stack. So what we're doing is we're saying we're entering with chat, and we're letting you start to type things in and ask questions as an operations person.

But what we're quickly gonna start to do is let you ask questions, you know, uh, how much am I spending? How can I pull back on this? Where might my problematic issues be?

And starting to cross domains. So you men mentioned a team, it's almost like you would recreate a, your environment in that, you know, digital sort of GPT context and ask questions that cross boundaries into the data space, into the ops space, or the storage or, uh, you know, wherever it might be. And that's, I think that's what's the really exciting thing is this is the, you know, this is like one of the first steps towards that.

And of course, that absolutely, that's always gonna lead us towards the, the discussion on ENT X, right? Because that's, that the other Big thing. Well, before we got to agen, there's one more point I want to make on this one.

Clear. Yeah. You know, we mentioned before a lot of people are afraid about AI taking their job, costing them their job.

Yes. This sort of knowledge base here, knowledge expert, uh, chat and so forth. This is not meant to replace people as valuable as it is on a team wide basis.

This gives every single person on the team the ability to be a superstar because they have the entire knowledge base of everything they want easier at literally at their fingertips, and in some cases even automated to pop in there. And this is why, you know, when they say you're not gonna lose your job to ai, you're gonna lose your job to someone who works AI better than you. Absolutely.

If You're an individual, learn to use this. And, and I, I think it's the great paradox, right? You know, the, the theory is we're gonna be simpler because of gen ai.

The reality is it's actually gonna be more complex. Yeah. But so what's gonna happen is if you're using those AI tools, you'll be able to master complexity faster and get to that higher order challenge faster.

And so we're all gonna have to push ourselves harder. Maybe that's why our brains are rotting. I don't know.

Or, or ahead snap videos ahead. But, um, Could could be that too. That too.

But I, yeah, I, I think there is a very valid point. I mean, we're not designing anything to replace anyone's job. We're, you know, we're designing things that help people with the workflows they already have today.

You know, that's, I think that's the other interesting thing about AI is so far we haven't developed any net new workflows. It's leveraging the existing processes and workflows and then trying to improve upon them. But you, the beauty of it, you know what someone, so all the venture backed companies I ever helped co-found were funded by my friend Brad Feld.

It was pretty well known in in the VC world. Yeah. Brad always used to tell me, 99% of tech is evolutionary not revolutionary.

And AI is a little revolutionary. I won't deny it, but the way we use these knowledge, uh, basis and the way we interact it is, it's an evolution of us getting better, of us being able to use them, more of, of them being more useful to us. And it represents the future.

It's not some far out star trekky or Star Wars kind of future. This is a future you could put your hands on right now. BMC is rolling this out as you're watching this in essence, right?

Indeed. Indeed. And so I, I, I think people need to remember that.

I'll tell you something else. I, I was at, I've been at a bunch of conferences the last couple weeks prior, and I was talking to someone a little younger than me who, who said, we were talking about this kind of stuff around generative chat bots and so forth, and they said, oh, cha generative AI was last year. This is the year of AG agentic ai.

Oh, it sure is. Yeah. But I feel like generative ai, I hardly got to know you, but, you know, boom.

That's how quick we're going. So, yep. Hey, we had our two, three years now.

Now we're, now we're at Agen. So now we're at Agen, AgTech ai and Priya, what is, you know, what does that mean? What does that mean for BMC in the mainframe world?

Yeah, I mean, look, it's, it's, again, it's an early, everyone's talking ag GenY, it's early days, and there's emerging standards. We're focused on the MCP standard. I know there's others that are out there.

I'm sure there will be more in the future, but the way we're thinking about it is a kind of a step process. You know, we started, we're starting with embedding the functionality of Gen AI into our products. Like we've just been talking about in the ops domain and the DevX domain.

We're then looking at how do we turn them into agents, meaning autonomous, you know, either purely autonomous, but more likely to be, you know, sort of guided in a way, um, agents that can actually execute tasks. And then the f you know, the ultimate goal is, uh, a workflow chain where you can have, uh, you know, an agentic workflow. And we already have some prototypes built of agentic workflows in the dev space, uh, you know, and things like that where it's chaining together different tools.

I think one of the, um, biggest value propositions right now for, especially for the MCP, is just connecting all the different dev tools you might have, or connecting all the different ops tools you might have in the average day. So I think that's probably gonna be use case number one. Um, and then use case number two will be sort of starting to automate some of those more repetitive tasks.

Going back to the spectrum of trust, where people feel they can turn it over. Um, as excited as customers are about AgTech ai, and the, the term I hear the most commonly is they want self-healing systems, but by the same token, they're still very concerned about how much they're turning over to that self-healing system. And then how much, like if there's a challenge with their SLA, who's responsible for it, right?

Is it, is it the IT operator? Is it the software provider? You know, so there's a lot of questions like that.

You know, we, this was a similar experience when cloud first came on the scene. Yeah, right. Anytime, you know, you know, the old saying, you know, how you get stuff out of a cis ops hands, you gotta un un unopen his cold, stiff, dead hand to, to get it out of there.

Right? That's right. It, it's the same, you know, there, there is going to be, I think this period where people are a little nervous about giving up control, about turning it over, automating it, letting a a, an agent kind of run full speed.

But if you're not gonna let the agent run full speed, you know what I mean? That's kind of defeating the purpose too. So I do think we're gonna have a, a period of, of trust building and then, you know, learning, learning to just let it go and, and see where this, you know, how far and fast it can go.

Yeah, for sure. And, and I think it's, you know, keeping the human in the loop, but it's also being realistic. Like, if there is an outage, if there is a problem, human's gonna have to be involved, right?

Yeah. Well, but you know, you, you look at, let me analogize it to another really like the, our electric grid. Yeah.

Right? Like, so I live in south Florida, right? The, we get hurricanes.

The electric grid really needs to be resilient. It needs to be automated, it needs to be able to, you know, uh, a a transformer goes out, a substation goes out, oh yeah. Reroute all of this.

That that's a world that's made for this kind of stuff. Right. And mainframes in a similar vein, right, in a similar vein, I, I really think, I really think mainframes are, are made for this, right?

And, and, and ai, and this is where it's like a little chocolate and peanut butter. I think the agentic AI running in the mainframe environment has, has a lot of potential and a lot of, uh, you know, space to do, to get stuff done. Yeah.

Stuff done with disaster recovery, automated failover, those kinds of things. Yeah. Especially for that, all Of these things.

Yeah. As long, absolutely. As long as you manage the ransomware element of it, because, you know, there's always that fear of, um, that's something that BMC does a little bit with too, is, you know, around you don't want, um, you, you do need an immutable copy of your data somewhere, right?

Yeah. That has to be physically and logically separated from everything else. So that's the one, one place.

But yeah, I agree with you. There's a lot of automation built up Sure. Is to these systems to, you know, drive the resiliency that they have.

Yeah. No. And so you're gonna take what's probably the most resilient system and existence right now and make it even more, uh, resilient with, with these a, a AI agents, excuse me.

Um, I gotta ask you the, the, the $64 billion question, or maybe it's the $3 trillion question. That's how many data centers we're building? Oh my god.

What does this get real Priya? Oh, that's a very good question. Um, To a certain extent, it's real now, right?

I mean, especially the generative stuff. I Mean, it's real now. It's real.

Now I think every customer is at least, let, lemme put it this way. Many customers are in the evaluation phase. In some, some state in the evaluation phase.

There are a few that are further out, uh, that are further adopted. But we put in front of our customers in a, a maturity model, kind of a four step maturity model. Most of them kind of fell between one and two in the, in the levels.

And they're, they're evaluating, they're testing, they're piloting, they're looking at different solutions. That's kind of where they're at. Um, I think the next phase is gonna be proof of value, proof of concept.

Yes. And in my opinion, I think we're about probably one to two, maybe two to three years away from full production level activities. But it's a journey.

It doesn't happen overnight. Nobody's gonna put this stuff into market overnight. So they're, you know, they've gotta take, take the steps to do that.

You know, if it takes 12 to 18 months to put a typical change into market in production on the mainframe environment for, you know, for big changes, not the code which is dropped mm-hmm. Frequently, um, then just think about AI and how much testing, how much piloting, how much, you know, you've gotta do around accuracy, governance and all those things. So yeah, I mean, it's 2025 now.

I think by this time in two years, we're gonna start to see some real significant implementations in production happening. Um, but I'll say like, even now, I mean, we have customers using our solutions to do that code, explain, you know, throughout their organizations. And so the, the earlier adopters have started.

Absolutely. You know, my experience with these kinds of things, I, I don't know if I've ever seen anything, this AI is the world unto itself, but my experience with technological innovation like this there, you know, there's no flag raised on the day it happens. There's not a button you pressed or, yeah.

You know, I I, I was talking to a quantum expert about this a couple months ago. When is Q Day gonna come? Right?

He said, you probably won't know until six months or a year after and you'll realize it came. Yeah. And it, and it may be the same sort of thing here where, because this is gonna sneak up on us because it's not an all at one thing.

It's a gradual building up of these things. Yeah. And then one day you're gonna turn around and say, oh my goodness.

The whole, the whole thing is, you know, these, these agents are running, they're doing it. Yeah. Um, so I think, and, and, and also I think this is just accelerating at such a pace.

If I was a betting man, and I'm not, I, I think two, three years might be far out there. I wouldn't be surprised to see a sizable, you know how they do the crossing the chasm model, right? Yeah, yeah.

15% early adopters. Yeah. 35% early mainframe.

I wouldn't, that's 50%. I bet you were at that 50% mark in 18 months. Alright, we'll have to come back.

And Shim, shimmy said it here. I'm on tape doing it. Come back and we'll, we'll, uh, we'll come Back.

Do it'll, we'll come back. Compare notes. Absolutely.

Absolutely. Hey, this has been a great discussion. Um, I, I just want to end it with sort of a, a generalized mainframe kind of observation, right?

Look, this has the, the potential to modernize the mainframe. I think in ways even beyond the, the, the most ardent mainframe modernization people were clamoring for. Um, do you think that it'll, is it gonna satisfy the mass, not the masses 'cause the mainframe is what it is, but do you think this is what the people, are they gonna be satisfied, I guess is my question?

Or what more do they want? What more do they want on the mainframe platform you mean? Yeah.

Um, no, I think this, this has the potential to really help the customer that says, these are the things that I need to keep on this platform. And Gartner says now, I mean, they're saying that this platform is going to be very significant around whatever, for the next 25 years, if not longer. So I think that, you know, the, the, um, the name of the game for the customer is strategic flexibility.

If I can have flexibility in my code base, if I can link to these other processes, if my people are using all the latest and greatest ai, then I'm just gonna keep increasing my productivity and I'm reducing the risk. And that's really what it comes down to for the customer. So I think there's a lot of promise and AI driven transformation for customers.

And I don't think you can assume that it's all about moving off. It's also about improving what you have in place. And that's increasingly what I hear from the customer base is, is, you know, how do I do that?

How do I, how do I make this platform the foundation for the innovation I have to do for my company and, and do it faster and more efficiently and, and with happier people? Fantastic. Priya, I've taken way more than of your time.

I, I know we went way over, but did I apologize? Yeah, but you know, it was, it was worthwhile. I think.

I hope you out there enjoyed it. Uh, we'll continue. We have a lot more, uh, information coming with BMC and some of their announcements coming out.

So stay tuned for that. And we have a lot of content here on Textron that we worked in partnership with our friends at BMC. We, including, I think we have a couple of webinars and articles and all kinds of great content.

So stay tuned for that. But for now, this is Alan Shimmel for Textron tv. Thanks for watching everyone.

Hello and welcome to the latest edition of the Techstrong AI Leadership Series. We're here with Sini sw, who is managing director for data and AI at Tech Systems Global Services. And we're having a little chat about, well, the future of large language models, a k, a LLMs.

And, well, I don't think this is the end of the story and maybe it's probably just the beginning of this journey, but Serini, welcome to show. Thank you so much, Mike. Bye Mihir.

So walk us through here. I mean, right now when I look at LLMs, there seems to be, ma most of the focus is on these massive general purpose ones. But I feel like there's other use cases, and I don't know, maybe there's even something beyond an LLM, but your assessment, where are we?

See, I think, uh, last 24 months, it has been, uh, a whole, uh, ride off innovation, you know, and new ways of doing things. Uh, when mankind was kind of introduced to this next token, you know, prediction capability that large language models really brought to the table. Um, every organization is evaluating their AI journey.

And when we work from tech systems, when we work with customers and chalk out a roadmap, uh, having an ai uh, driven efficiency is part of that roadmap. But then LLMs are just one step into providing that efficiency gains. Uh, there are several advantages to what LLMs can bring purely in the form of, uh, ability to predict, uh, almost human-like.

Uh, but then there are also a lot of drawbacks, including, you know, what you're hearing when something goes down, such as an infrastructure or, or a cloud operations. You know, the, the AI system kind of goes down. So how can we make sure organizations tap into this AI innovation while also, uh, enabling their own workforce that has become the talk of the power and more importantly, the way we are engaging with our customers.

Mm-hmm. So how do I get there? Because to your point, the models are probabilistic and, uh, so it's kind of, you know, the next best guess.

And it's to, you know, we've trained it and some say it's a, you know, an advanced form of mimicry and whatever you want to call it, that's fine. But, um, sometimes you know it's right and sometimes it's not. And we have all these processes that are deterministic where we kinda want them to be done a certain way almost every time.

And the last thing an LLM ever does is the same thing twice. So, um, how do we kind of meld these things together to get what we're trying to get to the end point here? Yeah, that's a, uh, interesting point, Mike.

The, the key aspect of a large language model, um, is predicting what's going to, you know, be told next, right? So it's, it uses, its its own, um, rich training dataset on which it has been trained. So that's why LLMs are not going to give you the same answer twice when you, you know, even when you press the enter twice in two seconds, you're going to get two different responses because, uh, the way that training data has been set up, the way the context window has been set up, the way the past historical conversations that needs to be retained for it to be able to answer again, has been set up.

So these are all hyper parameters and, uh, tuned, uh, configuration settings that can vary from model to model to model. And that's why there is, uh, this whole raise of, uh, you know, which model is the best kind of, uh, you know, argument going on right now. However, the, if you look at the big picture, it's not just about a language based translation that's not just, uh, what AI is all about, right?

AI needs to, uh, uh, think from a causation standpoint, it needs to think not just amongst the language. Our human brain can achieve so much of, uh, such intelligence, you know, by consuming low amounts of power. Whereas we are actually hearing all these large language models with billions of parameters, tons of GPUs, you know, to really make a simple prediction the next token generation work.

So there is still a long way to go, but definitely the LLMs have opened up, uh, an innovation mindset among the humanity. And we want to see where this entire AI journey can take us forward as a humankind, primarily because there are certain jobs. You know, we cannot ignore the fact that there are certain tasks that essentially can be repetitive in nature and can be translated.

For example, our tech systems, uh, we have built a solution called intelligent document processing. What it does is you have this tons of paper documents that needs to be digitized, that needs to be, you know, text needs to be extracted from it, and simple questions can be answered from that extracted text, which you, which you can basically achieve using the current technology layers of large language models. The moment you talk about making decisions, unbiased decisions, and setting it through a workflow such that these autonomous, you know, ingestion as well as decision making becomes a part of a process flow, that's when our security guardrails need to be tightened up.

Because today, in today's context, hallucination is real. Uh, I'm not sure if you're following, there are, there is a, uh, there is a, a interesting effort where, uh, five different large language models have been given $10,000 each and asked to invest on crypto. And we are seeing one model at a $3,000 portfolio value and another one at $12,000 portfolio value as we speak.

And it still continues to go up and down. So what it says is, even if you define exactly the same prompt amongst these five big LLMs, the way they make decisions and the way they actually, you know, respond back to that real time scenario, still has a long way to go. And that's what I think we have to be careful of not starting any conversation with just, uh, you know, uh, essentially pressuring into taking up AI stories, but rather look for the use case, look for the fitment, see what's the security guardrails, see if there is any risks that we're unnecessarily introducing, and then appropriately handling ai, you know, uh, uh, adoption into that organization.

Mm-hmm. Um, do we just also maybe me need to focus a little more on narrowly training some of these LLMs for specific tasks using, um, examples of something that is vetted better? 'cause Right.

It seems like to me, one of the issues with the hallucinations is that we've trained these things, their general purpose. We kinda grabbed everything and anything we could find, and you know, like in the case of code, for example, that is flawed, there's gonna be vulnerabilities in it that were created by humans that are now being replicated by the LLM, not necessarily the LL m's fault, but, um, maybe we need to just take a step back and figure out a different approach to training, maybe smaller. Right?

I absolutely agree. I think LLMs do really well when you have a clearly defined guardrails and a boundary box that you can set up for, for example, just expanding that I intelligent document processing example, if I train the model, let's say, to process Medicare claims, just in terms of expanding the text, understanding what documents are needed for this claim to be processed faster, and then reaching out with the communication to the customer and getting those specific documents such as healthcare benefits or a driving license or whatnot, you know, in terms of identification. So preserving that guardrail, or in another use case, you can also think like processing those invoice forms, right?

Uh, essentially when I have an invoice, I need to be paid automating the process of text-based digital process where this AI and large language model solutions can come in. They are well-defined guardrails, the prompts and context windows are capable, uh, to as assess that particular business process and take care of it. I think that's where you get a large lot of ROI, because at this point, customers and executives are asking, I don't want, uh, an AI solution just for the sake of it.

Show me the business value and the return on my investment. And to get to that return on investment at this point, because of all the hallucinations and the general purpose, not really yielding the required success criteria, defining a business process, setting up guardrails. And then obviously we are no longer just talking about ai, uh, and LLMs.

We are also talking about agent ai wherein you can actually connect a multitude of small defined focus points and then connecting them together to form a business process seems to be yielding a better results at this point. Mm-hmm. So are we just maybe a little bit on the too ambitious side and we need to kind of play a little small ball to figure out where to get the ROI on this stuff sooner than later?

Absolutely. I think, because again, we are talking of these large language models, um, even if they're available, uh, you know, for millions of tokens at, uh, cents and dollars still, as I said, the hallucination and the effectivity largely determines the outcome. And if you do not set up the right guardrails, garbage in, garbage out, so you essentially are not going to be able to make decisions out of what predictions, you know, these LLMs are going to come in.

So defining your guardrails, making sure, uh, understanding the risk reward scenario, and then feeding in the right data set to be able for the LLM to give you good prediction in spite of giving a good prediction, having the right human in the loop, you know, checkpoints so that you are not quickly veering yourself off into biases. I think it's all, these are all critical equations when we are implementing an AI solution at this point. Mm-hmm.

Um, what's your best advice to folks then? Because I think a lot of them are trying to navigate this whole, um, expectation, shall we say, and there's some irrational exuberance maybe, and then there's folks who are actually trying to do some things and they quickly come up to the limitations of ai, and then there's kind of this, uh, awkward moment between reality and expectation That's, that's, uh, fair. I think at, at a minimum, uh, simplifying, for example, a meeting happens, notes are taken, you know, action items are given, uh, but then you might forget by the time you reassemble the next week, right?

So how can you utilize some of these, uh, you know, innovations like co-pilots of the world, the meeting transcriptor, the summarization to prod you into making sure you are not, uh, you know, putting things off the plate, right? And making sure the key priorities are addressed. So start small.

That's what I would say for any customer who is venturing into, you know, the AI world, let's make sure where are the pain points in your business processes, where the LLM is rightly fit for solving those pain points. So that could be lot of language driven, like what I just explained, right? Like the, the invoice processing in a digital world setup or meeting transcription, or even media processing, for instance.

We are not just talking about just the language as a text. We are also, you know, we can identify a shop floors CCTV footage and then look for scenarios where there could be a safety hazard. So even that can be, uh, you know, the, the prediction around even media processing has tremendously improved.

Where you are able to ask, um, services like Amazon Bedrock or, uh, you know, Google's, uh, own, uh, AI engines, you're able to ask questions on, uh, is this a safety scenario valid, or are there certain violations you're seeing in this particular image frame? And there are good responses that these large language models are giving. So as long as you define a use case, apply a technical architecture specific for the use case surrounded with guardrails, that will ensure that it doesn't go off in a tangential manner.

I think that's one step at a time to really get to that ROI that organizations are looking for. Mm-hmm. Do you think, um, we are about to maybe build more software than we have in the last decade, in the next two years?

Some people would say, and I guess I also wonder, uh, what the quality of that software may be, and then how relevant is that quality? Because maybe a lot of these apps are more, shall we say, disposable Actually, that's very much, uh, you know, my, my mind thinks as an app developer myself, uh, uh, you know, the, the whatever we have developed in the, let's say it used to take three months, can now be done within five to seven days. You know, that's for a fact.

You know, with the, with the coding engine, the, uh, the, you know, developer, uh, uh, ai, uh, suite that we are all getting now, uh, auto complete of code, uh, you know, certain frameworks, UI frameworks, for example, you know, that you are not expert of. Now, suddenly you are equipped where you want to adopt a certain UI framework and then build your application. It's possible now.

So as you said, the development time itself has started really, really coming down. But then the validation and making sure the business process doesn't, you know, these are all like the graphical engine, right? So it could take a straight line path, which is your, let's say, uh, a success path, but the success path could also be taken through another seven or eight different directions.

So what will happen when a user navigates through a workflow, and, you know, workflow number seven is kind of taken up. What exactly will be the impact? What's the user experience?

So there's lot more emphasis, I would say, on, um, on, on the guardrail setup, on the user experience and the effec eff efficacy of the results more than the coding itself. That's how I'm seeing that the whole landscape to be evolved. Uh, you know, less time on coding, because you should take advantage of AI when it can, when it can autofill code for you in, in, in almost, uh, you know, using the right best practices.

But at the same time, keep a, keep a Sherlock Holmes eye, you know, that you are looking for, uh, looking for certain, you know, the, the rails. I mean, the guardrails is such a beautiful word, because if the train flies off the rails, you know, you are, you are going to have a crash. So make sure those guardrails is extremely critical for you.

Mm-hmm. Um, and yet you will hear people talk about, uh, token sticker shock where they're building the software and they suddenly wake up and they go, wow, all these inputs and outputs are costing me a small fortune. And to add a little insult to injury, once the app is built, they deploy it.

And because it's so verbose, it consumes more infrastructure resources than ever, and people are suddenly noticing that their cloud costs are a lot higher. Absolutely. I think, uh, it is information overdose.

You know, when, when, particularly when AI tries to be true to itself and tries to tell you how beautifully it has understood your question, and, uh, you know, tries to expl explain it in a verbose manner, uh, it, it kind of, while it is good to see such a detailed answer, sometimes the actionable part goes, you know, missing. Right? And that's why I think it's important to associate that use case as to what do you really want to see?

Uh, I would always advocate for explainable ai, which basically tells why I have chosen this decision for you, uh, rather than just saying, you know, a a 200, uh, lines of what it could all mean for it, right? So essentially make your AI systems pointed decision oriented, because ultimately when you make these small components that are decision oriented, you can connect them easily into that agent AI platform, right? So that's how you are, you should start thinking, uh, of finding, how can I get to that decision oriented yes, no flag, probably as simple as that, but more importantly, it's able to explain why did it tell as in yes or a no flag, uh, you know, when you want to know about it.

So, so that way the sticker shock could be well controlled, uh, have an architecture that really looks for decision making criteria, make sure the guardrails are followed and an explainability is constantly tracked upon. Mm-hmm. So is there something beyond the LLM, I mean, you know, I kind of feel like in a certain level, a lot of the tech in the LLM is, while amazing is, you know, we've kind of been around for a long time and we've just basically threw a lot of horsepower at it.

And I wonder if, you know, there's some other a AI innovation down the road that may supplant that, or is it just a question of kind of fine tuning LLMs from here on out? I think, uh, definitely LLMs have provoked our thought process. I would say I definitely, LLMs are not the end game, they're just the beginning, because again, humans interact in language.

So the naturally the language based model, uh, was immediately, uh, I would say we were, we were able to retrofit how it could be useful for us, such as the notes taker or a transcript summarizer, and so on and so forth. However, our human brain, as a, uh, mentioned at the beginning, it's extremely complex, right? And it does all of those work at fractions of a compute power that these LLMs are unable to replicate purely by just prediction engines.

So there are innovations going on as, uh, as I understand, uh, you know, from all these, uh, while there is always AI race as to who will really control that AI operating system, right? Which basically can do, uh, all that you're thinking of, um, it's going to take few cycles. Uh, at this point, I would say in 2025, agentic AI has taken that next leap towards performing some form of automation and not just giving a verbose overload of information.

Uh, but then there are, uh, still, you know, lot more innovations going on in that recurring neural network, you know, beyond just language. Uh, I'm, I'm excited to see what's on the other side. Uh, but one thing I would say is, uh, LLMs where, uh, where the first, I would say to open the gate, but then the castle is still few, few meters away.

All right, folks. Well, you heard it here, LLMs. It's just the opening act and all kinds of great things are starting to happen.

And buckle in. It's gonna be quite a ride. Serene, thanks for being on the show.

No, It was great talking to you, Mike. Thank you. All right.

And thank you all for watching the latest episode of the Techstrong AI Leadership Insight series. You can find this episode and others on our website. We invite you to check all those out.

Until then, we'll see you next time. Hey, everyone, welcome back to our Tech Drug TV coverage of AWS Reinvent 2025, sponsored by our good friends at suse. You know, we've been doing a couple of panels.

I love doing the panels 'cause we get a lot of points of view, and we've got some really, really smart people that I, i enjoy learning from. Let me introduce you to our smart panel for today. I'm gonna start on the far right with Rick, and I'm gonna let each of them introduce themselves because I'm not smart enough to remember all their names and titles.

But Rick, why don't you go first? Sure. My name's Rick.

I'm the general manager of the Linux team at suse. Wonderful, Excellent. Uh, Manuk, I lead all of our business and Linux application partnerships at AWS And Margaret Dawson.

I also love Linux, but it's not in my job title. And I'm the Chief Marketing Officer at suse. Excellent.

Thank you all. Rick. The other two folks gave their last name.

I'm going to call you out. Sure. My name is Rick Spencer.

That's what we want to hear, Rick. 'cause there's someone at home who says, that's my dad, my husband, my someone. I think I kids', mom, my kids probably know my name, but name, if you wanna find me online, I'm Rick Spencer.

Three, all one word on all my social media. There we go. Who's Rick Spencer?

One and two. My grandfather and my father. Oh, that's cool.

Okay. Really? Yeah.

Very cool. Well be that as it may though, we're here to talk about something really important today. You know, I wanted to start this conversation off with, I, I've been been a user and, uh, a my name is Alan.

I am an AWS user, um, for a long time. And you know, it's funny, when you start your first start, I don't know how many of you have been on, I assume you have, have done on your own AWS journey, but you whip out your credit card, you open your first instance, it's easy peasy. Mm-hmm.

Right? Pick. I'll go with the default Linux.

I click that, I'll click one of these, eh, gimme two of those. And, and it's very simple, but these things have a way of, of like being like rabbits where they breed and they, and, and, and at each level it becomes more complex and more complex. And then your, your cohort at work, he's on his own journey and she's on her own journey.

And then someone says, how many instances of AWS are we running on this table? Everyone gives the face. I don't know.

It becomes a complex kind of thing because maybe you didn't pick the same Linux I'm running. Maybe you didn't pick the same configuration manager mm-hmm. Program mano, I'm sure at AWS you guys know this journey well, where one day you wake up, you know, and then give, gave rice the whole finops movement as well.

Right? It was part of it. Yeah.

Right. What do I, my goodness, what am I managing here? What do we got?

How do I know what we have? How do we, how do we bring order to this chaos? Right?

And it, it's a problem. It's a real problem, right? For, for most organizations, especially at the enterprise level.

Rick, I don't know, do you see this problem on-prem as much at suse? Like, 'cause SUSE has a lot of on-prem enterprises as well? Or is this kind of a, a cloud specific?

Um, I would say it's not cloud specific. So what we see is that in a typical enterprise, they're abs absolutely managing a multi Linux estate as we, as we put it. And, um, there's different reasons that lead to that.

As, as you mentioned, like the ease on a cloud provider for like, you know, picking a workload, launching it without, you know, giving thought to what you know, what you're gonna do in two days when there's time to apply updates and et cetera. Um, also, um, you know, different, uh, different ways of running workloads. One company might acquire another company and that company had standardized in a different way.

Uh, so this is one of the reasons that our multi Linux manager tool is so popular. 'cause that allows you to manage any Linux anywhere at any scale. That's very useful in AWS environments.

'cause you know, EC2 customers may be managing, you know, workloads from, with all different, um, oss, not just ssa, of course, Amazon Linux, you know, other, other, other linuxes. And so that's, uh, a really good option for if you're an EC2 customer, you want to get like a pane of glass that'll help you make sure things are being up to date. Multi Linux manager will help you apply, uh, policies.

It'll help you mirror repositories so that you can, um, you know, operate with the utmost safety, et cetera. I think this goes to some things we've talked about a lot this week already, where an AWS and SUSE are very aligned in providing that choice. I mean, people may not realize that when they spin up an instance in AWS you can choose from a multitude of different linuxes or, or Kubernetes.

I know we're gonna move to that in a minute. But, um, I think the importance is that we're now very, very focused on how do you help people understand those different environments? How do you help people manage those different environments?

Have more of a, you know, single control plane. I don't actually believe in a single pane of glass. I don't think we can even do that.

But like, we can help you have better visibility. How do we understand the cost better? How do you integrate finops different things?

So that's really where we are today. And then, you know, part of that is then how we integrate ai, because that's helping you automate, helping you do things more easily. So I think the original demand and ease of use that came out of AWS, you know, initially that allowed developers to spin all that up and have that choice.

Now people want a little bit more control, a little bit more management, a little bit more visibility while still giving developers, while still having choice, correct. While still having choice. They're not giving choice up.

That's correct. And still, and ease of use. Developers wanna build an app, they wanna build cool things.

So how do we not take away any of the ease of use? We don't wanna add friction, but for the ops people, for the management, for all the other people that are leveraging, um, that incredible cloud infrastructure, how do we give them more visibility and more management, more control? I think a part, uh, a part of coming here at Reinvent with all the 60,000 developers and, you know, people who are part of the A Ws ecosystem, I think it's also to put a flag, not, uh, right now, but like what's gonna happen over the next 12 months.

And I think a part of this conversation of managing complexity is also, you know, some of the stuff that, um, Matt shared yesterday in the keynote around the work that we are doing with our frontier models. Yeah. And I think that, uh, the, the whole idea is that we are trying to abstract the complexity away.

Mm-hmm. So there is a level of, you know, abstraction, the complexity that is happening, what Rick mentioned, uh, at the, uh, the Linux manager level. Mm-hmm.

But as we progress over the next 12 months, I think we need to talk about how we are bringing the MCP servers as part of this conversation. How do we bring the, you know, the, the big announcement yesterday was around Quick Suite. Yes.

So I think the, the thinking here is that yes, we are having this, uh, SUSE Linux manager that is going to manage a lot of the, what is your security posture? What's your packages? What is the profile?

That stuff is, you know, that's beautiful. Now from a developer who just getting started, you know, the people who are doing one servers or two servers, they're not really super sophisticated into the nuts and bolts of the Linux, or as well as for the AWS for that matter. I think we are moving to this natural language processing interface, like a chat bot.

You know, you talk to the machine and the response back. So I think that's where it is very exciting over the next 12 months. I think where we see is integration of the, the SUSE manager with Quick Suite.

So customers can actually just speak or, you know, in natural language discuss, Hey, what is, you know, how is my overall the next distribution? What is my cost? How do I manage it?

What is my security posture? And I think that really makes it much more accessible and democratizes, and then also gives you more control and you have more control, more choice as well, right? Yeah.

And it also brings in like the Agentic capabilities. And so in some ways, I look at the Quick Suite as like, sort of almost an, an agentic orchestrator. And so you need the primitives there, which are those MPC servers, for instance, to, you know, right now you can go get multi Linux manager, you can install the MCP server, try it out.

Right now you can go spin up SLED 16. Our, our latest release we released a few weeks ago, install the MCP server, of course Rancher, um, install rancher, get your Kubernetes clusters and control, install your MCP server, which is great. But Quick Suite really can like help you take it to the next level by allowing you to, you know, run Agentic jobs, which may be, you know, if it detects an issue, the LLM can like make some decisions about maybe I need to log a ticket, maybe I need to use, you know, the other services that are available as part of Quick Suite.

Maybe enhance the information with some other things that Quick Suite would know, like, you know, who owns that server in your organization. Mm-hmm. Is it mission critical?

Or is this something that can go down? And those kinds of things. So I think the combination of like the SUSE infrastructure, uh, using EC two and EKS and Quick Suite is going to, it'll just be totally different in 12 months how people are managing their infrastructure at scale.

And there'll be like more uptime, more efficiency. Um, I'm, I'm really excited to see what, uh, happens over the next 12 months. You know, scale's a funny word, right?

Your scale may be different than my scale. Yes. Right?

And, and so it's relative, but you know, they don't call a WSA hyperscaler for nothing. Right. Some of this, the scale of, of the, of the install base right.

Of, of, of enterprises on AWS is truly massive, massive scale. Mm-hmm. And to me, it seems like this is a perfect use case for a AI and agent AI and MPC servers, right?

Because how else are we going to get our hands around this? I mean, when you think about why do we want to use ai, right? It's, it's to do things that, the mundane things, yes.

But it's to do things that we, we can't not easily get our hands around. Mm-hmm. And, and so I, I think it's important now, we spoke in the last panel about the strategic nature of the relationship now mm-hmm.

Between Linux, uh, between, excuse me, between s and a and AWS around Linux, around rancher, and around Kubernetes and all of this. But I don't think you can mention those three or four things without now mentioning AI as well, because this is an AI assisted model. Mm-hmm.

We've seen a lot, as you mentioned, man, there was a lot of, uh, announcements around AgTech and AgTech, AI and AI in general yesterday. Rick, I'm gonna throw it to you and then we bounce it around the panel here. How, you know, 'cause this is a 12 month roadmap, let's say, but who knows?

This goes real quick. How quickly do you see suse, you know, taking what was announced this week, internalizing it, if you will, and reflecting it on what's available in the marketplace? Well, I would argue it's happening right now.

And that Susa is uniquely positioned for this. I think only SUSE has a multi Linux management tool. Only SUSE has a multi Kubernetes management tool.

Um, only SUSE also has a, a Linux distribution that's made to work with that. Um, now, um, if I may, I, I would caution people to think about, like, if you're just grabbing an MCP server, hooking it up to your LLM and letting it, like do what it wants to do, that's probably not a good idea. Because if, you know, if you just take the approach of just exposing the API to an LLM, we've all read the tragedies of like, LLMs deleting production databases and stuff like that.

So the thing I would say is that, you know, if you look at SUSE's history over the last, what, 25 years, you know, we've been really focused on like security, safety, compliance. So we're very carefully building those agentic capabilities so that they fit into a real, real world workflow, you know? And, um, and I, I think we're probably the most trustworthy company to actually like, bring all of the, uh, power of the quick suite and all that agentic orchestration that people are doing, like, into the operation space.

I Think just gonna call. Thanks Rick. I think I wanna call back to your point about scale.

Like a, a company scale is different from B'S companies. I wanna highlight, uh, that SUSE and AWS have been partnering for two decades now. Mm-hmm.

And so we have thousands of customers that are running mission critical workloads, both on the SUSE rancher offering as well as stress. And these are, you know, company, you know, like High Performance Computing, SAP. So, so customers are really, they love the fact that the two companies have been working together.

There's a level of trust and we are supporting mission critical workloads for a long time. So I think Agen is just the next chapter in this partnership. I think we spoke already about managing the complexity of Linux, which is distributed across AWS and across your multiple, uh, multi-cloud environments as well as on premises.

How do we bring this back into, um, you know, a quick, uh, suite view, and then we can actually do real time analytics on that? We spoke about that. I think that then this entire narrative of abstracting complexity mm-hmm.

Then extends to container workflow. So with, you know, the, the rancher manager, the SaaS application that underlie underneath uses, um, uh, bedrock. So then, again, similar to what we discussed in Linux, in a natural language interface, customers can say, Hey, what's the status of my clusters?

Uh, what is the cost associated with it as you discussed? That's a big, uh, that's a big concern as well. And then, uh, how do I manage it?

And so I think, again, it's all about democratizing, making it easy, uh, for our customer. And, you know, we have a track record of doing it for two decades, and, uh, we just going, this is the next evolution of, I think there's one other piece of this strategic relationship is that we're doing this, you know, we talked about choice across very heterogeneous environments in terms of multi Kubernetes, multi Linux. Like, we're kind of embracing that together.

What the AI does is take all of those, you know, very, um, disparate sources almost of data and is does such a great job of bringing that together, just like we make it easier to manage all those disparate, you know, flavors of Kubernetes and Linux. So it, you know, there's these kind of thematic ideas that both companies are embracing, and it is about lack of complexity, but it's also about ease of use, ease of management. Um, and then I think the other piece that SUSE brings is that open source heritage into AWS that came with the supplemental packages on Amazon Linux.

So it comes back to whether you're using SUSE Linux or Amazon Linux, how does SUSE support that and make it even better, bring you the technologies and tools you want as you're using Amazon. You know, how does Amazon allow you to have a choice around that? And I think that is a very unique and differentiating, um, partnership.

Yeah. Right? Because we're bringing you the stability, the security, the scale.

Nobody scales like Amazon, right? Nobody brings open source technologies in a secure, more stable way. And then we're also giving that choice and control of heterogeneous, heterogeneous environment.

So I, I think that combination of all those things is really powerful for the customer. Absolutely. I, I, I couldn't have said it better, Margaret.

We spoke MPC service. Yeah. Everybody has an MPC server today, it seems.

Right? How many MPC server do M-C-P-M-C-P, excuse me. Mm-hmm.

I forgot what MPC thinks. I Don't know. We should make something multi Players gaming.

It is. It's a multiplayer console. That's what I'm saying.

That's what, well, that's where my head's at. Bring out the Xbox. Okay.

Yep. But you know, the, the problem I like, in my mind, I'd like to see Amazon come out with an open source version of the server that everyone could standardize on. And then sui, you could build your special sauce on top of this.

In other words, how many different, like right now, how many MCP, right? Yeah. Mm-hmm.

Now you have me questioning myself. Uh, how many MCP services? So I think one of the things we discussed, um, uh, so first of all, I think the standard spec for CP is, is open source.

Yes. It's Similar with A two A in terms of how the agents think. We have Yes.

Open source, um, more than, uh, you know, we launched this CP server slash agent tech slash AI marketplace back at the New York Summit in July. So we have thousands of I SV as well as products that are listed. So I think now at this point of time, um, the customers are really transitioning from piloting over the last year.

I think that's our, our thesis is over 2025. A lot of the piloting, a lot of testing, and 2026 customers are really going into production around that. So I think, uh, so everything that Rick and we discussed in terms of exposing the capability of, for example, the thing we discussed about either rancher, uh, um, you know, manager, or whether the SUSE Linux manager, the MCP is just like, you know, uh, it is just an interface into managing that.

Uh, you know, and how does it talk to an LLM? Mm-hmm. And then we bring that all of that, integrate that into Quick Suite.

So that's where the customer is, customers actually doing a natural language conversation with quick suite. Either it is text or it is voice. And then, uh, we abstract the complexity way or through the MCP server in the MCP client in the background, all of that insights, whether it is the state of your Linux operating system, whether it is how your Kubernetes cluster is doing, what is the security, what is the posture, the cost, all of that comes and says, Hey, I can you give me, and for example, a question would be, can you tell me how many Linux distributions that I'm using across my state here?

Mm-hmm. What is the status of my Kubernetes? Just gimme an overall view.

How is the cost trending over the last three months, six months, nine months? Just gimme a and what can I do to optimize? Those are really powerful things right now would take, you know, days and weeks for somebody to pull that entire view together.

I think we are in the next 12 months we heading, is to consolidate that view into one. I I would like to, um, well, first of all, if I may, if there's any viewers who are like, what is exactly MCP and how it's working, so think of it as basically like a shim between like any tool and an LLM. Mm-hmm.

And there's two main parts to think about. And the first part is like context, right? You tell the MCP server tells the LLM how to ask for context, right?

So how do you query for logs and that kind of thing. And then the other part is tools or tasks that the MCP ser that the LLM can actually take, right? You, you tell it, you tell the LLM, you can actually go do these things through the MCP server.

Mm-hmm. And, um, so it's actually relatively trivial to stand up an MCP server in the same way it's tri trivial to stand up a, a website. Mm-hmm.

Right? However, designing one that is usable in production in the way that we're talking about is non-trivial. And so, um, that's why, uh, we're like really excited to be working with Amazon to expose like our very careful painstaking work to like, you know, bring those natural language queries and those automated actions like into the operations and administration space.

And then exposing that back up to, to the, the quick suite where it can bring in other contexts that, you know, were are not being provided by our tools and other actions that, you know, are, are exposed to other tools. Like think of something as simple as like logging a ticket in your Atlassian or whatever mm-hmm. Your GitHub or et cetera, right?

So it can like, ask our tools for, you know, is everything looking okay? And it might say it's looking okay, but a little shaky. Let me log a ticket so that when your admin wakes up in the morning or it's looking really bad, let me use your PagerDuty and wake something, somebody up.

You know, these are the kinds of like very trivial examples of the kind of workflows that people are gonna be able to build in their, um, you know, using the, the, uh, quick suite along with our MCP servers for our management tools. So mm-hmm. Mm-hmm.

I wanna return to money. So it's, it's always on top of everyone's money. Ronnie, you mentioned a little bit, we, we can actually through Quick Suite ask the ai what can we do to optimize, you know, you wanna call it finops or whatever you wanna call it, but optimize spend cost.

Um, how, I mean, it's one thing to ask and get some suggestions. It's another thing to say, okay, you gotta close this, move that, do this, do that. How close are we to automating that?

Like, so for instance, when I write something with ai right? It says, would, do you, would you like me to do this? Yes.

Mm-hmm. And it does it, right? That's, to me, that's the money shot, right?

Can we do that now with, with the Linux, with this relationship and, and with what we have there? I mean Sure. Like, Do you want to though, is Question.

Yeah. So the way that we actually have implemented, like our, our logic is like, you wouldn't let an LLM do something, right? That you wouldn't let a team member do.

Like no sane SRE team lets somebody just like log in and make a massive change without a code review, right? So if you look at some of our demos and, you know, come to our booth, we can show you, you know, for it can, you know, write the recipes and scripts, check it in for you, start the code review process, you know, which is what you would expect a human to do. The only thing is it can be done a lot faster with a lot more context.

You know, the LLM handles complexity in a different way than a human does. But, um, that's to go back to what I was saying before, like that's really why I think you wanna partner with a company like suse. 'cause we take that very, very seriously.

Like, you know, making sure that your, uh, infrastructure is protected and compliant and following all your compliance guidelines while also giving you all the efficiency gains that, you know, admin teams are so on. I think like absolutely, I think in the enterprise setting, this is still, uh, it's still a, uh, a problem that everybody's working on. Mm-hmm.

I think if you saw, again, Matt, a keynote yesterday, he talked about everything that we are doing around guardrails and policies. Mm-hmm. So I think there is a lot of active work that we are doing both at the LLM level as well as through quick suite in terms of how do we manage and police, uh, you know, the, the actions that the LL m's taking on behalf of the customer.

I think have we, are we there fully? I think to Rick's point, um, you know, we can create guard rails, we can train data. There is already like LLM looking at the LLM to make sure that, uh, you know, we are in the state and narrow here.

Uh, and I think that's where we, we discussed like 2025 was a lot about experimenting. If we have to get to the scale in 2026, get into production, this is probably the most critical, uh, thing that we have to, you know, cross the chasm as they say, uh, to get, to make, uh, enterprises comfortable with, you know, taking that leap. Yeah.

And I think the question is when do you want the LLM to take that action versus you still want a human in the loop, right? And I don't think we're done with that conversation, right? There's still gonna be times where you want a human to push the button, so to speak.

Um, you're not gonna give the LLM access to your source code necessarily, right? Um, even if you want it to help you develop in your way. So I, I think there's still some, um, ongoing discussion and of where the human in the loop is, um, even with all the guardrails and all the, the, the governance that happens.

But I think the more you can automate all of those things and bring us intelligence faster, better, cheaper, right, then we can make better Decisions. Yeah. I mean the, I mean, we all agree though.

There's a massive push to get into that direction. I think the, the value and the opportunity is, is tremendous. Mm-hmm.

Yeah. And so that's why everybody's just, uh, you know, kind of run, you know, running for, Well, I, you know, so you ask yourself why, why, why, why must there be a human in the loop? Well, there's two reasons.

Number one, is the underlying technology good enough where I could tr I i, because it comes down to a matter of trust, right? Mm-hmm. Can I trust it by itself?

You know, I, I was driving my car on the highway a couple weeks ago going to the airport and it said, Hey, why don't try our, it's A-B-M-W-B-M-W assisted driving. I said, all right, let me try it. I'm by myself.

No one will yell at me. I, I, I hit the button and it started driving it, it take your hands off the wheel, take your feet off the pedal, just sit back and watch. And I, I, I found myself like this, right?

Sitting wait, ready to pounce on that wheel. And you know what? I never had to, it, it took the turns.

It, if I put on my signal to switch, if there's a car there, it tells me no. If there's no car, it speeds up in switches. It's a very similar experience to trusting the, the LLM, the, the AI to do these things.

It, it's gonna take time until you take your hands away from the steering wheel and put 'em on your lap. And we, we'll get there one day I think, I don't know if I'll be here, but we'll get there. And, um, it's, it's, it's coming for sure.

Like, there's no doubt in my mind this is the way of where we're headed. I mean, I think it depends on how you look at it, right? Because if you think of like the driving analogy being that, um, the LLM is changing your infrastructure like directly, like that makes sense.

But if you think about the way people actually manage their infrastructure through like Ansible and Salt and other tools, like we're there right now mm-hmm. Like those absolutely can generate like perfectly serviceable Ansible scripts that can go into your, into your whole GI ops workflow. And people can, can, you know, your other GI ops team members can look it over, other LLMs can look it over and make sure, like, does this meet our security compliance and et cetera.

So, um, I, um, I think the technology is there. As they once said on a TV show, we have the technology. Yeah.

But do we have, I think like a lot to explain a lot of that is deterministic in the sense we know there's like A to B2C, everything is fully track. I think the LLMs is non-deterministic, some part of it. Uh, so I think like once the technology is there, there's already a pattern here that, you know, the customers trust and you know, yes.

This, they're already deploying mission critical workloads through, you know, salt scripts and such. I think the, I think the, the LLM in itself has to, has to evolve to get there, right? And I think right to Margaret's point, we are still, I think for 2026, we still foresee the human in the loop.

It's gonna play a very critical, uh, thing. Yeah. Critical role.

Yeah. Agree. I mean, there are, there are patterns in like in for instance, Kubernetes, you can set it to like auto scale and different things.

Mm-hmm. So like, I think, um, a lot of it is like what RAC role, role-based access controls. Do you give the LLM And this is already a very common pattern, right?

Like a lot of platform teams will say like, Hey, our ops team is allowed to scale out, but they can't scale down. Or similar things like that. And so I think we'll see over the course of just literally the next 12 months, like patterns like that being brought into like this is a tool that we can give the LLM to just go ahead and do it.

'cause they can't do much damage. Like they could create a new table, but they can't delete a table. I Think the question is like, do you use, does ZLM put out patches to all the unpatched systems in your, like, do you trust it enough to do that or not?

Do you let it roll back a feature update or not? Right? So I think there's like a level of specificity Or certain kinds of patches maybe To do.

Yeah, exactly. Or not. And I think just one last point in the race to get to that determination, like, you know, the best state here where we can start trusting the LLM apart, a lot of it is actually training and what data that we are training the LLM on.

And in fact, and in fact that, you know, just SUSE has decades of, uh, data in terms of how customers are using both their Linux and the Kubernetes distributions for AWS you know, what Matt discussed yesterday are the frontier models around developing code on deploying code and running security. So we are running as, you know, as said, hyperscale, right? So we have like tons of, you know, supporting millions of customers, uh, over a couple of decades now.

So that data, and then what is the learning that we have done as a function of that, that informing some of the, the new AI or the new elements we are developing, specifically what that specific workload, I think that is probably the path to getting our customers more comfortable into deploying it and production use cases. I think that seems like the, the road to get there. Mm-hmm.

So there's been a great discussion, but you, you know what I'm worried about people looking at home. If they're watching this, they're probably not here. How can we get them started?

How do we, these are all great things that we spoke about, right? Really kind of job changing. If you're a, a Linux administrator or an AWS administrator, Rick, I'm gonna start with you.

Sure. Where do people go? How do they get started?

Where's the on-ramp here? Sure. So, um, I would say for a call to action, if you want to get involved, go to the marketplace.

You can get multi Linux manager there. You can get SLES 16 there. Go ahead and install the tech previews for the MCP servers, start giving us feedback, you know, what's working for you, what's not working for you.

That's exactly why we put it out in, uh, in as a tech preview so that we can iterate quickly with the user base. Mm-hmm. And same is true for a rancher.

And, uh, my call to action is do everything what Rick is. That's an easy one. Plus, uh, uh, you know, try out the new kiro, uh, software developer platform, uh, that is becoming now generally available.

Also, go look at, uh, you know, some of the new stuff that we are doing here with, uh, the frontier models, both on the DevOps side as well, security side. I think that is really gonna start, uh, pulling the story together in terms of what, you know, Rick is talking and then Yeah. And no coincidence.

Those are the three A agents that were announced yesterday, right? Yes. The kiro agent and security agent And the DevOps agent.

And the DevOps agent. Yeah. So you get all of those.

Margaret, I wanted to give you the last word. Wow, I don't see this. Now you've got me speechless.

No, I think I'm just really No, no, no, I That down. I was just gonna say that, that last two days, which feels a lot longer than two days, but there is just so much energy in this show. There's so much energy around Amazon, around ai, around just h how to collaborate.

And, and again, I'm gonna go back to, I know this is becoming a repetitive theme, but, you know, continuing to look at the ecosystem around AWS and I would say it's our ecosystem and a W s's ecosystem and the power of how all these companies and all these technologies are coming together to help people, you know, build applications that are better, faster, smarter, more secure, um, and, and deploy them, you know, what works best for them. So I, it's just exciting. Like there's just a lot of enthusiasm and great tech At, at at great scale too.

At great scale and great technology. Rick, Manu. Margaret, thank you so much for joining us on our Tech Trunk TV coverage.

We're gonna take a break here on Tech Drunk tv. We've got lots more coming at you today and tomorrow, so stay tuned, but we'll be right back. Hey everyone, welcome back.

We're here at AWS Reinventing our suite up at the wind, continuing our coverage of this year's event. This gentleman on my right, I actually, I think the last time I saw him was at Reinvent. I don't even think it was last year.

Evan, I think was the year before. Yeah. What a great, but he's a, a wealth of information and, you know, there's six degrees of separation in tech.

He's probably his three degrees of separation with this guy. He, everyone I know knows Evan Kaplan. Oh, geez.

You run in some bad circles. Yeah, I guess I get that's maybe what it means. All right.

Evan, of course is the long longtime CEO of Influx database. If you don't know influx database, shame on you, but we'll, we'll tell you about 'em in a second. Evan, it's good to see you first of all, man.

Nice. Alan, thanks for having me. A pleasure.

Um, you know what, let's start with Influx database. I, look, I'm going to guess 80, 85% of our audience may even be using influx at some point, if not now, Some high percentage. Yeah.

Well it's, you know, our people are your people. They're, they're, they're tech people, right? So, but for those who maybe aren't, they don't, they've never heard the word Time series database even Explain to them, if you can, what, what we're talking about.

Sure, sure. So first of all, InfluxDB is an open source time series database really is the first open source time series database. And, and by all external measures of leader by big margin in the space.

Mm-hmm. 4 plus million people who run it daily million sites run it daily from the largest corporation down to, you know, down to people using it at home and that sort of stuff. Mm-hmm.

And so our, our primary, let's call it invention or innovation, was by my partner Paul Dix, who in 2013 made the first commit. He had worked on Wall Street and had built a number of time series databases on top of other platforms, HBase, sql, things like that. And, and it turns out that there's enough difference, enough handling enough optimizations that are available, um, when you're working with this kind of data that it made sense for it to be one of those categorical databases like search, like document like graph.

Mm-hmm. And so he's generally considered the person who sort of invented this space, a modern version. The first version of the product was written in Go.

It had collectors now a project called Telegraph, which is actually more, more popular than the database. Really? Yeah.

There are about 400 different collectors for virtually every system out there, physical and virtual you can imagine. And so it's a super vibrant community. We've stayed with a promiscuous MIT Apache license model, so anybody could use it.

They Use it and do, yeah. Yeah. And if it's worth, I mean, just as a refresher for the audience, why, what, what, what time series is, why is it what do we mean?

Right? Why is it? And so really it's quite simple idea, which is anytime your primary tag, anytime your primary index is gonna be based on time, you can be incredibly efficient at handling large volumes at super fast.

Um, actual real time kind of, um, kind of, um, querying and ingesting and things like that. And so if, you know, you're gonna have that kind of application, IOT physical AI network telemetry, where you're gonna need that kind of speed, this kind of huge ingest, you start by building on the crime series specific platform. So you get away from these very discreet indexes that take time.

You get away from these latencies associated with queries that have to be, you know, aggregated in different fashions. You also have to do a bunch of things. You wouldn't, you have to downsample you start with high resolution, maybe even millisecond resolution, and maybe you wanna downsample to a minute.

You have to evict a lot of data. So just a bunch of stuff that you would do that a normal database doesn't do. So the category has really emerged strongly.

So we're not the only player. We have good competitors. Azure offers something now.

Amazon offers us. Like, so it's a market that's taken off. Alright, that's too long.

But no, no, it's not too long. You know what, for people who don't know what a time series database is that I think it's necessary. Look, for me personally, when I hear time series, I think influx.

I think because you had the open source model and, and the commercial offering, I, you know, there, I know there are other time series ones, but other time series databases. But, you know, the database market isn't what the database market was when I was much younger. Right.

And, and we do have, we have graph databases and vectors and this, but when, when Paul Dixon did this in 20 20 13, He made his first command. He wasn't thinking about, well, how's this gonna work with generator of ai? Right.

He did have, his background was in machine learning, really. He wasn't completely blind to it, but no, he wasn't thinking that. And correct me if I'm wrong though, this is really the, the whole AI thing.

Well, AI's helped a lot of the data, data collection, data storage, you know, access data's a big part of it, but it, it's been a particular boon for, for time series as well though, right. There's some real use cases. Yeah.

A certain, a certain, a certain kind. So, um, if you just sort of, you know, you break the world into, and it's increasingly become apparent, you have generative ai, which is largely the scraping of the digital world. Yep.

So anything, you know, and now we've scraped pretty much everything that's available and every day we scrape it again. And so there is a real shortage of digital, digital data, images, all that sort of stuff, because most of it's been scraped in some sort of way, scraped clean. And it's, and it's, and it gets, and it gets indexed every, you know, every day.

That is not, and so the issue on, on the generative side is you have to create synthetic data in order to build these models if we're gonna keep to make more sophisticated Right. And that sort of stuff. But the opposite is true on the physical side, right?

If you think about the physical world, the amount of data available to index is, is, is infinite. Right? It's just a question of what resolution you want to capture it, how often you want to capture it, and that sort of stuff.

And so, what what we're most excited about is, you know, as 'cause of our IOT orientation is the physical AI world. Because, you know, the, the notion in physical ai, the idea is I want to get a near perfect picture of the physical world to build my models around and to act on that world, right. To build my intelligence around.

And so the only way you get that is by willing to take sample measurements that are really, really Close, like time intervals. Yeah. Yeah.

So our default, our default timestamp is nanosecond. Really? Yeah.

And so we have some customers in quantum world who use that, but most, most, you know, you're not nanoseconds. No, but you know what, there was, I forget his name right now, I apologize, but he was like the chief AI scientist or one of the chief guys at Meta who just left, I dunno if John Lako. Yes.

Yeah. And he said, because we're probably coming to it, I don't wanna say a dead end, but, uh, uh, diminishing returns because of the problem you, you've outlined here. Right.

Which is, we think it's scrape, there's not much left to scrape. And that the LLM model only works. It, it, it can't imagine a sphere in open space and how it's gonna fall with gravity.

Well, let's say right? Where, so he calls them world models, right. Not lms.

And they try to model models the physical world. Yeah. And, and that's the kind of database, you know, data collection, that's gonna be Huge.

I mean, that's a really, that's what we're most excited about. And if you think about, you know, LLMs are probabilistic models, right? Yep.

Right. And so, and they're brilliantly probabilistic. Right.

They're actually really amazing. Um, but you know, when you, when you're operating in the physical world, you think of a robot, a self-driving car, a satellite in space, you need deterministic. You cannot live with probabilistic.

The chance of your robot, you know, accidentally vacuuming your cat away is just not something you will, you wanna live with. It is not something you wanna Live with. That's not, that's not risk I can manage.

And so, and you said this, so the notion of deterministic versus is probabilistic is important. And so collecting this data, building your models on really rich physical data, and then being able to act in a control system in a meaningful way, that's the future. Absolutely.

So, hey, we could talk more about that if you want, but I, I gotta bring us back to today if it's okay. Yeah, sure. Um, so there is the open source, then there's the commercial version.

You guys offer like a SaaS Yep. Version of it as well. We have a couple of cloud versions.

Yep. And we have you, you can run it OnPrem or run it in your own instance, And you could run it in the cloud. I know you've had a longstanding relationship with Amazon with AWS but you guys recently did an announcement, maybe it was a month or two ago already.

Yeah, yeah, yeah. We have, um, credit to AWS we have a, um, we have a very unique relationship with them. So we were always a marketplace kind of Yes, you could, you could purchase influx.

We run our own cloud services, our serverless platform on Amazon. Mm-hmm. And so we've always lived in that ecosystem.

We've always worked in that ecosystem. Um, but what's unique is about two years ago, they reached out to us and, um, they were getting a lot of requests because we have all these open source influx tvb to run influx on their platform. And so, you know, immediately I was like, you know, that doesn't sound great.

We're an open source player. They could just take the code. Well, It would, And it's not like it hadn't happened before.

I was just gonna say there is a reputation there, but go ahead. And so, so I was, I was a little bit like, okay, let's, let's, let's build some trust here. And, um, and the relationship we have is the first time they've, they've ever done this is they licensed our open source code.

They run our open source code, and then we build the value added enterprise features on top of it. And we monetize that, not in marketplace, but in console. So when a customer configures, I love it.

A certain configuration, we get revenue AWS So you'd ask why would AWS do that? Um, you'd have to get Brad, which I'm sure you could, who runs, runs those businesses mm-hmm. On, but, but a couple of things.

One is they saw the emergence of time series data, and they do have a platform, but it's, it's of a, it's a pretty, it's a narrower use case than influx. And they were getting a lot. And so just recently they didn't, they stopped taking new customers for that platform.

Oh. Their end of life income. So Their primary time series is gonna be time stream for InfluxDB.

And so in their world, that's a one P product. It's a product, their product, it's not influx. It's product.

It's not their Product. We work And we are close with them, and we, we work hand in glove on those deals. And we're more than happy when customers wanna, wanna purchase that, go Through through a S that works for us.

It works for That. It's a great channel. All That sort of stuff.

Let me stop you Yeah. For a Second. For my people watching this at home.

I, if you are not in this side of the business, if you're a, a consumer of this Yeah, sounds great. They got a good relationship for people on this side of the road though. I, I bet you you could count those kinds of relationships with AWS on one hand, you Can't even comment on it.

I think we're the only one now. I think they will, I think they will do more because it's worked well with us, right. Because they don't wanna work this stuff.

And unique Yeah. You had a unique situation where, hey, they don't want to use your good luck. Go use what you want.

You know what I mean? And, and there was no choice. Right?

Uh, influx is the bomb, is the, you know, the shizzle. Oh, I'd like to think we have that kind of market power. I don't think we do.

Oh, there are. I'll tell you, as someone who sits here, I don't have a voice in this race. Okay.

I appreciate that. It's Kind of like secretary, we certainly don't operate, We certainly don't operate without mindset. Don't let it go to your head.

Stay humble. Stay humble. But when I see, I mean, it's few and far between that we hear of another time series.

The hyperscalers have their in-house one, but you know, that's the old 80 20 rule. Yeah. It's 80 20 rule.

That's exactly Right. 80% of the function, 20% price. They're good if you wanna hit the easy button.

And so if you decide you really wanna Build something, but if you're serious about time series data. Yeah. I, I get it.

I guess though, it begs the question, what about the other hyperscalers? What about some of the other providers? Well, it's, um, we still run, we run our serverless platform on Azure and Google.

Okay. So those are available, um, it's likely what the announcement of last week was, not the, the original relationship. It was the, the introduction of our version three into the Amazon.

Oh, okay. So that happened a month and a half ago. And that's what we're most excited about.

That's our canonical version. Now that's where over time we'd love everybody to land on this version three, which is a almost a complete rewrite of, is it? Of all, yeah.

Of everything we've learned over the past 10 years. Let's, let's hear about some of the, Yeah. So version three, Killer features here.

Yeah. So version three, um, we just ran into a number of issues as, as customers scaled on our older versions. One is cardinality, and I know you're familiar with this, but maybe your listeners aren't.

When you get, you know, when you get the exponential, you know, the number of tags and the number of descriptors exploding, it can really choke off a time series database. It doesn't, it's not much of a problem in observability world. But in iot world, it's a pretty big problem because you can have tremendous variations.

Sure. And so cardinality started to choke off on older databases on that model. Um, compute and storage were linked together.

So that was expensive as you scaled, right? Most, and most databases are that way. But, but, um, unlinking them, we didn't support Native SQL before, really.

We sorted influx ql, which was SQL-like, so you could use it, but like all the business applications, the other stuff that were needed, SQ Q SQL added, and The tools that were built for SQ SQL or an optimal. Um, and so we, we ran into those problems. And so we, we started writing this about four years ago.

We wrote it in the open source, and we wrote it in Rust. Really, the Original database was in Go, we, one of the early Offerings with Docker and go, but we were in Rust. And, and Paul and the team had decided that Rust was gonna be a much stronger platform over the future.

More Secure for memory, safe, more secure, just a better platform for running database. So that was a rewriting rust. And then we built it on object storage as the data storage, which, so you could have long term retention without worrying about.

That's great. And then we obviously started sql, and then we did some really other interesting things. So we scaled it differently.

We scaled it horizontally. We, we always scaled horizontally. We just scaled it differently.

So it was much easier to duplicate. Mm-hmm. Um, and then mo probably most importantly, we built something, a processing engine directly into the database Right in, Into the database.

So there are probably six or seven triggers in the database that the processing engine can call. And anybody can write a Python application script or anything to use those triggers. No kidding.

So if you want ETL stuff on the fly, if you want to transform stuff, if you want to down sample stuff, if you wanna do anomaly detection, all, all of a sudden developers can write their own stuff and actually exercise it in real time at the same, at the same latency, the same performance that any database query will. So this begs the question, can I set up like a Python script repo for influx for these things? We, We have a, we have one of that in GitHub, right?

We don't have an, well, what you'd see as a traditional app store, but in GitHub we already have a repo and people are building stuff. I mean, it's pretty exciting. So the idea is that that helps us move up stack.

And so you wanna do forecasting, you wanna do anomaly detection, you build it Yourself. You want to do, have to Buy third party, Right? In today's world, it's all about scale.

So you took a 2013 database and brought it into 20, 25. Painfully just wanted say painfully. Well, none of you know, if, if it, if no pain, no gain.

Well, it Turns out, you know, one of the things, you know, I came from, um, from the networking and security world, not necessarily from the database world. I started here, one of the things you realize is like, you cannot accelerate the time it takes to mature a database. No.

Like, you can't just say like, I'm gonna have a database built in a year and think that it's gonna be able to scale. You're not gonna have gigantic. Like it has to run in the real world.

So in some ways, now that you look at ai, we're, we're kind of the boring part of that infrastructure, which is fine, but we're the least disruptable part of that infrastructure. Right. And, and, and it's nuts and bolts kind of stuff.

Unique thing here though is you have the open source. How big a help was the community in this kinda re relaunch? There are places where the community was excuse, I don't wanna call it a relaunch, Evan, that's a big Word.

Yeah, no thanks. Yeah. Yeah.

Just a, in this, In this, The version next gen, the next generation version, um, the community is super helpful in certain areas. It's really hard for the community. Really helpful in the database.

But, but here's the distinction. We built this based on a bunch of Apache standards, some of which we're the main committers. So Apache Data Fusion is and Apache Arrow, the, the, the memory format.

So we now commit to those and we use that in it. So we took advantage of the community. And then data fusion, that's our, you know, that's a project where we're the PMC.

It's a super popular, it competes with, you know, with with the query planners and engines that are in Databricks and, and in Apple's proton and things like that. Mm-hmm. And so that's a big part.

So we leverage those. And then we're really also leveraged on the connectors. Our communities constantly writing these telegraph plugins.

And that's the bread and butter here, man. You gotta be connected. Yeah.

And you gotta be connected without ETL. Right. And you can do that in time series.

What about, uh, MCP servers, stuff like that. Yeah. So we check, yeah.

I mean, sort of check four months ago. We are now using it in version three, so that people can do natural language queries against, um, against, directly against the database without knowing SQL or that sort of stuff. Some customers are using it.

I think it's really important. It's just, it's not driving our business today. Yeah.

But it's really important. It is. Um, so I, I gotta imagine with Amazon's, with this deal with Amazon and version three out here, you, it must be attracting a decent, uh, amount of buzz at the show.

It's, Yeah. This show is Crazy. I know, but it is 60,000 people Basically.

I mean, this show is, yeah. I don't know what was a decent buzz at the show? Their keynotes are the word casual buzz Yeah.

At the show. But no, it's in general, it's, we're just in a really good time in the business, having the database out, it having, you know, the level of maturity that we finally need, Amazon coming in, it just feels like a bunch of forces are working. The narrative now in the community is really much stronger around physical ai.

And people are paying a lot of attention to that kind of work. And so, you know, but, but this event, it's, you know, I think, I dunno if you read the keynote, but, you know, I talked to people who were, it's like everything was about agent, agent Ai, it, that it was all agent, agent ai, all Database stuff and all the infrastructure, all the cloud Stuff. They didn't talk about data at all.

Yeah. Database. They didn't even talk about data used to come to, uh, to this show.

They talk about S3 and, and Lambda and Serverless. Yeah. I it's still there if you dig deep enough.

Right. It's not in the main keynote. Not In the keynote.

And I get why No, I, I mean, I understand. I I, so we've spoken about this on our shows. Look, I personally think they needed to show they can go head to toe to toe with Google and Microsoft on ai.

'cause Google has a good AI stack. Yeah, a hundred percent. A hundred percent.

The train processors, all these things. And For the last 10 years, the narrative is about cloud computing. And so, and now, you know, cloud computing's default now, Right?

They don't even, it's mention cloud here. Yeah. It's all, you're right, it is all ai.

Um, I I, I had a question in my mind and I got stuck on this thing with you right here, but I'm sure it'll come to back to me in a second. But let me ask you, actually, I do remember it. We have, you mentioned graph databases before.

That's huge. Bigger than it's ever been, right? Yep.

Yep. And, and, and the other thing, what's driving a lot of this data is this whole observability space. I mean, you know, it's hard 'cause AI sucks the oxygen out of every conversation we have.

But you look at like observability, you look at, you know, the growth in graph databases. I've spoken to a lot of end user organizations where they're using a time series database. They're also using graph, they're also using sql.

Right? It's, it's not a one database town no more. No.

I mean, no. In fact, you know, my take on this, and you, you and I are of a similar vintage is, you know, when we were growing up in the industry, at least in the early years, there were only two databases that matter. Yeah.

It was, you know, Oracle and IBM PB two. Yep. And so you just choose which one, you know, and then we saw the, the emergence of MySQL and the open source, and that, that stuff probably happened, started, you know, 18 years ago or so.

And then you saw the, the taxonomy of dropping into these specialty databases, right. Documents, sq, sql, and all of the No SQL graph and all that. And now those are pretty well-defined categories with, with large competitors.

And so, you know, it really, and the ability to assemble the appropriate data models and do it are important. But I think the important thing is, is the Oracle and IBM of this world that I foresee, you know, are the Databricks and the snowflakes, and now the fabrics and the big queries and The, they, they Are, those are the databases, right? Yeah.

We are all, we are all live in that constellation. Our data, if done right, the models are built somewhere in Databricks or Snowflake, right? Yeah.

They're all the structured data, the unstructured data, it's all combined. The intelligence is built there. And we view ourselves, and this is distinct, and most people don't dive in, not as an analytical database.

Even though our analytics are great, we view ourselves as an operational database, really. Yeah. We want people to build control systems.

We want to build, you know, dashboard, list monitoring systems. We wanna build automation. We want people to use our stuff And I to be active into the Right.

Right. We don't, I mean, well, because it's Analytics Are there. Yeah, no, I get it.

I mean, you have to be, it's table stakes. Yeah. But that's an, I never thought of it that way.

That's actually a good, So you think about our customers, you know, whether it's Tesla trading energy from the ba, the power walls, whether it's, um, Utah sat, um, or Kuper doing, you know, the early satellite positioning and the change of positioning. Mm-hmm. Like, these are all things that are happening in somewhat real time.

These are things that Lakehouse can't do. Yeah. Right.

They're latency. The orientation, the cloud. Only half of our customers are three tier architectures where they have stuff OnPrem and in the cloud.

Like, you need, like, it is totally different. It's a very different World, different thing. You know, it's this whole, the, the, the, the data, the age of the data scientists, right?

And, and this AI thing is giving them rocket fuel. Yeah. Yeah.

Right. com. So we're very big in platform, right?

Yeah. The biggest element joining that community data scientist, it don't make sense to me at some level, but data scientists are very interested in making sure they have this platform. So where, So you say it that way.

So what, what what we see going on, and it's early, is that there's emerging category called the, you know, that that feeds the data scientists that feeds Yeah. These data engineers. Yes.

Right? Literally, they're not SREs, they're not DevOp. No, no SREs that distinct.

They're Nothing. Right? Right.

These are people who build these pipelines. So you have these distinct database, you have these flows. They own the engineering.

They're like, if you think of it, I mean, we used to talk about plumbing. They own the platform. They have the real plum, right?

They own the Platform. How does the data move across these applications? How are they made available to the model?

How do they operate in real time? That if I could train, you know, I have two college aged kids, if I could train them to do a job that I thought would be future proof, That's, that might be it. That would be the time job.

com. org, 300,000 strong community. And I'm telling you, those are the two fastest growing elements in that community.

Is data engineers and data and data scientists. Yeah. Yeah.

Because that's where the action is, at least right now anyway. And going forward, it's interesting. Now it's in the way we, you know, in the, in the late nineties, we, the network engineers, right?

Remember, remember how important those roles were. They still are. Obviously.

It's incredibly important. That's how I got into computers playing with Word Perfect. And Novell.

Novell, You're doing your IPX land. Yeah. Remember I was, I don't ask.

Anyway, Evan, it's been great catching up with you. Let, let's, we gotta give some call to action. You know what?

Okay, a good, a good marketing person I had here earlier said, you always gotta end with a call to action. So the call to action is, is if folks are interested in anything, any resource associated with building our role is to make it super easy for developers to start with Time series. The database is super easy to use.

Download available on GitHub on our site. com or do your local chat, GPT search and see how we're doing on go. How are you doing on GI Think we're doing pretty well.

I got a note today that a customer told one of our people, we found you. We did a, a search on chat PT for DevOps and SRE Oh. And you guys came Up and they, and they sent them to, yeah.

That was pretty cool. Yeah. It's world, that world has changed.

You could do a whole show. That's a Whole We do Anyway, my friend. It's Great seeing you.

It's good to see you. All right. Thanks for having Me.

I think Kathleen, He's thanks and thanks, uh, ausa folks for sponsoring this. Absolutely. Well, as a matter of fact, we have more Susa coming up later today, so stay tuned for that.

Welcome to Security Boulevard, the cybersecurity podcast from the Futureum Group. Each episode explores a variety of topics within cybersecurity and the technologies that drive it. com, security Boulevard, YouTube Channel Techstrong tv, and all your favorite podcast platforms.

Before we begin today's episode, let's meet the panels, starting with Mitch. Hey, good to be here. Mitch Ashley, I lead the software lifecycle engineering effort at, uh, practice at futurum.

Awesome. And Fernando, hello everybody. Fernando Montenegro.

I lead the fiber security and resilience practice over at, uh, at Futu. And I have a distinct pleasure of working with both of you on a regular basis. Alright, well, as you can tell from the backgrounds of my two friends, uh, they are not in the office this week.

They're actually out in Las Vegas because it is everyone's favorite post Thanksgiving activity that doesn't involve taking an app. It's Amazon reinvent everyone, it takes over the strip. There's lots of great excitement going on there, but there's also a lot of announcements, and usually they're something maybe innocuous, like S3 could be them driving a giant semi-truck out on stage, remember the infamous snowmobile.

Uh, but we're really focused on cloud security. So I think what we want to do for this episode is we wanna talk about the state of cloud security. We want to see where we are, where we hope we can be and, and maybe kind of figure out what you need to know about how to make it work.

Well, uh, yesterday I started my day shoveling snow. Uh, so, uh, so I started my day shoveling snow, which is totally fine. So we had about, I don't know, three, four inches, whatever, right?

And, um, but uh, my day ended in, in, uh, in a warmer climate. I'm speaking to you all from, uh, Las Vegas, uh, where it is 7:47 AM and, uh, I'm here for, uh, a WF uh, reinvent. So I apologize about the, the, the, the recording.

Uh, if that's the case, it's just that I'm speaking to you all from a, from a very, very nice hotel room. It, it is the best lighting that you can get in a hotel room in Vegas. But you know that that's how it goes.

And, and it's funny that it's, this week is reinvent. For those of you who don't know, the, uh, the, the week after Thanksgiving is historically don't schedule anything in tech because Vegas is gonna get taken over by everyone from Amazon, uh, that's not currently selling online books. And we wanted to take a, uh, little bit of time today, uh, kind of talk about cloud security, because, you know, one of the things we always get a lot of at reinvent is a lot of announcements around a lot of new products.

Uh, you know, it could be something innocuous like S3, it could be a giant semi-truck full of hard drives, the infamous snowmobile. Uh, but we wanted to focus a little bit on the security aspect of things, uh, because, well, for better or for worse, cloud security has had a heck of a journey over the years from, uh, virtually non-existent to why don't we do this the way, this way in every, uh, enterprise that we work in. Uh, Fernando, what are some of the things that you've been seeing that kinda give you pause about cloud security, but maybe also give you a little bit of hope?

So I'm, I'm optimistic about cloud security, uh, in the context that our conversations with stakeholders, whether they be vendors or, or, or buyers or investors, or we've sort of normalized what cloud security looks like. If I go back, so, uh, let's go back just a few years, like five years or so, right? We were having a conversation whether things were going to be, um, you, you take the word cloud security, you take the expression cloud security, you could put the emphasis on the word cloud.

So it would be cloud security, or you put the emphasis on the word security cloud security, right? And this, it, it's a joke, but it, it does resonate in the context that where does cloud security reside? Does cloud security reside with the cloud team?

Does cloud security reside with the security team? Right? And, uh, you, you may remember we had the, the, the cloud centers of excellence, right?

Where, uh, which were fine, right? So other organizations are adapting and, um, but I think we've come, we've come to a, to a, to an agreement, uh, of where cloud security fits, right? And I would argue that the two, uh, we wrote about it earlier this year.

Uh, there were, there were two major moves that, uh, oh, there's Mitch Lovely, right? Uh, there were two major moves that, uh, that, um, that had, uh, an impact on this. The first one I would say was when Palo Alto Networks moved a significant amount of cloud security functionality from Prisma Cloud into Cortex Cloud earlier this year.

And then the other major thing, of course, was, uh, Google's announcement or alphabet announcement that it's, it's intent to acquire with, which is a transaction that is almost that, right? I don't think it's, last time I checked it, I mean, it cleared a few regulations, but not all yet. And those two things signal to me that we've, we've been, we, we've sort of agreed that cloud security, or at least the, the detection and response part certainly be belongs with operations with, with, with the SecOps team.

And then it's wonderful that Mitch just joined us because Mitch, of course, is our application security expert. And, um, so there is this cooperation between okay, application security teams, you are, uh, creating infrastructure and business logic and whatnot that's running cloud environments. So there's stuff that you need to fix ahead of time.

And then the, the security operations team is, look, you are now getting telemetry about cloud. Do something about it, right? And, uh, um, so I'm, I'm optimistic.

I love that you brought that up, Fernando, uh, back in your original point about the fact that there was this discussion about where should these functions reside? Should they reside with a cloud team or with a security team? Because I deal with this a lot when I'm talking to people about field day.

Well, where should we go to do our presentation? Should we go to cloud field day, or should we go to another, uh, presentation? And, and I always look at it like, who are you trying to, who are you trying to convince, right?

Are you trying to tell people that work on cloud every day about the importance of what security means to them in their organization? Or are you trying to convince security people that there's a lot of things that we can do now in the cloud? I always look at it kind of like, uh, robot surgery, right?

Like this idea of doing like telemedicine where you have a, a surgeon driving a robot that's doing this, this kind of surgery, who's the best person to do that? Is it someone who can operate a robot well, or is it someone who knows how to do surgery? I think if it's you on the line, but, but I know for me, I'd rather have a doctor who's fumbling through figure out how to figure out how to run a robot than having a robot operator going, yeah, we don't need that pancreas.

We can just throw that thing out. Um, like I, I would rather have a subject matter expert who's being cross-trained on things rather than trying to bring someone who's not natively familiar with these tools and functions up to speed. And, and to your point, you know, Fernando, as you close it out, I still think that a lot of the things that we need to be able to move fast on really have to re reside with the operations teams that are doing that thing day to day.

I don't want the guys that are turning up route 53 to be the ones who are doing DFIR for my cloud instances, why? That's not their job. Their job is to keep operations running.

The SecOps people are the ones who are supposed to look at the logs and go, wait a minute, something doesn't feel right here. And, and the thing is, and so this, this goes to the trends that, uh, that we follow and so on. And one of the major ones that we talk about in the context of SecOps is what we call the expansion of the attack surface.

And what I mean here is that the attack surface or that, that some someone from SecOps now has to deal with, has significantly expanded, but it expanded both in the number of things we're asking people to do, but also in the types of things that we're asking people to do. Exactly. To your point.

Now, if you are in SecOps, you should be able to be familiar enough with cloud to understand what Route 53 even means, right? And, and, uh, uh, and yes, it's always DNF, and uh, but at the same time, what is the boundary between how you are handling an incident? So, uh, what is the handoff between SecOps and engineering, right?

Uh, what is the, the, how do you even change the metrics for that SecOps team? If I pass it off to engineering quickly, does that mean that, that we handle the problem and it's now resolved, or no, we have to do the regression. We have to make the fix and the regression testing and on and on and on.

So how do you play the, the, the, my time, my time to, to, to bring up economics first? Uh, how do you, how do you bring up, how do you align the incentives between those teams to make sure that things are flowing as they should? I think you hit a key point around flow, uh, Fernando, which is every time we expand the tax surface, which is only going to expand, right?

It's not gonna shrink, is we have the potential for creating yet another silo, right? Whether it's agents this time, or AI models tomorrow, or it's automations that we're putting in the business or in o in operations or SecOps for that matter, it's very easy to, for startups to create a product or a tool targeted that, or even for a cloud provider to say, we now have this thing, right? We have Route 57 or whatever the next thing is that's gonna come along.

And it, it is very easy for us to think about it as well, who is the group that administers that? Well, there's probably a lot more to that, right? These are all interconnected systems.

They don't stand alone. Yes. DNS is part of the fabric of the infrastructure.

Agents are part of the new kinds of way of, we're creating software and automations and, and doing business work. So I, I think vendors have to look at this as a holistic sell, not, you don't get to, you don't, the days of being able to go to the architect in the cloud architect team and have them sign off on your product or over, because you have to talk to the ciso, you have to talk to the security team, you have to talk to the infrastructure team, you have to talk to the SEC op team. That's who all who has to get involved in that.

And maybe you need to talk to the software architect also while you're at it, because that's all part of a system that they're all building because signing, having one group sign off on it is probably gonna lead to an isolated implementation, which is a failure in most cases. And I'll give you one more thing. I think that, um, there is an element here, you know, about the, the analogy of the, the, the drunk looking for their keys, right?

Uh, they look for the kyiv under the, the, the, the spotlight, because that's where it's, that's what they can see. But the keys may be somewhere else. I think about that, um, in the context of everything we're, we're talking about how are we capturing, are we sure we are capturing the right, uh, attack surface, right?

I was reading a paper this morning, uh, really interesting, uh, trying to formalize or trying to, to organize, uh, a discussion around how much of the actual attack surface you may not control, right? And the example that they were, they were using is the, the auth attacks via SalesLoft, right? And, and, and now, and, and now you have the, the, the, the shy Hulu, uh, uh, worm that, that's going through NPM and and GitHub.

And it's a really important point for organizations. Like, like you said, it's important for the vendors to, to reach the right people within organizations. And it's important for organizations themselves to have a very clear view of what their attack surface is.

And the reality is, hey, I can do patching, I can do, uh, uh, I can do patching in, in, uh, operating systems. I can do patching applications, right? Fine.

They are part of your problem, absolutely, but they're not the totality of it. So you, you need a broader view of cloud to bring back to the topic cloud. You need a broader view of cloud security.

How does identity flow between the cloud environments you're at, right? Where is your, uh, um, where is your IDP, right? How, uh, how are you, how are you doing transitive trust between applications, right?

Are you monitoring the behavior of how your AU tokens may be used, right? We all, we, yeah. Anyway, go ahead.

No, no, no. We, we saw that today actually, as we're recording this, um, uh, there was an announcement that OpenAI had a data breach, but it turns out that OpenAI didn't get breached. It was actually a breach that occurred about a month ago with a company called Mixpanel, because there's an API integration between Mixpanel and O and OpenAI.

And so we're starting to see that kind of thing. To your point, Fernando, about how much of my attack surface do I control? More and more what we're seeing is, is that companies are being kind of breached secondarily because something got into a provider of theirs.

I mean, you know, remember when suddenly Ticketmaster's database got breached, and you're like, well, how did that happen? Well, it turned out it wasn't Ticketmaster's fault necessarily. It was something else that was breached because they didn't turn on two-factor authentication.

And so we're, we're seeing these kinds of things where you're, your attack surface can be very narrow on your side, but it may not be something you can completely close off, because in order for Mixpanel to operate with open ai, you know, they needed to have things like name, email address, operating system, referring websites, you know, things that the API needs to actually function. You cannot completely remove that, right? Like, there's no way for you to wall that off completely.

So you're always going to have to be a little bit open. And the only thing you can do from a security standpoint is figure out how you can limit your blast radius from that, you know, give them the minimum amount of information necessary, prevent inroads from being done, like you said, you know, are, does OAuth to this other system allow me to do things on this, on my system that I would rather not have them do. And if you're not auditing things in that fine of a grain, you don't really understand the power of cloud because, you know, in the old days when all we had was perimeters, all I gotta do is stop the bad guys at the wall, right?

Keep the barbarians outside of the gate. Nobody ever asks what happens once the barbarians get into the gate, into the castle, because it usually doesn't end well, because it turns out that everything is soft on the inside. And, and cloud really does need to be like a series of, almost like pill boxes, right?

Where it's like you can breach one of them and, and maybe I lose that system or that, that zone, but you can't get any further without doing some massive, like, uh, you know, attack plan or something like that in a, in a way, you are creating more friction for attackers to have to overcome, hopefully making yourself a less enticing target. Absolutely. And, and, and this is the thing where I'm, I'm optimistic because all major cloud providers give you several controls to do that, right?

So for example, uh, I'm here we are at AWS, so in the AWS you have GP fees, right? So you can, you can limit the blast radius kind of to that VPC, and then you have organizations, uh, organizations and policies that there, there is the possibility of doing that. Uh, well, the, the, the caution I would give is that, um, the cloud providers, they have two competing, uh, pressures on them on one, then on one hand, they are trying very hard to give you all of these controls that limit the blast radius, right?

Uh, perhaps you implement something with the lambda as opposed to a vm, because now, hey, guess what? You don't have to worry about the, the patching that, that, uh, that VM anymore because hey, it's a lambda function. Yes, there are trade offs.

I understand. So on one hand, you have the cloud providers giving you that level of control that, that, that granularity and level of control. On the other hand, you have organizational, uh, I don't, uh, organizational pressures from clients to make the cloud operating model be closer to their existing model.

Oh, we used to have a data center where all the applications were, okay, great, we're going to have one VPC that is our data center, where all the applications are going to run. That is, uh, a suboptimal cloud security architecture. And I think that, uh, one of the big challenges for providers is to help clients educate themselves on this.

And for clients, it's how do you make that transformation within your organization, right? Um, and, and that is a hard cultural problem. You know, Fernando, I think there's one key question we can help the industry elevate, whether it's vendors.

I know customers already asking this, which is, how is what you're offering me or you're telling me that I can use of your product, your cloud service or offering, how does it reduce complexity? It isn't just about cycle time. It isn't just about, you know, preventing the next style or type of breach.

Every new thing we add to the add to the kind of mix, the Rubicon, if you will, that the SecOps team has to manage is, is another person. I gotta hire another process, another variant of, you know, variants. Um, I remember talking with, uh, the, uh, former CTO of, of, uh, Twitter was Twitter at the time, and his, one of his key questions was, will, will your product or service require me to hire any more people?

Because I don't, I don't have any budget to hire more people, more or less. That just increases the complexity, because if I'm, that means I'm taking on more work, not less work. And I think we have to really ask ourselves as vendors to say, we might have a really great solution, but, but is it gonna make the lives and the budget as well of, of our customers better or worse?

Because if it's worse, they're gonna, they're gonna try it, they're gonna walk away from it and say, I just can't take on one more thing. Absolutely. Um, the, the, the flip side of that though is that have that organizational structure.

Have those budgets been divine for a world we no longer live in, right? And for a world where security is that much more important, right? To make a, a very bad analogy, right?

Uh, why does NAFA need so many people, right? Uh, well, it needs many people because launching rockets into space is complicated. Designing things are complicated, and it's always a push pull between, okay, how many people do we need?

Well, uh, back when things started, they didn't need of many network engineers because the networks were much simpler back then. Well, the networks got more complex and they had to add more network engineers, right? The same thing happens with every organization.

Is your constraint on your security budget, right? Um, if it, does it match the reality of your operating environment? Does it match the criticality of your, of security to your organization?

And and importantly, does it match future state, right? Here we are 2026 and, and, or almost 2026, and we're looking into what's going on in the world, right? Yes, of course, A gentech AI is the, the, the big thing for 26.

And, and, uh, that is one of the things that's going to be very, uh, interesting to discuss here this week at reinvent. But more than that, what is the change in the regulatory profile, uh, coming, right? If you look at the regulations, uh, in Europe for Dora, right?

For, for resiliency, right? Yes. Those regulations are primarily aimed at financial services companies right now, right?

But they set the standard that we expect others to follow. And guess what? Those regulations keep, keep raising the stakes of what you need to do in cloud security.

They're, they're, they're coming. Dora Dora is coming for more than just for finance. Yes.

And, and, and we're going to need a map, a Dora map, a horrible pun. Horrible, horrible pun, right? Uh, uh, in order to, to, to, to fix the, no, we were, we were, uh, sorry, Tom and I were chatting earlier about, uh, uh, kids shows and whatnot.

So, so I'm sorry, I have earworm Dora the Explorer right Now. Be careful of those green room discussions. But, uh, anyway, but the point is, I, I think you are right.

Uh, and again, it's that push pull of how much do we change, right? How much did the cloud security change over the past 10 years in terms of budgets, right? Hey, as we moved more workloads to cloud, hey, we need more cloud security budget.

You know, I think there, there are people in the organization that think naturally about kind of what the next thing is, but most of the, most of the organization doesn't. They're kind of on, I don't wanna say they're on autopilot, but they're, they're working on what they're working on, right? And I, I always see it as the number one of the number one jobs because leaders have multiple number one jobs, which is why prioritizing is so easy.

But one of the number one jobs is someone has to be looking forward, right? Are we, are we equipping ourselves to fight the next war or the last war, right? We're in the middle of the current one, and the other, the next war is already not only on the doorstep, but it's here, it's happening through the rest of the organization.

'cause they're adopting whatever new technology, whether it's AI today or something else tomorrow. And that who has, that's who has to fight the fight about the budget. And are we spending it on the right things?

You know, it's not only going after the right amount of budget, it's also, yeah, do we really need to keep spending what we're spending on patch management? There's a much simpler way to do that, or a much more economical way to do that. Or, or we, there's something we maybe don't have to do anymore.

That's actually the easiest way to kind of save some money on the budget to say, how do we strike that out if it's not really providing value today? It's easy to let things layer on top of layer on top of layer, just let the momentum continue and then unraveling it is nearly impossible unless someone takes the charge and grabs the helmet. It's, it's almost like you've described technical debt in a nutshell, Mitch.

It's, it's, well, oh, isn't that what, wasn't that what this is about? No, sorry, I took us down that green room topic. But, but it kind of goes back to what Fernando was saying about companies saying, well, I just wish you would do it the way that I'm used to without realizing that the reason why you've done it that way for so long is because it is a series of the best decision that I can make at the time, layered on top of each other, hoping that they would only, they were only gonna be temporary, which we all know is a lie, because there's nothing more permanent than a temporary decision.

And when a model comes along that basically forces you to rethink things in a different way, you immediately recoil against it, because it's not the way that we do things, except it's the way you would do things if you had the benefit of doing them now as opposed to 10, 15, 25 years ago. And so I think that that's why we're, we're still fighting these problems, right? Is a lot of companies believe that it has to look like this, or it has to, to be pushed along like this, otherwise it's quote unquote wrong.

And, and our, our idea of security goes all the way back to, you know, something as, as crazy as, you know, like having a physical security guard, checking ID badges at the door, uh, creating man traps, uh, for people, you know, like you, you have to buzz through the second time. Uh, you know, we, we have, we now have to look at the way that we do security and realize that a lot of those outdated ideas don't work anymore. Like, yes, there's some aspects of physical security that are still important, but when I'm sitting at home all the time, do I really need to pay to have security guards in a non-existent office building, or should I be focused on using that kind of security budget to do better challenge response authentication or to, uh, you know, implement zero trust methodology?

So then the event that something happens in a coffee shop, I, I don't have those problems. I can't have those conversations right now. But what I can do is I can tell the people that are having those conversations not to keep one foot stuck in the past hoping, well, if, if it looks like what I'm used to, then it must be right?

As opposed to, you know, throwing all your cards out on the table and saying, okay, what is the result? What are we looking for? We're looking for a, a, a, a faster, safer environment for our people to work in.

Well then let's cut away all of the things that don't provide that and get to a state where we are, and then look at what we have to have versus what we want to have. And, and I, I, I love how you framed the, the, the decisions at the time. I think that this is something that we are as analysts, uh, as, as vendors in industry, as, as people in stakeholders in industry.

We need a healthy dose of humility and empathy as well, right? In the context that we don't know all of the constraints that were, that are in place or the constraints that were in place, right? And our best option, I think, to help people along is to, okay, baby steps or, or, or little experiments or, uh, let me show you something a little bit different, but, but we keep moving them along.

The challenge becomes when, uh, when people, like you said, they, they, they, they recoil, they default to what they know out fear, out of, uh, uh, rather than as a, rather than as a, as a decision, uh, as an explicit decision to say, look, this thing that is new is not working. We're going to go back to, we're going to stay with something. And that is, again, a cultural conversation, right?

And it's the kind of thing that, again, is driven by economics and psychology, um, uh, so much, right? And to, to bring this, to bring this back to, to, to cloud security, right? It's very comfortable to look at the, at the, at the, at the diagram and see, oh, look, this VPC is connected to this VPC, here are the pa, here's the, the, the, the routes, and here's the, the nat gateway that the, uh, and, and here's the, the load balancer that wonderful, right?

But isn't there a layer of abstraction above about the identities that are being shared about the, the data flows themselves, about the, the, the exposure to, or, or how the APIs, the, the AWS or or other cloud provider? Of course, APIs are being used, so we become more comfortable with, Hey, this is the little environment we're working on. Uh, it's a bigger world out there.

I think we'll probably go ahead and wrap it there, just because, uh, this, this is one of those evergreen conversations that we could probably come back to three reinvents from now. Um, but, but the important thing is, is that we have to show that we're making progress in this, right? Like we, we can't just sit here, do nothing for the next 12 months, and then have this exact same podcast in a year.

Because no matter how good our defenses are, the attackers are always sharpening their tools to be better at what we're, what they're doing against us. So if we sit still, unfortunately, six months from now, a lot of people who are doing this job won't have jobs anymore. So yeah, it's what it's, and, and, and this is one of those, I, I agree with you, and this is one of the things where I encourage people to open their perspectives if they can.

So for example, I'm looking at all the announcements from that are coming from AWS They are very interesting things. Like just a few days ago they released some Magen AI capability for security incident response, I thought was really cool, right? They are in, in, uh, increasing some support for post quantum cryptography on a couple of areas.

That's really interesting. One area of deep interest to me is the, the evolution of the sovereign cloud, uh, options, right? To go back to regulations and so on.

But the thing that struck me is that as I was going through the, the, the, the announcement so far, and we're expecting a lot more coming up, right? But as I was looking through that, the, the sheer number of security relevant announcements that were not under security, right? Uh, the fact that, uh, I, I, I don't think they are under security, but, uh, uh, the load balancers now support post quantum, uh, cryptography, key negotiation.

I, I'm pretty sure that's not a security announcement. It's a, it's an application announcement. There's another one about, uh, container, uh, image signing that's not under security, but while there's a clear security implication, right?

So, uh, my suggestion to people is keep an open mind about where security capabilities are coming and how do you operationalize that capability in your security program. Maybe it's talking to your friendly, uh, engineering team and say, Hey, how are you doing image signing? Or what can we do to help you with that?

And, and stuff like that. Alright, well, like we said, this week is Amazon reinvent. So Mitch, I think you're gonna be a busy man, as I can tell by the, uh, the wonderful hotel backdrop that you have.

What have you got going on this week that people should be checking out? Well, other than diagnosing a few wifi issues, which is what to be late today, um, you know, there's a lot of interesting kind of jumping to the other end of the spectrum. AWS launched, uh, KIRO, which is their IDE, uh, specialized in some areas that other IDs aren't.

Um, I'll wait for the announcements to come out here about that. But along with that, there are several things to your point, um, Fernando, is there are a lot of security announcements that are happening that aren't part of security, like adding in observability into the agent framework, adding, um, identity into agents. Okay?

We don't talk about that in the security sessions necessarily, or we do, but it's also in the agent control plane. It's in the, uh, development IDE environments. It's in the, uh, control and management configuration platform engineering section.

So there are a lot of places that I think we're gonna see, uh, security announcements. I know we'll see security announcements that follow all the way up, uh, kind of further left into the, into the development spectrum. Maybe that's something you and I can, can kind of figure out.

Uh, Fernando is what's the best way to kind of paint that picture as opposed to here's the siloed announcements, right? Because that's what we're all trying to sort through of what does all this stuff mean. I go back what Tom said earlier in the conversation about having a conversation about what you want to happen and then go from there.

Perhaps that's the way we're gonna do this. Fernando, you're out in Vegas enjoying the not snow. Uh, what have you got going on that people should check out?

Uh, similar to Mitch, we have, uh, uh, uh, lots of, of, of meetings. My, my big thing, uh, a little siloed, my big thing for the week is there are two areas that I'm poking at, uh, around, um, around cloud security. One of course is agentic.

And I am expecting, hoping to have good conversations, hopefully deeper conversations about our level of trust in the reasoning engines on agents, right? At which point does do, do we accept that we need a more neuros symbolic approach of, uh, probabilistic LMS plus, uh, uh, rules or, or other types of formal logic? So I'm hoping to go down that path a little bit.

Also, uh, sovereign cloud, right? And, and, uh, the conversation on sovereign cloud is interesting because they, they are related, right? In the context of we have the eu, uh, AI act, we have, uh, new things coming up in terms of, uh, what capabilities can you use in the cloud given the fact that it's regulated to being that particular region and, and, and, and so on so forth.

So I'm looking forward to that and roaming around the, the, the expo hall, like I love walking around the expo halls. It's a weird thing, right? Alright, well we wanna thank everybody for listening to this episode of Security Boulevard podcast.

If you enjoyed this conversation, please do us a favor, subscribe on YouTube or use your favorite podcast application. We don't want you to miss any episodes. Don't forget to leave us a rating and a review that really helps out because people know what we're all about around here.

com and futurum Group. com, tech Strong TV website or the Techstrong TV app. It's available on any platform or you can watch stuff.

We also want you to follow Security Boulevard on socials, including x, Twitter and LinkedIn Security Boulevard s that's security BLVD, uh, if you wanna make sure you're following the right account. Uh, thanks for tuning in. We will check you all out next week.

Hello everyone. Welcome to this tech strong session about where AI meets cloud platforms meets a lot of the hype that's going on right now with a lot of the free market forces that we are used to navigating in the past decades. My name is Ram.

I'm the chief evangelist at the Cloud Foundry Foundation, and today my session is about how much docker should a data scientist know. Now, the session should have actually been how much should a data scientist actually care about? But I think, you know, we are going to go for the more demure version here.

So let's get started. A lot of the conversations around data science and containerization and ML and all of that feels a little bit like, you know, the parable of the blind men and the elephant. Um, people seem to know a lot about what they're talking about.

People seem to have very strong opinions about what they feel this whole thing should be, but also people are, you know, just trying to figure out what their niche is and car little piece of the whole data science and the ML and the ops puzzles for themselves. And so in this rather uncertain world, it feels like, uh, and I'm saying this with a lot of experience as an empathetic developer advocate, is that a lot of the data scientists don't want to hear about the ops overhead and they shy away from the cognitive overload of how certain artifacts get deployed in production and how they are served versus they love to focus on the technical aspects of here's how my ML workflow gets set up and here's how my ML workflow is actually working, and things like that. And so it's, it's not very difficult to imagine, is it?

So people who are deep in the field of data science want to specialize in focus on data science as their area of choice, whereas a lot of the work that actually needs to happen in order to serve any kind of useful working means for this stuff needs to go through a whole bunch of cloud platform internals and cloud platform specific work. So it, there's a, there's a very clear line, and this is not the first time something like this is happening. So we had the whole dev and ops and then the DevOps and all of that happen in, in like the past 10, 15 years.

And so this whole notion of cloud platforms and having specialized ML and specialized ops stuff that are rather independent skills of each other is not something new to the industry. And it's not something that the industry is going to hear for the last time either. No matter what new technology we come up with, there's always going to be a way in which these problems are bifurcated into to, even if you think about something left field, like marketing, there's always stuff about writing content and then making that content live and discoverable and then, um, you know, a whole lot of operations go into making a single piece of content become more visible to a lot of people and make it easier to be consumed.

So machine learning and all of the data science work that's happening right now is no different. And we've seen this with cloud platforms. In terms of a small history lesson.

Lot of conversations began with what was known as the 12 factor application, and the reason the 12 factor application was even promoted as a thing was to make deployments to the cloud much simpler. So a lot of people before the 12 factor ideology came along were writing applications and deploying them to servers that they had control over, they had full control over. However, once the cloud came along, and once a lot of changes happened in the infrastructure world, a lot changed in terms of how an application had to be designed in order for it to be made available on the cloud.

So 12 factor came along, and then more recently we have what is known as the open application model, which is more of a cloud native thing. So if you're in the business of containers and Kubernetes, you're sure to come across the open application model. Then for the AI world specifically, there's what is known as the model pack, which is a specification, and there is the cloud native AI model spec.

So the module pack follows the specification called the cloud native AI model spec. And all of these aim to define how an application is structured in order for best deployment on the particular infrastructure of choice. So all of these provide different ways in which you want to take your application, and then you want to make it available in production.

Now, I like to think of this with a, with a tiny analogy. Here's the red color vehicle that I want to go to work in every day in the morning, however, here's the red color automobile that I'm going to be using in order to get to work every morning. So there's a, there's a massive distinction between, uh, what I really want in terms of an experience going to work versus what the experience is like actually getting to my workplace.

And so a lot of platforms have tried solving this problem in the past. For example, Heroku aimed to be the most sophisticated platform for deploying applications on the cloud. And then Cloud Foundry came along, which to replicate the experience of Heroku, but it provided an open source alternative for those who wanted the same kind of polished Heroku experience, but on their own infrastructure.

And so there's a lot of work that has really gone into trying and defining what the experience is like. Now, if you looked at this entire ML ops workload as a stack, the the tiny slice that you see on top, that sliver there, thus that part is your entire ML ops or your ML workload. And then this ML workload sits on top of so many layers of different operations and different orchestration and different infrastructure tools.

It's hard to believe that the entire focus of the world is on a tiny slice that's almost microscopic contained compared to all of the other things that are contained beneath it. And it's very difficult to really put a finger on, oh, I just need to work on this tiny piece, or I'm just optimizing for a little bit in terms of what I'm trying to do with an, with, let's say, fine tuning an ML application. But then there's a lot of supporting tools and there's a lot of supporting things that are actually present underneath it that make this possible and make it a reality.

Now, what is developer experience in the world translates into what is the data scientist experience in the ML world? And so I'd like to spend a little time in trying to defining what this data scientist experience actually is so that there's a nicer transition in terms of, okay, here's what my data scientist expects and here's what I can provide for them. Because a lot of times the conversation is about, Hey, I'm a data scientist and do I need to know the internals of what containerization actually is?

Um, the conversations can be, Hey, I'm a data scientist. How well should I know to write a docker file? Being a data scientist, you probably have the advantage of having a generative AI tool that can write your docker files for you more or less, but that's not the point.

The idea is a data scientist must data or a data scientist must data science versus how much should a data scientist actually get into the weeds of when, where, and how to be able to deploy an application to production. So the two two pieces of this puzzle kind of are where does the work actually happen for the data scientists and where does the actual serving or the deployment happen? And so there's so many times that we've seen how this happens, right?

So a lot of times programmers write code and then they check it into version control, and that's about where their contract should end. But they always have to be concerned with, oh, here's my code, here's how it should be packaged into a container. Here's how it gets deployed, here's how many instances I want during deployment, et cetera, et cetera, et cetera.

And so whether or not programmers like it, they have to take on a little bit of the ops workload, which doesn't necessarily always have to be a bad thing in the sense that unless you know how your application is behaving in production, you won't be able to architect it or fine tune it better. Now, you could argue that making an application behave better in production may not necessarily be the work of a programmer. But then again, that's a very opinionated, uh, path to take, right?

So in the world of data science, we have a very similar paradigm. Where does a data science, uh, a data scientist actually work? And where does the DS work happen versus where is it served and what is it served as it there?

For example, there can be a Jupiter notebook in which a data scientist does a lot of work, whereas you need the, the end artifact is an is an LLM that gets deployed to production. And so how does it go from one stage to another? And so that's really, and, and what are the steps that are required to go from this stage A to B?

And how much of those internals should the data scientist actually care about developer experience or data scientist experience in this case is something that is core to what a lot of people are trying to achieve. And they're going after the fact that if data scientists are taken away from their core propositions, it's going to be a lot of toil for them, and that's not something that everybody wants. And so let's get to the second part of this entire talk, which is to containerize or not to containerize, or rather to know the internals of containerization or not to know the internals of containerization.

That's kind of the questionnaire. And so let's spend a few minutes in making the case for deep diving into containers. And as a data scientist, upskilling yourself into learning about containers, let's start with the most famous statement made about containers.

It works on my machine, or rather it works on my inference stack, for example. So containers were born to solve this problem with compute where enormous amounts of inconsistencies and gaps can exist between where a particular artifact was built and first deployed versus where it needs to be. So it's that here's where a data scientist works versus here's where it gets deployed, but for a programmer, here's where it gets tested versus here's where it gets deployed.

So you might get tested on a local machine first, and then it gets deployed to staging, and then it was, it's tested there, and then it gets deployed to production where it's subjected to a little more testing. And so it has to work everywhere. And containers helped formulate this method where people were able to get it working in all of these places in a very homogenous, very simple way without having to actually struggle through a lot of the steps that it takes to make a uniform deployment.

And so because of that core proposition, if data scientists are actually struggling with things like, oh, I was able to get this working on my local stack, but it's for some reason not working in production, or it's not working in some other remote staging instance in exactly the same way, and you want to model the behavior in a more homogenous fashion, I think it's a good idea to learn containers and learn containers in a more deep fashion as opposed to just being very skin deep. A lot of times what I've found is the better you're able to tune your application, the parameters and all of it, the less expensive it is for you to run them in an actual production environment. I'll give you an example.

If you're, let's say, running an inference, workload and inference workloads we all know can be very expensive. If you're running an inference workload and you want to optimize it, unless you know the internals of the process that goes from the start of your inference workload to the actual inference that happens, it's very hard for you to be able to contain it in a manner where it is not burning through your infrastructure, it's not costing you too much, and you're able to decide actively and positively with all of the situational awareness about how best can you optimize your workload for cost, and you're not going to be able to do it without sufficient knowledge of container internals. And finally, there's the idea that, you know, there's an information overload perennially that's happening.

And the best way to avoid this information overload is by using containers and then taking containers as the best point of abstraction, as opposed to diving really deeper into what sets up the application stack and how it actually performs. So this, you know, is, in my opinion, these are three very good reasons in order for you to do a deep dive and learn well about containers, even if you're a data scientist and even if your job just involves creating certain ML workloads and not getting into the ops side of it. Now, that being said, I also want to play a little bit of the devil's advocate here, and let's take a very quick look, uh, maybe not as deeply into why I would say that this feels a little bit unnecessary.

Cognitive overload can strike anyone, and I'm sure despite having PhDs and despite knowing how to write like Python code, um, there, there is, there is a human element to what a data scientist can and cannot do. And therefore trying to prevent a lot of the cognitive overhead is not that bad of an idea, to be honest. So you can still, if you can still get away with some sophisticated ops mechanisms and automation mechanism there that you can set up u using the services of other ops people or other experienced people, I think it's useful to try and get away from, you know, learning dock, learning containerization, learning infrastructure, learning, a lot of the cloud native pieces that come together and things like that.

So there is the, the notion of cognitive overload and trying to avoid that as an active pursuit. And so that is definitely a reason for not doing a deep dive into, uh, learning docker and containerization and all of these tools. Now let's take a look at some tools in some communities that are building a lot of things on which I've based this entire premise on.

Now, this is not a problem that I've discovered. This is not a problem that I claim to be the only one aware of and solving, but there's so many different tools that are doing a great job of trying to put up a better data scientist experience by abstracting or obfuscating a lot of the different workloads that can distract a data scientist. And let's take a quick look at one or two of these tools that, that do a good job of this and see how it can actually help.

I'm going to pause for a minute 'cause the phone is ringing. Got it. Three, two, one.

So the first slide showcased all of the different techniques, and then like I said, we're going to look at all some of the tools that actually go into solving these problems. And the first of the tools that I want to showcase is known as kops. Now, kops is, again, please be aware that all of the tools that I'll talk about in the rest of this talk are all open source and available for you to play around.

org is an open source tool that largely concerns itself with some of the workflows that go into making and maintaining a lot of the model artifacts and a lot of the data sets and a lot of the different pieces of and ML workflow be in a single easy container. So Q tops is, um, borrowing from this world where we were able to package and define applications differently for different eras. So q tops sakes is approach that, you know, we had machine centric workloads before we moved to virtual machines later, and then containers dominated the scene.

And now can we take all of these learnings and apply them to this new world of models without having to necessarily compromise and put data scientists down in a world of having to concern themselves with where do I store data? How does it relate to the code? And which data and which code and which configuration actually go together and which is the model that is built using these data sets, et cetera.

Uh, in order to illustrate this a little bit further, here's a slide. On one side you have what looks like my desktop, but, uh, what is actually the spread of artifacts in a data scientist's life? Now, in that spaghetti is code that goes into creating a lot of the models, the artifacts, things like that, a lot of configuration that runs the code storage where all of the data sets, whether they're trained data sets or whether they're raw data meant to be cleansed and meant to be cleaned and meant to be used, or if it's a lot of the configuration that is required to manage these.

And also the models that come out as the output of several training workflows. Now, people just have to store them wherever they, you know, get space. They, they use tools like GitHub or GitLab for, for putting the code.

They use S3 buckets. They store configuration in Google Docs. Some code lives in Jupyter Notebooks because a data scientist is uses Jupyter native workflows.

And, you know, some stuff can be living in some storage that they bought a long, long time ago that people tend to forget. So people tend to, you know, over time accumulate a lot of technical debt in terms of where this happens. And so it's very hard for people to manage all of this in one place.

So enter kops and Kops proposes this notion of a module kit where kops basically takes all of this hodgepodge and helps data scientists define them. Now, it takes, uh, an approach that's very similar to what Docker does and what a Docker file does. They say, here's a kops file that you don't have to generate, one can be generated for you.

And so a kit file gets generated that stores all of the information that's present in a particular set of artifacts, and then it organizes all of these related artifacts into what is known as a model kit. And then you can transact with this module kit just as you would a container. And so for a data scientist, kit ops is designed to relieve huge amounts of toil when it comes to creating a lot of these places where you need to specifically design and store artifacts all in one place and architect them all to belong together.

They could all go in an OCI registry as a container, but the whole container notion does not apply when you're not going to run this individually. So kit ops takes an OCI artifact, it takes all of this content, addressable nature of an OCI artifact and puts all of these in different pigeon holes where they can be retrieved and used very conveniently. Now, let's examine the different utilities of kops, um, but in the form of questions, okay, so are you a data scientist who is managing, you know, library version conflicts and you have too many, you feel like you have too many projects and environments in order to accomplish the same kind of work, then you know, kops can be a good for for your organization.

Uh, are you having to deploy a lot of things? And this is the core of this presentation where you don't necessarily have to understand containerization. You don't necessarily have to involve yourself with CICD pipelines and a lot of those things, but yet you would like to take advantage of all of the sophistication and automation that those can provide.

If that's you, then Kops can be a great fit for what you're trying to do. Another thing that a lot of data scientists struggle with is what if you want to roll back to a version in production? How do you get to a previous version?

It's not something that's easy for the ML ops folks to accomplish. And so kops provides this simple way in order for people to be able to do that. And that's a very convenient workflow in the world of containers that you can borrow and make use of by you employing kit tops without having to get into container details.

Now, if you're struggling with keeping all of the different assets in one place and unifying the stuff that needs to be together to work together, then you know, kops is great for you. And finally, if there's, you know, a, if there's no clear way in order for you to query individual pieces of an entire ML ops artifact kit, then you know, kit ops can be great. And what I mean by that is if you say, just want to look at the data set that has gone in, or if you want to just look at some of the configuration files that are present, if you want to only look, download a model and put it somewhere, then Q tops can be very convenient for workflows such as these, all of which are accomplishable if you're using OCI artifacts and containers, but not as easily.

So without having to dive really deep into OCI artifacts and containers, you can extract all a lot of the advantages of going that way provided you use a tool like Kit os. So that's one of the tools that I've found that's very useful. A second tool that I'm going to talk about is meta flow.

Meta flow again is open source. Uh, it is open source stands in large due to the efforts that have happened at Netflix over the past many years in their AI and ML ops teams. And meta.

The meta flow docs has a nice image that kind of is very representative of this talk and also, I guess in some way was very reflective of what it is that I wanted to showcase. So it shows how a lot of the pieces that go into creating, uh, an application stack in the world of AI and ML involves infrastructure and knowledge of infrastructure and complete operational capabilities and skilling in terms of infrastructure and how much a data scientist actually cares about the different pieces and about the different ways in which infrastructure can play. So in order to really understand this, I guess meta flow is meant to simplify movement between stages.

So if you have, I mean, not if you have, you obviously have local instances where you do a lot of the prototyping for your application, you throw it at a remote instance or a staging instance where you do a lot of the testing work and you make sure that, you know, stuff is prepared in order to be in the third stage or what is known as production. And this is very common for a lot of web architecture and ML architecture is also the same. It follows kind of the same paradigm.

And so it begs the question as a data scientist, can you move your workloads between these three stages without having to struggle? Can you keep track of, you know, all of the pieces that are going from stage to stage so you can reproduce any of these pieces without any difficulty. Uh, there's also the question of how can you, you know, make sure that you know exactly which pieces, kind of like what we were looking with kit ups to where you can reproduce very specific using very specific versions of data sets of models and things like that.

And how can you structure something very complex without a lot of dependency conflicts? And finally, you know how you can, you know, pass data between different stages of the projects and without having to actually manually undergo a lot of tile. And so meta flow helps in all of these pieces.

Again, this is possible with a lot of automation. This is possible with a lot of, um, you know, containerization and some of those things, but do you necessarily have to know all of that is the recurring question. And finally, I thought, you know, I'll, I'll make a mention of cloud native build packs, which have been great tools in like grassroots level containerization for ML workloads especially.

org. Do take a look, it's a spec for how you can create containers in a way that's not necessarily dockerized. So a more open, a more portable format and a more suitable format for custom ML ops workflows.

And finally, just a quick mention about ML ops. Uh, I love the tale of the blind man and the lame person sort of symbiotically and syner genetically helping each other out. And I think a lot of times DevOps workflows are like this.

And now ML ops workflows are also taking this same shape and form. So you remember that thing that we spoke about all of the different pieces that can arise in an ML stack. Well, it turns out even in the absence of containerization and Kubernetes, you still have a lot of the ops overhead intact, and there's very little that one can do just as a pure data scientist.

Now you have to make sure that a lot of different pieces are available and working together. And there is the definite necessity for PA paths in ML lops as there is in the world of cloud platforms. And so depending on what part of the ML ops workflow that you are a part of, there's a lot in terms of what a paved path can do for you.

And maybe that's the next big thing that we'll talk about next year, uh, in this same session. But thank you so much for having me tech strong, and it was fun preparing and delivering this talk for you today. If you have opinions and if you have thoughts about how ML ops and ops workload should actually function, please feel free to use the social media handle that's there and reach out to me.

I'm available on all leading social media platforms with the same handle. And I'd love to hear from you about how you're tackling a lot of the ML ops workflows as a data scientist or as an ops person, how are you serving your data scientists? Once again, thanks for listening and hope to see you next year.

Bye-bye. AI coding tools are everywhere. In fact, AI tools are everywhere.

Do you have the right tools to make your applications, your enterprise applications work? Well, join me on the Tech Field Day podcast and we'll find out. Welcome To the Tech Field Day podcast, where we bring together a group of IT technical experts to discuss a single idea about key concepts in the industry.

This podcast features a variety of perspectives from members of the Tech Field Day delegate community. It's often recorded in association with one of our events. Tech Field Day is part of the Future Room Group, and this podcast is also published on our sister company Site Techstrong tv.

On this episode, we'll be discussing how generative AI coding tools are making enterprise applications worse. But before the discussion, let's meet who's on the panel today. I'm Calvin Hendrick Parker, I'm CTO and co-founder of Six Feet Up.

I'm Jim Zarinsky, chief storyteller at Zero Defect Computing Incorporated, JQ, chief Product Officer at Nexus Tech. And Of course, I'm Anta Cook, an event lead here at Tech Field Day. And I, uh, recognize this interesting topic for us about how generative AI coding tools are enabling a whole lot of applications to be built, vibe, coding of applications, and that some of the major software vendors have made statements about having large proportions of the code and their applications written by generative AI tools.

Yet at the same time, some of those same organizations are commenting that these large applications that are full of AI generated code maybe don't work as well as they used to. There being some commentary on Windows 11 needing some rework. And it does lead me to wonder whether that rework is being required because the generative AI applications, while they're good at making small pieces of code, aren't necessarily very good at making enterprise code.

I wonder, um, Kelvin, you get involved in some development projects at times. Do you think generative AI tools are good at small scale and not so good at big scale, at least for building applications? I'll, I'll preface that with, it depends.

I think the, the, the tools themselves are, uh, Excel based on who's driving them and their level of expertise with managing the context. Um, I actually, I'm at reinvent, uh, Amazon's big conference this this week, and they announced their, uh, three agents, uh, on day one's keynote. And I think they're obviously trying to double down on, uh, AgTech with kiro and then some of the tooling that they're, they're releasing, uh, they have the AWS transform, uh, tool, which is supposed to be able to move you from a legacy code base to a, a more modern code base.

Uh, I think they've seen success, but I think they've also been working very hard at, uh, generating some sound bites that are, uh, meant for keynote uh, consumption. I think there's still a lot of work behind the scenes that's gonna go into making this a true reality for most enterprises to pick up these tools and, and go, that's kind of my take on it to start with. And that translation from one, uh, programming language to another, one framework to another is something that came up when, uh, we were at Kon and I was talking with, uh, Martin Reynolds of, of Harness, uh, he pointed me to some, some work that had been done about translating something that was written in, um, JavaScript and was being translated into Rust in order to make it a more maintainable.

And these tools are really good at that part because it's well known what you're going to, and so you're just saying go find, go look up all the world's knowledge on the, on the technology you're moving to, given the context of what we're going from. That's, that's actually a, I think a straightforward use case for this. The, the enterprise tooling of let's go build brand new, uh, never before seen bespoke software is a different case.

I mean, we've had success with it on small projects and some large projects, but it, again, it's that careful, the careful driving of it by a, I find very senior resources who understand and have been in the industry for a long time. It's hard to pass that knowledge of how to drive these tools down to more junior folks. On a related question, if I could, uh, I, I, I have my theory on why BUN was acquired, but I'm wondering if there's gonna be, be a vertical integration that is part of the m and a strategy of some of these, uh, AI providers so that they can have relevance in what, uh, someone believes is the biggest market they can go after right now.

And, and as a data point, right? Where I think that is, you know, IBM clearly with their granite models and the stories that they brought with Watson X really made it, uh, very straightforward for people that have very strong in-depth COBOL legacy bases, uh, to bring those to more portable Java, uh, for your particular runtime. I'm sure they have a very specific runtime in mind for you, uh, for you to do that.

But it is interesting that BUN was acquired. So I'd, I'd like to get, uh, other, other input from folks on what they think about that. I think Bun Bun was a natural acquisition for them, given how Claude code, the fact that that was the, the, the TUI framework behind it.

So I, I dunno if I read too much more into the tea leaves on that one. I don't if Jim has an opinion on that Since you mentioned IBMI also saw a story, I believe it was just this morning that the CEO of IBM was talking about where we are with, uh, ge uh, general AI intelligence, and he basically said it was about a 1% chance that it's gonna happen and it would require immense upscaling and all other kinds of things. So, um, I, I'd like how you put that Calvin, the, uh, meant, meant for keynote consumption.

I think there's a lot of that going on. And I'll speak personally this morning. I just did a presentation, uh, implementing a chat bot against some really sensitive crime data for the city of Chicago with a colleague of mine.

And, uh, it's not easy to implement complex stuff even with really good, uh, coding tools. Uh, the reason we have senior developers, right, is so that juniors can learn from them. And the, the person I was working with, she's been working with this particular tool for 25 years, and in five minutes she showed me more stuff about the tool I was using that I didn't even know about how to use it properly.

And, uh, so I, my concern a again, I consider myself to be one of the people that's down in the trenches here, and this all sounds awful pie in the sky to me. And I just don't know if organizations, you know, I I imagine senior developers are rolling their eyes so hard that they're hitting the backs of their heads when they hear claims like this. Uh, AG agentic is one that really frightens me from the perspective of turning over that much control to tools that no one really understands underneath the covers of what's happening.

Uh, so that's my take. I I thought the IBM CEO's take, Uh, was quite intriguing. Does does it mean that we're looking at only incremental benefits in the, in the tooling that is used by the developer as compared to the onstage keynote promise of yeah, just, uh, write de declare what you want and then sit back and watch it.

You know, we go from vibe Kobe to like vibe, I don't know, audience. We we're, we're literally just watching. Uh, and and there's our, there are already memes going through this, right?

Where, you know, it's the, it's the picture of, you know, I think it's from, um, uh, the social network movie and Zuckerberg staring at his laptop with that dejected look on his face, and it's the, the caption is, you know, watching chat. GB two do the job that I used to love. Um, and so, I mean, so, um, I'm, I'm, I'm a horrible Python developer, right?

But, uh, I've shipped better quote, quality, uh, passing test code, um, recently because I do use Gemini. Um, and that that's my tool that I use. Um, I've even tried to use Gemini inside of, you know, uh, vs code, um, vs code, of course defaults to, Hey, you're gonna use copilot, right?

You're gonna use copilot, right? You, um, so for me, I, I do see incremental benefits, but I don't, I don't know if I, I'm really ready to say wholesale turn over, you know, the whole design, uh, process of product engineering over to an AI quite yet. I wonder that if one of the challenges is that most of that information, most of the, this is how you build an enterprise application, this is how you build a good enterprise application, that that information doesn't exist anywhere that these ais have been trained.

Mostly it, it exists inside people's heads and is transferred person to person as gym experienced, uh, not through documentation or, uh, books, white papers that could be scooped up and fed into a large language models training path. I think possibly, uh, the challenges that information simply isn't easy to feed into an AI to a large language model in order to, to learn how to design enterprise software. I feel, I feel like that's gonna change really fast.

I feel like tools like Antigravity and, and Kiro, uh, from Amazon, they're going to be watching what the developers are doing and reacting and actually incorporating. I think they're gonna start incorporating that into the, either the training, the fine tuning, the, that, some other, again, I'm, I'm, I'm a little Amazon biased this week because of where I'm sitting, uh, but there's, there's interesting things on the horizon. I think those things that they presented at the keynote are probably 12 months away still.

Like, they, they looked good. They, they sounded amazing. But I think when it comes down to actual use cases, Amazon is probably getting that kind of improvements internally when they're saying they're migrating old versions of their services to do new versions of code going from old J dks and New J dks.

Again, those are like best case scenarios. They make great case studies, like the great white papers are gonna be of those things, but when they go to build the new things, I think that's, and, and I kind of wanted to touch back on the a GI comment that Jim made. I I, I think that's interesting.

What got us here will not get us there is absolutely my take on it as well. I, I think we're gonna see more putting together domain specific small language models that are highly specialized. Like you'll have a JavaScript model and a Python model and a, you know, Java model in your toolkit and a, and a orchestrator model sitting at the front end watching and, and kind of making these things all make the right kind of decisions.

You're already seeing that today with some tools like Goose from Block. Uh, that's one of my favorites that I, I talk about quite a bit. They've got their, um, kind of, um, uh, the, the director and, and the, the worker, uh, models that you can actually configure today to have a multi-model set up where one's watching the other's doing the work.

Yeah, you, I, I watched your, uh, side by side where you were kind of like, uh, doing like a bake off, if you will. Um, and please Pillsbury, uh, do, do not sue us for me using the term bake off on this, uh, you know, podcast. But it, it is, it is interesting because effectively what you were doing was like a speed dating version of what I think is gonna have to happen every single enterprise where they have some capacity to ship digital product.

And if, and if they're doing that, and if, and if let's say that they're, you know, kicking the tires internally, you know, there might be, uh, they, they, they maybe start with the world of maybe what Alistair was referring to earlier is just like that, that enterprise data. None of these companies have seen that before and it's just trained upon it. Um, so they may start with, uh, Hey, I'm gonna come up with some lightweight way of doing fabric, a data fabric, and from that data fabric then someone says, ah, we should have a way to like, uh, materialize views and personalize and save and tie it to this line of business.

And they may start with low code, no code within a vendor ecosystem of what would've been their business intelligence group. But, but I do believe that there is going to be this appetite for, uh, to your point, Calvin, I wanna imagine something that never existed before. Um, and I, I just don't, I don't know where the connected tissue would come from for that.

Uh, legacy enterprise specific, call it quirky, uh, you know, uh, uh, approach that Alistair's referring to of, well, that's the way we've always kind of done it here. Uh, this is our data standard and format. So, um, that, that's that bake off that you did.

I'm just trying to imagine like what's the, what's the toil in the enterprise setting knowing that your time probably has to be tracked somehow or tied to some cost center. How, how, how do, how does an enterprise have any chance of succeeding? And this does, does this mean everything has to go to the, some like global systems generator, probably several of them on the floor at AWS saying, no, no, no, no, sweet summer trial.

Don't try to do this. Let us help you. Right?

But the, the issue that I'm gonna see with the enterprise is they'll probably hamstring themselves by saying, you'll get to use one tool, it's gonna be co-pilot inside a VS code. Where I think the real advantage of like that bake off what it showed was given certain kinds of context, certain tools performed better. They're obviously gonna converge over time, but you may still have sweet spots where certain agentic coding tools are just better at building the CI pipeline than another.

Uh, I did that during the, the last tech field day, I built a blinky lights electron app, and sure enough, codex one shot at it built it up real quick. I was like, incredible. Now let's make a CI pipeline that can build it in the cloud for me.

I could not get Codex to do it for the life of me. I went and dropped over into Goose a one shot at a CI pipeline, and then it started working, but I didn't spend a bunch of time trying to like force that square peg in the round hole. I, I, I quickly defer to another tool because I think that either it's, you know, there's too much junk in the context window.

The, the system prompts that are behind some of these tools just don't have my use case in mind. And so that's where some of these tools are very limited. I think enterprises are gonna need to adopt some specializations.

Like I could see there's the, you know, IBM version of this tool. com platform, those kinds of things. And they'll be very specialized and understand what you want a lot better.

And so one shot will be easier. Well, one thing I'm not hearing in all of these discussions, by the way, is, um, how secure is all this? Uh, I just came across right on my Thanksgiving, Turkey reading was an article on the Atlantic about chatbots are becoming really good criminals, and they were describing how, and we just saw this recently, right?

Where, uh, you know, state actors are using ai, generating AI to write really good code that penetrates from a thousand different directions, whatever it might be, right? And, uh, in fact, I was mentioning back to boots on the ground, you know, my topic today that I was working on with my colleague was about how do we lock down access to embeddings? Because we don't wanna let everybody have access to the embeddings themselves because well, somebody may not know how to write Python to connect to say, a MySQL database to actually get at it, but an AI tool could, and, you know, what do people think about, well, you just, it's all vectorized, don't worry about it.

But ain't that hard to get an AI to look at vectors, you know? And so I'm just, this, this the headlong rush I'm not hearing about, you know, really we should make sure that the wheels are down before we land. You know, that's like a really important thing.

And maybe, uh, they're down in lock. And as, as a lifetime developer of 45 years, that's what concerns me. I'm not saying we should stop, but do we have a checklist?

Do we have a checklist to at least check that the AI is doing what we really said it should do? And are you hearing that I'd be interested from the AWS or IBM perspective, whatever you guys have heard, are people talking about that or Not mean they actually are, that was a, a big impetus on the keynote on Tuesday was the security aspects of the various models, the new policy guardrails that they're releasing inside their agent, uh, uh, framework. But I, I, as I look at that, even like Google's anti-gravity tool that they released, what, a week and a half ago, it's been a week and a half maybe.

And within two days of that releasing, there was an exfiltration, um, vulnerability discovered almost immediately because these agen tools have the ability to use tools like they, that's the, that's their key feature is also their key weakness. You're gonna have to employ other techniques and be given that, like we're not only developers, like a lot of us on this call are also systems, people using tools like OPI on a Mac, uh, little snitch is like an absolute required. Uh, I don't want, I wanna know if a process on my machine is making a connection I was not expecting.

Uh, 'cause that's, that's may the only surefire way to know and have it proactively block those kinds of things. Uh, because I don't think you can write a bunch enough guardrails yet with these tools, they're still non-deterministic. They still can do things because it's statistically probable to do them.

And if they've been trained with some nefarious, you know, materials, uh, baked into them, it's, you have no, you have no control of that. You're not auditing or analyzing these models. Uh, you, you sometimes you don't know where they'll come from.

Uh, that's a difficult piece, but you have to take other countermeasures, I think to, especially in the enterprise, the enterprise should absolutely be having, uh, watching their outgoing traffic like a hawk. I, I assume they are. And I, I do it at my own desktop level.

When, when you think about what it means for an enterprise to take on a net new creating of an application, uh, what's that joke in software? Once you've started writing the software, now you have two problems or whatever, whatever that is. Um, so as they, as they create this new software, I am still left wondering the, the cho uh, the, the, the chores that need to be done.

Uh, do we see any indication that if you know Jim, like your example, like is, is this thing gonna do das Rast and all the other things that need to happen on that stack to make sure it's secure and stay secure as it drifts through, like updates and changes. But the other part of that is, is I'm wondering if, is there, is there any, is there anything we're seeing where, um, relief on the call it site reliability engineering side or the, or the platform engineering side, these, these teams have literally less toil on their plate as we ship new, you know, applications. So I'm, I'm, I'm kind of wondering about the full lifecycle, you know, setting aside like whether we can even get there or not, but let's say when something lands, um, now what, um, day two is forever, That's here.

I mean the, well, it's announced again, keynote wear. The other two agents other than the kiro application agent was a security agent and a DevOps agent, they were announced. Again, you can, you can recreate these on your own with your own sets of like cloud code or GOOSE or ER type tooling where you have system prompts that are geared toward these pieces.

You have the right hooks into the event systems to to hook into your CI pipelines and watch and, and and maintain. And, but it's early days. I think these tools are still very early days.

You can't, I don't think you can, should rely on them a hundred percent. Um, but they're gonna, they're gonna definitely reduce the cognitive overhead that developers and operators and platform engineers have, and it's gonna make for better software down the line. It'll be so much.

If I was a enterprise SaaS platform like A-S-A-P-A Salesforce, uh, you name some large SaaS platform, I would be worried because now these enterprises are gonna have the ability to not only build or a replacement that does exactly what they want, but maintain it because they'll have agentic tools sitting in the, in the, in the sides making sure that these things stay patched, secure. Uh, someone wants a new feature that can write up a spec. I, I think that's coming.

I, I don't think we're far no one, I don't think anyone's safe from this. I, I think if I wanted, because everyone would love to have exactly the software that fits their need, everyone settles for an 80 to 90% solution because it's already built and probably costs less than if you were to go build it yourself. Even with the prices that like a ServiceNow and a Salesforce, et cetera charge on their subscriptions is still cheaper than going in and probably building right now.

Hmm. Do you do, do you believe that, uh, AI firms are gonna start, uh, putting lobbyists into place to ensure that, um, there are more onerous, uh, uh, ways of saying like, oh, you gotta be, have these check boxes. 0 this, you gotta be lurd per, you gotta, you have all these acronym soups, and is there gonna be an agent that keeps you closer to the acronym soup checkbox, you know, validation That, that exists today?

That, I mean, there are open source tools like cloud custodian that can, you can build those checkbox checkers that are real time event driven in your inco. Those are, those exist today. And I think you're gonna see more of that because more folks are gonna wanna say they are compliant and they're actively staying compliant.

Yeah, it's, it's interesting move from we're compliant at audit time to we are provably, continuously compliant uhhuh, we've gotta get there. That's absolutely vital. One of the other fun parts in this is, is, Jay, you were asking for less toil by the operations team.

I think both Jay and Coen would like to see that. Um, I was just on a call with, um, big Pando who have, uh, the, what we also saw at, at KubeCon a lot, which is an AI that sits on top of all of the observability data that you are getting out of your applications combined with all the inventory data that you've got from, uh, from your configuration management systems, and then, then also bring in all of the incident information, the tickets that are coming through ServiceNow and correlating all of that into some insights. I thought that was a, a really useful thing because, uh, particularly when there's high criticality incidents going on, getting rapidly to what the actual root causes rather than getting rat hole in some symptom, uh, could be incredibly beneficial.

And there's some really nice AI driven tools around making it easier to join the, an active incident or to identify possible resolutions. I thought there was some really good pieces in there, but we are straying away from our initial, uh, premise that was around how AI coding tools are either helping build better software or maybe not helping build better software. Kelvin, you've used a bunch of them.

Uh, your, your conclusion is that you, you like AI coding tools, but you still want a human involved. Uh, I, I, I think human guided right now is still the way, uh, I, at some point, these eight ag agentic coding tools are going to be building software that we as humans can't read. Like it's written in a certain way currently because we still are in the loop and reading the software and analyzing what's going on and trying to code review the tools will become as ubiquitous as, or as, as, uh, useful or, uh, generally, um, capable as like a compiler at some point where you trust its output because the compiler has been well tested and, and build software that you trust, or does it, uh, it's been posited that the, the GCC compiler many, many years ago in the first iteration could have been, could have been compromised with a, a backdoor we would never know.

And I, I think that's, that's an interesting element around at the moment, we want AI tools to write code that humans can maintain, but in the end that, that the end solution is not necessarily for humans to maintain that code. It's for the AI to build tools that builds code that the AI can maintain over time. And that we take that observability process of just treat it as a blank box.

And when I send that this input, does it do the thing I want it to do? Because fundamentally, we're just moving up the layers, right? We're not caring about the individual layout and code calls.

We're caring about the results that are being delivered. And that's where AI tools and, and AI coding pipeline tools, well, it's not even gonna, right. What does, what does code quality at that point?

Yeah, Uh, uh, uh, to go back to my entertainment example, like maybe we're just becoming just, you know, an audience, uh, for what's happening. Um, there will probably be, uh, situations regulatory or otherwise where even if you did ship quote unquote, you know, byte code binary only or whatever, there's still gonna have to be the human readable compilable, uh, the old fashioned way version of something. So we may have, we have, may have that burden where you're actually doing, like you're doing a, uh, dual source, uh, uh, or, or, or whatever the, the, the requirement would be so that if, if, if for, gosh, you know, sakes, this thing did go sideways and it starts eating, you know, the hand that feeds it, we need to cut over to the human inspectable.

Um, I think observability has always been, uh, this, this phrase getting, uh, constantly reinjected into the conversation. And so I, I do think there probably is something to be said for, you know, being able log with Lang Smith and throw a decorator on something and see how long it took. Um, but how many people have been doing that with application performance management and monitoring, you know, for, for o well over, you know, decade or so, and the original, like Mercury interactive stuff, going back to the older days of like just testing how you can hit or, or load test a web application.

Um, these are the same and similar patterns. But again, I go back to that same toil thing. When you, when you take the automated binary only machine, only talking to other machines when you have to put it to where the human can inspect it when something goes sideways.

I still think that observability part is, um, I'm, I'm still thinking like, how, how are we solving for the proliferation? Because Calvin, you've convinced me this is gonna happen. I'm just thinking like, what's the operational impact proliferation wise, if we, to your point, we don't have more of these agents to come help us along the way.

Yeah. Well you, you see that today in the enterprise. This is a, this is like something that plagues them anyway, is that the proliferation of tools, the stack of tools and places you have to go.

So we're gonna, I, I don't know if there'll be winners, but I think there'll be correlations. Actually, what could be interesting is if you see more of, because of data gravity, because you, the way, you know, you've got logs in one spot and your database is in another, you don't want to bring those things together because it takes too long to then get to a conclusion or a, a root cause analysis. You're gonna be having, uh, ad edge compute sitting next to your data in, in these cases that are very specialized and understand what it's looking at.

Yeah, I said the small language models people have been, uh, talking a little bit more about which is where this is the specialist, it, it, it, it can't tell you the capital of Kansas, but boy does it know a lot about this particular log file and sequence. Oh yeah. And they can run on very lightweight hardware.

I mean, raspberry pies, you know, running like, you know, 1 billion parameter models that are, you know, small and fast. Like speed is gonna be part of the, the feature, right? It's, I, I feel like speed is a feature of tooling.

Like when I'm programming in Python and we are now in a new world and we've got tools like UV to install and manage Python install and manage my dependencies, I use it mostly because it's so freaking fast. Um, and it makes my life as a developer so much easier. 'cause I, I, I'm, I'm not, you know, waiting, it kind of goes with my flow a lot easier.

And I think these tools, these generative AI tools need to be in that same speed realm, which is why the smaller ones are gonna come to the forefront. As usual, I opened a conversation that couldn't really fit in the space that was available for us. So thank you for joining us today at this Tech Field Day podcast.

But before we go, where can the audience, where can people connect with you and potentially carry this conversation on? Yeah, absolutely. com/i/calvin hp.

I typically post quite a few things there. com. I'm also on Blue Sky.

That's that new thing all the kids have been talking about. com and of course on LinkedIn, if you know there's only gonna be one of me with that last name, Of course you'll have to spell it correctly. And I seldom do.

Sorry, Jim. And of course I'm Alistair Cook. You can find me on LinkedIn as well as across various tech strong and tech field day sites.

Uh, just Google my name and avoid the cricketer. Uh, so thank you for listening to this episode of the Tech Field Day podcast. If you enjoyed this discussion, please subscribe on YouTube or your favorite podcast application so you can see far more of these discussions.

Consider us giving us a rating and a nice review so that other people get to consider it too. This podcast was brought to you by Tech Field Day, the home of IT experts from across the enterprise and a part of the Future Group for upcoming events, more episodes, head to tick field day com slash podcast. View us on text on tv.

And thanks for listening. We will see you next week.