Techstrong TV December 8, 2025

Hey, everyone, still feeling anxious about ai? I've got even more reasons for you too. You're watching Textron Gang.

Hey everyone, it's Alan Shimmel, and happy Monday to you. Uh, I am still, as I recorded this, you know, we record day before, so as of Friday, I am still in Las Vegas, nursing, uh, uh, AWS reinvent hangover. I guess, though I didn't drink anything.

I think several of us have that same, uh, uh, disease though, or symptoms. We'll, we'll talk about it maybe, but, um, welcome to our Monday Textron gang. Before we get shouted, I got a call out a big day for our Bard, Mike Ard and his lovely wife, Charlene.

It's their anniversary as we record this. So we're gonna wish Mike and Shar a very, very happy anniversary. See how red I can make his face on here?

Uh, happy anniversary to you, Mike. You're a lucky man. And as Mike said, when he was out here in Vegas with me this week, who would've thought he bet the under when, when they got married and, and, you know, he's lost his money, but he's gained a life partner.

Um, moving on though, we have Jack Poller with us, Kimberly Bates, Andy Mann, Mitch Ashley. This is like a majority Colorado board here. Um, oh my.

But welcome, welcome gang members. Mike, I appreciate you coming on on your anniversary. We've got some interesting stuff to talk about today.

We're gonna start off with yet more reasons to people who are worried or anxious about ai. Yeah, it's interesting how rapidly this, this whole thing is shifting because, um, early on it was all about, well, is AI gonna take my job and replace me? And that's a currently a concern.

But a survey suggests that people are also now diving in a little bit, getting, uh, the understanding of ai, maybe less odd by it, but certainly more concerned about losing control over it. And the fact that, uh, you know, they're trying to figure out, well, A, what am I allowed to do? But b um, they're starting to understand that some of this stuff can just kind of spiral without some sort of guardrails or controls in place.

And they're starting to ask some interesting questions about all this. So, Alan, we've been talking about this issue for a while now, but it's interesting, this, it seems to be taking on a different nuance. You know, it, it has been taking you on a different nuance, Mike.

But here, here's an interesting thing. This is, I, I, who is it? Z love's, uh, Maslow's hierarchy of needs and needs hierarchy, right?

So first, people are worried about their own wellbeing, right? Am I gonna lose my job? Am I gonna lose my livelihood?

Am I gonna lose my place in society as, as a result of this AI stuff, right? And I, I think we are still wrestling with that as a society, as as humans. But, but then the next thing starts, right?

And it's like, Hey, wait a second. Can we trust this thing? Um, you know, what, what's going to, what?

Is it trustworthy? Is it a security risk? Can I let it have, you know, intimate details?

It probably already knows intimate details about me. Unfortunately. Um, you know, well, what are we gonna do?

Who's regulating this? This thing's gonna run amuck. What happens if it decides to just get rid of us or something?

So there, there are these trusted safety issues. And you know, I, I think even that falls into two categories. There's what I call the irrational non-technical anxiety, which, and I've seen this with friends and relatives who are not in tech, who say, I'm not using that.

I'm not using that. I don't trust it. I'm shutting it down.

I don't, I'm not telling it anything about myself. I don't trust what it tells me. Everything's a fake.

And then there's the tech people who are maybe a little more enlightened only because they're exposed to it more. It's not that they're necessarily smarter, but they're exposed to it. And they, and these, these are the kinds of people, Mike, who were like signing the letter to at, to AWS about, Hey, we've gotta put some guardrails in here.

This thing, the security, you know, the security people are always on the megaphone blaring everything is No, no, no. But, um, you know, this, this is in my mind a little bit more rational, a little bit more developed nuance than just saying, oh, I'm gonna lose my job and we're gonna eliminate poverty money and everything else, and, and live, you know, on Vulcan somewhere or something. But, um, thi this, this is real.

This is real stuff. There is security issues. There are, uh, privacy issues.

There are trust issues that AI is gonna have to win over the minds and hearts of people. You know, Alan, I think it's even more fundamental. I think when we talk about AI is replacing me.

You're replacing my value. What's my intrinsic value? If AI can do everything I can do, then how do I make a living?

Then how do I feed my family, et cetera. And, and honestly, this is one of the things I don't like about our hype cycle, is we get the, uh, the tech giant industry pundits, you know, CEOs talking about how we're gonna replace all these jobs and, uh, yeah, we'll do something like universal income. We can't even figure out how to give people a tax credit or feed our folks, you know, let's talk about a universal income so people know that's bs.

So that overhyping just, just makes the anxiety even higher. I think we're in a, who is the Mel Brooks anxiety with that anxiety, High anxiety. I think we're in the spiral right now.

Yeah, We spoke about it last week. But, but Mitch, I, I think, again, back to the hierarchy of needs that is very personal to me. It, it threatens my very existence.

Now we're seeing a secondary and a tertiary anxiety of, wait a second, I don't even trust this thing. Right? I don't, I don't trust it.

There's security issues. You know, the, in my mind, that's a little, not that replacing my job is irrational, but this is a little bit more nuanced. It, it's not, I'm not just worried about my own personal wellbeing.

I'm, I'm worried, you know, about how's this, you know, what, what could, what bad could happen to everyone? Mm-hmm. Well, I'll echo echo, uh, Mitch a little bit.

That I think part of this is driven by the media in some extent. We have a, a media that lives off. Sure.

Blame the media guys. Why can't we blame the analyst? Absolutely.

He's gotta respond. So, y You, you Know, I knew that was coming, Right? Mm-hmm.

Okay. Yeah. The old expression, if it bleeds, it leads still applies to ai, is let's talk about all of the bad things that can come about it.

And then as Mitch says, when we talk about the good things, we talk about the good things in ways that are essentially bad, it's how is this going to change our lives? We don't talk about it changing our lives for the better. We talk about it changing our lives for the worse, right?

And who are, I think you're right, Alan, that there is a divide between those who are technically literate enough to understand what the AI and LLM world really is all about, and those who aren't. And in some extent, this is like where we were with the introduction of the machine age and the industrial revolution, right? Is it is a massive revolution in the way our society is working and will work in the future.

What the happens, we don't know. And that, you know, that unknown leads to a lot of anxiety, But this is healthy. This is healthy, this is like what should be happening.

Because as we've experimented with ai, and we've seen each of us have gone in there and said, well, that's baloney the information I'm getting back, or that's inaccurate. You know? And we were the early adopters of it, right?

I, I don't think myself as an early adopter, but certainly I was, and as compared to my family members, um, that I was with this last week at Thanksgiving. So, um, that's important. I mean, there, there was an article this week in Wall Street Journal about Waymo, and they've taken some of the guardrails off of Waymo, so it's now a little bit more aggressive.

And what they were noting, driving more like a taxi driver, and they had one that they were swerving in and out, um, two Waymo's were swerving in and out, and they also had cited one where, yeah, the Waymo always comes in up to a, you know, a four-way stop, and they acknowledge everybody else before they'll take the turn or take, take the stop sign. And, um, and she said that, no, that's not what happened this time. Um, now the goodness of that, another person in the article was quoted as saying, I will now take Waymo Marcella the taxi driver because it's more aggressive.

Okay? So, I mean, that's, that's a trust. So she wasn't taking Waymo because she wasn't trusting it to be whatever.

And yet now I'm saying, okay, so, you know, I haven't done Waymo, but you know, heck, so, you know, there's, I think there's, there's a good and bad in here, and that we should approach any kind of new technology with some skepticism. Um, and, and the report that you guys cited, the, I think it was Edelman, um, that's the primary purpose of their study, is to look at trust and look at, you know, trust. Whether or not I'm looking at voting or the ai, AI is the obvious one, but a whole lot of other things that they're looking at.

And oh, by the way, Mike, in that report, the media are the bottom of the barrel in terms of trust. So, sorry. You know, even when we had newspapers, we were still at the bottom of the barrel.

So we're used to being there. I don't even think analysts were on the list, but, but let me, let me follow up to what you said, cam, you know, it was, it's last week was Thanksgiving. Well, actually, now you're watching this, the week before was Thanksgiving.

And, um, it, it, and Thanksgiving is always a time to take the temperature of your friends and family, whether it's politics, technology or, or any other number of things. And, and Kimberly, I had a very similar thing to you, right? I found myself doing ai.

I call 'em AI parlor tricks with, with people showing them all the cool things. I, I showed them a saw I made of me as a Pittsburgh Steelers head coach. It was a big hit, big hit.

Um, but, but it, it, it, it, it kind of goes over a fact. Are we headed to a society, to a humanity point of thing where AI defines haves and haves nots. If you are AI enabled and you embrace it, are you gonna have a better life, live longer, work less, make more money, be happier?

I'm just throwing things out at you versus someone who says, I don't trust it, I don't use it and keep it away from me. And, and your life will be less rich, less, you know, diverse, less everything. I don't know.

I think it's gonna be released for the time being very similar to what we currently do, right? We all go to work, come home, have dinner, and you know, the conversation invariably turns to work and there's a bad day at work, and you basically start explaining to your family that, you know, you work with idiots and blah, blah, blah, blah, blah, blah. Well, that's just gonna change.

And say, you know, I had a bad day at work and I work with idiots except they're AI agents and they're idiots. But I had to go spend all my time fixing all this crap that they did. And it's just gonna be the same conversation with a slightly different inanimate object as being this source of, I, I disagree.

Let's take, let's take a couple of recent things. Let's take the cell phone and the internet. These, all, all of us are of nature.

Some of us younger than others perhaps, but we're all around the of the same generation. Think about your life before the internet. Think about your life before the cell phone, right?

I was showing someone pictures of me last night that someone had sent me from 1983, and they were like, wow, look at these pictures. Uh, you know, these are great. I said, keep in mind these weren't pictures taken on a phone that were digitized.

These were photos that someone actually recently took a, a snapshot of, or, or, you know, a digital, a phone grab of, right? An instamatic that was technology at the time. Absolutely.

With the flash cue. You remember our flashbulb blind for a second, but, but think about our lives before there was a, Hey, you go home and you turn on the tv, Mike, it's not Uncle Walter on there no more. Okay?

It's not, it's, it's, there's a hundred channels, a hundred million channels and nothing on, right? As the Bruce Springsteen song says. And so it has, technology has a profound impact on our day-to-day and, and how we do things.

I think AI is gonna have that kind of impact. Things that we just are gonna start taking for granted. Like, Hey, AI, go, you know, a digital butler, if you will.

It's a new way of doing things and doing the science. It's a new way of doing science. It's a new way of creating content.

It's a new way of customer service type of customer service of, of automating those things. And to my, I think whoever was making the comment, will we be happier, more content, whatever. And I, I would venture to say, not really.

Technology has not necessarily made us happier or more content or working less. It's just a change in how we do things. Look how it's brought us together, though, is one, one Nation, right?

And all of that good stuff. Of course, I I, I think it's gonna be, I think it's gonna be more of the same. And I'm gonna have a bunch of AI agents and they're gonna squabble with each other, and I'm gonna yell at them and say, don't make me pull this car over.

Well, no, you just, you're gonna say, pull the car over 'cause you're not driving. Am I gonna need to pull the keyboard over? Hold on.

Oh my gosh. Alright. Hey, but you know what?

Let me just tie a bow on this one. I hear you loud and clear. People who have anxiety around ai, whether it's at, whether it's at your inner core of like your imposter syndrome, run wild.

Because AI's gonna expose you for not really being who, who you claim to be and, and make, you know, doing the job that you're doing and being replaced to fears around trust and safety and, and what could this thing ha what could happen if this thing runs amuck? Um, we hear you. I, I don't think you're crazy.

I think it's something we all have to come to terms with and, and figure out and, but it's gonna be a personal thing, right? It, it's not gonna be a blanket thing. It's going to, it's going to go individual by individual coming to terms with how they're gonna have AI exist in their world.

Sound good? All right, let's take a break here on Textron Gang and come back. We'll talk about, uh, our next topic.

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 cloak, digital executive protection, defending the new attack surface your personal life.

Hey folks, we're back and we're gonna talk about ai, but we're gonna geek out a little bit about it because, well, there's conversations that says that we need a new approach to the data center in terms of how we're gonna build and support these applications and environments. And HP and a MD are calling for a more open rack scale AI infrastructure. And there are surveys out there that says that, um, it leaders, very few of them feel like their current infrastructure is up to the AI task.

So, Kimberly, as you look at all this stuff, do we need to kinda re-architect the data center, rethink this whole thing from the ground up? And is AI gonna just, you know, be in the 2026 year, the year of infrastructure? Well, I think it was Dell that coined the AI factory, um, terminology almost a year and a half ago.

And when they came out of their conference, and, and I didn't understand it initially, and then I dug into what they were talking about, and this was what they were saying is that this is so big that we are going to create the data center people, the people in the enterprise are gonna create another factory to manufacture, and I would say manufacture these tokens. They're gonna drive the AI initiatives within the systems. So you would have your regular enterprise environment that's doing the online transaction, and then to create this AI factory that is also able to do the work of the inference engine.

And I believe this is what this, this is exactly what HVE, this is not the first racks rack type scale offering that they've brought out. They've brought out the GreenLake, and as primarily the difference of this one is based upon open compute, um, project and the open rack, um, spec, one of the open rack specifications. Um, and then the other big news on there is because they're, you're partnering with a MD and then they're also using their latest, um, acquisition Juniper in this rack scale kind of ability.

Um, we've also saw that come out with a, um, AWS and I, Mitch and Alan, you can probably talk about it, which is they announced their AI factory, it's already shipped, Dell has shipped theirs, but they'll probably do some revamp, and we'll see that as it goes through the year as they update and improve. And we find out more information about what is needed on the platform. Um, and then, you know, what, a month ago I was sitting in a place called Oxide Compute, um, and they have rack scale devices.

It's not specifically for ai, but I would expect for them to be delivering those kind of environments. So yeah, this is where we're going. Um, and especially now that inference is starting to increase the amount that's being delivered.

Um, and, and the enterprises are getting their, in their hands wrapped around the data and, and to be able to deliver on these use cases. I'm, I'm gonna throw this down to the group 'cause, um, but I'm struggling with this in my mind. So if I use a service, whether it's Amazon or whatever, I wind up paying for tokens, and tokens are for input and output.

So every time I do something, there's a cost on the inside and out and that, and then the output, is that gonna drive more people to want to build stuff that runs in their own data centers so they don't have to have those kind of token based costs. And it'd just be something that I kinda run locally because it's gonna prove to be less expensive over time. I don't know, Jack, you want to throw a thought in on that?

Um, it's less about tokens and more about the volume of data. So the real issue is to get the benefit of L ai and LLMs in particular, you wanna throw as much data at it as possible, particularly if you were a corporate environment type of place, you wanted to have access to all of your corporate data, shipping that data into the cloud and putting it into a, an environment that AI can access it at the speed and scale it needs to, becomes very expensive. And then you have a latency of access issue.

So there is the feeling that right now organizations are gonna, and also the security of that data, moving all that data around. So organizations are really gonna want to keep all of that data in-house in their own environments and therefore need an infrastructure built to be able to access that data. And this is the startup, and I think I mentioned it, I don't think Kimberly was here, but Andy, you and I might have been on a a, a Textron gang a couple weeks ago where I talked about the fact that right now we don't have a well understood recipe for how does an organization, you know, if a, if a CIO says we're gonna do AI and we need to do an AI training and AI inference, how does an organization put that together?

If we said we need to do virtualization or we need to do containers, you go to a, uh, a DevOps person and they understand that and they have a recipe and they can go build that relatively quickly. We don't have that right now, which is why organizations like HP and Dell and, and AWS and all these different things are coming up with their own factory, which is a recipe that says you put all these components together on the hardware side and all these components together on the software side. And with that, you then have the infrastructure you need to do it.

Since there's no standardized infrastructure right now, everybody's coming up with their own flavor of it. Jack, I think that's an excellent point, but I think there's something more fundamental missing here. This is more like the moonshot NASA mission where we know that in order to, to, to do, you know, a hundred gigawatt or whatever, uh, data centers and racks that support 10 gig versus 10 meg, we need to invent technology.

We need to come up with tank or you know, or you think about some of the things that NASA came up with, the flux capacitor. No, we need a flux capacitor, right? We, we, right.

No, seriously, we, we need to come up with better ways of producing enough energy that won't destroy the plant. We need to come up with better ways of cooling down these racks so they don't, you know, without using 2 million gallons of water, we, we, we need, you know, it's one thing to say, you know what, I'm gonna come up with a recipe and I'm gonna go down to the supermarket and pick up these ingredients. It's another thing to say, I've gotta go invent these ingredients.

I've gotta go make these ingredients so that we can have a recipe. And so I think right now we're in a bit of a Cambrian era of people experimenting. Uh, and we'll figure out what innovations, what technologies, what inventions are gonna help us to, to build these factories.

And then at some, so that, that's the phase one. Phase two is, okay, now we have those things and I can write down my recipe versus Jack's recipe versus Andy's recipe and, and, and go with it, right? But we're, we're still in, you know, I, I'm from Long Island, right?

If you ever read the story about the lunar mount module, the lamb, right? They told Grumman, go build this. You got a year and a half.

They didn't know where to start. No one had ever built a lunar module that was gonna land in no gra you know, microgravity. And they didn't know if the damn thing would take back off after it landed like the, the, the capsule going back up.

And they had to kind of make it up as they went. They had to invent, they literally invented things to do this. That's where we are right now.

We're inventing this, you know, we're not quite up to a recipe yet. We still at the inventing it. Well, and that's what the, I think one of the benefits or one of the highlights of this announcement with HPE is, is that it is based upon open compute project and one of the open compute project for those who are not aware of what this is about.

Um, and it's usually held in September if you wanna attend the conference that they do. But it is, brings a lot of the hyperscalers together. I mean, who's involved with that is gonna be Google.

It's gonna be Facebook and a bunch of other folks that are dealing with this. So they're, they're upfront and center, maybe not exactly what the enterprise needs, but they're upfront and center about what's going on in the, in, in the, their, their area. And so that is how this is coming together.

Um, and I have oddly, I have a lot of, um, confidence in what they're delivering in terms of spec coming outta there because they're moving so fast. I mean, it's not a slow process for them to bring something out. Um, and more likely that it's going to be a solid kind of concept and offering that a vendor can take then and build their own rack for the benefit of the enterprise.

I think the whole nother Go ahead, rich. There's a whole nother layer to this, Alan, which is, you know, if, if AI is the, is the nail gun to the traditional hammer of traditional code, we don't need a nail gun for everything, right? And so, for example, there's a whole field of neuro symbolic fancy term, but basically a combination of generative ai, neuro kinds of processing along with traditional symbolic languages.

So you see people, you see companies announcing things like security guardrails, compliance agents, those aren't all AI based technologies. A lot of that is procedural logic that's added on top of results from, from AI may have some AI components to it as well, but it isn't necessarily throwing more AI at the problem. And, and when we seek higher levels of accuracy, a lot of that is symbolic language processing against ai.

The other part of it is, I met with a startup during, uh, reinvent that is, is creating technology that will take AI content or generated content or data that's used by AI and create more symbolic, um, processing against that. So taking the results from AI and now saying, now future executions of this, we'll do, we'll do a symbolic processing result or process against that. So we're not consuming tokens every time, which are extremely expensive, or we can collapse the amount of tokens that we need by optimizing the AI part of it.

So it's, it's not a, everything is gonna consume massive amounts of tokens. Yeah, we're gonna consume a lot more of them, but there's an economy of mixing these technologies together. So mi Mitch, that's an evolutionary step, right?

First you, you kind of invent a thing and then you put your efficiencies in. Mm-hmm. That's what you're talking about.

We've got more, More efficient. I, I I, I would disagree, uh, walking around AWS reinvent last week, everybody, and you could see it was becoming a major conversation. This whole notion of finops and applying it to ai because people are already at that point where this stuff is too expensive to run in production environments.

And, you know, that comes back to, you know, Andy, there's this word called observability. Are we gonna apply that to AI and finops or what? Absolutely.

I mean, you know, there's a whole bunch of things you need to observe within the AI infrastructure, within the architecture itself to make sure you're doing the right thing. And it's not just token use, right? That's a cost issue.

Finops is obviously very important, but it's also about quality. Am I using the right LLM? Am I, are my people using the right LLM?

You know, um, are they asking the right questions? Are they passing through PII through to a public LLM, you know, are they submitting my IP to Claude and now Claude's learning how I'm coding and now my competitors are learning how I'm coding as well. There's governance issues there, there's cost issues.

Absolutely. And, you know, there's actually, um, well ESG value here, right? I mean, Alan brought it up at the beginning of this block talking about the resources that we're using.

We are literally pillaging the landscape for this stuff, right? Uh, and it is normal. Uh, and, and Mitch, to your point, you know, talking about the idea of the, of these revolutions, this is something I wrote literally 20 years ago, is first comes the revolution, then comes the management.

So management tooling is absolutely gonna be part of this gold rush. Actually, let me back up. Management tooling is part of the general store that is servicing the Gold Rush.

You know, you've got hardware vendors like HPE and a MD, obviously Dell, as you said, ly Nvidia, you've got the cloud players, AWS we saw that last week at reinvent everywhere AWS doing ai, um, SP you know, the service providers like Equinix, IBM, um, but management tooling is absolutely gonna be the thing you're gonna have to provision and deprovision dynamically these resources use an incredible amount of money, cost, power, water, this sort of thing. But, and you know what? Mining was always a dirty business.

Uh, we still see the impact on the landscape of failed mines certainly here in Colorado. We remember the Gold King mine, uh, leaking out into the mighty Colorado River. All this toxic waste.

Um, we do need new inventions, Alan. We need new energy inventions. We need new efficient water and efficient cooling mechanisms.

Um, otherwise we are absolutely gonna go back to, you know, to torture the metaphor, the disgusting, dirty, toxic environment that was gold mining. We're just gonna apply that, I guess down to data mining, and I would love to see us do that a little bit better. Yeah, I mean, look, you know, you don't wanna invent LA last centuries Pittsburgh steel town, right?

That you, we, that's not what we're looking to do. However, here's, here's, lemme give you the good news. The good news is we are at taking this on in an open approach, it seems.

So rather than each con, each company, each player here, you know, in essence reinventing the wheel, starting from scratch on their own, saying, keeping it close to the vest, not sharing it. We we're in a collaborative way of doing this, taking a page from open source software even right? Where you, you got like Linux Foundation or Cloud Native Computing Foundation, right?

They're sponsoring these open things where it, that rising tide lifts all the boats and then people can innovate from on top of that, right? And so with this sort of open approach, it speeds innovation, it speeds standardization and, and, and standards and, and best practices, and then allows people to sort of solo on top of that, right? And, and, and exhibit their creativity.

I believe the phrase is necessity is the mother of invention, right? Yeah, Very true. Well, if, if, if I may part of the open thing here, and one of the big things that is in the announcement is the, the, and Kimberly alluded to this with Juniper being part of this, and a MD being part of this is the current sort of AI infrastructure stack is Nvidia based, which means that it's, um, uh, NVIDIA's networking protocol, uh, which is based on InfiniBand, whereas this will be ethernet and most likely ultra ethernet, which is an initiative brought up by J Mets.

And AMG is part of the, one of the founding members and running the, uh, ultra ethernet consortium to drive everybody towards the commodity of ethernet versus the, the proprietary fin band environment to be more open. So Jack, I noticed that they're using NVLink for me from Nvidia in there. Um, so, but I didn't catch what that was all about because I'm not a network specialist.

So if you Wanna, uh, they're probably more that the existing Nvidia GPUs are NVLink based, but there's a drive from AMD's, GPUs and the other, uh, and uh, I'm assuming, and I haven't looked into the Google and some of the other GPUs that are now becoming on the market, will probably more be more ethernet based rather than envy link. You know, I think it's, it, we have a habit of thinking we're gonna solve the problems that we have with the ways, the current methods of that we use for solving those problems. So, for example, I think fintech's gonna get reinvented.

We've gone through this, this evolution before with just take, take sql for example. You know, and when I started in databases, you wrote your sql, you ran it, the CPU went wild, or the disc disc activity was insane, you pulled it back, you figured out how to make it more efficient. Then we had DBAs who would work on that.

Those SQL statements try to make 'em more efficient. Then we built query optimizers that the, that the DBAs use to, to optimize those. Today, the system optimizes the queries themselves.

We don't, I mean, yes, we can do things to make it more efficient ourselves, but that happens automatically. I think FinTech is moving up up the cycle and will be automated as part of this when it comes to token and token consumption and prompt optimization, things like that. So it's, I think that will all be reinvented in a, in a different way rather than waiting for the bill to come out from AWS Google and Microsoft to say, damn, that's expensive.

Who, who did what this month that caused that to spike? Oh, I think we're gonna reinvent a lot of things, Mitch, um, you know, asset management to understand where we're putting all these workloads or configuration management to make sure we're not overusing, uh, various resources, uh, and specific resources like GPU instead of CPU. We've been doing CPU monitoring for the longest time, now it's all about GPU.

So now we've gotta figure out new ways of monitoring even, uh, let alone provisioning access management identity. Think about all the agents running it as ai, and now we've gotta have agent AI as part of our access management. What role is, uh, an AI agent gonna take in our role-based access controls?

You know, there's all sorts. We're gonna reinvent all sorts of management tooling, uh, to deal with this. This is always the way we do it.

Agreed, agreed. Hey guys, we gotta, we gotta pull the plug on this se uh, segment though. 'cause we, we, we have time for our third segment.

So great conversation though. We're gonna take a break here on Textron Gang. We'll come back.

Mike has more 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 in. If you watched the show last week, we were talking about how cumbersome multifactor authentication is, but Jack Poller has an article on Security Boulevard.

It's worth a deeper dive on it 'cause it suggests that maybe we are not as secure as we think we are with MFA, and maybe we're kind of leading everybody down a primroses path that might have a bad ending. But Jack explain. Well, let's start with, before we ever get to ai, we need to authenticate ourselves, right?

And we have to prove that we are who we say we are. So we started years ago with passwords, basically a shared secret that says, if you know the, say you have the same secret I do, you are who we say you are. And then we said, Hey, passwords are easy to steal.

We can convince people to give up their passwords very easily. And you store all those passwords in central database that can be stolen. So let's change that from something, you know, the shared secret to something, you know, and something you have or something you are.

And that would be multifactor authentication, MFA or two factor authentication. And we do that with trading. Uh, like you have a cell phone.

So we'll send you a message on your cell phone through a text message, SMS or we'll send you, uh, a me, uh, a number to your email. Uh, the problem is, in the way that technology works there is very easy to do what we call a man in the middle attack, where we can put a proxy in there to fake that you're typing in on a real login page when you're typing on somebody else's login page, an attacker's page instead. And so you give up to the attacker your shared secret or your two-factor authentication code, and then they can take your information and log in as you and get your access tokens to whatever you're logging into.

And then once they have that, they have your access and can do whatever they want. All of that is technically complex, but doable. Unfortunately, now we have a group called Tycoon, which has built this entire infrastructure to do all of that as a service.

So now the criminals are running software as a service just like the good guys are and the bad guy. Software as a service says, Hey, you want to go set up a page, pay us some money. And we'll, we have all the infrastructure that makes it look like, you know, your login to Twitter, and it's not your login to Twitter, but somebody gets access to it, but, or your login to Bank of America.

We can duplicate that for you. Pay us some money, we'll do that. And then you get access to whoever you phish to get into that account.

Um, it's now so easy. It's basically your password based authentication or shared secret authentication is at this point relatively meaningless. Uh, so what are the alternatives?

The alternatives? They're sort of two good alternatives. One is something called pass keys that comes up with the Fido, uh, organization created something called pass keys, which doesn't use shared secrets, but uses, um, public key cryptography.

And it is a much more secure way to do that. And the good news is, last week, Microsoft integrated passkey into the Microsoft's, uh, login process. So now when a website offers you a passkey, you can store it with Microsoft or use your favorite password manager, like one password or any of the other password managers to store your passkey.

And it's a much more secure way to do it. The other way to do it is to use biometrics. Now, I wanna put a caveat out here that there are two types of biometrics.

There are biometrics that are stored only on the secure, uh, device in your computer or on your, like your iPhone or your Android phone where the capture of your thumbprint or your face never leaves the hardware chi, right? So there's no way for a bad guy to extract that and use that recording of your biometrics. There are some biometrics where your data is stored in the cloud.

If it's stored in the cloud, it can be stolen and you don't wanna use those. But anything where it stores it on your local computer is good. And then we have technology from a company called Badge and a couple of others, which never stores your biometrics at all.

They've developed technology that can recreate a private key and public key pair from your biometrics at any time. So you can do phyto keys and other things without ever storing your biometrics, but still use biometrics to prove you are who you say you are. So the good news, the bad news is it's now really easy to defeat password based authentication.

And to fa the good news is we have other alternatives. We just have to get people to use them. Can I ask a question about it?

Um, are the alternatives more expensive? Because it seems like, you know, that always winds up being a hurdle. Every time we have a chat about MFA, They should not be more expensive.

That doesn't mean they aren't, but they should not be on the technology side. It requires the website developer, application developers to integrate the new technology, which imposes a cost on them. Um, but all of these things have common libraries.

There are no JS libraries and other libraries to make it easy for people to do this. And the identity and access providers, as far as I know, are not charging extra to implement Fido because they want to encourage and they're actively encouraging security and secure features and functionality, and they want to help you build an environment where your users aren't compromised. So Jack a question on this, because I read through and the first thing that popped in my mind was whether or not what the barriers to adoption were.

Because, you know, change is difficult. We, we don't like to change. And, um, on one of them I'm thinking that you got a fob that you care, you use, um, for that.

And people didn't particularly like that, even though it was very v very secure. Um, so that never really quite took off. Um, and the biometric elements, you know, there's innate fear about it, if you will, um, on that.

And that's, I believe, you know, I, I'm a little skeptical about it, but anyway, there's innate fear and it's changed. So what are you, what are you thinking about can be done to help adoption or, you know, am I right in terms of concern about this adoption and process of getting there? I think you're right in concerns of adoption, it took a very long time to convince people to use MFA.

And in fact, the last time I did a, a research study on this in the 20 23, 20 24 timeframe, uh, just two years ago, uh, more than half of organizations still didn't make MFA mandatory. Even though we understand the benefits at that time of NFA and implementing MFA today, while it's not, um, it is a much better situation than passwords only, it introduces friction into the login. It means there's another step to do.

The good thing about Fido Pass keys is it is actually, once you've set up the pass key, it becomes invisible to you. You enter your username on the website and it says, oh, you have a pass key. It goes retrieves the pass key.

It does all of that in the background. And you don't have to do anything other than say, yes, I want you to let you use this basket to get to this site, but it is a change in the way we behave in a login. And so that is part of the adoption friction.

And I think the good news here is that the consumer websites and Microsoft are driving this because they face significant financial risk from stolen accounts. And so they're really interested in driving this. I've got a few thoughts on this, right?

And, and I've been a proponent of MFA for a long time, right? I think we all know that the, our basic password, you know, trust system is broken and, and we need to get away from passwords there ist there still is tremendous pushback on MFA. I know even here at our own organization we instituted MFAA couple months ago, and the, and the the IT guy on our team who works with Mitch and I gripes still that he can't get people to, to sign on and do it, right?

Because people don't want MFA. However, even this MFA Jack, which you're saying is, you know, now becoming a little longer in the tooth and not quite as secure instituting MFA, I've seen studies where it will reduce security incidents by 75 to 90%. Imagine that if I told you I could reduce your security incident, 75 to 90%, why wouldn't you do that?

Why would, well, I'll tell you why. You mentioned pass keys. I consider myself a bit of a power user.

I'll admit it, right? My name's Alan. I go to a website these days and it said, would you like to use your pass key?

Of course, I'd like to use my pass key. I'm a security dude, boom. I want to use my pass key.

Which pass key would you like? Would you like your one password pa pass key? Would you like your Apple Pass key?

Would you like your Microsoft? Would you like to scan this QR code? And, and I, and it was vexing me.

I don't know which one should I use, but I I, I use 'em all and see which one works best. And you know what? They all, they, you know what they all do.

Really? All those ones I just mentioned to you, they're all looking at my face or doing my fingerprint thing or you know, and, and, and letting me in there. Does it give us a better security?

Absolutely. Is it next generation MFA, I don't know, you know, passkey versus MFA, it, they seem pretty similar in some regards to what goes on behind the scenes is different. But clearly, I, I think our number one scourge is just the majority of people who still use plain old passwords don't even use password managers, right?

You can't tell me in today's day and age, if you're a user online, that you shouldn't have 25 different passwords, 30 different passwords for various sites and eight and services you access. And if you're not using a password manager, let alone MFA for them, shame on you. You're, you're just, you're the zebra in the herd waiting for the day where a lion picks on you.

So I'll, I'll take the other side of that conversation for a minute. So you, we have had ATM cards for decades. You go to the bank, you're putting your card and you typically type in a, you know, four numbers and, and, and you get access.

I, you know, I'm not hearing about people getting hacked by their bank accounts because they have four. Oh no, Mike, I gotta call bs. You know why you don't hear about it?

Because we've taken the pain away from you. It happens all the time. But the bank bears the cost.

Yes, it happens all the time. The bank bears the cost. There are people cloning ATM cards.

There are people stealing your pen. Go look up skimmers, credit card skimmers, all of those things. And, and, and, and yet I have not gotten an email from my bank in a decade saying I need to change my pin numbers.

And yet I will get an Email From some website saying, I gotta change my password. 'cause you every other day, because you, you keep your debit card underneath your socks, inside your sneakers and you never use them. Oh, you kidding?

Underneath the mattress. Right next to a sock drawer. The rest of us, I've gotten, I get new debit cards all the time.

They say, we suspect we saw suspicious activity. Here's a new card. Mike hasn't even opened up his plate.

He never from the bank. He never called the 800 number to activate it. Even I'll, I'll concede.

There are a couple of cards in my wallet that would classify as that Uhhuh. Mm-hmm. But, but seriously, because, and but there's a lesson there because it doesn't cost you anything.

It's just a minor pain in the butt. Ah, someone got my passcode, someone got my debit card thing. I had to get a new debit card, I had to activate a different card.

But it doesn't cost you in your wallet when it costs you in your wallet. All of a sudden stuff gets real. It's when you call the bank.

Yeah. And there is a lesson there, Alan, that's absolutely correct. And I think part of the lesson, I mean two things which we haven't already talked about.

One is that we need to place less of a burden on the end user for their own security, right? I mean, let's think about this logically. Most people can't handle risk.

They don't get it. They don't understand it. You know, people writing their passwords down on, on post-it notes and sticking them on under their keyboard.

We've all seen this, right? Humans are awful at managing risk. And part of what you're talking about there with the ATM card, the bank is making it easy for you to manage your risk.

They're doing the fraud detection, they're sending you a card proactively, you are not doing analytics on your spend. They are. And they're making it easy for you to deal with the risk.

And then the fact Is, Andy, you don't have any risk. 'cause if anything happens, they eat it anyway. Also.

True. Exactly. And the other part of this, by the way, is, um, and, and you know, Jack, this is amazing.

This is one of the reasons I come on tech, on tv 'cause I can learn stuff. I feel like Keanu in the Matrix now. I'm like, whoa, I understand identity.

Um, but m FFA is absolutely broken. But one thing you didn't say in your article was, how about we don't have a user ID and password for every damn transaction? Look, when I go to the hardware store, I I buy a new toilet.

I, that's it. I'm not gonna get another one tomorrow and then another one the next day. I don't need persistence in my identity.

You've had that transaction And you've never had me. I install your toilet. I was gonna say we haven broken a toilet heard identity compared to a toilet, but thank you for that analogy.

Not with standing the rash. And I use the word advisedly of connected toilets that are all of a sudden, uh, communicating with the cloud, doing analytics on my business as it were. Uh, maybe that's for another day.

But the idea that we need a user ID and pastor for every transaction, I think is a big problem as well. I know it's about data collection, right? It's about personalization, it's about, you know, data mining.

I get why people do it, but that's one of my bug bears. Look, I don't mind using a token. I don't mind using your MFA, uh, using my windows hello or YubiKey or whatever it is, if it's gonna help me.

But, uh, if there's just no reason why we need so many user IDs and logs in logins for every transaction, no wonder people repeat passwords and get hacked because they get exposed. Well, I, you know, I don't, I I don't wanna, you know, I could take four hours talking about this stuff, right? And, and there's the, you know, you go down one path and it opens a whole bunch of others.

But let's just say to Mike, one of the goals of IPAs, keys and badge and the other types of technologies is to eliminate that database of passwords, user IDs and passwords that then gets compromised that forces you to get a new password or a new card or whatever. It's getting rid of the shared secrets is how do we do this technology in such a way and then make it usable for, as, as Andy was talking about, the user interface part of it and removing the friction is part of that. There is a learning curve here that it's something different than a password, which is why it's named, it was called something else else, but they called it now a pass key to put the pass in so that people would associate it with passwords.

But it is a little bit different and you know, it's, there's, there's, so it is gonna take time. It's a learning curve. And you know, we still have, we still have organizations that say, you know, your mass, your max length of your password is a, is eight characters, right?

I mean, that's just insane. There's, there's absolutely no reason that your password should be space limited at all. We have infinite amount of storage.

Why are we limiting? Like, but you know, I've gotta Four hours, Hour password somewhere. But, but let me look.

I feel, I feel like we left something outta this conversation. We didn't discuss ai. Well, I, How, how does ai, how does AI figure into this?

And, and because let me, let me tell you why. I think the, the identity problems that AI may cause, could cause are gonna make this stuff look like child's play. Well, each of those AI agents has an identity, so it's gonna get crazy.

And, and how do I know Mr. Smith from Zion, right? Isn't now looking like Mitchell right back to the red, blue, red pill, blue pill scenario.

Mr. Anderson. Well let me, let me just put one caveat out there.

This is why we do not use voice authentication. Yeah. Anybody who offers you voice authentication refuse it, Right?

I mean, And there's a lot of technical reasons why I'm giving that advice, but let's not die there. Let's just say voice authentication is very easy to compromise And, and, and a world of AI cloning. You bet.

Um, so I gotta, I gotta, I gotta go stuff some more money under the mattress. But this was interesting. You might find an old debit card there.

Anyway, few tokens, guys. We're outta time. What a great discussion today though.

Great panel. You know, it's good having those Colorado people and they're nice people. Uh, Mike, happy anniversary.

Thank you all for watching. It's, uh, Monday, we'll be back tomorrow with more Techron Gang. A lot of our EWS reinvent coverage will be re streaming over the course of this week.

So stay tuned for that. On, on, uh, Textron tv, we're also putting a lot more of these and a lot of the events we cover up on our OTT app. 'cause we realized it wasn't up there though.

It was available on YouTube and our Text Drunk TV website. Um, so check out the OTT app on, on, uh, iOS, uh, Google or, or Amazon Fire, Roku, apple TV and check out my new podcast Agents of Dev. Yeah, the really, with a really snazzy opening that the, the text drug TV video whizzes came up with.

They killed it. Yep. All right.

Hey Mitch, thanks for the plug on that. Have a great day everyone. We'll be back tomorrow with more.

Hey everyone, welcome back here to Tech Trunk tv. You know, I'm thrilled to have my next guest here on with us. I've actually known her for probably longer than she wants to admit that she knows me.

Um, 'cause she, you know, she's pretty a young woman herself. But let me introduce you to Priya Doty. Priya is the Vice President of Solutions Marketing for B-M-C-A-M-I at BMC Software.

Priya, welcome to Tech Drunk tv. It's great to have you on. Thanks Alan, and great to see you again on a, a lovely Friday afternoon.

So good to, yes, Yes. Well remember by the time people see this, it may not be Friday, but Yeah, But it, we did record this on Friday. That's right.

So Prita, you know, of course we're LinkedIn followers, friends, connections, whatever. It's yes, I've seen you, I've seen you getting out there a little bit on the road doing a bunch of things. Give people, you know, and I, you know, it goes arm in arm with your, with, I guess it is conference season, number one.

Number two, your role is VP of Solutions Marketing. I would have you do that, but give people a sense, Priya, of, of your journey, not just in the last couple weeks, but how, how you came to be, uh, here at BMC in this role. Yeah, well, I, you know what, it all goes back to DevOps, Alan.

So, um, I actually started my career as a developer, um, working alongside ass four hundreds and then JavaScript and other things like that. And, uh, at some point I, I morphed from being a developer to a product requirements writer and from that to product strategy and then solutions marketing. So it was this like the step journey.

But I remember first meeting you when I started doing a lot with the DevOps community. And I remember finding you on LinkedIn and saying, wow, this guy's really active. I need to know him.

Um, so yeah, I mean, uh, my journey really did start in the development world, uh, today. I, like you mentioned, I'm VP Solutions marketing for BMC Amy A MI. But just taking a step back, you know, in terms of what we focus on at BMC and then diving into, uh, what I do, BMC software, I mean, many of you have probably heard of it your, your listeners have.

And, uh, it's evolved over the years. So the company today really focuses on helping customers to automate and, uh, bring to market orchestrate, whether it's data application systems, all the way from the core mainframe all the way out to the cloud. And that is really the core of what we are, we're an automation company.

Um, the piece that, uh, I cover is BMC, Amy and AMY stands for Automated Mainframe Intelligence. So the, it's kind of the best known secret in the industry that BMC supports the full stack of a mainframe software environment. And as you know, there's lots of companies out there that have mainframes running the IBMZ platform for various reasons.

And I guess, you know, what we're, what we're on a journey on at BMC is helping customers understand, um, that it's, it's optimization and transformation, but at the end of the day, it's an AI driven optimization and transformation, if that makes sense. So that, that's the journey we're on. And, uh, it's, it's been a good journey.

I've been at BMC two years and, you know, have launched the AMY assistant product, which is our agentic AI gen AI framework. And it's, it's just been a lot of fun. Absolutely.

You know, you, so I, as I mentioned before we got on camera, I just came back from CubeCon, myself, cloud native con, I forgot what one I was at before that. And now of course I'll be at reinvent. And you know, you can't walk two feet in the tech world without tripping over AI here.

Right? I mean, it is. Yeah.

It is everywhere and anywhere all at once. Yes. And, uh, and, but rightfully so, right?

It is, well, it has the promise of, of changing everything, of, of disruption in so many places. And it's funny, there might be people out here and say, it could disrupt the cloud, it could disrupt that, but nothing disrupts the mainframe. Right?

Those mainframes, they're like cockroaches. They'll be here after the nuclear holocaust. Those mainframes will still be running, you know?

Oh my Goodness. We're battle tested. Right?

They're, they're designed for anything Absolutely hardened to hardened, hardened as hard it is. Right? Um, but yet even the venerable mi mainframe in the mainframe market Yeah.

Is being not severely, that's not the right word, but greatly impacted by Gen AI and agent ai and, and, and what this can do. And, and it's on everyone's, it's, it's top of mind for everyone. Um, I know recently you guys did a, uh, 2025 mainframe survey about, and one of the issues, or one of the topics covered was trusting ai.

Yeah. And, and this is, this is a, this is a double-edged sword. Talk to me a little bit about that.

Well, the, the thing that was, I guess, really surprising is, you know, you, you think about how much will somebody allow or be interested in an AI doing in your environment? And so we think of it as a spectrum of trust. And we asked a number of questions around, you know, what kinds of things might you wanna do with ai?

And what was surprising is how many people were open to so many things working in that, in that environment. And I think I'm also seeing it in the client base, you know, outside of the survey a year ago, it was, Hey, we're, we're dipping our toes. We're interested, we're testing.

And this year they're coming back and it's, Hey, I gotta have a POC, I gotta set this up. I gotta do it. So they've, they've made a rapid progression.

Um, and listen, they all know that nothing is gonna be perfect, right? They're not gonna have a hundred percent accuracy, but they're willing to give it the benefit of the doubt. And I think that a lot of that has to do with the fact that they've been socialized around it with the tools.

They're, we're all using, you know, every day. And we start to see 'em, and we think, how can I do that at work and do it simpler and easier? I agree with you.

I think there's a couple things there. First of all, I think there's good old fashioned fomo, right? People who fear of missing out.

Everyone else is using it, and they're not. I think secondly is, is quite frankly, we've, I don't, I've never seen anything in 30 plus years in tech have this kind of on ramp, right? I know.

And, and here's something I think that's heartening. Your numbers and what you see in your mainframe survey are not very different with the same sort of outcome that we're seeing in other surveys. So, for instance, I recently saw a survey of all developers, not just mainframe.

Yeah. 90%, nine 0% are using AI one way or another. Yeah.

Which, which is probably in line similar to what you're seeing there playing, but here's the kicker, 40% don't trust it. 65, and they're still using it. 65% think it introduces instability and still 90% use it.

It's the same thing you're seeing. Yeah. We, it may not work yet, but we're still gonna use it.

Try. Well, and, and I think what, to, to your point, I think part of it too is we're seeing a lot more of how do I explain what's here? How do I analyze the application?

How do I understand what the root cause is? So it's almost like, help me as advise me what's going on. And then the next step is gonna be sort of more of the automation of repetitive tasks.

And to be clear, I mean, there's a lot of automation already in every software platform, so this is just taking it to the next step. Um, but yeah, it's agreed, it's fascinating. I think the other little knit on the survey was there's a lot of younger generation in the mainframe community that's coming in, and they're much more open to the technology, and they don't have the same perceptions about mainframe that the, that the next generation did.

So their perception is it's a blank slate. Hey, I have this thing, why can't I use AI here? So they don't see the same barriers that maybe earlier, you know, people who worked on it earlier.

See, Uh, I, you're right. I do think, you know, people have preconceived notions. I I do think maybe a lot of people who have been in the industry a while look to say that they're worried about their jobs with AI is, is an understatement, right?

Yeah. I think a lot of people are worried about what does it mean for their career and future. Um, nevertheless though, you know, the trains left the station.

We're all playing with it. We're all using it. And so it really, I think, becomes a question of how do we get comfortable.

Mm-hmm. How do we learn, how does AI earn our trust? Yeah.

How do we learn to trust it as, and not as a replacement, right? But as a partner, as a, yeah. As a 10 Xer, if you will, as they call it.

And, you know, specifically when we talk mainframes, Bria, how, how is that kind of playing out? Well, I mean, there's, there's multiple ways to answer that question, right? I mean, some of it is our, our product roadmap and how we're strategizing around building out the roadmap for the product.

But I won't bore you with all the gory details. Um, I think that what we're seeing is, you know, around leveraging it for particularly around development and then operations, right? And what we're seeing is it's, it's a step function.

So you start with the explain capabilities. You start with like, explain my code, help me understand it. Uh, then the next phase is, all right, let me help, help me selectively refactor, right?

Let me help look at selectively, pull out snippets of code, look for dead code, identify places that I might want to refactor, and let's go do that bit by bit. But we're not trying to do, um, you know, mass transpiration of code, right? It's, think about the ABCs.

It's, uh, you know, thinking about first understanding, analyze what you've got, think about the business logic, and then go do the conversion, right? Um, so that, that on the dev side, that's one place. On the ops side, you know, it's, it's really tapping into the AI ops journey that many customers are already on, but just taking it to the next step.

Okay, so now how do we get from, uh, doing AI ops, using dashboards, pulling all of our monitors into one place, looking at AI ml, but then taking that to the next step to get to how can I get better intelligence on what my root cause might be so that I'm, I'm not just, you know, stabbing around in the dark, but I can really understand what it's, and that that's what's here today. Um, I think customers are very interested in what they call self-healing systems. And that's the other piece that we're looking at a lot right now.

Absolutely. You know, I, I think one of the, uh, one of the places where the mainframe, you know, I look kudos to IBM and the, the new Z version and all this stuff, and yeah, they've, and the whole mainframe software world, right? Not just IBM, but BMC obviously is one of the bigger, it's a small world when you look at the mainframe software providers.

Yes. Right? There's only four or five major ones done an amazing job of on modernization, right.

Today's mainframes run anything you want, basically. Right. They're really great.

I don't know if managing the mainframe has kept up with that though, and I'm wondering if that's not an area where AI can, can really make a dent, you know, and help us out. I think so, and I mean, I think that's what we're seeing is that, you know, what the customers are saying is, first of all, they don't see, the platform is not modern. They see it as a modern platform because of all the, you know, it's got, you can run GPU accelerators in there, you can run AI inferencing in there.

I mean, there's lots of things you can do with it. Um, but when it comes to optimization and transformation, that's how I like to think of it. Because most of our clients at BMC, they're looking at how can I optimize and transform this environment, just like you said.

And we think of it as sort of five key, uh, we call them patterns, right? You think about, um, re-imagining your dev workflows, you know, how can you make it better for the, for the developer, refresh it, leverage ai, uh, re-energize the operations teams. So again, leveraging ai, doing more, refactoring some of your code, um, recalibrating your resources, quite frankly, you might wanna, you know, just re think about again, how are you doing data management?

Should you be moving some of that data into a hybrid cloud environment? Um, and then last, and not, but not least, a security, you've gotta continually recertify your solutions to make sure that they can hit the compliance goals you have, um, hit the security goals you have. And I think one of the biggest fallacies in the mainframe space, people have no idea how bad the insider threat vectors have gotten.

Like, truly no clue how bad and how much they're exposed if they just assume that the hardware alone is gonna save them. Right? So, um, that, that's kind of how we think of it.

It's just, you know, it's, it's that mindset of how can I help you optimize and transform? And it's not about like, doing everything at once. I mean, a lot of our clients, they get stuck in the compliance loop, and they have to spend a lot of time on that every day.

Um, and others are spending more time dealing with, you know, resiliency or, uh, you know, getting faster to faster to market and innovating faster. Absolutely. Um, Bria, you know, you mentioned the security thing too.

And, and you know what, it, it's something I've spoken about before that I want to just mention on here, is in many ways, the mainframe being as secure as it was at the, at the, at the machine level, at the, you know, platform level was its own worst enemy because it gave people this maybe false sense or heightened sense of security and allowed them maybe to take their eye off the ball or not focus on the security of the software. Don't worry about it. That mainframe is rock solid.

Right? Right. Most secure platform out there.

We don't have to worry, am I using an old package? Have I updated my packages? Have I, you know?

Yeah. And, and that, that's something that bears repeating the people. Just because it's a mainframe doesn't mean security is on, on autopilot.

You Absolutely. And every customer group will go in and we'll ask them what their priorities are, and they'll, and security is not at the top. And then they'll hear, you know, oh man, these are the types of insider threats that could happen.

These are the kinds of ransomware situations that could happen. And invariably they leave and the first thing on their mind is security. And so, absolutely.

I just, well, no, because it's a victim of its own success, right? Yeah. We've all heard that it's the most secure platform out there, dollar for dollar.

And, and so, you know, you get or The credentials secure, right? That's the challenge. Well, Well, exactly.

Because that's the way in. People don't break in the, the bad guys don't break in anymore. They log in.

Right. Brilliant. Brilliantly said, Alan.

Yeah. Yep. And that's, that's the truth.

I wanna talk about another big thing in, in the mainframe world. And that is, you know, back during COVID, right? We all heard the horror stories.

I can't get your unemployment checks out. 'cause that program was written in cobol. Oh, yes.

And we don't have cobol uh, uh, programmers. And thank god, India still has a ton of people there. Training in COBOL will outsource it.

But the fact of the matter is, I think one of the biggest movements in the mainframe world is a COBAL to Java conversion. 'cause hey, we'd run, it runs Java. Great.

Yeah. Is that pr, is that real? What, what's going on on that end of the, of the mainframe market?

Um, I think there's a lot of different solutions out there. And, you know, some of them are more proven, but most of them are still very nascent. Um, I think that customers are definitely, you know, they, they've, many of them have said for some time now they're looking at where should an application be run?

What workloads belong on what platform? And that's been going on for a long time. So what I'm seeing is the desire is to convert, but do it in a smart way.

Right? Um, and by the way, not everybody wants to go fully to Java. Um, that requires more maintainability.

It, you know, requires, it's not as backward compatible. It may not have the same level of performance. Um, so it's not a, it's not a prescribed, It also gets you on the hamster wheel.

Right now I'm on Java, I gotta upgrade every time Java does. That's it, right? And all of those things where you could run cobalt code from 20 years ago, and it probably runs good now as it did then.

Exactly. But at the same time, I think there's clients that are saying, well, if I'm writing in Java, that gives me a lot more strategic flexibility because I can get more programmers. It's easier to find, right?

So it's, it's really, for us, what we're trying to do is first of all, support Java across the platform. So that means, you know, in the dev environment, in the ops environment, and we've been on that journey for a while. And then what we've just announced in October is cobalt to Java, you know, sort of refactoring support.

But again, for BMC, it's how do we help you with that A, B, C, you know, how do we help you analyze, look at the business logic, and then selectively convert. We're not gonna, we're not gonna be your partner to come and like just do the, you know, translation of the code. Um, and I don't think that's what we recommend people do.

So, Gotcha. Um, how could our friend AI help us with this? I mean, that's what AI does, is the coval to Java conversion.

It's, you know, AI starts with helping you understand the code. It can document the code literally at the click of a button. You know, think about something that might have taken weeks before, and then it, when, when it comes to the conversion, it's, you know, a step by step every step of the way, uh, AI is there to help you convert the code.

So it's, it's pretty awesome, Alan, to see those gen ai, um, I guess they're not algorithms, but just the, you know, the LMS and how they function and how they're having such an amazing impact, um, one Thing. And day by day, I mean, day by day, day by day, it gets better. And the, the cool thing with BMC is we're embedding these functionalities into the existing suite.

So if you already have the BMC Amy Dev X product, I mean, it's just, it becomes part of the suite as you upgrade and, you know, continue on your versions. Well, I, I think it goes back to what we spoke about before. This is why we're seeing the pickup.

We are, this is why we're seeing the, the usage even in spite of trust and everything else. That's right. It's there.

Use it. You Know, uh, another place where it excels is, is, uh, upskilling even helping people upskill themselves. Yeah.

Right? So it's sort of like knowledge expert chat, right? Yeah.

Yeah. They wanna learn how to do something. And it's funny, I so personally, I've been forcing people to do this.

Now when they ask me to do some, or they ask how to do something, or they ask how they should go about doing something, what they used to Google for, I said, don't Google it, ask ai. It'll, it'll show you better. Yeah.

And it really is when you go side by side. Now, there are people, and I've written an article on this that say, ai, ai rots your brain a little, because it almost makes it too easy. Mm-hmm.

At least with Google, you had to go through the search results and click on things and, and pick out, you know, the nuggets and pearls that you needed, where with ai, man, it just delivers it for you. And, but when time is money and money is time, and there's a crunch on you like that too, I mean, that's a preferred method, I think. Yeah, for sure.

I mean, and listen, Google isn't perfect either. Google isn't perfectly accurate, accurate either. You know, you And getting worse every day.

I might, right? Yeah. Yeah.

But that's another story. Um, but yeah, I mean, I think what we're finding with the upskilling piece is we launched, uh, a knowledge expert within a e assistant, and it's just, you know, a standard chat functionality, but it's from within the product, right? And that means that if you're a newbie, you can ask it questions, but also if you're an experienced person or you're just trying to remember something that happened before, you need to go look it up, uh, or you're in mid-career, it can help like any level of skill to get better and faster and, and ultimately help to onboard people faster, which is key.

And then I just go back to, I was, uh, so I know you're, um, an ex New Yorker, like me, I'm a New Yorker, and I was on the subway the other day. You just don't have the accent anymore. I do, but Oh, yeah.

We'll talk about it another time. Go ahead. But, um, but I was on the subway and I saw this ad and it said, why would you use the same GPT that you use to order pizza to pick stocks?

I think good, right? Yeah. That makes you think, That, makes you think, right?

So I think it's the same with the vision we have for the knowledge expert. It's, you know, why would you use the chat GPT generic function that's not necessarily domain trained or context aware to, to talk about, to ask questions about your specific mainframe environment, you know? Yeah, absolutely.

You Could. But should you No, you could, and you might get good responses some of the time, right. But I, I think that is the next phase of this, where we move off these frontier models that are, you know, this wide and, and have the whole sum of knowledge of mankind or something in there.

Right. They scrape the entire internet. That's right.

And there's a question of how much more could they scrape? They scraped all the data already, right? Two more of let's call 'em SLMs.

Yes. Or more, you know, specific Right. And contained also so that they can't be poisoned, you know, by general kind of stuff.

Yeah. And they're much more domain specific. I, I think we're going to see more and more of that, that's going to become the norm, right.

Than than a a, a, a one size fits all. That's right. And, uh, LLM And, and listen, BMC is curating the best of, you know, we'll look at any specific situation, we'll curate the right LLM for that problem, and then we'll help the customer to train it with their own data.

That's the goal. Right. And that is, quite frankly, what I've been doing here, even with our own, we use, I wrote an article on this last week about the future of journalism and media and ai.

Oh, Cool. Yeah. You know?

Yeah. We, we use it here, and, and I've trained, I trained it on my style, on my voice, on what I wanna, you know, to be like, and it, it absolutely works. And it, it, it's in there.

But here's the other thing though. We're seeing this, like, for developers, it's inside the IDE. Yes.

Right? So literally, as they're coding, the AI is correcting, suggesting helping. It's almost like an alter ego, if you will, that embedded contextual expertise, if we can call it that, is really, I think, the future, not just for software development, but for software operations management, and probably in a lot of things outside of tech too.

Yeah. But, you know, once we get to that point where it's not this frontier model of everything anywhere at once, but very specific and very deep, and you put it, you build it in, like it's being built into IDs today, I, I really think you're gonna see a huge productivity kind of jump from that. And that's what even we're seeing internally.

I mean, we're using our own IDE for some of our assembler developers and just for code explain. And they're seeing productivity increases, um, on the order of 20 to 30%. Just from that.

You know, Priya, this is a great discussion, but I, I feel like we, we've gone over our time here. Let us, um, let us take a break here, and I'm gonna bring you back and we're gonna continue our discussion with a part two, if that's okay. Cool.

Hey, you're watching Text Drunk tv. I'm here with priyadi. We'll be right back.

Check out part two. Hey guys, thanks for the throw. We're here with Ellan Peleg, who's the CEO of Light Run.

And we're talking about the impact that all these AI coding tools are starting to have on our backend DevOps workflow processes. Ellan, welcome to show. Thank you so much.

Thank you for hosting me, Mike. Great to see you again. Good to see you as well.

I think what we're talking about is not wholly unexpected. I mean, sometimes when you put more stuff on the front end of something, it's eventually gonna break the back end of something. And what we seem to be seeing is a lot more code is being generated and it's moving through those pipelines.

It's not clear to me that all that code is making it into production, but it seems to be stressing our workflows and our, and the teams that manage that. So what are you seeing and what are the challenges? Super interesting.

So actually, you know, what we've seen is that, you know, a Ai c cell conduct has literally become the new reality, right? I think, uh, Dora claims that Dora recent sent a Google report claims that around 90% of the developers out there already adopted some sort of AI system, you know, coding tools, coding agents, and rights. Um, so, you know, developers simply now spend less time writing code themselves, but rather more like prompting, right?

By debugging, by, uh, by coding. And then the bottleneck is moving ahead to, you know, reviewing the code, debugging, fixing, verifying, uh, in fact, the world also claims, uh, that 60 to 70% of developers' time is now spent actually in debugging, fixing air code and fixing their code. Um, and the bottleneck, again, is moving to the runtime side of things.

Um, and basically, you know, on the moment, the code suddenly, you know, meets real world conditions, real world, you know, life and Southern Code is not siloed anymore, and it's part of an overarching system, including the runtime, including scale, customer data, potentially operations, APIs, third party dependencies, and so forth. So this is where, uh, you know, suddenly things start, you know, break. Um, on the contrary, the past year has been also the most expensive year in software outages.

Speaking of, you know, the major outage of CrowdStrike of last year, and just, I'm not sure exactly when this one is going to be broadcasted, but last, last month, we, we've seen, uh, these major outages coming from the big IPO scale, such as AWS, uh, the shut down the world, at least for a few hours, staying with, uh, staying with Azure and so forth and so forth. So both trends kind of, you know, contradict and conflict. Um, and this is exactly the gap that we're feeling here at lighton.

We help, you know, fix issues at the pace of ai. So fixing issues and specifically runtime issues should be also streamlined. And, um, this gap is actually widening.

And this exactly, you know, where Lighton is, is being super helpful. Troubleshooting remedi remediating software when software is already operational, you know, potentially serving customers at scale. Uh, we should move faster.

Um, 'cause otherwise this bottleneck is widening and we need to help engineering teams fix issues at the same pace. They actually develop code. So developing code is, is not the bottleneck anymore, but whether making sure it's running and operating right?

So, to your point, it seems like I hear the same things and developers are spending more time reading code than writing it, but the problem with debugging it is they didn't generate it, and they don't really understand how it was constructed. So how do we help them debug something That, that's a great one. Actually, to your point, understandability becomes a key challenge.

Uh, I mean, eventually when you know, wheels hit the road, this is the challenge. Like, it's not me in my siloed, you know, dev machine writing my code in, in the id, but rather, you know, code suddenly, you know, should operate at scale. Uh, and there's so many different requirements of how software should operate at scale.

Uh, so key element is, uh, supporting the runtime context. Actually, this is one of our key announcements, uh, uh, which is us democratizing runtime context to the wider ecosystem. Uh, speaking specifically of, of the coding or testing phase, imagine that each time developer is introducing a new piece of code, potentially even generated by, um, you know, AI or AI code assistant tool.

Uh, he will have runtime signals eventually letting him know how the software is going eventually to behave at the runtime. So it's not only about writing code that works, but it's about writing code that runs at scale, resiliently. Um, so I think like helping engineering teams not only debug the software, but even before debugging is happening, making sure that the software they right doesn't really work on their machine.

But whether it fully operates and is resilient, uh, to sustain the scale, sustain, you know, so many potential, you know, vulnerabilities, potential bug potential, um, outages is something that should be kept in mind in the hearts of every developer outer, making sure it is not just, you know, shipping code, but making sure that the code will eventually run and operate smoothly at the one time. So do you think developers are spending more time actually doing that? Because it seems like, you know, they're writing more code and they're enjoying the productivity benefit, but it's not clear to me that they're using that time to go back in and optimize the code, or for that matter look for vulnerabilities.

In fact, Dora also claims that developers using AI code assistance also introduced 41% more bugs. Mm-hmm. So, you know, as you move fast, you also break things.

People tend to say that even before the GN AI era. Uh, so it's, it's definitely happening. And I think the key here is not only about embracing AI or mainly productivity gains, but making sure you are embracing AI in a resilient, safe manner.

So quality is becoming, you know, the next frontier. So how do you make sure that developers, sorry, but are not becoming lazy and simply not accountable? Or, you know, how eventually the software that is about to serve your customers and help you achieve your business goals eventually will help you in achieving your business goals rather than, you know, just developers shipping much more lines of code, because potentially they might become a bit lazy and, and reliant on those ai, you know, magical tools.

It, it's truly magical out there. But this magic eventually can somehow, um, you know, introduce some quality issues in, in fact, this is what the study, you know, all of the studies out there already proved. Uh, so again, in order to eliminate this one, developers engineering team should be equipped with fully the runtime context and how eventually the code their shipping truly is, is about to behave when, you know, uh, when, when the he, the wheels, uh, hit the road.

Right? The other thing that seems to be happening too, is that as more of this code gets into production environments, and it's verbose the cost of running, it seems to get more expensive. 'cause we're processing things that we probably didn't need to in the past.

So are costs gonna go up? Definitely, uh, one reason is simply having introducing much more lines of code, much more compute, much more, you know, code that is that eventually is running. The other thing is AI also, or embedding AI agents as part of your sort of delivery life cycle or embedding much more AI generator code, also introduces like much more non-deterministic behavior that is a bit unpredictable, which can definitely raise your costs of maintaining, scaling your environments.

Um, so definitely it's, it's another huge concern. Again, it ties back to, to my previous point, which is the operate side or the runtime is becoming the side. We should all be careful now because it's quite clear that, you know, AI already reshaped how fast code is being generated.

Now. We need to make sure that, uh, at the runtime you are maintaining your resilience metrics cost, um, and obviously security. So all of those operational objectives should be kept.

And even, and, and, and you should also expect to hire, I would say, uh, standards there because, you know, as AI already proved all of us, it can help us move faster. It should, and we should expect to have better customer experience, better resilience. So shortening, you know, processes at the upside, um, both from cost, but also from, you know, resilience, uptime, troubleshooting time, um, security remediation, all of those.

Uh, we as consumers for, you know, softwares running in the world, right? Consumers of those digital assets, we definitely expect higher standards over there as well. Mm-hmm.

Um, what's to be done about all this? I mean, I can't put the genie back in the bottle. These guys are gonna be using AI coding tools.

So what do we need to do on the back end to kind of absorb all that? Um, so I would say much more guard those and governance. Um, and, you know, quality gates in again, as, as you move fast, you wanna make sure that you keep moving fast, but you know, not breaking, you know, things.

Um, um, while doing so, uh, what we started, you know, to see is that the new reality is actually a reality where code is cheap and bug are bugs are expensive. Uh, quite funny, but it's the, it's, it's actually the reality. Um, so I think CIOs, uh, engineering leaders and whoever is responsible for the SDLC must take proactive actions, um, in order to verify that eventually the software delivers higher standards of, you know, quality and resilience.

Um, and I'm not sure, I'm not sure we were there yet. 'cause as mentioned before, you know, coding has been all like streamlined. You write code in minutes, um, but eventually when you know, soft, sorry, but when s**t hits the fans, um, what happens is that it takes you days, weeks to respond, at least in when calco ft, right?

You literally need to onboard tens or even hundreds of engineers in a world group them together to make sure that, you know, software is, is being remediated. It shouldn't be that way in the gene ai. Mm-hmm.

It should be streamlined. And, and if code is being written in minutes, it should be fixed in minutes. Mm.

Will we therefore need more AI on the back end to make up for the deficiencies of the AI on the front end? And what might that look like? Um, I think taking a deeper look at, you know, the DLC and different playbooks that exist in enterprises or, you know, software organizations already adopted in the past, each one of those should be automated using the power of ai.

It might be a very custom built, you know, internal, um, you know, playbooks, internal policies, internal governance, all of those that are still manual should be streamlined with the power of ai, everything from the front end up until the backend, um, automations, DevOps, or SDLC. Um, so, so my recommendations, you know, CIOs, uh, VP engineering and, and general speaking, um, engineering leaders and whoever, again, oversees the SBLC, use AI to automate and streamline all of those processes across, across the board, uh, from frontend to backend, uh, digital experience, everything from code to production, definitely. Mm-hmm.

So we're coming up on the end of the year that, which means we'll be gearing up for the new year. So what's your crystal ball telling you that 2026 is gonna be like, I believe that 2026 is more about the market technology that, you know, AI literally changed the landscape, especially for engineers. And especially for engineers, especially for, you know, the, the SDLC, uh, there's a new term out there, which is called a DLC agent, uh, development life cycle.

So agents are really conquering the SDLC and are really creating a new form of, you know, generating software. But those also introduce, again, much more risk and much more like non-deterministic behavior. So enterprise and software organizations will simply be concurred by more and more, you know, agents, farms running tens of thousands, hundreds of thousands of agents should be now orchestrated, should be now governed, and should also, um, introduce their, you know, reliability standards.

So I think, um, day zero was more around embracing AI for productivity gains. Day one, I, I mean, 2026 will be more around governing those and making sure they eventually help us in achieving our business goals rather than degradating the quality of our software. All right, folks, you heard it here.

Hey, if we don't put the governance tools in place, then this AI stuff's gonna quickly become too much of a good thing. Hey, Ilan, thanks for being on the show. Thank you so much, Mike.

All right. And back to you guys in the studio. Hey, everyone, welcome back here to our coverage of AWS Reinvent 2025, uh, from Las Vegas.

I'm really happy to have my friend Margaret Dawson here. Margaret yes. Is the CMO at suse.

But beyond that, she's one of the most interesting people that I love interviewing, to tell you the truth. And here I'm being your partner today. Yes.

We're doing a different Thing. You know, if you can't tell Sus SUSE is our sponsor, uh, sponsoring partner for our Tech Drunk TV coverage. This here at Reinvent.

You've seen this up here, you know, all throughout the show. But now we actually have someone from Susie here to talk to. Here's the deal, though.

We're gonna be doing a couple of different interviews right. Today, right now, I just want to kinda lay out Margaret, that's sort of an overview. And also I wanted, look, you're a veteran of reinvent.

Yep. You've been here a bunch of times, as have I. This one feels a little different.

Hmm. And, and if you don't mind, let's start right with that. Okay.

What's different this year? Well, what's the same? Is it still a lot of people?

Oh, yeah. I, I haven't seen the count, but it is massive. Um, so it feels bigger than ever.

It feels like we've come fully back from whatever downturn we had. Yeah. What's different, you know, the one thing that's interesting, and you and I have chatted about this a little bit, is that we're not hearing the word cloud.

We're not really hearing cloud, Which is kind of weird for AWS, But I think it's just because like, we're there, like it's inherent. Um, I will say in conversations with, you know, people that are wa non non-Amazon and, and people that are here at the conference, we are still having that conversation about how do I manage things across on-prem all the way to multi-cloud. Um, in my Amazon meetings, we are talking about multi-cloud.

We are talking about, you know, how do we have that seamless experience for our customers? So it's there, I just think it's under the weight of everything. Ai.

Yeah. Right. So everything is, is kind of under that bigger umbrella, which you'd expect It, it seems to be all AI all the time.

Yep. And, and it's not just the word cloud. In, in years past, you'd come to an AWS conference and you'd spend a lot of times talking about things like S3 or Lambda Yep.

And serverless Kubernetes even. Right. All of that has become sort of cosmic background radiation as we focus on how AI is gonna empower all of this.

Well, All of its AI is integrated into all of that. I will say, if you go into some of the sessions that are more technical, you're still getting that. Yeah.

Like I was at a, an EKS session yesterday. I was at an Amazon Linux session yesterday. So you're still getting into the guts and getting roadmaps and, and all that, but it's, it's a level down.

Yes. Right. So you're probably not seeing that quite as much, but I think you're right.

Like we're talking about, okay, how is AI helping us with Linux? How is AI helping us with container management or Kubernetes? How is AI helping us with general management of our cloud ecosystem?

Absolutely. So, I, I want to talk about, 'cause it's, when we say ai, it's like AI in all its flavors. Yep.

But before we get into that, you mentioned Amazon Linux. Yep. And I, we'll probably talk about it a little more in depth later, but I know SUSE had a, a big, we did announcement around This.

We did. Um, and this is exciting because I think that at this AWS reinvent, we're really transitioning from being a listing on a marketplace to a strategic partner. And to me, the difference is, is when you start adding extra value to their software, right?

And that's what we're doing with Amazon Linux, with what they announced around supplemental packages for Amazon Linux or sp mm-hmm. Which that's a cute name. Sp.

And so we are providing open source components that have been tested, verified, secured, et cetera, as part of those packages. Um, and so what I love about this is that our passion is open source. I think Amazon is a huge consumer of open source, but you don't necessarily see that as a customer.

Right. And now they're bringing that choice to their customers in a secure, in a reliable way, which is what we do. Right?

Absolutely. That's, that's like our, our secret sauce. So, um, to me that, that transition is exciting.

And then the second thing if we just kind of keep going with what we're announcing is we now have SUSE Rancher for AWS, which is a SaaS solution. Really? So we now have two.

Okay. Didn't realize it was SaaS. Yeah.

We have two SaaS. So we have Observability cloud. Mm-hmm.

And we have SUSE Rancher that are both delivered SaaS through the marketplace, you know, no touch. So, you know, try before you buy the whole thing. And I think that's also kind of moving that lever to a new place.

And with that, we can now manage not only EKS, but any flavor of Kubernetes. Right. Wow.

So if someone has EKS, which a lot of customers are leveraging their Kubernetes, but let's say they also have two or three other flavors of Kubernetes across things, we can now manage all of those clusters. Um, the original intent was just managing multiple clusters of EKS, which is very hard. Mm-hmm.

Right? Um, Amazon has a very strong management plane kind of per Kubernetes cluster, but not this way. Right.

We can help you manage all of those clusters, plus any other flavors. I I think that also comes into play if you are using multi-cloud, right? You've got some hundred percent Kubernetes on AWS some's on Google or Microsoft or somewhere else, or Oracle or wherever.

You could manage them all with that. That's right. I, I wanna go back to SP mm-hmm.

SPAL. Um, you know, so I'm a security guy. I've got 25, 30 years in before we called it cyber.

Yep. One of the biggest problems we face right now is this, what we call software supply chain security. Right?

Right. Because software today is kind of Frankenstein. We put together a lot of mm-hmm.

Components, pieces, scripts, add a little special sauce, and out it goes, being able to put in these components and pieces that we know are secure. They're not injected with malware, they're not, they're up to date, they're someone else's job to make sure they're Secure. But there's still all the open source pieces that developers love.

Right. So we are testing, and that is exactly what you want, as if I was a CIO at an enterprise. Right Now, you know, you want your developers to build the apps the way they wanna build them, but you cannot afford to have an untrusted or potentially vulnerable component In any way if you're a CIS, though a ciso Well, CISO would be even more that way.

Yeah. Correct. You, you're loving this.

Yeah. Because that's, that's how malware gets injected percent into our supply chain. Yep.

Right? And I think that's critical. And I mean, this is our whole value prop, right?

Is taking open source and putting it through that trusted supply chain. And I was thinking about this an analogy, and, you know, I love cars, so I just went back to cars. Like you think about the old days with Ford, they built everything, every component was Ford, every manufacturing line, the whole supply chain was a single company airplane.

Same way. Boeing. Yep.

Today everything is third is sub components third party. Yeah. And what happens if you get a component in an even a physical car, or you know, an airplane that hasn't been, you know, gone through that test testing and security and all those things, and something breaks down, you can never find it.

Same thing with code. Think about it. One of these little libraries or components or tools isn't trusted To find that piece, once you've built out an application, is very, very hard.

So how you bring in that trusted supply chain is critical. Absolutely. And, but this is a very elegant solution to that, right?

Mm-hmm. And, And, and they don't have to leave Amazon, because remember, developers love working in AWS They do. Yes, they do.

It is a very, they, and that's really the AWS secret sauce. It is, is they grabbed the, the, I Feel like we forgot one of our announcements. Yes, We did.

There's a third one there Is. The other big one is we are integrating Amazon Q and Amazon Bedrock. So two foundational pieces of their AI story, um, with both of our Linux and suse Linux Enterprise and, uh, SUSE Rancher Prime.

Really. So now the com, the capabilities around those two, um, AI solutions, uh, can be fully utilized when you're using Amazon within. Mm-hmm.

Correct. You know, there's another sort of undercurrent that I, I wanted to hit on, and that is, you know, some people call it modernization. Some people call it transformation, but it's the, and I'm not pointing fingers or anything, but a lot of people's VMware licenses tripled, right.

As part of the acquisition. And it's not necessarily that they're moving off of VMware because of that license mm-hmm. Upgrade, but it's giving them time, a, a pause to reflect and say, Hey, what options do I have?

Well, and I think what's important is that most of those people, and the reason we're calling it modernization or transformation, is they're not trying to replace what they already have in their traditional, or sometimes we call that legacy infrastructure. Mm-hmm. They're trying to look at this transition as a way to get into cloud native.

Yep. So if you can have a virtualization solution that moves your VMs towards the future in a way that is somewhat elegant, you know, and then you can move to containers from there, that's what you want. Because right now that migration can be sometimes challenging.

Yes. And so for suse, that's our sweet spot. So what we're saying is, look, we're not gonna go into your data center and replace all that, but if you wanna move some of those workloads to Cloud native over time, we have a virtualization solution that is very sweet.

And now we've made it easier than ever to move those VMs very, very quickly over to suse. And then you're on the path, you're on the same platform, same rancher platform, suse virtualization, lives on rancher. Mm-hmm.

Um, and so you can get to cloud native much more easily, and it can be managed in the same way. So that's a key thing. I, I mean, I'm, I'm just thinking about this common theme is managing things in a common way, a single control plane.

And we do that with both virtualization and containers on rancher. I love it. And, and it is, you know, whether you want to call it modernization, transformation, I don't care.

It is the path to getting onto the cloud without having to necessarily move everything to the cloud. But it's also about having one foundation, one platform that allows you to manage no matter where you are, whether it's AWS in your data center or another cloud provider or what have you. And That's critical because some people think they have to consolidate to have that control.

And in some cases, for sovereignty, maybe that's true. Mm-hmm. But I think most people want that control, but they also want choice.

So how do you get choice with control? Control? I mean, to me, that's Suse.

So su I was just gonna say you spell it SUSE, but, um, I feel like I'm on a TV commercial, but you know what, I, you mentioned sovereignty. I do want to come back to that. We don't have time to jump into it right here, because I wanted to return to all the many flavors of AI and what we're hearing here at, you Know, no, I think this is something Amazon is doing very well at, at this, right?

They have Bedrock, which is really all about foundational models, right? Mm-hmm. And how you can plug those in, and they're, they're really starting to say, I don't know if it's bring your own LLM, but they're making it easier for you to work with many, many different models.

Yes. Um, with q they're really bringing together, you know, a agentic ai, generative AI in one place. So while we are seeing, I guess, a merging of these different flavors, I think we do need to be careful not to just say AI too loosely and assume that everyone knows what we're talking about.

'cause there's very different things under that larger vernacular Umbrella umbrella. Sure. You know, Margaret, you mentioned that it, it'll, it gives you freedom around mm-hmm.

Your, your AI choices, what frontier model you want to use, right? But also, they announced something else called Forge. Right?

Which allows you to create your own frontier model. Now, look, there's, there's only four, five frontier models in the whole world that we're all having to use right now. The ability to do that and bringing it down so that SMEs small, medium enterprise and enterprises can create their own is an amazing, you know, choice.

Uh, or it gives people options to really do this. Um, I, I, I, I don't know how many people are actually gonna do It. Yeah.

I don't know. I mean, I think that's, that's gonna be a rare thing. But I, I, let's go back to what you just said, because I think thematically at reinvent and at AWS something that excites me is that we are talking more about open source.

We're talking more about choice, choice. We're talking more about allowing people to work the way they wanna work as they work with AWS and their, I don't know, thousands of partner ecosystems. And that is exciting because I think that is a shift, um, just culturally or, or value wise.

And I think, you know, everyone sees that that is the future and it's great for customers. Absolutely. I want to talk about partner systems and everything else, but we've, we've got a few more interviews we're gonna do.

We do stay tuned. We've got a, a really, a great bunch of SUSE information, and not just suse, I don't, we've got our Amazon partners, partners, everything going on here in Reinvent. I'm looking forward to it, Margaret, but it's not just Margaret and I, we have more people coming on.

Um, so stay tuned for that. You're watching Tech Trunk tv. We're at AWS Reinvent, sponsored by suse.

Hey, everyone, welcome back to our coverage of AWS Reinvent 2025. It's been an interesting two days, a packed full of information and announcements, innovation, a lot of ai, and a lot more too. Um, glad you can join us.

This next panel promises to be one of our best. So I'm, I'm glad you're here to watch it with us. Let me introduce you to our panel members, and then I'll talk about, I'll let you know what we're talking about.

I wanna start on my far right, gentlemen. Well, there's only two gentlemen here, me and him. So let me start with Spencer.

Sure. Spencer, if you wouldn't mind. Yeah.

So I'm Spencer Dillard. I lead, uh, EC2 EEC two's Edge businesses, uh, including, uh, local zones, a s Outposts. Uh, but for today, more relevant.

I also lead our Amazon Linux, uh, commercial Linux and Windows businesses, uh, in addition to some other areas of a s And I've been at AWS since 2011. Uh, so lived through quite a few changes and excited to talk about what we're doing. Absolutely.

Spencer, welcome and thanks for being here. Next is Spencer. We have Sri.

And Sri, if you wouldn't mind introducing yourself. Yeah. Hey everyone, I'm Sri sku.

I'm a product manager for Amazon Linux. I've been with Amazon Linux for around three and a half years. I'm excited to talk to you more about Amazon Linux and our new features, um, for it.

Thank you. She, and, and to my immediate right, you may have seen her on, uh, one or two already of our panels and, and interviews here at, uh, AWS Reinvent Coverage. Christine, I'm Christine Puccio.

I lead our AWS growth strategy, uh, for suse. And, um, been doing that for about a couple years now. And it's, uh, it's been, this year has just been so packed with so many great, um, announcements, and I'm really excited to talk about what we're gonna talk about today.

Yes. We're going to, we're, we're gonna focus in today a lot on Amazon Linux. But I, I just, I wanna preface all this with, you know, Christina, it is, you, you kind of shepherd the AWS, uh, SUSE relationship.

And, and in my mind, at the very highest level, I think we bear's repeating, it's a strategic relationship, and it was announced as a strategic relationship on, on a lot of different levels here. Right. This Amazon, Linux is one of three or four different areas where we've been, you know, looking at over the last day or two.

Um, so it, it's an important relationship to suer it's an important relationship to AWS and, and I think it Good job. Nice job. Many, Many people involved as well.

No, I know, but you know what? Someone heads it up and, and is response. I've always learned, I've done a lot, I've done four or five startups in my life, and a lesson I learned, if it's not someone's full-time job, it doesn't get done.

So That's what they told me. That's what I got. I've learned that the hard way.

So, good for you. Um, but guys, let's kick it off, right? What I, I wanna focus in, as I said today on the Amazon Linux piece of it.

Now, our audience out here, everyone knows AWS everyone knows AWS gives you a lot of choices around Linux, including Seuss for suse for what, 20 something years, or as long as there's been an AWS. But Amazon Linux is a, is a, a different kind of animal, right? It's Amazon's Linux tree.

You are the Amazon Linux expert, aren't you? So let's, let's start here for people who may not be as familiar, maybe with what is Amazon Linux? What makes it special?

Mm-hmm. What, what are some unique characteristics? I know it's going through a regeneration as well mm-hmm.

Share with our audience, if you will. Sure. Um, Amazon Linux is a Linux distribution that was created by AWS, and it was developed by AWS, uh, it's also being maintained by AWS uh, the first version of Amazon Linux was launched in, uh, 2010, actually, 2025, uh, Marx, uh, 15th year birthday for Amazon Linux.

So, wow. It's a, a special year for us, Uhhuh. Uh, so it's been a long time.

Uh, 15 years is a long time, and we've learned a lot from our customers from the changes happening upstream. Um, so it, it's, uh, it's been fantastic to see the evolution of Amazon Linux over these 15 years. Um, the latest version is, uh, AL 2023.

Uh, when I say Al, it is short for Amazon Linux. So for the audience, it's easy to understand. Um, so Amazon Linux is, uh, mainly, um, uh, used because it is optimized for a Ws, it comes with deep, uh, AWS, uh, integrations, uh, with various other services.

Um, for example, E-K-S-E-C-S, um, A-W-S-C-L-I, um, and various other services that you can think of. Um, it helps, uh, reduce, um, operational burden for uh, our users, because, um, think of, uh, it as, like, when you're launching an instance, for example, you have to think of various parameters. For example, network configurations, attaching IAM roles or EBS volumes, et cetera.

And Amazon Linux has integrations with all of these so that when you launch an instance on EC2, it just works out of the box. And, uh, not la Uh, last but not the least is, um, Amazon Linux helps you lower your cost of, uh, um, ownership. Yeah.

So how does it do this? While our customers still pay for the compute resources? Um, Amazon Linux is free of cost.

It has no licensing fee. And on top of that, the AWS support is included as part of Amazon Linux. This is, it's like, you know, really it's a big thing for our customers.

So all these factors make Amazon UX special. And Spencer, please add on. Sure.

Uh, I, I think a few of the things I would add, I mean, uh, really great introduction overview of, uh, why it matters to us. Um, it's Amazon Linux is used by basically every AWS team internally. It's used for our own infrastructure.

Um, and, you know, it is a fedora based os. Mm-hmm. Uh, it originally started as a, a Red Hat, uh, clone.

Uh, a few years ago we shifted to being, uh, FEA based, which has introduced, uh, a number of aspects that, that drive our thinking, uh, going forward. And in addition to the total cost of ownership that, that Sheree mentioned, um, we're really see it as critical to the security that is important to our customers. The, uh, that one of our most important properties to is to ensure that we are providing up-to-date patches.

We often support kernels that are older, uh, which is, you know, good challenge, uh, but we're really trying to focus on security and ensuring that we, uh, are providing as secure a solution as possible while where possible really minimizing the effort for customers to have to be forced into a migration or things like that. Obviously, at some point you have to, uh, and at the same time, we're also providing, uh, out of the box integrations with things like elastic fabric adapter, elastic network adapter, uh, drivers for AI and, and NVIDIA chips and various things. So really ensuring that whatever you want to run on AWS it will work on Amazon Linux.

And so we're really excited about what we've done to make sure that more customers and users can, uh, run their workloads on Amazon Linux. Absolutely. Cherie, you mentioned the latest version is, uh, AL 20 23 3.

Correct. And, but in terms of backward compatibility, my understanding is we're gonna end of life support for AL 2022. Uh, it's called L two.

Oh, excuse me. Yeah, A two. Okay.

Yeah. When, when, and, and that's pretty imminent. Uh, that's right.

So, end of support for a L two is upcoming, uh, on June 30th, 2026. So approximately six months from now, that's when, uh, that'll go, that version AAL two will go, uh, on end of support. And a L 2023 is the latest.

I would imagine, though, it's a rather seamless experience to migrate, uh, or update from the a L two to a L 2023. It, it really depends on a lot on, on what the customer is using. And one of the key reasons that the partnership with SUSE has been really important is that it unblocks a lot of cases where customers have been challenged.

Because moving from, uh, red Hat Enterprise Linux clone to, you know, uh, fedora based has really, you know, has met a shift in what packages are available, uh, for especially, uh, the Apple packages that are available on Red Hat repos, those need a solution, right? And customers don't generally want to go build and compile and download the source and deal with their own patching. So being able to provide these additional packages is essential to reducing the effort for customers to migrate.

Uh, and going forward, this is something that we really see as absolutely central to our vision for Amazon Linux is ensuring that, uh, first and foremost, we are maintaining security, that that will be our top priority and continue to be. But borderline more important is migration and minimizing the effort. Because the reality is, if there is effort to migrate, then many customers won't.

And in not migrating, they actually end up being less secure. So in many ways, that migration, uh, Friction is actually Can Trump security as a, as a, you know, te as a tenant that we consider. Mm-hmm.

Absolutely. Um, so I, you know, you mentioned Fedora. I'm not gonna get into the whole Red Hat mm-hmm.

Stuff. Yep. Stuff, believe me.

That's, that's a good word. Stuff. But what I, what I do wanna mention is the idea of enterprise Linux, right?

Mm-hmm. Now, SUSE has an, an enterprise Linux. Mm-hmm.

And I always do the initials, but you guys call it s**t, how you say SLES, but, you know, tomato, tomato, um, it's a, it's a true enterprise. Linux Red Hat has an enterprise Linux too. Amazon Linux is an enterprise Linux.

And that's really what I want to emphasize for the audience here, right? It's an enterprise Linux distribution. Um, and so it is, it, it's strategic, right?

Mm-hmm. Now, let me pivot to announcements, right? Beyond the strategic relationship between suicide and that red hat I, I spoke about, there was some specific Amazon Linux suse, um, integrations, partnership kind of announcements.

Christine, this is your baby. Oh, Well, I think I, well, first of all, this has probably been one of the most, um, I don't know, heartfelt projects that I've, I've worked on, because I think it was a, a first of two, um, companies coming together that traditionally could be competing for the same, you know, workloads. But it was having the engineers from our side, um, you know, our Linux group and, and your side just coming together and building a concept and requirements document, and really looking at how we address security together.

How do we address building the packages? What packages, what packages do we prioritize based on customer feedback? And it was, and at first it was funny to see the engineers and everybody in the room together, because they're like, why are we here together?

Yeah. But it's, it, at the end of the day, our value at our company is about choice. And our, we know that our customers are always going to operate various different workloads on various different operating systems.

And so it just became, you know, we were able to help in this instance, and not just provide packages, but actually, uh, increase the, the, you know, volume of time that it would take in order to do that themselves. And I think that's where the unique partnership is in this, and why I was, so when I first saw this project, um, and, and was read into it, I was like, wow, this is, this is really super cool, and this is kind of a first, and I really love working on, on those types of projects. And it, it has been a real pleasure to, to work with, uh, Amazon and AWS on this.

Likewise, I don't think we mentioned the term, and I want to make sure we get it out here, and that is, I, again, I say the initials, you say their name, but SPAL spell Al Al s pal. Yes. That's why I say the initials and say, but SPAL sp, and, and you know, that's what you're referring to a lot here, and, and it is unique.

Think about this, right? You are taking packages that in essence, exist in Cuse Enterprise Linux mm-hmm. And making them portable and usable by Amazon Linux.

And look, there's a great day for open source, because that's what open source is about, right? The ability to, to have portable codes like this that can move from one Linux to the other, somewhere Linus is smiling on that. And, um, and so it's, it's, I've never, honestly, I've never heard of anything like it, but it's, it's, it's really cool.

Yeah. And I think one of the things that has enabled this is that we have a common, you know, value of allowing, enabling choice. And, you know, from the AWS perspective, we don't want to tell customers how to run their workloads.

We want to advise them where there are things that they should be aware of or concerned about, et cetera. But our goal is to make sure that they can achieve solving the problems they need to solve, however that is. And so it's pretty natural working together to say, you know, at the end of the day, that is what this is about, is making sure that customers can choose the solution that's right for them.

And, you know, Amazon Linux may not be right for some others. That's okay. What we care about is that customers can solve their problems.

Right? Yeah. Agreed.

Let's, if you wouldn't mind, and, and Shay I hope I'm asking the right person this, but I I, let's peel that back a little bit. The, the specific packages. What, what kind of functionality or, you know, what's in these packages?

Sure. Um, so Amazon Linux actually has, uh, approximately 2,500 packages already. Um, a lot of our customers use these packages, uh, which are a part of the core repository.

Mm-hmm. Uh, however, there are some packages that helps you, um, increase the productivity, uh, for a developer or for a system administrator. Uh, for example, uh, let's take the package called as r uh, R is used for statistical analysis like, uh, and programming.

Uh, and this kind of package was not a part of the core Amazon Linux. It is an extra or an additional package. So you actually would find these packages, uh, as part of the Apple, uh, repository.

Apple is extra packages for Enterprise Linux. Um, and, uh, uh, our customers, as they were migrating from a L two to a L 2023, wanted to know these packages. Like, Hey, I, I use this package.

I rely on this package. Can you help me, uh, provide these packages? Because otherwise, the choice that our customers have is to build these packages from source, which, if you can imagine, consumes a lot of time resource, and they have to maintain it, which is a huge deal.

Yeah. Right. So, uh, on, on our customer's request, uh, we understood that, uh, okay, some of our customers rely on these Apple packages.

Um, and that's why, um, we had to bring these packages to a L 2023. Now, to do that, that is where we partnered with SUSE on getting the Apple L packages and making it compatible for a L 2023. Yes.

So that was the partnership, and this is called as sal or supplementary packages for Amazon Linux. Uh, it is a dedicated repository, um, that work that has thousands of packages, like Christine was saying, we started prioritizing these packages based on our customer's feedback. Our customers, uh, provided feedback on GitHub or via support, uh, or TAM'S technical account managers.

And that's how we know that these are the packages our customers are looking for. And that is what we prioritized in the initial phase. One.

One thing I, if you don't mind, is also that Susa has been critical to also help identify some of the, you know, the areas and packages that Yeah. They see widely used that they see as being critical, because, you know, we have sometimes have different lenses, so that, that expertise has also been very valuable. Yeah.

Sorry. No, I think, um, the other part to this too is that there's, there's like over 8,000 packages mm-hmm. Within, is it epel, epo, right?

Yep. Narrowing that down to try, and I think I wanna really talk about like how long it took, not even long, but like how critical the discussions were to talk about what type of packages are there, how are we gonna support them after we provide them, what does security look like? All of that were things that we discussed even before we even started looking at delivering them.

Right. And, and that's why I think what makes this partnership really special is because we understand that security. We talked about that earlier, you know, two, two components of customers, you know, critical needs are lessen the complexity and security.

So this was really a way that we did a lot of homework, a lot of back and forth. The prioritization of the, of the packages were even like slipping, you know, back and forth. As time went on, we just got, we even had more.

So I really have to say a big thank you to, uh, our engineering team at, at suse, and also the support from Amazon's Linux team. It just really, um, it, it was really awesome to see everybody come together. It's what's such a unique Yeah.

Unique partnership. Yeah, Absolutely. You know, I, I want to focus in on the security aspect of it, though, at a time where software supply chain security is so critical.

Yeah. Unfortunately, you know, we have at the, the, the, the folks at csaw, primary gated, the SBO m mm-hmm. Uh, regulations and so forth.

And, you know, whether or not we still see a lot of this coming out of the quasi-governmental CS a mire and, and this and so forth. But software, supply chain security is, is a critical, critical piece of this. And a critical part of this announcement is that Susa is certifying the security.

Susa is standing behind these packages saying, Hey, the packages you're getting from us, they don't have SHI loot. Mm-hmm. Or, or one of these, you know, worms that are out here now that are just wreaking havoc.

Yeah, yeah. You know, with a lot of package managers out there. Um, and, and that, you know, that's not trivial.

Yeah. That's really Important. That was a truly essential part of the SIM driver, is that, you know, when we look at our teams, you know, we can do that.

We have the expertise, we Sure. You know, but the, you know, the value and the, the challenge of keeping up with, is this package actively maintained? Is anybody looking at it?

Yep. Do we go fix it ourselves? Do we then end up stuck, you know, maintaining something that we may not fully understand, but we identified a vulnerability, like if we're not, if we weren't careful, you know, we can very easily wake up and, and, um, tons of operational challenges and potentially really disappoint customers in that expectation.

So being able to, to share that responsibility and shift it so that we can sleep at night and our customers can, because somebody is looking, a lot of the supply chain are not, uh, you know, as much on a best effort basis. It's something that is core to this relationship. It's really Important.

You know, a, a word we've talked a lot about on these panels and in my videos these last couple days, is scale. Mm-hmm. Mm-hmm.

They call Amazon a hyperscaler. Mm-hmm. Mm-hmm.

It's, it's just that Spencer, it's a scale, it's not a dozen packages that I could keep an eye on. Yeah. Yeah.

It's thousand thousand, 8,000, 3000 are going in to maintain, and, and you know, how maintaining any software, let alone open source is Right. Uh, I found a bug in this week. I update it.

I don't want to have to go through my, uh, j uh, you know, the, the, the last big one and find wherever it's running in my, in my infrastructure. It is not at doing that. It's scale.

Again, if it's not someone's job, it doesn't get done Well. The other, the other piece to this is that, you know, SUSE does have the open build system, and that's where we actually, uh, harden and secure our, our the packages, right? Yeah.

And that is actually open to other, uh, companies that, that use it, you know, other open source Linux companies that use it. And so we, we are behind that, and we actually use that to deliver, um, the packages. Love it.

Yeah. And there's another, uh, deeper layer to this. And when, when we talk about packages, it's not like, okay, there's one package and that's it.

There's always like a ton of dependencies around those packages. So identifying those dependencies, making sure that those packages are there. So that also is a part of this entire partnership.

It's all right. Yeah. So there is a complexity there.

Um, and yeah, S bombs aren't easy. This was definitely complex Because it's like the commercial and so on and so on and so on. Mm-hmm.

Once you start getting into these dependencies, well, I got this from here. They got it from there, and what are they doing? Yeah.

Yeah. And, and the one thing I would add is in the reality is all of us, uh, have challenges of keeping up with the amount of kernel cvs these days with the, the changes that were made, and mm-hmm. And, you know, I, I, I think when we look at what that is going to take to ensure we're staying on top of it, a lot of it's a choice of where do you, you know, invest.

Mm-hmm. And Absolutely, we're running a little low on time. I want to bring it down to a call to action.

Mm-hmm. I always like to have a call to action in these things. Let's number one, uh, Amazon Linux 2023 is available now.

You don't have to wait till June to No. You'd be silly to wait till June to make that migration, number one. Number two, the S PALS are available now.

Yes. How many, how many packages have we delivered now? There's quite 800,000, 800 actually that from end of August, Right?

To to mid-November. November. Yeah.

That's a, I mean, that's how fast we've been Operating. We still landing more mm-hmm. For my Amazon using folks, and there's a lot of them out here.

Mm-hmm. How, how do they access this where? Yep.

Absolutely. So, uh, customers who are using a L 2023 can actually, um, install and enable this SAL repository by a simple DNF command. Um, just install the repository, and then you can install the packages that matter to you.

You don't have to install all the 1800 packages. You can just install the packages that matter to you. Even that happens with a simple DNF command.

So it's very easy. It's just two commands that you can use to access the repository and install the packages. Fantastic.

Do you think we'll see a time where we'll have sort of like a recommended configuration for AL 20 20, 20 23 with the al, or it's always sorta a la carte? I, I would take a stab that it's, you know, first it's gonna come down to is it something customers want? Yeah.

So we maintain various, uh, uh, IES that we build for different architectures, different. So there's a number of Omni's, uh, Amazon machine images that we build, uh, with Amazon Linux. So if it is something that customers want, then yes.

But the reality is that it's, it's not terribly difficult. And for many customers, it becomes really tricky to try to guess what that set would be, and then for them to understand and how does that change? Right.

If I have another update, maybe a package goes away, what does that mean? Right. And so we may, but I, I think really for now, it's, it's understanding how customers are actually using it, monitoring what packages, not on an individual level, but in aggregate, are really being used heavily so we can make sure that, you know, I'm missing anything.

We wanna really make sure customers are unblocked first. Maybe we'll make that easier later, but it's not a terrible, you know, inconvenience or issue today for customers to enable it, install a package, and if they want to create a, an, an omni of their own that already has that running and they're done. Right.

So it's probably good stuff. A simple way to go. Absolutely.

Well, RI Spencer, Christine, thank you so much for coming on here. Text Trunk TV with us today. I'm sure our audience appreciates it.

Great work. Great work. I mean, look, maintaining, how was it?

8,000 packages uhhuh? Totally, yeah. Maintaining 8,000 packages and, and having an enterprise, a true enterprise Linux.

Yeah. I mean, the folks at, at, uh, Seus been doing it for over two decades. Mm-hmm.

It's not a trivial task. Yeah. Right.

Yeah. It takes a village. Yeah.

And, um, continued success, success with it. We, we will see it. I'm sure we'll see more of it coming and, uh, we'll, we'll be following up.

Thank you so much. Thank you. Thank you.

Thank you. Thank you for watching. Uh, we'll be back, I think this may wrap our day two coverage up, but we, we have a full day, more of, of Amazon coverage of AWS reinvent coverage tomorrow, uh, starting with our Textron Gang first thing in the morning.

Well, first thing in the morning, Vegas time. It might be a little later for you guys out there on the East Coast. But for now, this is Alan Shimmel.

Thanks for staying with us today. Have a great day. You've just watched Text Drunk tv.

All right, folks. Uh, very warm, welcome. My name is Raj, and with me is, uh, we'll be introducing ourselves, but today we are talking about golden parts or spaghetti pipelines, the dark creator of Platformers.

It's, uh, influenced by a lot of Star Wars. Uh, I wouldn't say that I'm a Star Wars fan, but, uh, I think, uh, I've watched quite a bit. So we, we are gonna be talking about how platform engineering has, uh, evolved in today's world and what, uh, you know, platform engineering has come up to.

And we'll introduce a cool open source project in ent. Uh, obviously, uh, that's how I have summarized the talk for you. Again, my name is Raj.

I'm A-C-N-C-F ambassador and a community manager at antes. My journey started off with chaos engineering, a lot of things around litmus chaos. And now I have been doing a lot of platform engineering, K Zeros called Open, SDN.

Uh, other than that, I, uh, from a community aspect, I run KCD Bangalore, uh, platform engineering meetup. So you can connect with me on my socials. Har, would you like to introduce yourself?

Mm-hmm. Sure. Fr thanks.

Uh, yeah, so I'm Hareth Thanks folks for tuning in. Uh, I'm the Osbo lead at Marant, uh, OSBO, for those of you who don't know, it's open source program office. So, um, the typical role of osbo would be to focus on the upstream contributions and, um, contributing to the open source community.

And we at Martis are especially focused at the Kubernetes ecosystem. So we work around technologies such as cluster API, um, um, and we open telemetry in Prometheus, Grafana, you know, for the observability stack in and so on. Yeah, happy to be here.

Alright, thank you so much. Rad. Uh, for the agenda, I think I have given an intro already on what we will be talking about.

Usually I don't keep a set agenda in place because, you know, you can stop me when you want. It's, uh, obviously being recorded. So we'll try to cover as much as possible.

We talk about a lot of platform engineering and a lot of, uh, uh, a lot about the tooling as well, how a real IDP might look like. So we, we'll find out what we'll talk about. But before I start, before I start talking about, you know, what's, what's there, what, uh, platform engineering, what's the platform engineering ecosystem looking like today?

I'll just start from the, the developer ecosystem itself, and if you can see my screen well and clear, this is hello translated in a hundred languages. Uh, there are so many more languages, there's so much more that you can translate hello to, but in the developer ecosystem, it looks something like this, the CNCF landscape, and that is what is expected from developers. Developers are expected to learn tooling.

They're expected to learn different kind of tooling. Uh, beyond writing code, developers are expected to run learn container and time kiosk engineering, networking, CICD, uh, building pipeline streaming messaging policies. And developers don't want to learn so much tooling.

Developers want to be writing and shipping the best code. They don't want to be testing. And, you know, being involved with qa, being involved with learning CN CF tooling and implementing that, running it in s switching production.

But that is what the ecosystem looks like today. That is how, uh, enterprises or teams are functioning today. Uh, developers are expected to do so much that there's a developer to developer experience takes a hit.

And that is where the idea of, you know, DevOps came in. The idea of, you know, moving from, uh, the old school way of development to, you know, having the ops side of things to make shipping easier came in. And that in itself has become tough.

I mean, if you have to talk about DevOps engineering today, there's a sense of change or the sense of, uh, you know, shift from DevOps in itself. But before I introduce that, and before I talk a lot more about cloud native technology, let's talk about how cloud was meant to be. The idea was a data center interacting with a public cloud environment that is what customers or developers or the idea of cloud brought in.

But this is the reality we have today, multiple cloud providers. There's AWS Azure, uh, people are hosting their, uh, infrastructures on private cloud edge environments. And there are so many APIs under the hood that eventually it has become a complex distributed system or a complex distributed infrastructure.

And the idea of, uh, you know, container orchestrators was to make it simpler with Docker Swamp, to Mesos, to Kubernetes, where the community thought that Kubernetes is that one single source of truth or a powerful schedule, or a powerful container orchestrator. But this is what we have eventually reached too. Kubernetes has matured, but we, we can see that even if we are using Kubernetes under the hood as the orchestrator, it's Kubernetes, which is, you know, being used, uh, as, as an orchestrator in your Azure environments or your AWS environments or your GCP environments, edge environments.

But there are still multiple APIs under the hood. It's, it's very hard to manage these multi-cloud, multi cluster deployments. And the ideation that we had with, you know, bringing platforms and KU was that Kubernetes will remove these, uh, uh, complications, these dependencies and Kubernetes will act as the single source of truth or the manager to these multi-cloud, multi cluster environments.

But where we are, where are we today? I mean, with, uh, you know, platform engineering and the concept in itself, I believe platform engineering is not a new concept platform as a product is platform engineering has existed for as long as we have known. DevOps in itself had the idea of building platforms and, uh, ensuring that the developer experience is eased out.

Developers are able to ship code faster, and they're able to, uh, basically build, uh, build an infrastructure out of different tooling. But platform as a product is how, how it changes the ecosystem is that now you are trying to ship tools that are predefined. You're using the C NNC of technology.

You are, uh, using AI native technology. You are hosting it on different, uh, cloud environments or your VMs, or on your GPUs. So the, the idea is to shape a readymade standard approach to developers where they don't have to do much.

They are shipped something that they have access to. There's an interactive UI per se, or there are interactive tools that they can choose from. There's a marketplace if you want to choose the, your csis, your CNIs, your container registries, your everything is shipped to you as a complete total platform, which I believe a lot of it has been achieved by, say, Heroku or the other, other options that are out there.

But as I said, platform engineering has evolved to ship platform as a product where you can use your multi cluster multicloud environments with ease. But before that, let me just go back to the topic of DevOps. What the current state of DevOps is?

DevOps actually DevOps right now. I, I believe that DevOps as a concept can never die. DevOps as a concept will always exist and mature.

It's, it's similar to suggesting that, you know, say, uh, uh, you know, development in itself might die and yeah, might take over. It's, it's, it's similar to saying that, you know, Python or go might become, uh, redundant and some new coding language can take over. I believe that, uh, DevOps in itself has evolved and platform engineering has become the subset of DevOps today.

That's how I, I look at it, and I believe the, and large enterprises will still focus on the DevOps side of it, because if you have not improved your DevOps, then how can you even look at implementing platform engineering as a concept or platform engineering in your different teams? Because, you know, there are different teams. They want to have a standard approach.

And if you're not following the right DevOps practices, or if you're not following the right DevOps mindset, then reaching the platform engineering maturity is, is, is impossible. In, in my, in my opinion, I, and I believe the viewers will watch this, uh, presentation, uh, on, on 30th, they'll, they, they agree that, you know, maturing your DevOps practices can help you mature your platform engineering goals in itself. And DevOps challenges are driving platform engineering.

What went wrong with DevOps that, uh, you know, platform engineering came in as, as a niche or as a concept. I mean, before DevOps, you were, uh, developers were writing code, there were unit testing, but after DevOps came in, they had to write code, they had to build their pipelines, they had to write code for their builds, and then they had to write codes for monitoring metricses. And then came the unit testing side of things.

And as I spoke about, developers don't want to learn about FRA and new tooling. There's a slow developer onboarding and cognitive overload and developer burnout has actually hindered developer growth. Or you can say the amount of input of productivity that developers can come in with.

And that is where we, uh, you know, consider platform engineering from a cost perspective, from a reliability perspective, there are so many outages, kiosk engineering, incident management, reliability engineering, uh, you know, uh, debugging, uh, integration testing has improved so much. So, you know, to, to address these critical outages incidents, to find out what's going wrong, to ensure that your systems are consistent. And even if you are, uh, you, you are making changes or, you know, you're adding features to our systems, because the infrastructures are so dynamic and in, in nature, there's a shift left, uh, resiliency or development happening.

We need to ensure that, you know, if your production releases are happening frequently, say in a month, you're accelerating your cloud native journey, adding tooling, you have to consider the platform engineering approach where you're standardizing the approach and you're ensuring that, you know, you are shipping code in terms of a platform or an internal developer portal, IDP as, as the world popularly knows, but there's a dark side to the rail. There's a dark side to platform engineering. Even if the idea of platform engineering is to focusing on self-service, internal platform, streamlining, software delivery, platform engineering has not been, you know, subdued or, or performed in the right way.

The, the platforms that we are trying to build today, uh, they, they are overly complex in nature. Uh, they are, I mean, teams are platform engineers as the personas, but they have not reached the right approach to it. And I'll, I'll cover some dark side why we, instead of building the right golden parts or the right, uh, uh, platforms, we have, you know, created spaghettis.

If, if you say, so how, how I've defined the talk or why is it all over the place? The first point, of course, uh, too many stormtroopers overly complex platforms, uh, there's lack of focus on the core needs. You have to begin by addressing the most pressing challenges faced by the developers.

You have to add features iteratively rather than, you know, adding all of the features together. There has to be a minimal viable product mindset. You have to prioritize features based on real world requirements.

There has to be regular, uh, reviews, periodically assessing what's going wrong, why the platforms, uh, uh, i, I, uh, are having redundant features, or is there a complexity issue that you're facing with your platform building in itself, uh, there's a lack of developer adoption, uh, develop. Even the most well built platforms become ine ineffective because developers are hesitant. You need to have a user centric design build platforms with developers, uh, in mind, focusing on their us, uh, usability, their iit.

It should have an intuitive interface, need to demonstrate value. Show developers how the platform reduces the cognitive overload and enhances their productivity. You need to constantly support them, uh, offer, uh, robust documentation, have an accessible support system, uh, ensure that the developer onboarding is easy.

And, you know, developers are able to adopt it in a, in a structured way. I believe platform engineering is missing the real goal. Many organizations jump into platforms as I spoke about, but they don't have a purpose in place.

So I believe education and training, conducting the right workshops, uh, sessions, familiarizing them with the platforms and incremental rollout as you, as i, as you say, gradually, uh, changing the engineering practices or moving from the old school software delivery model, having the right feedback loops in place, actively, uh, solicit and act on feedback from users, which is your dev developers. I'll, I'll talk about platform democracy and idea or concept I really believe in. But yeah, uh, you need to find out the real goal.

What is the real evil, if I have to say? So, uh, you, you, the idea of trying to integrate legacy architecture organizations with leg legacy systems want to integrate it to modern platform practices. And that is not how it's, it's supposed to be approached.

You need to have a modular design where, you know, you need to ensure that your legacy systems are able to interact in the right way with your platforms. They have to be, uh, there has to be gradual modernization rather than immediate, uh, modernization or, you know, just pumping in the resources or the funds and ensuring that, uh, you know, your platforms are compatible in nature. And then you have to use your middleware, right?

You need to ensure that you're bridging the gap from your older tech to your modern platforms. There is a Kubernetes sprawl, as I spoke about CNCF landscape is growing like a baan tree. Uh, there are roots and branches that, uh, people or developers cannot access so easily.

You need to standardize your tooling, have a curated list of tools that your organization or your, uh, platform needs. You need to assess the ROI, what's, uh, the return to investment on the effectiveness and the tooling that you're using. And then you have to have a consolidated effort where you know, your developers, your stakeholders, your decision makers, your customers in itself are, are able to, uh, you know, have a consolidated effort towards, uh, your platform goals.

Security is the important, uh, open SSF has been doing, uh, commendable job. Uh, there's, uh, you know, you, your centralized, uh, platforms become threats to, uh, any sort of security issues. You need to ensure that there's a security by design principle that you're following, where it's not just about the platforms design, but you have the right r back controls the right encryptions.

There's regular auditing in place, and of course, you have to educate your teams in terms of security and how you can minimize the human aspect to it as well. Tele isn't easy. I mean, scalability and performance bottlenecks are there.

You need to ensure that you're planning for scale load testing. Again, conduct regular performance and operation testing, identify and address the bottleneck. And then of course, dynamic scaling.

You need to implement auto-scaling mechanisms to handle the variable workloads effectively and efficiently. Uh, I think this is the second last point that I have. Cost optimization is missing.

Uh, we often see that people have built platforms approached software delivery in a certain way, but there's no proactive cost optimization. Cloud costs, uh, resources or resource optimization, or there are other tools. I mean, open cost cube cost out there that you need to ensure that you are having the right, right resource utilization and you are able to improve your overall efficiency by, uh, and at, at the same time, you're reducing your resources and your high operational costs.

And lastly, of course, observability. Uh, without proper monitoring, metrices logging, uh, you cannot have a platform. I believe that you cannot identify how your platform is performing if you don't have the right observability in place.

You need to define your metrices. You need to define the right SLOs, SLIs your Ts, uh, how your system is, uh, behaving, say in a steady state, or when a new tooling or dynamic scaling happens, how your systems behave. And you have to have automated alerts in place to find out the critical events.

The, the scenarios in itself with this, I have, I believe I have covered some main platform challenges, but one platform challenge that I believe needs to be addressed at a higher level is platform engineering needs to be democratic. Platform engineering has evolved through multiple stages from, you know, a rigid separation between development and operation teams to the emergence of DevOps to eventually centralized platform teams. I believe to address this, there has to be a platform group where multiple teams on different focus areas have to come together.

It can be the producers or the consumers. So the idea is to make platforms democratic, you need to redefine your roles. Producers are no longer the only platform teams.

They include your internal teams, your executives, your compliance folks, and then your, uh, eventual customers as well who are eventually consuming. These platforms have to become a pla part of your platform group to ensure that your platforms are safer, faster, and obviously are enabling the developer self-service as the idea of a developer self-service as the eventual goal. And as I spoke about platform needs, platform engineering needs multi cluster configurations.

While you are creating your IDP, you need to ensure that you're able to manage your multi cluster configurations. They are AI ml, uh, you know, there, there's an AI ML workload side of it, or, uh, your, the platforms are moving towards an AI ops, ML ops approach. There's hybrid multi-cloud environments.

We have spoken about, uh, it, most enterprises are deploying, uh, hybrid environments. You have your Edge IOT environments, which are, which have to be highly available, uh, in nature. There are multi-tenant teams.

There. You have to maintain isolation between different teams. And obviously there are country specific data, so in laws as well, where, which you have to comply while building your platforms.

And the major challenge of building these multi cluster platforms is that, uh, the, the ideal goal or ideal scenario is single application per cluster, or having multiple, uh, alpha providers ensuring that your dynamic on demand clusters are placed in the right way, but it serves a lot of challenges. Your workloads are inconsistent. There are no right policies in place.

Operational, uh, goals are not met. It becomes complex. And then there's a tooling sprawl or Kubernetes sprawl as I spoke about.

And that is where you need the right manager or the right, uh, tool to ensure that you're able to manage your, uh, uh, golden parts. Well, there's no Kubernetes sprawl. Uh, you know, your beachhead services are not being managed well or your services while you are managing these multi cluster environments.

Even if you're using Kubernetes as your scheduler, you need to ensure that you are doing it right, because I have seen Kubernetes being used in mainframe IBM mainframes as well. And this is how I have envisioned the platforms of today. This is a simple example.

I have taken, I have worked, uh, uh, with, uh, antes today on platform engineering, where back when I was at harness, you were doing a lot of software delivery. So I believe that, you know, you need to ensure that there's the right IDP framework in place for your smooth developer onboarding there. Security tooling.

I've taken an example of Paco, that it has to be in place to ensure that you're orchestrating, uh, your security, or you have the software supply chain assurance, the CICD, of course, that's the foundation of your platform to ensure that you're delivering your softwares faster. You have the GitHubs in place, getting in the pipelines in place. Then comes your resilience engineering, which is your service reliability management, your kiosk engineering, error tracking, incident management, and eventually your, you know, optimizing your cost and your process, which is your cloud cost management, your software delivery, uh, software engineering insights that I believe completes the structure of your platform and builds the right foundation.

And this is how I have layered it into different steps or different, uh, processes, frameworks. And I, I hope that, you know, eventually folks will watch this talk or will build their platforms tomorrow, will follow the sort of, follow these, these steps that have these, uh, different modules in, in their platform in itself. One last point before ETH takes over and talks a lot about multi cluster platform engineering and tooling, infrastructure has coded, I believe Terraform, uh, brought in the boom in terms of bringing, bringing the platform mindset.

But, uh, there's a core role that infrastructure as code has played, uh, in terms of platform engineering. It has enabled platform standardization and reusability. Uh, the, the idea of platform engineering, uh, is obviously to build the right IDPs and IAC helps encode these platforms as reusable or composable components.

Uh, you, you, you are able to drive, uh, uh, you know, uh, uh, environmental, uh, I mean, it, it, it allows you to have the right environment to be replicated. Uh, if, if it's working on your machine and you have to work, uh, you have to ensure that you are, uh, using it in a different dev environment or a staging environment or a broad environment. You need, you have to have the automation and the consistency in place so that even if there are rollbacks or, or there's a, there's a disaster, uh, recovery mechanism that has to kick in it, it becomes simpler.

And then obviously, last couple of points I'll co cover quickly. In the interest of time, you have to have the foundations of self, uh, developer, self-service or self-service portals. You are templating the, the infrastructure as code templating has to be, you know, say a catalog based, uh, so that you can provision it in, say your, uh, you know, your in IDP framework, say a backstage or a human tech or a port, and then obviously supporting, uh, the, the GitHubs and DevSecOps practices, you need to ensure that they, they are following the right security and compliance practices.

There's a vault secrets management in place. There's a workflow, uh, workflow orchestrations, say using Argo CD or Flux. And then, uh, developer experience tools and, uh, your dmls are, are in place perfectly with this.

I'll allow Barat to take over to talk about a little bit about multi cluster platform engineering and what we have. So barat, uh, you can, you can take it from here. Alright, folks, so problems, problems, problems, right?

Uh, we heard a lot of problems, uh, a lot of challenges and as we like to call it in corporates, let's not call it a problem. Let's call it an opportunity. Yeah.

So in terms of the challenges that we spoke about and the opportunities to fix the multi cluster, multi-cloud problem, we have a bunch of them. Um, the previous slide talked about IAC, um, that's, that's one of the most common ones that's been currently used, but of course, IAC brings in a lot of dependencies with itself, right? So if you talk about this structural, um, step-by-step kind of thing that we can see how we can solve it, there's the DIY open source solution where IC also fits into this category, right?

But then of course, you have to handle all of this on your own. Um, it, it brings in a lot of operational burden and the expertise dependency on those particular tools. And then there are proprietary solutions, which are great, of course.

Um, but the biggest challenge with that is if not today, if not tomorrow, eventually one day we're gonna run into the vendor lock in problem. Um, we've seen this a lot happen lately, but one of the things that everybody will instantly recognize is of course, um, VMware, right? With the whole Broadcom situation, people felt boxed in, locked into that particular platform, and they want to get out.

So this will always almost happen. With that in mind, we wanna talk about an enterprise grade open source solution, which honestly has been, um, the business model of many good open source companies like Red Hat and, and, and others, right? So here in the IDP solution that was mentioning earlier, the bottommost layer remains the infrastructure.

It could be your clouds, it could be your on-prem, it could be public or private clouds. And then the topmost layer is your application delivery, where your end user applications rely on, right? I wanna talk about the middle layer, which we are trying to like focus on, which could be the platform orchestrator, right?

So we need a mechanism to figure out how do I provision, um, Kubernetes clusters and across clouds consistently, and then how do I also ensure that the D two operations are going as per the plan as well? That's the layer we're gonna focus on. So this is where we wanna focus on this open source project called as ent, where we have a platform engineering solution in, in like, you know, three segments, let's say cluster management, state management, and then observability.

So observability and finops, I'm, I'm just gonna group them, and that's probably the most straightforward one to talk about, where observability is just having eyes and years on what's going on with their platform, right? It could be logging, it could be metrics, it could be costs and so on. Then the left side of, uh, the screen, the cluster management and state management are the mirror images of, of, um, day zero and day two operations.

While cluster management helps define your infrastructure configuration, state management helps define your services configuration. I'm gonna be showing a live example, uh, soon. But essentially that's, that's the key thing that I wanna convey.

Cluster cluster management is infrastructure and state management is services. So if you look at the generations or, or the transition of how things, um, have, you know, gone ahead, right from 2014, which is like early days of Kubernetes, all the way to let's say 20, 23, 24, is that there's been early adopters, and then there's, um, OpenShift, which is a very opinionated, opinionated way of Kubernetes and of course, um, on the great vendor solutions. And then as we progress, we can see that there's a good, um, community driven solutions right now where Kubernetes has been the fabric that is orchestrating all the major workloads.

And in order to develop this, we have platforms, right, which is cord. So here's where we encapsulate like sort of all the open source components that, uh, are used in cord. Uh, like I said, the whole thing is driven by existing open source projects.

Cluster management is taken care primarily by cluster API and all the other cloud providers like capo for OpenStack, Kappa for AWS Capsi for Azure and so on, right? And then there's the K zero s and Cosmo tron, which is the Kubernetes distro K zero s, that's, that's what, uh, is underneath. And the control plane manager, which is Cosmo tron, and similarly in state management or service orchestration, asto is in flux.

And then in the observability side of things, we have a whole bunch of other, um, you know, open source solutions. So this slide basically shows, uh, another layer of IDP and how we basically have it if we are doing completely DIY kind of solution, right? So in terms of observability, we have like cube cost, Grafana, Prothe and all that.

And then kinu, and then, you know, RabbitMQ and all these bunch of services. And if we go to the next slide, we can see how all these complexities are simplified into the three layers that we're talking about, where it's all encapsulated for you and delivered to you as a single platform cataloged. io is like a sim like an analogy for, for us to understand this is mobile apps have play store and service templates has catalog.

That's it. Any application that you wanna deploy, um, for example, Argo cd, right? Which is one of the common things we use for our cv.

So it's available as a service template, and all you need to do is do a helmet install and then specify which particular chart you wanna deploy it. That's it, it's as simple as that. Here we have like multiple applications, right?

And all of these are, you know, um, tested and, and, uh, they have gone through like E two E tests and manual testing, and then they're uploaded onto catalog. But in case you have an application that is not intended to be public, we can still use your own application and just make sure that we specify the proper OCI parts of the chart. So what I mean to say is, even if the application is not public, you can still upload it to your own catalog, uh, as a helm chart and then specify that during the installation that is supported as well.

I wanna show a live example of how we use Cord in order to provision a Kubernetes cluster on OpenStack. So I've chosen OpenStack to be an example for this demo. What we can simulate the same thing across multiple clouds as well.

So first let me show, um, like, let, let me set up a bit of context. Currently we are on a kind cluster, which we will use as a management cluster, and this cluster will be the base in order to manage hundreds of clusters. Then we've got our cluster templates, right?

As you can see, these are cluster templates and you can see that each one exists for a particular variant of a particular cloud. And today we are gonna be using the OpenStack standalone control plane template, right? And then similarly, the equivalent of this, we have service templates.

So for the example that I'm gonna show, I just used a Nvidia GPO operator, right? So service templates can be installed onto your cluster just like, uh, what I showed earlier using helm upgrade, install, and specifying chart. For now on my cluster, I just had these two and I'm gonna be using this one.

And then finally, let's take a look at the cluster deployment that defines this configuration, which is what I mentioned as a single YAML file to define both the infrastructure specific configuration as well as the services configuration. So your cluster deployment references the template which you want to use based on the cluster, um, based on the cloud, it references the credential, which I just, um, applied before this. And then this is typical infrastructure configuration changes from cloud to cloud.

And over here I'm using T 2 45, which is a flavor of, um, I mean, which is a GPU flavored instance, right? But for the control plane, I'll be using a normal CPU only instance. And then services I just mentioned, what kind of services I wanna be, I want installed on this cluster.

So for now, I mentioned the GP operator and that's it. So in the interest of time, I had already applied this cluster deployment just before the talk and cord controller takes this configuration, reads the Infras spec stuff, understands the template, uses the credential, and uses, you know, the rest of the infrastructure configuration and actually deploys a cluster on OpenStack. Once the cluster is deployed, then it would also figure out the service spec and it would deploy the particular service on that cluster.

So let's check out, so this one, I've already checked out the particular cluster and if I do a configure view, as you can see, this is the one which we have provisioned, right? And then the service configuration, um, just to, just to let you know, since we chose the Nvidia GPU operator, IT has installed that and then the operator has, has done whatever job it has to do, right? Which is to let the cluster know that this is a GPU enabled cluster.

And how do we confirm that this is working by describing the note, right? Let's describe the worker node. There you go.

com/gpu and here we go. So essentially the Nvidia GP operator told our Kubernetes cluster that this particular instance as a work note, um, which is G-P-U-G-P-U enabled and added this label so that the workloads can utilize this particular Label. And yeah, that's it, right?

So in case you want to, um, scale this, all you would need to do is add more services onto the single ya. So we can easily imagine putting this particular AML file into a GitHubs enabled repository, and your platform engineers would just need to work with this AML file, update a version, let's say for example, or add more services like Istio in case that's a service that we are interested in and according to do the job of picking up that configuration and coming back here and applying that on the child cluster. I think with that just, uh, pr I'm gonna pass it over to you so that you can just, um, finish with the community stuff Folks who are watching this talk.

You can scan this QR to access the cordon GitHub. Uh, feel free to check it out. Feel free to check out the components.

There are different repos, the KCM, the KSM, the C and other repos that give you access to everything about Cordon. This is the main repo. And if you're on the CNCF Slack, uh, you can join the cordon channel or scan this QR to join the CNC of Slack and then join the Cordon channel to be a part of the community.

Once again, thank you so much everyone, and thank you so much, uh, uh, Brian and folks at Techstrong for, uh, helping record this. And yeah, I hope you'll love this talk and join Cordon, uh, and the card community.