Techstrong TV Aug 5, 2025

Hey everyone. Are we suffering from a lack of confidence in it? Resiliency?

You're watching Text Drunk Gang. Hey, happy Tuesday to you everyone. It's Alan Hummel for Textron Gang.

You know, through the magic of the internet, you're watching this, but I'll be, I should read the term you're watching this, there's a good chance I'll already be in Las Vegas for summer camp for Hackers with a all, a lot of my security friends for this week. But, uh, I've recorded this in studio before we left and we've got a great Tuesday line up here for our text on gang. Let me introduce you to our gang members, uh, joining us, looking very dapper today.

I might add JP Morgan fall. Mitch Ashley, Mike Ard, returning from his hiatus. He thought he was gonna be the next Yankees bull pin pitcher they were picking up, but no, no joy in Mudville.

And then joining us from the Land of Oz, where it's an ungodly hour where we're recording Alistair Cook. Hey Alistair, welcome and thanks for joining us. Thanks, Alan.

It's always a pleasure to be on the show with you. Beautiful. Alright, so Mike, let me kick things over to you on this beautiful Tuesday.

Uh, we're gonna start off with a, a report that, uh, we're not as confident in our resiliency in the I and it's not just security. Mind you, this is it, operational resiliency. Well, and there is this new report from SolarWinds on that very topic.

And it's interesting, at least from my perspective, we have a consumer confidence index all the time that we survey people with, but there should be something that's the equivalent of that for it. And it looks like SolarWinds went out to try to accomplish that. And on the one hand, most it people I know or confident in their own abilities, they have a certain amount of, uh, pride of ownership and pride of work.

So they are always gonna say that they are somewhat confident. But when you poke at it a little bit deeper, it does seem like, well, there are issues with inefficient workflows, not enough staffing. Maybe I don't have the right tools.

Maybe I don't understand this AI stuff, and everything's changing faster than I'd like to admit. Mitch, what's your take on what's going on here? Is it the best of times or the worst of times?

Or is this the way times always are? Well, I don't, I think we might have a new crop of therapists that it, people are talking with, and that's where we gathered this data because that's kinda what the report basically held out is, what are the issues? And I think, yeah, it's, it's staffing and skills and things like that.

But I think, I think underlying all of this is the theme of we have to do more. We're at more is expected of us. We don't necessarily know about the new stuff that's being thrown at us and it's being thrown at us at a much faster rate.

I think it's that pace of change and how much they're dealing with. And meanwhile, you know, some punt is telling you they're not gonna have a job 'cause of ai. So they're kinda like, what am I supposed to do here?

So I think there's, there's a lot of things that can be addressed. And I don't think there was anything new. It wasn't like, oh, that's a big surprise that the workflows are inefficient.

Okay, great. Do you address that now or do you work on AI and maybe use AI to make that better down the road? Do you work on improving security or do you, uh, go work on your security skills?

Maybe you do bo both. So, I, I, it wasn't earth shattering. I think it was more an amalgamation of a lot of issues, but underlying it, just trying to deal with it all.

So I I maybe I, it was just the way it was phrased, but early on article, I think it's the first sentence. It talks about it, people referring to themselves as resilient. And the only thing that comes to mind in my mind is does that mean that you recover well from trivia night after team goes out and plays?

I mean, what does it mean you are resilient? Um, your operations should be resilient. And uh, and the issue is, if that was the case, why do we, you know, have such, uh, an initiative to chase after DevOps?

And the whole fact that none of this addresses DevSecOps is bewildering to me because that's where you get resiliency from. It's where you find your, your, you know, your lean processes. It's where you identify your automation.

And none of that's mentioned here. So I, I don't exactly understand what SolarWinds is trying to say here. Kinda ironic, the survey also said 13%, um, said that they, that they lack the right tools.

Well, that's kind of counter counter to what, what SolarWinds might want 'em to say. Anyway, I stepped on you, Alan, jump in or, or Alice or whoever. No, no, no.

I think that's fair. Mike, jump in. I'm gonna say something.

Well, I'll leave them. Well, I, I, I was just gonna point out that, you know, most it people I know are kind of like Timex, right? They take a lick at and keep on ticking and that's all they're kind of like trying to answer here at the, at the end of it.

But I do believe that, you know, this is a survey of traditional ITSM people who probably don't have a whole lot of DevOps experience and maybe not enough of those folks who are in the survey base because that's not where solo winds normally plays. But, um, it's clear to me that there is a lot of reliance on manual processes. People are somewhat, you know, still doing the same thing the same way they've always done it.

'cause that's the only way they know. And I think that continuing to do things the way you know how to do them does lead to the, the feeling that we don't know how to deal with these newer things. And so I think there's a, a definite crossover to jps point that this doesn't address DevOps, DevSecOps types methodologies.

But there is a huge s SWAT of enterprise IT that isn't DevSecOps. Uh, but simply because the transition from those years and years of legacy is so hard, yet most of those are surrounded by little bits of innovation that bolt around the sort of sea anchor applications that don't change fast. And it's these elements that I think are terrifying for the engineers who've grown up with much slower moving things and take away their competence.

They can recover. You Know, Alan, I held a lot of compassion for these folks too because operations, IT operations in particular and SecOps too. They're the scotties of engineering.

And you know, Kirk's hollering down, I need war drive in 60 seconds. We're all dead, right? Everything is an emer emergency and it's gotta be addressed this second.

That's resiliency. Well, look, I think these numbers are all made up. This was done just to embarrass me and I wanna fire the person who did the survey.

'cause that's what we do in America. But that being, that being said, that being said, I'm struggling to keep my arms down. But that being said, I think the issue here is goes to what you said JP, about people thinking themselves as resilient versus operationally resilient.

Well, but I think when you're an IT person like this, your resiliency is your ability to keep operation and going, right? And so they, they, I forgot the word, but you know, they, they put themselves in that. That's what if operationally they're resilient.

They're resilient. I think what this really comes to though, you know, I read an interesting article, I think it was in the times this morning about the changing work culture in tech, right? People used to want to flock to work to tech, work in tech, whether it was Silicon Valley startup, chase the dream of stock options or just being an ITSM tech worker who makes, who makes the internet work and, and makes all, you know, is on the cutting edge of technology and all the cool stuff.

The fact of the matter is, even though we have AI and we have all these great things going on around us, being the tech worker these days isn't a lot of fun. It's not, we're under increasing pressure to do more with less. We're all faced with layoffs, right?

We're being told that job may or may not be around in the next three years because it's going to be replaced. And they want you to put on a happy face, smile and say how resilient we are. And that s**t don't fly.

It's not gonna fly for very long. And I think we're starting to see it now in, in surveys like this, where it's not just the security curmudgeons who are always unhappy. It's, it's the it people who used to are the bread and butter, the backbone of what makes the digital world will go starting to really feel the pressure that, you know what, this ain't fun no more.

And it's, I'm sad to say that, but I, I think we have to confront ourselves with that may very well be a new reality. I'll, I'll leave it right there. I'm hopeful it might get better if, you know, these AI agents live up to their promise and the job itself could become a little more interesting and maybe things are a little more automated.

And so maybe, you know, there's hope on the horizon. I mean, I get that AI is also somewhat of a threat, but it seems to me there's still a lot more companies out there that don't have good IT talent. And so we'll just distribute it more widely.

And this AI stuff may at the end of the day be a boom. I can argue, You know, I I I put an article up on Techstrong ai. I saw in interview Mark Benioff of Salesforce saying he's spoken to a lot of CEOs and he challenges them into show me jobs that were actually replaced by ai.

By the same token, he's laid off what, 7% of his workforce and says 50% of what they do. Seems to me, mark Benioff speaks with fork tongue there. Um, we, what are we, are we replacing people or are we augmenting people?

So I've been used doing this, you know, a lot actually working project right now very deeply leveraging ai. And you know, it, it, it's an augmented tool. It really, I, I see it as for, you know, I'm doing a coding problem, right?

And, uh, and challenge. And so my, I see programming changing for me from actually having to write in the language to describe what I want the AI to do and the AI actually doing the coding. So I view it as a form of programming.

It, it, it is that level and it is the same thing. The it people have the opportunity too, right? It's, instead of spending hours combing through logs and files looking for issues, right?

With regard to a, you know, a root cause analysis and, and tools like SolarWinds and things like that, you know, they're supposed to do a lot of the pre-processor work and hand you, you know, an answer. We know they don't. We know that that's the start, not the end, right?

So do, if these people learn how to use these tools, they have the opportunity to then, you know, ask questions, right? Load up this data into the, and then ask the questions in a, in a, an inquisitive way to get to the answer instead of themselves having to chunk through the editors and look at all the, on the individual line items. And it makes the experience a better experience and it gets them to a faster answer.

Allows, does it make, make it more resilient? Yeah, this makes it more resilient. But I I the opportunity is there for them is what I'm saying.

It's a, you know, it's, it's a matter of learning it to incorporate the tools and, and it should be augmentative, it should not be replaced. I don't, I don't see these agents sitting there going, ah, I got this problem. Don't worry about it.

It's all taken care of already. Agent's gonna say, ah, forget about it. We got, we kinda got it here.

Only, only Mike's agents. Only Mike's because he's from the Bronx. The Bronx.

Well, we talked about this yesterday, Alan, on the show. Um, you know, 'cause I'd written the article about you still have to have engineering chops, right? And, and AI isn't ready to take on that level of the problem.

And we talk about augmenting a ai, augmenting a our work a lot. And when you dig down, I'm guessing probably what you're experiencing and what you're doing is you're directing jt, you're telling it what you wanna do. You're telling it what it's not doing.

You're telling it, wanna do differently, do things differently. And prompt is the new code, prompt. All of that input.

And that process is kinda like you're in real time writing a requirement is design document and building it all at the same time. And that's, that's how it's changing the work. Now, I've talked a lot about the landing zone for AI and tech is software, software development.

That's where we see the greatest application of it and the most impact. And it's starting to trickle into just a little bit of DevOps and testing. We'll see more in ops.

You know, for example, you know, Kubernetes, we've, we've seen an observability move into Kubernetes. We'll see AI move into Kubernetes increasingly too, to help it. It's not gonna take it over and do it all for us.

But that's gotta take on some of the complexity of those tasks for us. I know I've, I've been, I've been away for a week and I've had a time to think about this a little bit. And you know, we have all, we're big fans of it, right?

And we all love tech, but let's be honest, most of this stuff is overly complex and doesn't live up to the promise. And it's been great in the sense that it's job security for it people. But, you know, working with this stuff on a day-to-day basis kind of sucks.

And maybe AI is gonna put a little pig on the lipstick or, or a little lipstick on the pig, sorry. But at the end of the day, um, a lot of the promises that have been made it people about all these IT platforms just didn't meet the grade. And so stuff is hard to deal with.

Nothing's integrated and it's stressful. You Know, Mike, Mike, the days are long, but the years are short. And, and you know, you, you might be looking among the trees and not seeing the forest.

Let me see what other analogies I could come up with. But I think my flights have been delayed on his trip. Well, I, but here's, but here's the deal.

When you look across time, look across 25 years, look across 35 years, look across from the advent of the, of the commercial internet till today and how it has changed, not just the it workers' life, but how it's changed life on this planet. It's remarkable. And yes, the, the, the day to day, the inch by inch is tedious, sometimes discouraging.

But when you look at the breath of, of, of accomplishment and how it changes how we live, it's, it's revolutionary. Now, I, that being said, I go back to what I said in the beginning of this segment. Tech workers did tech because they had in their own way an opportunity to change the world.

It was a great professional work. And even if the day to day was somewhat tedious, even if, you know, building resiliency was more smoke and mirrors than, than true re re resiliency. When you stripped that facade off though, and just focus on the day to day and, and take away some of the carrots, good pay, great working conditions, job security, doing exciting things, then yeah, it becomes a real job.

Right? And that's, that's not fun. Anyway, we're over time.

Let, let's, let's take a break on Techstrong gang. We're gonna come back here and talk about, uh, it un it Unified. Well, we're gonna talk about a recent Broadcom Tech Field Day Techstrong event.

You're watching Techstrong Gang Discover Techron Group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us.

You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients. Let's revolutionize your tech journey.

Contact us today and tell your story to the world in the most powerful way with Textron Group. 0 that Alistair was one of the lead players on. And it relates to our previous topic in my mind, because it really is about trying to make the IT experience may be better and some folks are at least making an attempt at it.

But I don't know, it seems like there's a lot of parts in this thing too. So, Alistair, how do, what's the balance here? What's your take on what's going on and, and bring us up to speed on the event?

Well, Mike, the, the event was the first real deep collaboration that we've had for a live event between Tech Field Day and Techstrong Group. Our Tech Strongs our, our favorite part outside of Tech Field Day, our favorite part of Futurum Group. And we love working with you guys on lots of projects.

Uh, this particular one happened last week. We, uh, streamed out a series of presentations from a series of technical experts at the, uh, at Broadcom, uh, VMware by Broadcom, uh, starting of course with, uh, Sabina Anja, who was a guest here on the Techstrong group a couple of weeks ago was, uh, prelude to our live event. Uh, during the live event or during the, the Stream.

We, we also had a bunch of the Tech Field Day delegates. And that's one of the things that makes Tech Field Day absolutely unique. And as an event, is that we invite in a bunch of independent technical experts who have their own opinions and, and things to share.

People will be great guests here on the Textron gang as well. Uh, and we have them interact with the presenters. So throughout the stream, you saw that, um, my, my delegates were asking the presenters questions to get to a little more of the truth of what's happening in the real world and how the, these things are being used.

And those same delegates also write about their thoughts, their opinions of, uh, what was being shown. So these are, this was great to do this with, uh, tech Strong. And as we speak, this will be being live streamed on the, uh, tech field day LinkedIn.

So if you missed any of the, the live event last week, we've got a a refresh stream now. But don't step away from this. Watch the rest of the text on you.

Uh, I did wanna highlight and, and pull Mitch in here because he's been one of my delegates at events and we will be a delegate at future events. And I wanted to pull in his opinion of how that, that sort of feeling of having this group of technical experts in the room with the presenters makes for a different kind of experience to a lot of the, the webinars and the, uh, presentations you see from vendors. Yeah, I, I liken it too.

And I congratulations on a great event. I think the format, uh, that we, we did together was fantastic. I liken it to didn't, don't you wish you were in one of those meetings that, uh, you didn't get invited to, or you'd just like to be a fly on the wall and kind of hear about the questions that were being asked?

'cause some of 'em I would've thought of, and a lot of 'em I wouldn't have thought to ask, but that's a great question. Um, and, and there aren't gotcha questions. It's not like we're, you know, trying to make anybody look bad.

It's like different perspectives. And that's one of the things about the, the delegates is they're not all, you know, copies of one kind of person and what kind of role or kind of whatever. They come from a heavy networking, heavy operations, heavy development, heavy ai, whatever it might be, type of background.

So they've got different perspectives. 0 of VMware. It's the next era of VMware moving it into the self-service model, which I wish I would've had when, when I was running it about a little more than a decade ago.

Um, you know, 'cause I was looking for something like that. And, and, uh, we hadn't gotten there yet. So it was a really good time to have that kind of a deep dive in several different areas.

And it wasn't just about that, but I think hearing from the experts, both the delegates and the presenters gives you a better rounded perspective as opposed to just going to a conference and hearing one person speak about it. What is the level of self-service there? 'cause sometimes I feel like, you know, it's self-service in the Henry Ford way, right?

As long as the car is black and, you know, cost this much, you can have it. So what are we actually giving to folks is self-service and how much flexibility is there in that model? Well, what I saw in the new release of, uh, VMware Cloud Foundation nine is that integration into the VCF automation, what used to be called Aria Automation.

And that's got a capability to differentiate this persona of the cloud consumer and give them a catalog of things they can deploy. Now, those things can be pre-built virtual machines. They can be entire Kubernetes cluster.

There are pre-configured services that sit on top of those Kubernetes clusters. And so this feels to me a lot like a tool for building an internal developer platform, uh, where here's the catalog of things that you can deploy and wrapped around that catalog is not just, you can deploy it onto some test environment. It's, there's data operations in here as well.

We can make sure your data is protected. You can make sure that maybe you're running A-C-I-C-D pipeline to populate out all of the executables that are in here, along with maybe it is a test environment and, and there's a lease time for, you're only allowed this amount of resource for a fixed period of time. So there's definitely maturity coming into that portal.

Is it the sort of same sort of scale we see in the major public cloud providers? Absolutely not. There isn't the diversity of services.

There isn't the scale that you see, the elasticity that you see in public cloud platforms. On the other hand, this is inside your own data center. It's on your own hardware and your ability to control all the compliance and all of the, uh, security around this is, is much stronger, uh, at least more ability to directly control what you want.

So yes, it is consumed from a catalog. So it is here, here's the sizes that are available, but hopefully there's more than one engine size and more than one color available. Uh, but it is still on premises resource.

So it is a limited scale, But, but this new version of VMware can be run in a public cloud. It's supported by AWS and Google and Microsoft and, and I, I'll tell you something else, they've, they've borrowed a lot, I guess from Tan Zu, right? To make it much more cloud native Cobe, uh, uh, friendly, usable to me, this release is, is literally a, a Swiss Army knife, right?

It, it, it has something in there no matter how you want to use it, whether it be on-prem, whether it be in a data center or the public cloud, and, and, you know, whether it be cloud native, you know, Kubernetes containerized or not. There's, this is a, a very usable, broadly usable platform now, and, and I kudos to them to, to, for doing it. It's also transition or hybrid environment to Alan, not just on-prem and in the cloud, but it's meant for workloads that are both on traditional VMware hypervisor type of architecture as well.

And that's where the world's hybrid, multi hybrid world hybrid. So Alistair, is it your sense that the mere mortal IT administrator can now manage Kubernetes? Or is this more about just provisioning it, but I still need DevOps engineers to make that puppy run for the long haul.

I, I've always been at the opinion that Kubernetes is an infrastructure tool that the same people who are looking after virtual machines are just delivering now Kubernetes clusters. And that's to a certain extent, what we see here is that the, what was the tanz, Kubernetes grid, whatever the branding was, is now called the VMware Kubernetes Service Inside Cloud Foundation. And yeah, you can deploy yourself with Kubernetes cluster and the worker nodes are easy to deploy, and the updates and changes, those have always been the nightmare of that coordinated update of all of the plugins and components before you can do the, the COBE update itself.

These things are all packaged together in a, uh, more controlled way. And like most Kubernetes platforms, it's a n minus two support within the platform. So there's, uh, you don't have to immediately update, but when the administrator makes it available, you as the owner of the cluster can choose to update.

Does this completely abstract understanding Kubernetes and the, the networking complexity and manage store, uh, storage for it and volumes and all of those, those elements? Absolutely not. Uh, there's, there's still Kubernetes underneath this.

You're still hitting cobe CTL commands here and there. Uh, although there's tools in the actual automation to generate those manifests, those YAML manifests to deploy things for you. So there is some guidance in it, but I think you still need to understand what Kubernetes is as an infrastructure tool to get the best outta that hybrid multi-platform modern applications kind of, uh, milage That we have now.

Fair fair guys. It was a great event. I should mention, it's still available on demand.

com. You could grab it there. Eventually, it will make its way to the, uh, tech Field Day YouTube channel and Techstrong tv.

But right now, it is available on demand. You go check 'em out, all, all the various sessions and so forth. So go do that.

We're gonna take a break here on the Gang, come back and we're gonna talk about, uh, expanding AI agents framework. Shocking. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com. Home of Security Bloggers Network. Hey, folks, we're back.

And we're talking about AI agent frameworks. Once again, it seems like there's a lot of these all of a sudden, and the, we're discussing specifically one that was donated by Cisco to the cloud native, or sorry, in the Linux Foundation. And those folks are gonna add another framework to the ones they already support from Google, which is the A two A protocol, which kind of sits as a compliment to MCP, but, um, I think this one's a little more identity focused, but jp I'd love to get your thoughts here because it's kind of like, on the one hand, I'm like, this is great.

There's another standard that we can use. And then I'm like, oh, no, there's another standard we can use. And is the Linux Foundation thing gonna start to look like the CNCF framework all over again?

And what's going on here? Well, I mean, these things do follow consistent patterns as people are, you know, I I, I liken it to, you know, the, you remember the old Maze games on PCs where you didn't know what was in the room until you went into a, like, into a section and it lit up that section, and then you could see what was in that part of the room. Uh, and that's kind of the way the last five major shifts in technology have operated.

And this is a lot of people, you know, things like this happen, happen in X ml, happened in web services happen in cloud. These standards emerge as people try to make sense of the part of the room that they're in that's lit up. Oh, look, we need one of these.

Oh, look, we need one of these. And obviously different, uh, skills and different focus areas are gonna have different perspectives, right? This one's coming outta Cisco.

So lo and behold, its secure communications is gonna be a core element, um, that they've recognized is lacking, and the ability to have these autonomous agents communicating with one another, right? How do we, how do we ensure that they authorized, you know, that they author, authenticate to each other properly? How do we have a common framework for them to, to exist and not be hacked?

How do we control, uh, the actual communication pathways between them, right? How do we, how do we label them? How do we, uh, you know, name them?

How do we find them when they're existing out the network? And so, uh, you know, at this point in time, right? This is, uh, a group of companies answer that, you know, they've obviously convinced a, uh, good group of core AI leaders that this is a potentially valuable project, right?

You have the likes of Google, Salesforce, Microsoft, Amazon, ServiceNow jumping, adobe jumping on board, right? With, uh, with this release. And so, uh, the clearly the people in those organizations who are, who are associated with, uh, their individual AI efforts and in, in standards efforts, recognize that there's something valuable here.

And so, uh, now the question becomes, well, and this is the more difficult one, is how, as these things start to emerge, how do you incorporate that end, right? Because they, they're leaking out and you're, and you have individuals who are building architecture. They're building agent architectures today.

Okay, great. Uh, the last thing you want is, oh, this new toy came out today. Let me add this, which we have seen, and Lord knows, that's how you end up with a huge amount of your tech debt coming into a new application, right?

Is that the early part of that, of your tech debt? You know, initiative starts with the fact that it was new when you started, and you threw all this stuff as it emerged at the problem domain. Oh, look, here's some observability.

Let's throw that in. Oh, look, here's some communica authentication here. Let's put that in.

And you get to a point where nobody really wants to spend the money to, to say, okay, all the pieces are in place. They, they're pretty solidified. Now, we should probably redo this, right?

And so that is my concern as these things start to leak out, is that they find their way into a project, they become, they're, they get used and, and then they're not refactored in later on. Hopefully, now that it's easier to refactor the code using AI agents, uh, companies will take that opportunity to do that more. But, you know, this is, this is what where we are as an industry and, you know, agency has as much of a chance of being a home run as it does a foul ball.

Mitch. I mean, I looked at this stuff and I, and, and clearly there's a need for agency, but I also scratched my head and I was like, well, shouldn't this just be part of a two A in the first place? And we should just take these capabilities and it should be one project, and I'm not clear we need a whole other project around this thing.

Or is this just like the, the next natural evolution of A two A? I don't know, but I'm a simple guy. Well, one of the benefits of being part of Linux Foundation, or one of its, you know, subs, if foundations, if you will, is we may see something like open Telemetry merging with open, um, uh, tracing may, maybe they do come together at some point, but it's early enough along.

I don't think you want big, big standard even open standards efforts because they'll get bogged down. They'll, they'll kill it by the weight of itself if it isn't quite this cleanly. But if you look at who started it, it makes sense why they started it, right?

MCP got started by by Anthropic, and it was all about giving their models and other models access to data and, and systems outside of the model. When you look at A two A, that was created, initiated by Google, that's about agents talking to themselves, collaborating, communicating. So kind of another layer down in the stack, if you want to think of it that way.

Guess what? Talk, speaking of stacks, this one's by Cisco. So guess what it has, it relies on agent communication protocol, which is another new emergent standard.

Um, it has identity management. It, it adopts, um, an OSAF framework, uh, open a, I'm sorry, o Open Agent Schema framework, uh, open a OAS. It's, it's too early in the morning.

I can't say it anyway, it, it's, it's adopts yet another standard that I can't spit out all at once in one sentence without taking a breath. So it, it's, it's another layer. It's a kind of at, at a deep, more deeper layer in the stack.

And we're gonna see more of this more thing there. There's open, there's agent DNS, there are other things that are in the pipeline that I think will, will, might not only see emerge and become adopted, but they'll also start to combine where it makes sense. But for now, I think we need it fragmented.

You know what it, you know, if you look at the pattern, especially around distributed computing in the last four major, uh, you know, e evolutions of key technologies in this space, they're just recreating the operating system At some level. So does this happen like, you know, naturally over time, or are there like, you know, a bunch of folks in a smoke bill room making trades, or how's this? No.

Yeah, I, so I, you know, that's, that's a jade, you know, this isn't politics, Mike, or how our government runs, right? I, I, I think, I think what we have going on here is more, this is like a ca Cambrian explosion of life forms, right? This is Darwinism technical.

Darwinism, let's, I, I coined that phrase. Give me credit for that. This is technical Darwinism at work, you're gonna see a lot of these frameworks competing, cooperating, cooperation, vying for air and space in this crowded market.

And, you know, for those of us who still be still believe in a market system, the best will rise to the top and, and become dominant. And those that don't fall by the wayside, that's the way it should work. Now, you know, you could take the Mark Andreessen approach, which says, if I put a hundred million dollars into this one, even though it may not be the best, it'll have enough resources, you know, it'll, it'll windows the OS two, so to speak, right?

We'll do better marketing and everything else. And it may not be as good in os as OS two was, but the world will focus on Windows. We might see that here because, uh, projects that are given to the Linux Foundation, the CNCF might have a leg up on projects that aren't part of a foundation that have a single big brother sponsor.

But it's Darwin is its technical technological Darwinism, and, and hopefully the best succeed. It's almost like the formation of the universe, the big bang, right? At this many fractions of a fraction of a fraction.

These elements were formed, right? As it progresses and, and grows. And I think it's just, it's, it's just emblematic of no one do, no one is dominating in this industry, right?

There isn't a dominant player yet, whether it's in the L LMS or the nature, there will be, right? But because there isn't everybody's contributing through open standards, instead of saying, my proprietary API and my pro tri proprietary framework, we'll see those things come along. But by the way, what not the open part is happening on the, on these kinds of standards.

Where it's not happening yet is on the data side as why i's stumbling through, through that acronym. But at the same time, we see these open standards. Some vendors are starting to lock down their data so that other people's models can't get access to your data in their SaaS service, whatever it might be that we've gotta stop that we've got, because that's my data.

I mean, it's no, no more frustrating. I won't name the vendors' names of, I can't get my data out of the CRM system to do what I wanna do with it. I've gotta work within it, within the confines of that one product.

And that, that's not just CRMs or some one CRM, that's that way, but I think that's gonna be the next battle. I think you're spot on, and that will be an entire topic this week. So stay tuned on that one.

But, um, I would just point out one last thing about all of this is that the pace of innovation is a lot faster than it used to be. So by the time we wake up and three, four months from now, or is, is the a OA crowd gonna figure out that they need most of the things in these things and have done something about it and put it in code? My money says yes.

Well, well, it Goes along with the technical Darwinism, right? A technology Darwinism, because you have mutations that are accelerating with, with AI that at a speed that was not plausible when led by humans. Yeah, true.

Alright, gentlemen, thank you for joining us on this great tech strung gang today. Thank you for watching. As usual, we have tech drunk TV immediately following, uh, we will be back on tomorrow Wednesday, uh, with another great show.

I won't be on that one, but Mike, I guess you'll be driving the bus. Mm-hmm. Right off the cliff, ma'am.

Alright. Alistair, again, thank you for getting up at the ungodly hour in New Zealand to join us. JP Mitch, talk to you soon.

This is Alan Hummel for Techstrong. Have a great day, everyone. We're out.

Hey everyone. Welcome back here to Techstrong tv. Let me introduce you to our next guest.

io. His name is Ian Pel. Ian, welcome to Techstrong tv.

It's great to have you on. Great being here. Thanks.

All righty. So Ian, we're gonna talk all about rude and what you guys do and, and you know, in this how in some way you're making the world better. But before we get to that, let's talk a little bit about you.

Sure. If you don't mind, share, share your story a bit. Yeah, of course.

So, um, I started off, I've always been kind of a geek. Uh, I've always enjoyed, uh, it, um, and, uh, have played with it throughout my whole, uh, growing up. And then later into my career, uh, while I was studying college, uh, MISI ended up joining the Army and, uh, did, uh, ended up joining the military intelligence, um, organization and spent some time there working in Counterintel.

Just really, uh, it was, it was a lot of really great learnings on kind of how to interface with people, how the world operates, how adversaries operate, how to think outside the box, um, when it comes to, uh, all different types of security. Um, and then I, uh, found a passion for startups. And, uh, so I worked at a number of different companies, uh, spent some time at Rapid seven.

Uh, I was at a company called Cloud Lock. Uh, that, uh, ultimately what there was A-C-A-S-B security vendor was acquired by Cisco, um, for about $300 million. Um, and where we merged with the, uh, cloud security business unit, or reformed the cloud security business unit as part of their also acquisition of open DNS.

Yep, sure. And, uh, I remember, Yeah. And so, um, I was there along with my co-founder, uh, one of my co-founders, um, who ultimately he ran the cloud security business, the product team at Cloud Security there.

Um, and, um, we decided it was time for another startup. So he, uh, he went out and started, uh, started the initial kind of roots of this company, um, called Slim ai. And then ultimately, uh, moved into this new journey that is Root and I came over as the CEO and, uh, we brought in a couple of other co-founders.

And, um, yeah, that's, it's been a, an amazing journey so far, and excited to see where it goes. Very cool. Um, when were you at Rapid seven?

Oof. Was, uh, 2007, 2008. Oh, Those were my years, so Oh, really?

So I, I, I, I was the co-founder of a company called Still Secure. Okay. And, and we had a product called, well, we had a product called V that was more like a Rapid seven competitor Qualis and that whole space, but we were more well known for our NAC network access control.

Yep. And, um, but I knew, I knew that, you know, I knew Alan Okay. The founder of Rapid seven pretty well, and then I knew Corey well as well.

Yeah. I knew the whole team. Yeah, sure.

Just that's funny. Before, before we were, before I was there, I was actually, uh, at Inter Networks for a short stint, and that was their whole thing was nack. Oh, yeah, yeah, yeah, yeah.

Sure. That's right. In inter they had a nack and Yep.

Yeah, that was, it was a brief moment in time, right around 2007. Yeah. 2006.

Five to seven by eight. Yeah, Exactly. Um, anyway, yeah.

But it brings back memories, Ian. Yeah. And it's, and it's always good to have, I, I enjoy having, you know, cyber, we call 'em cyber, and I used to call 'em security people that on the show with me.

Um, so look, no one wakes up in the morning and says, ah, let's start a company today. Right. You gotta, you've gotta kind of have a little fire in your belly and really believe in what you're doing.

Mm-hmm. What is it that Roots doing that really made you just give up a, a nice job in a successful company to, to dive back into this insanity? And I say, with all due respect, I founded four co-founded four companies.

I, I, No, no, no offense at all. No, no offense at all. So, uh, yeah.

So my, my co-founder and I, and, uh, I have two other co-founders, um, also with, uh, some military heritage, um, on the Israeli side. So we have Oh, very co Yeah. So there's, there's four of us, which is also unusual for, for co-founding team.

Um, but, uh, two in Israel, two here. Um, uh, and, uh, we were walking around at Black Hat a couple years ago, and we basically said, everyone's talking about this. There was this big whole shift left movement, right?

Everyone was talking about how do I reduce vulnerabilities? There's this mm-hmm. And, um, every vendor there is trying to apply an, uh, this approach of how do I reduce that vulnerability account to an acceptable level that hopefully everyone can work on, and everyone feels like they're winning.

Um, it's this perpetual pursuit. But the problem that we had seen in, in kind of an early iteration of our company was we were, we were realizing that there was just no way to actually keep up in the way in the loop that we have today, the, the traditional mindset. Um, because the number of new vulnerabilities being generated within our software supply chain was increasing, uh, exponentially.

And there was just no way to keep up. We actually, uh, we, we had a speaking slot at, uh, CubeCon, uh, and, uh, we're on the main stage talking about this specific issue. And it was just, there was just, it, it was, we're like, everyone's trying their best, but there's no way we're gonna ever win.

Uh, which is kind of a little, not the best message, but it is. Well, it's, but it's a reality. Well, it's the security.

It's, but it's the security person's dilemma, right? Yeah. And so, yeah, so we, so we walked around and said, well, what if we took a fresh approach to this?

And just completely went back to the start and to a first principle's approach and said, what if we could just fix everything? Nevermind the aspect of triage. Um, and nevermind this aspect of golden imaging for your developers to build on.

Uh, which is not a, something that most organizations can do. There's literally not enough humans in the world that have that capability and, and skillset. Um, and, uh, we went on a, we started on a mission to figure out how to, how can we patch all of open source?

Um, and, uh, that was when it was the very early days of, I don't know that even people were talking about genic ai. It was just ai. Um, and we started doing so leveraging our deep expertise around containerization and around cybersecurity.

Um, and we're, we are, we're also born out of an open source project that we've since donated to the CNCF as 21,000 GitHub stars, really focused on container ification. So to kind of speak to our, our expertise and chops in that space and our commitment to open source. Uh, yeah.

And so that kind of all folded together, and it's been, uh, uh, a, we're at, we've been at the tip of the spear of figuring out what is the art of the possible for AI and agents and the types of outputs and the speed in which that we've been able to deliver these outcomes, uh, for patching away vulnerabilities has been, uh, far exceeds what we expected. Um, and now we have customers today that are, they don't think about triage. They're the, we like to say that developers, uh, no longer are chasing tickets to patch vulnerabilities.

There's, there's no more this concept of I need to break my applica, make the decision. Do I ship this feature or do I break, uh, uh, dedicate more of my sprint, uh, to rebuilding the app? Because if I upgrade, it's gonna cause a breaking, uh, change.

Um, we eliminate that entire thought process. Uh, we just secure everything that's upstream that you're pulling down, and we deliver it with an SLA with provenance and following all the SALSA standards. And all of a sudden SLAs become easy to achieve.

Very, very, very cool. Let me, uh, give you a little of my own history here. So when I, when I started co-founded, still secure, our first product was actually an IPS.

So at a time when the world was on IDS mm-hmm. We said, come on, 85, 90% of this stuff is garden variety, you know, not worms back then. Right.

You know, you had code red and, and stupid I love you and nonsense stuff. Oh, yeah. But, um, why wouldn't we just block it automatically?

Right. We, we could, you didn't have UTMs then You had an I-D-S-I-P-S, but you could like, work with a checkpoint firewall using like OPSEC or something. Oh, yeah.

You know, just, just block it at the, it was every, there was no cloud. Everyone was, it was, you know, the, the, they called Mo and Castle. Funny thing happened on the way to market.

Everyone, not everyone, but most people didn't want to turn on automatic blocking. They were afraid they were gonna break something. Yep.

So we kept banging ahead on that wall and looked for a new wall, and we started a vulnerability management. Yeah. Based on nessus, like everyone was using back then.

Mm-hmm. And, um, I remember as we were talking, you know, rapid seven came out, a couple of us qualis was there, found some, anyway, we said, but wait, that's not enough. Finding vulnerabilities.

Why can't we just give you the patch, give you the remediation? Not everything's a patch. Give you the remediation.

Same problem. I'm, we're afraid to do that until we take about 90 days, the qa, all the peer mutations of this patch. 'cause God forbid something else should break, especially if it's the CEO's desktop or something.

Yes. And, and we got outta the automated remediation space as a result. There was a company back then, I don't know if you remember it, Citadel, their product was Hercules dis uh, you know, they became the defense department thing.

They worked real close with Tenable. Yep. Um, then we did network access control, and we said, okay, this time we found a fresh soft wall.

Right. We're not even gonna let you on the network if you don't meet our, you know, golden, uh, Yeah. You're gonna go To the practice ticket, if you will.

Yep, yep. And, and that caught on a little bit because we weren't doing anything to your endpoint. We were just quarantining it basically.

Mm-hmm. But this idea of applying remediation patches in an automated fashion, I don't understand why in 2025 it hasn't, it's not an old problem that was fixed a long time ago, but it obviously isn't. So I could, yeah.

So let me answer that. Um, so go ahead. Uh, so our open source project and, and kind of the first iteration of our company was called Slim ai.

Uh, what we were trying to do was take this open source project and specify it in a way that, and the concept, right? It was, which is where most of the industry is right now. There's a lot of vendors out there that are saying, build on our base image or build on our golden image.

We'll give you some sort of SLA around it, and we'll guarantee there's no vulnerabilities in it. But it's, uh, but we, what we were trying to do was leverage our open source project, which minimized all the compo, removed all the components in your software that didn't need to actually be there for your application to run. The problem with that approach is that the, uh, that's very dependent on developers having great test suites, and many of them do.

Uh, many, many do not. And even the ones that do, what about those one-off cases where you might accidentally remove something or there's something that's minimized and, you know, the once a year it causes a breaking change. And what we discovered was even if you cause a breaking change, like 1% of the time, developers will not trust it.

Um, and yeah, that then, and the whole thing fails. So the trick here, and what root focuses on is we are experts and we've created a fleet of genic ai, uh, uh, uh, of various agents that operate as a swarm, um, that are constantly inspecting the software supply chain for all of the most popular open source projects and for any, uh, uh, packages and PA and, uh, oss that our customers want supported. And it's interrogating the pa potential patches that can be applied to remediate the vulnerabilities that exist in your code without causing a breaking change.

And if there isn't a patch that matches that criteria, our agents will go find a version that can be, uh, reconfigured in a way to be deployed within your version of your open source. And, uh, and then our agents will not push it back to you until it's successfully passed the entire test harness. And if there isn't a sufficient one, the agents will create test harness to verify that that, uh, new patch that's applied will not cause a breaking change bef, and then we push that back to you, and this entire process takes minutes.

Um, and love it. Yeah. And, and so the, I think what's, uh, one of the things that we discovered on this journey was how much we needed to do this.

Uh, or not just us, but everyone. Um, and so, uh, there was, I'll give a real life use case. Uh, we just rolled out the third generation of our agents, and the, there was a recent, uh, vulnerability that came out that impacted both the entire Debian and Ubuntu ecosystems, you know, very popular links or operating systems that everyone builds on.

And, uh, that critical vulnerability, uh, the upgrade path was you had needed to move to the, basically caused a breaking change. You had to move to the latest gen. So if you were building on a, if you were not building on WN bookworm, or if you weren't building on Ubuntu 20, uh, uh, or sorry, if you were building on Debbie and Trixie, you were fine, but behind you weren't.

Okay. And same with Ubuntu. You had, you had to be above 20.

Um, when we tried to create a backboard of patch, we thought this would be a great opportunity that would be stable and also patch that vulnerability. We thought this would be a great opportunity to actually test and bake off, uh, if you will, uh, against our human researchers. So we took one of our best researchers, and we had them work on trying to create this fixing change.

1% of companies out there have the capability do. Right. This is, this is, uh, I gotcha.

Yeah. Um, that took this researcher eight days, and the reason was the, in order to backport this patch successfully, it required updating 17 different snippets of code over three different commits. So a very complex patch to ensure you do not cause a breaking change.

Um, our agent did it in sub 15 minutes. And so when you, when you think about that delta, right? The, everyone likes to talk about 10 x-ing.

It's not 10 x-ing, it's thousand x-ing. It's not even, it's exponential stuff. And, and so when you put the, if you take, take this to the next logical step, right?

And thought it's okay, well if we're, if that's the rate that we're able to patch these vulnerabilities, and then obviously adversaries are going to figure out how to weaponize this at that speed. And then on top of that, we're completely thinking incorrectly about SLAs and compliance requirements as they exist today. This thought process of, oh, I'll fix things in 30, 60, 90, or once they detect something, even a critical seven days, right.

That's anchored in a reality. Uh, that is, that just doesn't exist today. I know it may not be known to most, but yet, um, but the, the, that, that is a human-centric timeframe and time span that ceases to exist.

It's Not today's speed of business. Exactly. That's that.

Right. There's the issue, the speed of business today is not on that human mind kind of, you know, clock if you will, of days. Exactly.

And, and, and our, our, our, our, the industry's guidance thus far has been, well, don't trust open source, go into these gated ecosystems and build on some sort of proprietary vendor lock source. Um, and, but They're not necessarily any more, not only are they locked, but they're not necessarily any more secure, quite frankly. E Exactly.

Right. And, and the transition is not easy. So we have customers, um, so we, we, we have customers of all size.

We're, we are very excited and, and, and proud of the fact that we have customers that are small few person shops. And then we have customers that are publicly traded companies, and they are, we, we literally have containers, uh, are that are secured using our, uh, solution deployed on in NATO missions. Um, and so the, what's, when, when we baked off, uh, in against some of these other versions of our other golden imaging approaches compared to ours, um, we were able to secure the entire software supply chain, uh, of that.

This customer, for example, I'm thinking of, uh, was able to secure all of their containers. It was 37 different core containers that they were building on for this large Kubernetes deployment. Um, and, uh, the, it took them three weeks to move just one of those containers to this new base os because again, when you move to any of these minimal base images, everything breaks, and also that's just a tax on your engineering team.

It's a tax on innovation that, that, that's a giant business decision and a huge sacrifice. And again, not how the world should be or kind of the forefront of the, of the world is, is operating. Um, we, we secured that entire supply chain in under four hours.

We were fully integrated into their CICD. Um, and, uh, it, it's not a one-time fix again. Uh, what the way we deploy is it's ongoing.

It's cont it's inspired by fed ramp's conman process, right? So, uh, mm-hmm. Basically, every time someone does a poll, or at the worst case every 24 hours, the system is going through and re re interrogating the entire supply chain, looking for any new vulnerabilities, and then immediately deploying the fleet to figure out how to patch that for you and push it back to, and we do this all very transparently.

So all the patches we generate, uh, we we're hyper transparent about what's in there. We publish what's actually in the code. You can see it within the container.

We give an SBO and a V statement. So, again, true to open source. This is, uh, something we're, we, we think transparency is key to the future here.

Not, um, these gated ecosystems or, you know, security through obscurity. You more questions? Ian?

We're low on time, but I want to get this, I'm stuff out. I'm sorry. Oh, no, don't be, look, you're telling me you're sorry.

I talk like you, you're, you're preaching to the choir. Um, where do these agents live? Do they live in the CICD pipeline?

Do they live in like a gi in GID and GI Ops? Do they, I mean, they don't live in the repos, right? They're do they live in the IDE all of the above?

Yeah. Great question. So our fleet of agents live, we host the agents, the SaaS service.

Um, so those live on, um, various cloud providers, uh, like AWS for example. Um, and then we integrate with, and we can integrate any number of ways. So we can integrate directly with your, uh, CICD, uh, we can GitHub GI actions, you know, however you want to set it up, uh, Jenkins.

Um, we can integrate directly with the various registries. So you can plug us directly into A-C-R-G-C-R, you know, you name it. Uh, J Rog Sky's the limit there, ECR.

Uh, and, um, so we try to make it super easy. And then we just recently actually rolled out, uh, an MCP. So you can, as part of Claude code or part of Cursor or whatever, you can literally just say to it, yeah, hey, now patch all my patch, my os patch, my, uh, libraries, you know, and it'll just reach out and just at the developer level, now, you can even do all this before it even goes upstream.

So it's, um, it's highly customized. It's not customized. It's highly configurable to whatever you would like to do.

We, we've built the platform API first behind everything. Excellent. Um, I think you answered my second question, which is sort of what was the difference between the pure open source version versus the commercial model?

You, you're hosting it, you're SAS in commercial, and the open source people host it themselves. Is is that There or So, uh, so Well, the open source is a different product at this point in the Yeah, the, the, yeah. The open source is still, fo is still out there, it's still popular for, and, and that's called Slim toolkit.

And that's that, right? Uh, that focuses on, uh, and we've actually since, um, uh, it's in the CNCF sandbox now, right? Um, so we, that is more focused on, and again, there's a lot challenges for most folks, and also a lot of organizations really just want this to be fixed, right?

They just wanna pass their audit, they just want the compliance issue to go away. And so, uh, what we do is we, as part of our platform, you get an SLA, so a guarantee that we're not gonna cause a breaking change. And that also, you're gonna have these vulnerabilities patched within whatever timeframe is you need to meet.

Um, and then also, uh, basically that guarantee how wide you want that guarantee to be spread across your organization. Does it, do you need it to apply to five images or, uh, a library, or do you need to do a thousand, right? Um, so those are kind of the dimensions that we license on.

But people can try out the product today for free on our platform. Um, there's, we have this com, we have a com, this concept of a community version that you can try out, you can buy mm-hmm. There's actual licenses that you can buy starting as cheap as under $10,000 a year, you know, seven, 800 bucks a month.

Um, and then obviously we're, we have much more advanced versions that can do things like FIPs and so on, um, to help people really as part of their, uh, FedRAMP journey. Yeah. We have a customer delete me, for example, that's in the, that's, uh, on their journey to FedRAMP, and we're supporting that effort and we're, we're basically conman in a box for them.

That's right. You know what? So, uh, back in the Nak days we were in, we, we were an information assurance certified, uh, DOD solution.

So yeah, I had good times. I spent a lot of times in Fort Chuca, which was down there. Oh, that's where I Went to school.

Really Good old, good old Sierra Vista. Yeah. That's where the Army Intel School is.

Yeah. Oh, yeah, Yeah, yeah, yeah. I was there from, I ate a lot of, a lot of Mexican food there, waiting for them to finish their testing.

Small world. Hey, it is Ian. We're at, we're over time, but I, I, I enjoyed the conversation, so I apologize.

io. Yes. io.

Community version licensing everything. You're gonna be a black hat this year. Of Course.

Always. We'll be there. We're doing video on the show floor.

If you see me come over and say hello, I'd love to meet you in person. Beautiful. And come back and keep us posted here, man.

Great story. Absolutely. I Love it.

It's nice meeting you, alrightyy. Appreciate it. Take Care.

Nice meeting you as well. Alrighty. Bye-bye.

Excuse me. Ian Relle, CEO ru io here on Tech Drunk tv. We'll be back in a moment.

Hey, everyone. Welcome back here to Techstrong tv. Our next guest on Techstrong TV today is Casey Kinder.

Casey is the founder and CEO of a company called GR Stream. Let's welcome him. Casey, you're on Tech Trunk tv.

Thanks for being here. Thanks For having me, Alan. So, as I mentioned, you are the founder and CEO of GR stream.

I always like to explore what drove you to this crazy level of craziness to go out and found a company and, and, you know, try to make a go of it here. And I don't have to tell you every day's a battle, right? You breathe life into this every day as a founder, especially as CEO.

Give people a sense of your background and, and how you wound up here. Yeah, sounds good, Alan. So I think really there are three things that led me to, uh, where we are today.

Um, number one is, uh, I'm a, I'm a math guy. I was a, a math major in, uh, undergrad at U Chicago. Um, I like solving hard problems.

It's sort of just what it's, it excites me. It's what kind of keeps me going every day. Um, and, uh, the, the second thing I guess is I started my career at Deloitte Consulting, just kind of, uh, you know, as many, uh, quant focused people do in the consulting industry.

And, but I got really fortunate and I, I landed in Silicon Valley on a project or on multiple projects when Silicon Valley was really just building out the, the, you know, sort of the first generation, the first wave of large scale infrastructure build outs. And, and it, it's, it sparked something, it made the complexity of it, the excitement of it, the energy of it. Um, you know, I was there for just a couple of years before I started my first company.

Um, you know, what it gave me was a, a grounding and a problem that I thought was really, really interesting and wasn't going to be easy to solve. And that is, how do we manage the complexity that is inherent in the, this evolving it and network infrastructure that really powers our world today. Um, that problem, you know, excited me 20 years ago.

And, um, I, I'm even more excited today because I think we're we're closer than ever to really getting our arms around the solution. Absolutely. So this is one of these overnight sensations that's 20 years in the making, huh?

Well, I mean, yeah. I mean, you know, I, I've, this is my third company, you know, I had two hypotheses prior to this on what it would take to solve the, you know, that foundation problem. And each iteration, sort of the problem domain has shifted and, and the complexity level has grown.

And with the, the advent of ai, I started, you know, down this path about eight years ago with a, a small research team with a real simple problem. Okay? Now, we've, we've attacked, we've attacked the problem in a couple different ways.

Um, I won't go into the details of the prior hypotheses, but the, you know, um, you know, our, our fundamental goal starting at Rock Stream was we're gonna, we're gonna harness machine learning and AI to solve all of the problems that were intractable for us in our prior to, to runs at the problem. And, um, and that really was the goal. So I, you know, I had a small team of researchers started to identify what the, what the kind of underlying problems are and attacking it with, uh, with AI and machine learning algorithms.

Excellent. Casey, you know, you know the old saying you can't make wine before it's time, right? And, and, and I agree with you, right?

So many problems. And I, like you, I've al I've been in tech 30 plus years, infrastructure, uh, security mostly. And yeah, I look back at problems that seemed insurmountable then that are kind of common, you know, table stakes today, but yet, you know, things keep getting more complex and new problems.

And much like the book, the Goal, you ever read the goal, right? As soon as you solve one bottleneck, the next bottleneck presents itself, right? And that's kinda where we are today.

AI has, you know, a crazy potential to help us. It also has crazy potential to make yet more headaches for us. Right.

Um, talk a little about gro you, so you, you gave us the setup into GR stream, but as it existed, I give give our audience a sense of where it's at, what it's doing mission wise and stuff like that. Yeah. And, and the mission is really simple for us.

It's so without AI and machine learning, large, complex IT, and network infrastructures with cloud overlaid, um, in order to keep that up and running and optimal, and delivering the services that continue to evolve on top of that, um, requires a large number of, of engineers doing operational tasks to keep the lights on, to keep the systems up and running and optimal, right? Um, our, our goal really is fundamentally to reduce the amount of effort required to do upkeep and respon, you know, respond to incidents and fix problems, and allow more of that talent to do innovative tasks. So what we've built is a, a cognitive AI architecture that consumes sensory data, basically telemetry data, everything that's happening in, in the environment, and the, you know, um, com complex web of networked data centers that drive an enterprise, um, set of services.

And we take all that telemetry data, we process it through a series of algorithms, each of which a distinct learning algorithm from their own sort of research domains. Um, and at the end of that, we predict when an incident is going to occur. We allow for, um, operations engineers to, to prevent any occurrence, any similar occurrence in the future.

So they don't fix the same problem twice. They don't have to do the same maintenance task over and over again. And, um, once the system has evolved with the team and they're sort of functioning well, um, it takes on more and more of that operational repetitive work for the support team.

So, DevOps teams do less ops, more dev, um, network teams, do more engineering, less operational support and so on. That's fundamentally what we do. We process it through a series of algorithms.

We enable automated action at the end of that that's intelligent. That is, you know, isn't a set of, of rules that have been built, uh, you know, a runbook that's been coded, but rather a, an intelligent response system based on learning algorithms. Love it.

Love it. You know, we didn't even mention the URL people who want to go explore this themselves. Where, what's the best way?

dot com or? com. G-R-O-K-S-T-R-E-A-M.

Just like it's spelled underneath your name here on the video on the lower third. Alright, Casey, let's shift gears. You guys recently re, uh, announced a new release, grs, excuse me, grok predictive IT operations, uh, provides IT operations service management teams with an AIOps platform that continuously learns and adapts self-healing.

That's always been a kind of holy grail. Um, talk to us about rock predictive IT ops. Yeah, so I'll, I'll just say that the first, the first rung of the ladder that we had to, we had to climb up was, um, making our system smart enough to respond quickly when a problem occurs, when something happens in the environment that requires action to be taken.

So the kind of the first step is to understood, kind of sift through the noise that telemetry data, and figure out what is actionable, what's actually just to shift in the system redundancy exists in all of these, um, you know, large networks and, you know, bubble up what act what requires action and respond appropriately to that signal to, to fix something, to restart a service, to create a ticket and dispatch it to an engineer, whatever that is. So, still reactive, but just fast and dynamic. That was kind of the first rung of the ladder.

And what we've been working on for the last several years on the research team is, okay, so we've, we've gotten, you know, the, the problem has always been, you know, in our space we wanna go from reactive to proactive. So step one was to solve the problem with ai, the, the reactive problem with AI to relieve some of that pressure from operations teams. Um, and the second part of that problem is forget about reaction.

We actually want to stop the problems before they occur. And, um, and, and we do that in several ways. I would say, let's say three, three ways.

One is we have a predictive algorithm that monitors the, the, uh, the occurrence of incident patterns in the environment and the operational data that kind of precedes those incident patterns. And it predicts when an incident's going to occur within, we can kind of fine tune the timeframe, but say 8, 12, 24, 36 hours, and said, there's a high likelihood that this particular incident is going to occur, this problem in the environment's going to occur. So let's go out and take action to prevent that.

So, you know, rather than waiting until something breaks and dispatching an engineer to fix it. Um, so that's number one. Number two is we can observe the, the pattern of occurrences.

So the problems that have happened over a long period of time, we can surface the, this pattern in a, uh, an actionable list. Think of it as an automation pipeline. Things that are sucking energy from our high value and engineers requiring them to do operational tasks over a period of time, list it out and, and identify what items on that list ought to be, uh, automated.

What can we do to automate each of those, those items to prevent them from occurring in the future? So that's the second poll on the tent. And the third poll is enabling our, um, language models to process the information, apply reasoning, and take autonomous action to prevent the issues from happening in the future.

And, you know, those three polls in our, our preventative and predictive tent allow us to really kind of take it once and for all from being reactive to being fundamentally proactive and predictive. Agree. com website and it's right there on front.

It is. And we have some great videos too. I mean, I, I think it's, it's tough for folks to, you know, read a whole lot of text content these days.

So I would encourage you, and we're we're, That's why we're on here, my friend that didn't do this as a written q and a. Yeah, we're working, that's an understatement. Yeah.

We're working really hard to produce videos that not, don't just talk about what we do, but actually show you a lot interactive so you can click on things and see how our user experience matches with the kind of the value that we deliver. And that's the, be that, that's sort of the really important when it, when it comes to, uh, AI powered systems, because a lot of, you know, a lot of folks will deliver products, and the AI is so deep under the covers that you don't really know what's, what's a rule, what's just a rule that's been coded versus what's a predictive model? What's a, and the reason that's important is because, you know, if it's a rule, it doesn't evolve.

And all, you know, every environment changes, every company changes rapidly. And if you don't have learning algorithms kind of producing the output, then you know, it's only gonna work for a short amount, amount of time. That really is so key to the whole look, even before ai, you know, it, the time crunch is continuously accelerating, it seems.

Right. And what worked two years ago certainly doesn't work today. It's ancient history.

Um, but, you know, you mentioned what people like, we, we do the same thing. You know, we do do maybe 400 webinars a year, and we survey our audience, what do you like, what don't you like consistently? Their favorite type of, we call a webinar a learning experience.

Their favorite type of learning experience are hands-on demos. Not, not a PowerPoint with, with screenshots of a product, but actually logging in and following along how the product actually does what it's doing, what, what, how do you do it? And they love this.

And, and it's almost counterintuitive because it's very vendor specific. It's very product specific. But they'd rather do that than listen to a talking head with a bunch of slides.

Yeah. You know, narrating the slides. So I, I agree with you.

That is, that's what people like today, of course, you know, get it all done in seven and a half minutes, because that's kind of the attention span. But, um, right. You gotta break it up in pieces.

Yeah. I mean, we're human humans, humans learn With our hands. Humans, we're tactile creatures we have to touch in order to really learn That.

That's, I think that's it right there, case. All righty. Hey man, thanks for coming up here on Text Drunk tv.

This was great. I appreciate it. com, check 'em out.

We're here on text from tv. We're gonna take a break. We'll be right back.

Hey guys, thanks for the throw. We are here with Glen Weinstein. He's the CEO for Cloud Smith.

And we're talking about model context protocol, MCP servers. They're everywhere, but no one's quite sure what they mean just yet. Glenn, welcome to show.

Thank you, Mike. It's great to be here. All right.

You guys have been working in the space of DevOps observability and, and everything related to application development for some time now. And you too are also seeing MCP servers, and I believe you have one of your own, but what are the implications for all of this? Is it just for AI purposes or is there something else going on here?

Yeah, well, AI is a means to an end here, Mike. I would say it's the tooling, but what this is really about is recognizing that people develop software very differently today than they did even a few years ago. Um, cloud Smith is in a position to help software development teams to develop faster and more secure, more securely.

And I think tools like Cloud Smith and really honestly, a whole bunch of other tools need to expose ourselves to the AI agents of the present and the AI agents of the future. MCP is just a way of making sure that we do that, um, correctly and efficiently. It seems like a lot of these AI agents that we're seeing, and even the co-pilots before, are lacking context.

And as a result, what happens is they seem to generate some code, but it doesn't happen to run in the environment intended because each environment is well as Snowflake. So, uh, will tools like yours surface up the data through an MCP server that the AI agent needs to get that missing context? E exactly.

That's, that's definitely one sense of the c and MCP, the con the contextual, uh, background of, uh, the development environment that a particular developer is working in. We're not talking about AI like the, like, uh, Google Gemini running on the Google search box answering generic questions. We're talking about developers saying, how many Cloud Smith repositories do I have?

Is this Docker container image in one of my Cloud Smith repos? Has it been scanned for vulnerabilities? Questions like that require a lot of context.

What, what do you mean by cos with repo, I wanted to see my repos not someone else's repos and that sort of thing. So an MCP server allows us to provide the context so that the AI can come up with a relevant and meaningful answer. Does this also mean that maybe I don't have to be as much as a rocket scientist as I used to be able to observe, use these tools?

I mean, just theoretically I should be able to use natural language to ask the agent to go answer many of those questions, right? You know, that's one use case for, uh, something like the Cloud Smith MCP server, which is just to straight up use your ai LLM, your Claude or, or, or, uh, chat GPT Pro and just ask questions about your Cloud Smith environment. Maybe give natural language direction, go create a repository, go migrate this, this package, things like that.

But I think the, the longer term power is gonna be more than just answering questions. It's really agentic and it's this idea that developers and I, you, we already see it on our own team, um, are increasingly relying on agents to perform multi-step processes. And one of those steps may be to pull or push a package to Cloud Smith.

And we want Cloud Smith to work well in the context of an agent talking to another agent, talking to an MCP server from another vendor, and the humans don't get involved in the, in the intermediary steps. This ensures that degree of integration too. So as a developer, yeah, you can ask natural language questions, but it kind of goes beyond that.

Like you can perform entire tasks that you would normally have done step by step and just let your AI agent do it for you. Hmm. Will there be multiple AI agents that need to talk to each other?

And, you know, we hear a lot now about something called the agent to agent protocol, but, um, is that complimentary to all this? Will we need both? Because it seems like one's for talking to agents, the other one's for agents talking to data, Highly complimentary.

You need both. Um, you need MCP first. That's really, in my view, the more urgent, uh, requirement here.

But a to a is a great evolution. Google just donated the entire project to the Linux Foundation, a definite step in the right direction to open source this. Um, what we can do today is we can help individual developers that are working in co-pilot or working with whatever developer tools they're working to make sure that Cloud Smith plays well in that environment.

Um, where it really will become relevant to companies like carlsmith in the future is when we develop our own agents. So you see this a little bit like, uh, you know, our, our, um, uh, you see this in sales tools and things like that where the company will brand an agent with their own name. Our, our internal leading candidate for a name would be Smithy, uh, an agent that ask those questions about your Carlsmith environment.

That's, that's temporary. And I, I don't run, uh, luckily we have a, a chief marketing officer here, but, but, so we don't have that today. But, but if and when we think it makes sense to have our own native agent, that agent is gonna want and need to talk to other vendors' agents to properly answer questions and provide a meaningfully contextual answer.

So that's where eight A really is gonna come into play, where every vendor has their own agents, and I just need my agent to kind of talk to your agent to steal a Hollywood phrase. Do you think we'll also get to the point where I feel like observability, it's been a core tenet of DevOps for such a long time, and yet for the most part, we're all still stuck on monitoring predefined metrics and we're just kind of getting our heads around observability. I wonder though, in the age of AI with AI agents, it becomes essential because when I talk to folks, they're like, well, it's great that the AI did this thing, but I don't really understand how it did it and now I'm being asked to debug it.

Yeah, yeah. I mean, uh, so AI tools are, they're getting so sophisticated so quickly, and it's, it's great when you see AI tools give you the full explanation and references of how they can, how they drew their conclusions. But to, to think about observability specifically, I think, I think MCP servers and, and LLMs in particular in in general are an amazing observability tool.

Your pro your products has to create the data in the first place. We have, you have to have rich client logs. You have to have an API that can access them.

But the, the last mile in all that is getting all that data into a human's brain and answering the question that they meant to answer, that's where people tend to get lost. It's sort of like assuming, um, that, um, normal mere mortals can write their own SQL queries. It, it's not the way the world works.

You need tools that kind of help you with that. And I think that, uh, using an L to say, this is really what I want now, go to my data sources, go to my APIs and get me what I want, there'll always be a role for whether it's a human or an AI to assist in those kinds of queries. And so it doesn't replace APIs or having really rich data, it just makes them accessible to mere mortals.

Hmm. How long will it be before all this comes to fruition? I feel like we talk about it like it's all here tomorrow, but it will take some time for all this to come to gather in a way that's consumable.

So where are we on the journey, Um, in general, AI assisted tools? I mean, they're already here for software developers and, uh, if your, if your team isn't experimenting with and using them to be more productive, you're, you're falling way behind. What, what's not quite here yet is this use case that you and I are talking about right now, which is really cool idea.

And I think, we'll, it will come soon, which is, uh, the one I led off the interview with. Like, Hey, cloud Smith, tell me about my repositories. Tell me if this package is in there.

Um, I do think we're gonna see that in, in, and I think it's gonna be in months, not years, that customers are gonna start relying on our MCP servers capabilities to integrate with their AI agents to answer questions like that. I just think the generation of developers that's coming up now, getting hired, moving into jobs, they just assume AI agents are going to be their companions. And, uh, that those, these generational turnovers, at least in my experience in the tech industry, they have been quicker than you think.

Um, it's, it's, it's not long. It's months, not years. Well, we need to rework our DevOps pipelines and workflows for all this.

'cause it seems to me that the AI will be building code orders of magnitude faster than, than we have in the past. And we kind of were, you know, basically happy if we released, you know, once a day and probably once a week something went wrong. But in the age of ai, won't the volume increase to the point now where maybe I gotta revisit how all those pipelines are actually constructed.

That trend has been underway for a while now. The idea of doing more and more builds every day. We work with customers that do hundreds of builds a day and really don't think twice about it.

Um, so I think this will be a continuation of that trend, which is a distinct trend. I mean, I remember more than a decade ago, it was the world that you've described, you know, you do, you maybe will do a build next Friday. Um, but so we'll see and we'll see a continuation of the trend of more and, uh, more frequent builds, larger builds, um, listen and not to be too self-promotional about it, but that's gonna put pressure on the artifact management systems.

And that's why your artifact management has to serve up packages super fast. Well, cash globally, everything needs to be as efficient as possible. We're all getting hooked on the drug of AI doing things quicker than we could do them ourselves.

We, uh, the amount of logic and, and uh, kind of smarts that go into ag agentic ai, uh, tasks is just really awe inspiring. And you don't wanna get to the end of that and then have your bill take 15 minutes. That's, that's just not gonna work in the AI in the AI era.

Um, so yeah, it's, um, it's gonna change the expectations rather. I do wanna answer the other part of your question though, definitively, which is I don't think the fundamentals of software development are changing. You still need to know, uh, business requirements.

You still need to translate them to technology. You need to do a build, you need to de deploy to production. Those fundamental pieces aren't changing.

The assist is what's changing. It's like working with a whole team of junior to mid red level developers that are just helping you be faster. Does that artifact repository you described become more crucial?

Because in my mind we kind of never really leveraged it to its full potential. In theory, we should have been checking it for all the vulnerabilities that are in there and now AI components, while, you know, they'll probably be created by things that might be hallucinating and there could be packages that don't even exist and all kinds of weird things happening. Does the artifact repository become the place where we can kinda, uh, bring some a layer of order to what might be potentially chaotic?

Absolutely. And you're right, we have not fulfilled the full potential here. So the legacy players in this space are Jfr Artifactory.

And so inside Nexus, they were built in kind of a pre, uh, pre open source, pre vulnerabilities era. They really were built, uh, from an on-premise mindset to just say, just get the packages where they need to go. 'cause we kind of can't rely on the internet.

They never really made the transition into true, um, secure the software supply chain solutions. And you now see an explosion in that ecosystem. And relatively few of those customers use the artifact management platform for security, which is a huge opportunity.

'cause you should, um, what better place to have a data plane and a control plane for what's going into your software and what you're building than at the artifact management layer? So, uh, so the phenomenon you've described is real, uh, it's absolutely real. Where the, your copilot, uh, agent will su suggest either packages that are outta date or they're not well maintained or that kind of nobody's using and they're falling out of fa favor or fashion, but you know, somehow they picked up a little tidbit about it and they'll suggest the wrong package.

Or just hallucinate a fake package, which is then opens up this whole, um, slop squatting, uh, opportunity of bad actor, just create that package and now it's a real package and a malicious one. So all of that pressure is gonna be put on software development teams to secure their bills when agents are making 90% of the decisions. So we better get some protections in place.

So what's your best advice to folks right now as they kind of look at all of this? 'cause I think everybody's excited about the coding side of the equation, but they may not have gotten through the, um, downstream impact and effects just yet. But what should they be thinking about now that they can see that?

Well, as far as I can tell just about every developer's using some sort of AI coding tool, it's just a question in what degree? Yeah, That's Probably the entry criteria here are use and experiment with, um, AI tools. Our most cynical senior developers who poo-pooed the idea of AI assisted development a year ago are, are now sold.

There's, there's not a lot of cynics or skeptics left. So, so get on board, uh, with, uh, with what they can really do. I tried out for yourself and, and just figure out what they can really do.

And then I think, um, uh, the call to action here is start to think about the full tooling ecosystem. It's not just about GitHub. Uh, it's not just about your IDE, it's about all of the tools that you work with.

Raise your expectations for how they should be participating in h Antech workflows. Um, I think, um, within, you know, a couple years tools that have not kept up, uh, don't really have a true API first, uh, architecture and haven't fully implemented in a, a secured MCP server in eight a are just, they're not gonna play anymore in the future ecosystem. All right, folks, you heard it here.

It might be time to take a minute and figure out what the cause and effect here is gonna be, because we are definitely gonna have a lot more code than ever. It's just a question of how much of that code is gonna show up in a production environment, how fast and how good this quality gonna be. Hey, Glenn, thanks for being on the show.

Absolutely pleasure, Mike. Thank you for having me. All right.

And back to you guys in the studio. Hi Everyone, and welcome to the six five Summit AI Unleashed. I'm Tiffany Bova, and I am joined today by the man, the myth, the legend, otherwise known as Sanjeep Sahu.

He is the president of Global Platform Group at Ingram Micro for the ecosystems track today. Welcome, Sanji. Thank you so much.

A pleasure to be here. Well, look, I don't know if many people realize that Ingram Micro touches like 90% of the people on this planet when it comes to technology and has for like the last four decades. Yep.

Um, when you look back and think about there being this inflection point of being a technology distributor that had to embrace digital, what do you think was the moment where it was like, hold on a second, this is just not some transition. This is definitely where the market is going and, and now we find ourselves at this inflection of ai. What, what do you think, uh, Ingram's position is now?

I think Ingram is an inflection point and becoming a platform business, right? But if you think about, we had been in business for more than four decades that you said, and we didn't own anything. We connected the amazing technology brands with all the resellers reaching out to almost 90% of the world's population.

The idea was that if we could embrace digital and create that experience between our resellers and the OEMs and the technology companies better, that's what we wanted. We, that's how we started embracing the digital mindset and became starting the platform journey and rest in the next few quarters, we started doing iterating step by step. Yeah, and I, I wanted to double click there because digitizing and digitization and digital transformation is a mindset change, not just a solution or an outcome.

And where do you think there's opportunity for the ecosystem, if you will, to understand that the mindset really has to keep pace with what's going on technologically? Absolutely. A lot of transformations fail because you know what you know, and you do not embrace change.

And sometimes to become who you want to be, you have to let go who you are. And that's hard. You always focus on the art of impossible versus the art of possible.

Our mind tells us that, no, no, this is working well, you are a successful company, so why change? Why do you change everything that you have done for a long time? So the technology evolves and you build amazing technology, but if it is not adopted, it'll not work.

So one of the things we did was create something called as operating model DG ops, operationalizing digital, because adoption is not an option. You have to continuously build, evolve, capture value, and move on, and most importantly, make small wins and change the mindset. Well, you've been involved in this digital transformation for a long time.

Mm-hmm. And you almost historically, as an individual sanjeep, right, looked at legacy businesses that have gone a traditional route and said, hold on a second, like, technology is gonna be moving, whether it's financial services or banking. And, and now in distribution, do you see correlations in, in industries where they're more open to embrace these digital transformations?

I think every industry has to adopt to transformation. Digital transformation is a name, but ultimately every organization is focusing on driving top line and optimizing bottom line and moving fast in the market. The best transformation is when you don't call it a transformation, it's not a project, it's a DNA tell me one company that do not want a DNA that can adopt and pivot to market changes, can really create value and can understand their customer experience.

And that is transformation. So digital transformation is using digital technology to fuel that journey. And some companies do it better than others.

Some company do not change faster because you know of lot of, you know, legacy and traditional businesses. But I think Tiffany, every company should really have transformation in their DNA, where you actually focus on the art of possible. You focus on how do you continuously change And what, what, what do you believe distribution's role, Ingram Micro specifically is in helping the channel ecosystem make this pivot themselves using kind of being their own client zeros, if you will.

Like, I, I don't believe that partners or the ecosystem sells technology. I, I believe they sell change and change is super hard. And so what are the things that, that Ingram is really investing in to make sure that these partners stay on this journey?

This channel sells a lot of amazing technology. Do we use that technology in our business? Do we use data AI cloud to really create a better partner experience or a better vendor experience?

What we are doing at Dinga Micro is using technology and it's not just talking about AI and technologies. We started this journey with X vantage, you know, three years ago. But using this technology and starting with the journeys, understanding the problems and trying to create a better partner experience.

Can you actually have a platform for every single person or can you solve special pricing? Can you have hardware, software, cloud in, in a single order ticket billing? There's traditional issues that are in this industry if we can solve them using technology.

Partners are freed up to grow their business better with the insights that we give similarly for the vendors. So our go role is to connect the 1500 vendors that we work with, with the hundreds and thousands of resellers that we have, reaching out to almost 90% of the population, have a seamless, better connectivity and make them connect better so that everybody gets value in this ecosystem. That's where Ingram Micro can play a huge role in the channel.

And how are you reimagining value creation, especially with Xan? I think that's a great platform and springboard for this value creation for the channel. And Advantage is not a tool that supports a distribution business.

It is a platform that's making us a platform business. So when I talk to our partners and our vendor partners, say partner with a platform, imagine the possibilities together from PDF to SKUs, from integrating months to minutes from solving complexities, taking OPEX out, having hardware software integrations in one single platform. Reimagine your business with the power of platform.

And that is where Advantage is. Helping the platform can understand and adopt to the changes. It's a new way of integrating with us and that's where we are super excited about creating value in the ecosystem.

And the role on that platform of ai, how and where are you integrating that on both sides, right? So you're doing it, I'm gonna guess internally, right, to help the platform, but also externally for the ecosystem. Interestingly, Tiffany, when we started the expanded journey, we started with a foundation of data and ai.

We had more than 40 years of data. The first thing I did was to hire a chief data officer and told him to build a real time data mesh and an AI factory. Most of the mistakes companies do is jump on AI and find a problem to solve.

We started x expand with the foundation of AI and data and then from that created engines that took friction out and now we are speeding the go-to market and solving problems. For example, if you are creating a complex code using data and automation, you are doing it in minutes and seconds. You are taking a complex catalog and converting it to our SKU format, you're doing it in seconds.

You are doing integration from months to minutes. All this is the data and the AI that we have that is helping us. That's the power and the backbone of X vantage platform.

What Do you think the greatest, uh, or most significant, I should say, missed opportunity is for the channel when it comes to Xan, the platform and all you're exposing from data and analytics? I think number one is do not look at X vantage as just a tool to do distribution. Do not think about, okay, this is another tool we should log in to do our business, get, you know, updates.

I think the opportunity is reimagine your business as a partner with the power of a platform. And the platform is not perfect. We are building it in the last two and a half, three years, we have put in more than 32 million lines of code.

We have more than 30 patterns. We are replicating 300 million messages every day. We have four petabytes of data.

We have brought in engineers, you know, and we are working on it and we are solving problems. It's not perfect, but we are approaching our partners and our vendors and asking, what are the most complex problems you have and how can we solve problems? And if you do not approach the way that the platform can solve problems, you will miss out.

For example, we are talking to some vendor partners, creating a data store with AI to push recommendations, will join recommendations to the CUS partner base or SMBs. We are looking at some of the customers to partner together, take their opex, you know, improve their opex and go to the market. We have a certain cybersecurity vendor very recently integrated where the platform is actually their backend and helping us, you know, to grow their business.

There are multiple ways you can integrate with the platform. It's not single way. I think that's what the missed opportunities understand the power of a platform because the channel has to change.

The whole world is changing. How do we cater to that change using the power of the Platform? What partners are getting it right?

I don't need names necessarily unless you wanna share it, but, uh, two things I'd ask on that is what is the persona of those partners that are really leveraging it? 'cause what you just described is something that a channel partner most likely would never invest in on their own. Correct.

Right. Yeah. So it's a, if I'm going to e eat, you know, and be my customer zone, you know, one, I almost can't afford to do everything you just said for terabytes and petabytes and all this.

I'm not gonna do it. But if I can leverage Ingram's, expand it, it gives me a competitive advantage. And so what, what's the sort of persona of those partners that are, uh, really get that message?

So if you look at the channel or our partners and what we are doing, Ingram Micro, we have to move from uh, order taker to an order maker. Most of the channel is fulfilling orders, but what the industry needs is you actually, fulfillment of orders can be automated, but you need solutioning consulting, you know, bundling, going and asking your customers, what problem do you want to solve? How can we, because solve those.

Because you can look at all the technology together. So the partners where the leaders are involved to look at their business holistically with the data of the X vantage platform, the insights and instructing their teams to use it in a way and, and exploring capabilities, knowing that they cannot invest themselves even in the mid-market or the SMB and we have some enterprise also leaning in. That's where you see success.

If you are asking your team go and use the platform and give, uh, another distributor platform, you'll not see money. Yes, there is some benefits you will see, but truly when you want to realize the power of the platform, it has to start with the leadership. It has to start with the C-level executors of the companies making a decision.

I want to partner with a platform because I cannot invest in the AI and the insights. Let me look at that and use the platform to grow our business. That's where you see the most value coming in.

Yeah. So you think it's a a a, you said transactional partner finding more challenge with what we're talking about here. Correct.

Versus someone who might be a little more software led or services led, where they're like, this is great, right? I can maximize and take advantage of advantage in a way that I don't have to make those investments. Yeah.

Right. And I can, I can use it here. What would you say to those partners that are still a little resistant, um, to go on this journey and saying like, you know what, what I'm doing now is working, like my clients are happy, but I feel like those clients, even SMBs, are gonna wanna go down this journey and they're not gonna wanna do it themselves as well.

They're looking for partners to help 'em do this. So what would you give for advice of those partners that are still on the sidelines waiting? Yeah, I mean, look, the platform can support transactions that is day-to-day that we do, right?

The idea is that the motion in the industry, changing the sales motion, even if you look at cloud ai, cyber cloud is all intertwined. If you look at services, you buy a cloud, you need to have services. You buy hardware, you also need, you know, subscriptions or cloud.

We need to understand that as the sales motion is changing, the partners need to reimagine how they look approaching their business. Would you really focus on looking at hyperscalers, looking at services or have a connectivity through a platform and do that? The second thing is, we have something called as dvantage integrations.

Today, our partner works on multiple systems switches. Today we have an integration hub, almost like an app store, which can actually connect those integrations to our platform, you know, which gives those integrations from months to minutes. Like you have a CRM or CPQ and the partner doesn't have to switch, and you can really build your efficiencies to the platform.

I think we have to really look at it. The transaction part is fine, but how do you really grow your business together? And that mindset has to change.

So my advice is pick one or two use cases, and that's always my advice. A new technology think big, but act small. Take take one or two use cases, experiment with the platform.

If you can solve those problems, understand and then iterate more and, and look at your, some of your complex problems and then use the platform. You know, look, I've, I've worked with Ingram for a long time, uh, with Ingram Micro for a long time, and I'd say I, I always appreciate that what the role of distribution has played in this ecosystem in the supply chain, right? In the moving of technology.

It doesn't look anything like it looked 20 years ago, 10 years ago, even five years ago. So I would, if I was gonna ask anybody where I thought it would go, sanji, you'd be one of the first ones I would call and be like, where do you think it's going? Right?

If you could say, look, I, I feel like, 'cause you're really pushing the envelope here three to five years from now, where do you hope X vantage and the platform and all that you're adding value in, where do you hope it goes? It is not about just automation, right? The biggest mistake people think is platform is all automation.

It's a combination of freeing up time for non-value ad work so that we can invest that time in relationships with our partners to add more value. So, but with the involvement evolve of AI and how technology evolving need to use data and AI or agentic AI to make better decisions, and I see that happening in the industry right now where solutioning, bundling the challenges about pricing, the challenges about matching, all that will evolve and change because technology is changing a rapid piece. Technology consumption is changing quite a bit.

So the distribution has to change as well. You cannot really have the same notion of an OEM to a disty, to a reseller to end customer that doesn't work that way. Everybody is going to everybody.

So that aggregation of a, through a platform that can scale and connect all the pieces of the ecosystem, in my opinion, is the future. And that's what we are trying. It doesn't mean we are perfect, but that is what we are trying to really help our partners get there together with us.

And I think the component, there's another component to that, I would guess, uh, is the partner to partner connection, right? Because what you just described, right? The OEM to Disney, D to reseller, reseller to customer, right?

But along the way, I feel like there's more opportunity for partner to partner interaction and engagement. And it, it's been one of those things we've talked about for a really long time, but I've never really seen it scale and maybe the marketplace is the way in which, uh, the platform is the way in which that that will finally come to fruition. Yeah, I think what happens is that the more you can actually get the technology and the platform working, you free up things, for example, from tracking calls.

So now we are proactively reaching out our partners with some sales opportunities. The more you free up, it frees up the time for interaction engagement in the platform. Both engaging with Ingram Micro and engaging with partners of Ingram Micro, for example.

Looking at solutions, insights, recommendations, communities of your partners. And the more you do that, we make more education for our partners to make the right decisions, how they can make their own businesses profitable and can go to market better. And that's the goal, right?

You really, you know, automate the repetitive things that they do to run their business and help them to be more cognitive, strategic and consultative approach for them to learn. And that's the way I see the platform operating more and more. Thank you Sanjeep, for joining us as the opening track for our six five Summit ecosystems track.

It was really a pleasure talking to you. com/summit. We'll be back shortly with more.

Welcome Back to the six five Summit. Uh, we are talking about AI and making it real and putting together the infrastructure and the building blocks to get that payoff for consumers and for businesses. We love AI here at the six five.

And you know what we love even more. That's semiconductors. If you wanna hear about semiconductors, you are in the right place.

Everybody's, uh, we're talking about chip designs, we're talking about architecture. We're talking from CPUs to GPUs to accelerators, memory networking and foundry services, and pretty much everything in between. Uh, joining me today is Kevin O.

Buckley from Intel, a friend of the six five. We are gonna chat about chip based designs, packaging, heterogeneous integration, and I don't know, whatever Kevin wants to talk about. I love it.

I love it. Pat, thanks. Thrilled to be here.

Yeah, it's great to see you. It's been a long time since we met in the desert Las Vegas at your, uh, at, at your big event and you've subsequently had, uh, your big tent event to give updates. And, you know, a lot of people might have missed the event.

Uh, I unfortunately wasn't able to be there in person, Kevin. I was there in spirit though. I just just wanna let you know I never doubted it for a second.

No, I appreciate that. So, hey, in four years, uh, you have put together a process roadmap that's back on track with Intel 18 A and that inclu 18 a, you know, it's, it's easy to just say 18 a process, but inside of that are a lot of innovations. Uh, things like, um, gate all around and, uh, BSP, otherwise known as backside power delivery.

Uh, can you talk about the significance of these two technologies and why does it matter to customers? And maybe even talk about what they're, what they're saying about it. Yeah, you, you, you bet.

I, I think, um, as I reflect on our career in, in the semiconductor industry, pat, if you, if you go back to when you and I were young pups here, semiconductor advancement A long, it was a long, It wasn't, it wasn't that long ago. Depends upon the, alright. Uh, but if you reflect on early in our career, most of advancement in semiconductors was about shrinking things.

It was about making things smaller, which reduced capacitance and um, uh, you know, allowed the devices to, to move faster and allowed us to pack more in. And you know, I think everyone has a high level understanding that at some point we ran outta gas on a lot of those just make 'em smaller elements that we could count on. So innovation is now coming in different areas.

And, and the two innovations that you described that we've introduced in our 18 a technology, uh, what we call ribbon fed or gate, all around technology. Uh, the first of those is about changing what a transistor physically looks like. And in my career, we've really only done that one other time.

And, and, you know, in 25 plus years, when we went from a planer transistor, you know, sort of a flat transistor to the FinFET devices, and that was 10 to 15 years ago, depending upon where, where you were in the industry. So, you know, going from a gate that sort of wraps around the top of the transistor to now a gate that goes all the way around top and bottom of the transistor, uh, is a huge innovation that allows us to make transistors faster without compromising performance. And then our backside power technology addresses the other element of silicon scaling, which is, okay, I got a really cool fast transistor.

How do I get electrons in and out of that transistor and backside power for the first time, uh, anywhere in the industry, allows us to, you know, use metal levels on both sides of the transistor, both from above and below, which offers huge advantages in power performance. It's a big deal for us to, to be first in the industry to combine these two technology elements. Well, it is, and particularly, uh, given, uh, where you came from, you know, I've been tracking intel for 35 years and, you know, a lot more ups than downs, uh, on, on what's happening.

So it's been pretty astounding to me that, you know, it's funny, people say four years, gosh, that's a long time. I'm like, four years. Wow, that's not a long time in this, uh, in this industry.

You know, I used to work for a company that had a foundry, and then it didn't, given how, uh, hard it was and how capital intensive, uh, it was. So, so, yeah. And you know, the last four years since I've been even meeting with, with pretty much every executive at the company, uh, on the ELT, um, my first question was, Hey, how's five nodes in four years going, how, how, how's this going?

And people are like, well, you don't care about the design. I'm like, no, of course. I care about the design.

Uh, and Intel needs really good designs and really good technology, uh, to manufacture, uh, uh, that in. And it, it does seem to be, uh, uh, coming together, uh, uh, for you. But, uh, I wanna, I wanna auger in, uh, into ai.

I mean, what an opportunity for silicon. Listen, I always thought silicon was cool and sexy and important, but it took a little bit of time for the rest of the other markets. You know, the, the capital markets, um, uh, the software markets, right?

Software guys are like, Hey, uh, it's all about software, software's eating the world. And my response was, you're not gonna run that software on air. Okay?

Right. Uh, and, and now really semiconductors are leading the charge, uh, in, in ai. So pretty broad question, how, uh, does your roadmap align with the needs of AI and HPC workloads?

And again, you've gotta make a bet now for something that might have, might pay off in four years or four years ago, you would've had to me, made the bet then, uh, for it to pay off. Now That, that, that, that's exactly right. I think I'll, I'll hit it from two angles, pat.

The, the first from the fundamentals of, of the semiconductor. The, the good news is our, from an Intel perspective, the good news is our legacy, our history has been as a semiconductor technology manufacturer focused on high performance computing. You know, we've been developing technologies that, you know, for what had been our, our only customer for many, many decades, intel products to enable high performance compute, which is very, very similar and, and, uh, very well aligned with the needs of AI accelerators and the, the compute host nodes that connect to them.

So, uh, whether it's at the advanced nodes, the two technology elements that you and I just chatted about, you know, our 18 a technology with backside power and ribbon fat, those are exactly the drivers that the industry needs to enable the highest level of AI compute. The complement to that is, I think we all understand AI compute, um, especially in the training space, is not about what's happening in our pocket, it's about what's happening in mega scale data centers that are just extraordinarily interconnected. So for that, you need networking capability, which is core to, to our offering everything from copper connectivity to optical connectivity, but just as relevantly the packaging technologies that allow, instead of a computer being one ship, maybe with a couple sockets on the board, or four sockets in the advanced, in the most advanced server configurations to No, no, no, dude, this is a hundred thousand, uh, boards all working coherently as a single compute element, which is literally what's happening in our data centers right now.

So for us as Intel Foundry Pad, it's the semiconductor technologies that we talked about, and now the interconnect technologies, the advanced packaging technologies that allow that scale and those massive compute systems to operate coherently. And I'm thrilled that we've got both as core to our Intel Foundry offering. Yeah.

The industry has come, uh, so far. I mean, um, it, it, you know, used to be just a discussion about CPUs and then, you know, cpu, GPUs, and then once we ran into bottlenecks there, uh, we started talking a lot about HBM. And then we also talked a lot, you know, packaging used to be a second class citizen.

Now it's, it's as port as important, um, as the wafer itself. And I'm sure, you know, we could debate this, but, um, you're not gonna have advanced SOCs without advanced, uh, packaging. So it's all of our, you and I together, You and I don't need to debate this one, pat, you, you we're, we're definitely on the same side of, of, uh, of, of, of this.

You know, my, my perspective there, and I sounds like it's aligned with yours not that long ago, like five to 10 years ago, packaging was really about, Hey, I've got these little tiny solder bumps on a chip, and I need to connect them to big solder bumps on a board. And that's what packaging was, right? It was a glorified space transform.

It'll let us connect, uh, solder connections. Now it's just the fundamental driver of 3D interconnection, compute density. And, you know, it's just such a change that there just in the last couple weeks was the annual ECTC conference.

It's one of the major packaging conferences, and it was like, filled with rock stars. I mean, you know, that those packaging conferences as a leading indicator of where the industry is putting its attention and its investments, uh, was just filled with some of the most exciting advancements in the industry. Yeah.

So, um, one of the biggest architectural changes to chips is moving from these monolithic designs, uh, into triplets. Uh, I mean, listen, if you can, if you can, uh, have good yield on that, you know, 800 millimeter, uh, wafer, um, go for it. Okay.

But, uh, the reality is that that's, that's not the case. And why put something on leading edge node when it doesn't have to, when you can put it together in a triplet configuration and put the right silicon on the right node, but you can't sacrifice performance and you can't sacrifice power. So we had a good conversation about packaging, but talk about some case studies, some recent successes, right?

Yeah. You know, is this, is this working? Are you actually doing this right now?

We are, there's a couple of awesome use cases that I think that are right down the middle of, of the examples that you used. Um, one of the areas where scaling in semiconductors broke most fundamentally was in memory scaling. Though the, the industry's gotten really effective and creative about continuing to scale what we call logic.

You know, the, the, the fundamentals of the flip flops and storage gates and things like that. But the sram, you know, the, the fundamental storage unit is actually really not scaling well. So an example of use case that we're seeing a lot of a MD was a, was a great pioneer of, of driving this.

And some of the solutions they're doing Intel products is as well in a number of other companies, is this aggregating their compute that the fundamental core compute blocks from a lot of the memory. And I'm not even talking about DRAM and HBM, I'm actually talking sram. So, uh, you know, there are some incredible advanced packaging applications today where the most expensive, aggressive logic technologies are used to get those fast transistors to do compute, but the memory can be sandwiched right on top, you know, using through silicon vias so that you can do those SRAs in a more cost effective technology without substantial compromise.

Yeah. And by the way, the advantage is those 800 millimeter monsters that you talked about, I don't need to compromise that with my sram. I can do the SRAM up here and I can use that full 800 square millimeters or less if I wanna be more cost effective for the logic devices and the logic devices only.

And that's allowing a lot more compute capacity to be deployed more cost effectively. The other big application there, pat, that I think of is connectivity. Um, you know, it used to be when you did what you and I would call an SOC, you would have, you know, the compute and, and then you'd have PCI, you'd have your DRAM interfaces all integrated monolithically into a dye.

And we can now push a lot of those expensive, you know, esoteric, I mean, that is a compliment. Analog circuits onto a separate chip. And you can, again, focus your compute investment in the center die and get all of your, uh, n minus one technology utilization of hey, perfectly good enough, 64 gig or 128 gig per second, uh, PCI fis for the, for the latest configuration, or the latest DDR or HBM fis, you can put on a separate d huge, huge leverage in AI in particular.

Yeah. I appreciate you, uh, correcting me. You can do it, you can have an 800 square millimeter dye and you can stack stuff on top of it through, through.

Yeah. It ain't cheap dude, though. You're right.

It ain't cheap. That is extremely expensive implementations. Yeah, we definitely see that with, uh, with memory, uh, for sure.

So, hey, um, it does take a village to be successful as, as a, as a foundry company. I mean, from, uh, tool partners to, um, IP partners, right? Um, to, to really pull it all together so you can have a potential customer that can come in and have the confidence that their design is supported every step of the way.

And it's gonna be, uh, written, you know, nothing is easy, don't get me wrong, but as easy as as it can get. Uh, so they have a decent, uh, time to market. Um, can you talk about on the chip side, uh, the ecosystems, the collaboration, the partnerships you are pulling together, uh, to make this a reality?

Yeah. You, you, you got it. I, this pat, maybe, you know, as I reflect on the transformation of Intel Foundry over the last few years, you know, I tend to jump a lot to, Hey, look at these new technologies we've developed.

We've got these new features, we're driving state-of-the-art, um, maybe perhaps the biggest transformation to the company and the business has been in a necessary embrace of an ecosystem of partners. Yeah. So that we have what our customers need, right?

And that, and just speaking openly, that's not historically what many would consider Intel's core strength, right? Intel had a, you know, Hey, this is how we do it, and embracing companies like Synopsis and, and Cadence and Siemens on even just the A EDA tools. So we're using what all of our customers expect to use.

And in the chip space, embracing IP partners that can put in place standard chip to chip connectivity that, you know, will work, whether we Intel foundry, uh, manufacture the die, uh, but we may be talking to a chip to manufacture at another foundry that has to work. Customers cannot have to worry about that interoperability. So having common partners for IT and standards is really critical.

You know, we've, we've announced a CHIP alliance that has, you know, so many of the familiar names that you would expect on the IT side and the ED a's tool side, but also design services partners, um, uh, even uh, packaging partners. So we went over the announcements we made at our foundry, uh, event, uh, a month or so ago, pat, for the first time, us, as until Foundry, we actually brought the Amcor team out on the stage and said, Hey, if you wanna use our most advanced packaging technology, you know, what we call mib, historically, you've only been able to buy that from Intel, but you've told us customers that you want an ecosystem of partners to be able to manufacture these advanced packaging technologies, and we're enabling Amcor to do so because that's your voice. And that's a big change for us.

It is. And I have to tell you, you know, people talk about the new intel. I think your side of the business embodies the new Intel, uh, a lot.

And, you know, part of it is you have to, because it's other design companies like to really fulfill your vision, you need to bring in new design companies in other than, uh, Intel's, uh, design. That's right. And a relationship, like any relationship is, is a give and a take, right?

You are giving things back to the industry, and the industry is giving you back things as well. And that's just a, this is a, the mature way to look at technology and listen, you know, you're gonna fight like heck, you know, to win as much market share as you can, but finding those smart places to work with others and make it a, make it a, a good bidirectional relationship. You can make money.

They can make money. Um, and, um, uh, you can, you know, walk up into the sunset. Gosh, I'm about to cry here.

Ah, oh My, let's, let's go, let's go find a beach together, man. I'm always Exactly. Hey, this has been a great conversation.

We have time for, for one more, uh, question here. So how do you see, listen, I, it's funny things that are sometimes come up in new on people's radar screen. I'm thinking, that's not new and I kind of ignore it.

But this whole idea of heterogeneous integration, right? Which is essentially, um, I mean, a couple ways to look at this. Heterogeneous can be in, in design, in, in the way that, that, that you do this, it can be just a distributed architecture.

Uh, there's a lot of different ways to look at this, but how will this market, uh, evolve here? You know, it's funny on the, on the mobile side, they're all like monolithic designs, baby, right? Anything that seems to be below a certain threshold is, you know, it's not a heterogeneous design.

And I, and I'm just curious, like, not necessarily even on mobile, but just overall, how does this market play out and, and what is your role in this? I I think heterogeneous means different things to different people. I, I, I love the question.

The way I, the way I see it, pat, is I really do think heterogeneous integration is the inevitable endpoint for us as an industry across all markets right now, of course, you know, as an intense focus on ai, but we've already seen heterogeneous integration in general purpose compute, even in PCs, you know, lo lower MPCs even are using heterogeneous, uh, compute to enable, uh, um, you know, customers to develop products that can address a broad spectrum of, of applications. I have no doubt that we will see this in the mobile space. I have no doubt that we will see this in the automotive space in a variety of different markets.

We can debate the when, um, but my personal perspective is it's going to happen. The economics will demand it, and the, the compute demand and the connectivity demand that we're putting on our products, uh, will, will also demand it. So I think it's, I think it's inevitable.

There's one other aspect of heterogeneous that, that I want to acknowledge. I think that's really important. And it's when I'm actually, I, I truly think we're standing tall as an Intel team in delivering, and, and that is like, my goal is to add value to my customers right now as, as big a company as Intel.

Sounds like I'm a startup in, in the Foundry space. I, I, I'm a startup, so I have to do things to, uh, ensure that I'm adding value to customers. And one of those is, heterogeneous to me is heterogeneous with a capital H I'll put an Intel foundry, die next to P of TSMC silicon or, or Samsung silicon.

Heck, I'll take other foundry silicon and put them, uh, using my MIB technology right. To, to connect them with. And we're doing that today.

So, so heterogeneous for us is about figuring out what the customers want, what, what the market needs and enabling, and, and, and we are investing to be, you know, a premier heterogeneous supplier, because I really think that's where the market's going. Yeah, I think it is too. I mean, to me it's a foregone conclusion on certain types of silicons and certain type of, of market.

I'm waiting for that first smartphone, uh, chip to pop up, uh, and, and have it. But having them in PCs, I think is a, is a good first, uh, step here. So, right on.

Kevin, man, this is great. I really appreciate, uh, uh, your time here. You know, you have a lot more work to do, but you've, you've achieved a lot.

I'm looking forward to seeing Panther Lake. I'm looking forward to seeing Clearwater Forest. Uh, I'm, I'm excited about those, but to be honest with you, I'm more excited about, uh, your Foundry customers and when you start, uh, cranking out, uh, chips, uh, on 18 a, uh, for them, even though I know you're, I know you're, you're doing, you know, on other processes before that, but I'm, I'm especially excited about, uh, 18 a because 18 a i i, I believe is really the, you know, I'll call it the grand opening, uh, for, for, for Intel Foundry.

You know, the doors have been open, but, you know, with customers walking out with, uh, with, uh, the goods is, uh, I'm, I'm gonna put it on my calendar. We see it the same way, pat, we see it the same way. Thank you, man.

This is, I always get energy talking to you, man. I really do. I always appreciate that.

I Hope so the same. I hope you feel, uh, I hope you feel the same. I mean, it, it, uh, I, I love this stuff.

So yeah, thanks for coming on and, and hopefully, uh, we can have you on, uh, again in a few months. Anytime. Always fun, pat, take care.

That was a great conversation with Kevin. Hopefully you loved it. I just want to thank you for attending this semiconductor spotlight for the summit in its sixth year.

We're all talking about AI and with semiconductors from GPUs and AI accelerators to foundries triplet ecosystem, this track is looking at the entire full stack moving forward. com. Stick around.

We've got more insights and executives coming up. Network engineers are a very special breed. They are the firefighters, they are the knowledge bases.

They are the people that make things happen. However, has anybody talked to them recently to find out if they think that still in this episode of the Tech Field Day podcast, network engineers are facing an identity crisis? Welcome to the Tech Field Day podcast, where each episode we bring together a group of IT experts from across the enterprise to discuss a single topic or premise related to enterprise IT Tech Field Day is a part of the Futurum Group, and each episode we feature delegates from our Tech Field Day event series.

For this episode, we are recording on site at Networking Field Day. Before we introduce the premise for the episode, I'd like to take a moment for our guests to introduce themselves so you know who they are, starting with, Ryan. Hey, I'm Ryan Harris.

Uh, I'm a senior engineer. com. Okay, Chris.

My name's Chris Grundman. I am an executive advisor on network infrastructure topics. I also am a co-founder of the Network Automation Forum, Nathan Nielsen.

I'm a solutions architect at Worldwide Technology. I am on LinkedIn and I just created a blog site that doesn't have any postings yet, but it will following this event. And it's called The Route Reflector.

Alright, thank you all very much for joining us. Let's jump into the premise for this episode. A person hunched over a keyboard furiously typing in console commands, holding ethernet cables, praying that the packets will start flowing.

We all know what a network engineer looks like, right? A Dewey really, 'cause in this episode, network engineers are having an identity crisis. It may not be news to you because if you've been involved in this industry for the past several years, no doubt you have heard various forms of technology is gonna take my job.

Whether it's automation, orchestration, ai, you name it. We have really been inundated with a large group of people telling us that our jobs are gonna be redundant sooner or later. But secretly in the background, some of the aspects of our jobs have been changed or made redundant.

That example of someone furiously hyping on the CLI that's considered old school now, uh, now we are spending a lot of our times, uh, reacting with chatbots or logging into GUIs to be able to get better visualization of the network. I guess the question that I wanna pose to the panel of guests here is, do you feel like network engineers have had an identity crisis? I'll definitely say that the, the CLI is very clearly dead, as everybody knows.

Nobody has used A CLI in probably decades at this point. Um, but truthfully, I mean, I don't think this is really that new 'cause I think people have been saying that we have to learn Python for like a decade or more now. Um, and you know, there's, every vendor has their, and their, their centralized management platform that makes everything two clicks and is the super easiest thing that you've ever used.

Right? Um, and some of that is somewhat true, but I mean, to a certain point, I'd say a lot of times, um, still logging into ACL I, I'm still running commands. I'm still doing the same things I was doing 15 years ago.

Um, but then I am doing other things. So, uh, it changes, but I don't think it's changed away fundamentally from where it started. So, anyone else?

Yeah, I don't know. I mean, I think it is very interesting. I think there is somewhat of an identity crisis happening.

I think that, um, at the network automation forum we set out to answer the question, why haven't we seen full adoption of network automation yet? And I think one of the answers is identity. Um, and what I mean by that is we tend to, as, as human beings, not just network engineers or anything else, um, pick up different aspects of our lives as part of our identity, right?

So maybe your political party or your religion or your sexual orientation, or there's all kinds of things you can adopt into your identity. Now. They don't have to be part of your identity.

You can let them go. Um, well, theoretically anyway. And I think that, um, for a long time network engineers have tied their identity to their ability to function on the CLI.

That doesn't necessarily mean that's going away, but things are evolving, I think. And so when you look at, you know, from the question of why hasn't network automation taken off more, I think one of the reasons is that we were kind of trained to believe that our ability to work quickly on a CLI is important and is part of, you know, we've adopted that as part of who we are. Uh, I think it's kind of like, um, we were talking about the industrial revolution earlier, and like the second or third industrial revolution was when assembly lines started coming out, right?

And all of a sudden people who had, you know, be, become artisans and craftsmen of like, you know, filing down pieces to put sewing machines together, um, wasn't necessary anymore because we could manufacture parts that were high enough tolerance that you could just put them together without having to go in there and do all that artisanal handcrafting. And I think that as we, as networks become more and more fundamental, whether they're becoming commoditized or not, I think part of making the network more reliable is making it more standardized. And as you make it more standardized, there's less room for the arts and crafts of, of, you know, putting this thing together in a very special way.

And really one of the ways to make the networks more reliable is to build them the same every time. Mm-hmm. And so that can infringe on this identity that like, no, no, it was my brain.

It was my hands. You know, that, that created this thing. And if that goes away a little bit because of just standardization, um, I think that can take a hit to people's identity for sure.

Yeah. I, I definitely, uh, agree with that. I, when I was packing to come out here, I found I still had a console cable in my backpack.

Right? Just because that's what it's, it was natural for me to know that, hey, when I go somewhere, I may have to get out and connect to something and, and get something going. Um, and I, I've also had had jobs where it was, um, you know, I was the one that that knew where all the skeletons were hidden.

I was the one that, that knew this network inside out. And I, I was needed. Right?

There wasn't, there wasn't something that could come in and replace me. 'cause I was the one that knew everything. And, you know, and, and I really, I claim to fame is not the right term.

'cause I'm not famous at all. But my, my what really, like kind of set me apart in my career and made me successful was my ability to jump on a command line and really just bang out some, some troubleshooting or, oh, we've got this outage clear the way I'm gonna, we're we're gonna get this up and going, you know? And, and now I, I mean, I thought it was really cool when, when, hey, we can have secure CRT up.

I've got 15 tabs open and I can type this one command. It goes to 15 switches at a time. You know, I thought that was, that was useful.

There's also danger in it though, right? Because maybe some of those tabs shouldn't have been open and I shouldn't have pushed that config. But then really this, the, the whole automation movement, you're right.

That was the first time I heard like, oh, automation's gonna take our jobs. Adoption is something that I have personally struggled with. Like, I feel like, um, I mean, yes, I have, I, there's an orchestration platform.

There's, there's a tool that I have to where I can, I can come up with templates, I can standardize a config, I can push this out. And now that I'm on the partner space and I'm, I'm going from one network to another network, to another network, to another network, it's, it's really helpful to have some sort of normalcy between, and I do feel though, that I'm, I fall behind in areas where, okay, yeah, there's, there's orchestration happening. We're we're using things like, um, you know, netconf to, to deploy configs to these devices.

But there, there, there's an overlap. Like that line started blurring between developers and, and network engineers during this, this whole automation movement. And there's times where conversations are a little over my head and, and I'm, it's a networking conversation I'm having with the networking team, but we're talking about things from like A-C-I-C-D perspective.

We're, we're talking about these this way that we've got this, this tool automating this one function. And I'm like, okay. I, I think I sorta get that.

But so my personal identity crisis there is like, man, I, I don't, I feel like I'm falling behind on something that I shouldn't be falling behind on because I don't know automation like, like Chris and, and others do. So that's, you know, am I in the right spot? Am I still doing the right thing?

Am I gonna be obsolete here in a little bit if I don't keep going this way? Or is it this thing that I need to learn now? Like that's the, that's the crisis that I deal with.

Yeah. I think it to, to Ryan's point though, it's not new. I mean, I remember 'cause coming up from like an ISP background and building service writer networks, so like, you know, learning BGP and OSPF and ISIS and really getting hardcore into, you know, deep networking topics, uh, I had no idea how DNS worked in the beginnings of my career, right?

And I had, and then I had to learn that because there was reasons, you know, that that actually impacts and networking things. And then later on I had to learn more about how applications work, because that's what the network and the data center was there for, or how, you know, printers work because on the campus network, you know, so there's always been this kind of growth, um, at least for me anyway, where I've always kind of, I've always felt to some degree felt a little bit behind. But I think that's also part of working in technology, is knowing that, you know, things are going to end, maybe you get really, really good at, at a particular piece of hardware, a particular piece of software and or a particular methodology.

And then, and then that changes, right? You can kind of get into these dead ends and things like that and, and being able to back outta that and learn something new. I, so I guess what I'm saying is I think that learning and getting better and growing, it should be part of the identity.

And if you, if, if that's the main part of your identity, if, if growth and learning is how you identify yourself as a network engineer, then maybe you don't have an identity crisis when these things come up. So I think, uh, for me, a lot of like the identity and of the identity crisis is, uh, FOMO in a lot of cases is seeing what other people are doing. And, um, they're not doing the same things that I am.

Right. Um, you know, I, I go online and I see, uh, you know, people using, uh, you know, doing chat ops and like rolling their own stuff and like dealing with, uh, you know, LLMs and doing some really, really cool stuff there. And then other people are really diving deep into different, you know, automation, uh, realms.

And then other people, you know, are going off on other paths and, you know, doing data center network in which, you know, I've dabbled in, but I don't do that day-to-day. And, you know, six months to a year later, you know, I haven't touched that. It's like some of that's forgotten and, or something has changed.

There's a new big thing that came out, or I didn't keep up with that vendor's product announcement. I didn't hear about it or whatever. It just didn't cross my, my radar.

And then now it's sometimes I feel like I'm like, oh my God, I know nothing anymore because missed the boat because I missed that boat. Or like, I mean, on some of the things it's like, man, can I even contribute? Can I even learn this stuff now that everybody else seems to know everything else so much better than I do?

Um, but in reality, it's, uh, I'm trying to compare myself not to one other person. It's to 50 other people that I'm seeing them all do cool things. Right?

Exactly. And I'm comparing myself to 50 other people. That's such an impossibility to, to really go after.

And that's sort of where I see I have to catch myself and stop and think, like, no, no, no, you're doing something. It is interesting what you're doing. Um, and it may not be the, the most cutting edge stuff that I'm doing at times.

Like that's just the reality is of having a job is that companies don't, they're not like, Hey, this is the new thing this week. Do it now. Right?

That doesn't always happen. Sometimes it does, but not always. So let me ask this, because I think we kind of, we've, we've jumped ahead to something kind of, you know, obviously important, but we missed a step.

What, what does a network engineer do? Like I, because in order to have an identity crisis, you must first have an identity. And I, you're already leaving the YouTube comment.

I know, I understand. It's totally okay. But there are a lot of things that network engineers do that they probably shouldn't do.

There are some organizations that treats network engineering, like advanced network operations, or you guys are the, the troubleshooters the firefighters. But is that what everybody should be? Is there a template for a network engineer?

Because as soon as you say, well, I'm, I'm not doing the same things that other people are doing, or other people are doing cool stuff, and I don't, that to me says that there isn't one standard definition of a network engineer. I think that's precisely it. Yeah.

I think, yeah, I think that that touches on something which is that, um, you know, one simple way to look at evolution is a path towards specialization, right? Um, the way that evolution works in biology is that things become specialized for a niche. It doesn't mean that necessarily better or worse than anything else.

They're just more adapted to survive in this little niche, right? And they get, they get specialized into that for whatever reason. And, you know, to kind of, to your point, um, you look at, you know, a network engineer who's working for an ad tech firm versus a network engineer who's working at a hospital versus a network engineer who's working, um, you know, at, at a retailer, the very, very different structure of what they're doing, right?

Within the same kind of realm. And then even within that, you, you mentioned like it was an engineer operator. Well, then you look at that right, too.

And if you move from network operations to network engineering to network architecture, that can cause an identity crisis as well. Like, oh, you know, if you're doing architecture, sometimes you're talking about how to integrate systems with each other versus how to actually configure this on one device. And so just moving or moving into management, right?

We're network engineer moving into management, that can create another identity crisis. So I, I think these things are fairly natural. Um, and, and I think it is hard to define what a network engineer does, especially if you look at that stratification, right?

What, you know, is a person working at the tier one help desk at an ISP, are they a network engineer or not? Or is it only the person who's actually, you know, building methods of procedure for an enterprise? Or, you know, what does that mean?

That's a really good question. What, what is the identity of a Network engineer? Yeah.

Yeah. That as I'm, as I'm think like chewing on that, I'm thinking of, like earlier in my career, we, we, we joke that some of the people that worked at this one place only knew networking from this company's perspective. Mm-hmm.

They didn't know this company's network from a networking perspective, but that didn't make them any less of a, of a network engineer. They were supporting the network. We, and it was split into like an s and an engineering team where we had day-to-day operations, but we also had project engineers doing projects, but they were, they were only familiar with the way that it was done here.

So yeah, that, that definition is, is definitely gonna vary. I mean, we, we constantly say, when, when we have customers come to us and they're, they're asking, you know, which, what is the right answer to this particular thing? As much as they hate hearing it depends.

That's almost always the answer. It depends. Like it's, there is not a one size, one solution fits all.

As much as we wanna standardize on stuff, follow best practices, there isn't going to be a, a deployment that's exactly the same from one to another. We'd love to get some standardization within an enterprise where there's repeatable tasks and stuff. But yeah, I think, I think defining what that is, it, it's a really interesting take on it.

Yeah. Because if you, sorry, if, if you're, We are constantly evolving, right? There is something you can't stop learning at at any point, or you, you will become obsolete in one, in one way or another.

Um, and, and I think part of my crisis right now is that I've, I mean, I'm, I'm not kidding. I have eight books stacked up on my desk right now of things where I'm like, oh, I really need to learn that. Oh, I really need to learn that.

Oh, I, and now there's like so much stuff I'm like, man, which one do I even open up first? Or how do I, and it's all kind of like, okay, I feel like I need to know this stuff because if I, if I don't, I'm gonna be behind. But kind of like what Ryan is saying is like, man, I, maybe I am comparing myself to 50 people that are really amazing at something.

And I, I don't need to read all nine of those books and understand 'em completely if I'm going to, if I'm still gonna be relevant in the, in the career field. So I'll also say that, um, you know, I, I started in networking right out of high school, you know, I got my CCNA at like 19, I think. Um, and you know, in, uh, the 15 years that's passed, um, you know, I was a network engineer then.

I'm still a network engineer now, but those two roles are so wildly different that like, it really begs the question of whether or not, uh, was was I a network engineer there or am I still now, like, what is, how do you define that? It's such a vague term. Yeah.

You could probably like put a more, uh, specific role on or or title on any of the number of jobs I've had in those years, or, um, you know, and like, yeah, technically you were this at that time and this or whatever. Maybe you weren't a network engineer at 19, um, which is maybe a fair, fair point. But, um, who knows?

I mean, I'm not gonna say one way or the other. Um, but, uh, you know, I guess the question is like, is it an identity crisis when you're like really putting it a, in a vague thing and then your job or role changes? Well, Let me phrase it this way because maybe this will kind of help.

I'm gonna give you an example of two other professions where people are considered to be highly skilled doctors and lawyers. I'm sure everyone out there on the internet will agree that all three of those professions, network engineering doctors and lawyers see change. But I think one of them sees more change than the other because a doctor is gonna learn new healing methods, they're gonna use new technology, but the human body doesn't change that much.

I mean, it will eventually over time, but the human body 50 years ago is pretty much the same human body that we have now 300,000 years ago. Yeah. Lawyers have to memorize a lot of information, and there are ways to interpret the information that they have, but by and large, the law is a very slow moving thing.

Even when you're making new law. It's a very, um, slow process because we have to debate, we have to discuss network engineers who started out doing this 15 years ago, probably know things like ISDN, route maps, um, a whole bunch of technology that by and large doesn't exist anymore. Network engineers started doing this five years ago, probably have a very, uh, unique skillset that is not immediately applicable to everything that we do today.

I mean, think about the number of people who specialized in SD wan. Are they still needed as much as they were when SD WAN was the thing that everybody wanted to deploy? I would argue that one of the reasons that we have an identity crisis in the network engineering roles is because the technology that we want to specialize in, in our evolutionary roles gets discarded so fast that we almost have to be generalists.

We have to be general practitioner doctors in order to not be put out to pasture more quickly. That's a really interesting way to look at it. And I, and I think one of the reasons is 'cause that, that forces us to zoom out, right?

And if, if you zoom out and look at it that way, where you, if you lump doctors together and you lump lawyers together, then you almost have to lump technologists together, right? Right. If, if you're looking at that kind of societal level, we, you know, because within doctors, there are all kinds of doctors, there are neurosurgeons, there are general practice doctors, there are er doctors.

Um, and then you, like, I think all of, like the nursing professions probably get wrapped up in there somehow too, as well, right? And lawyers, there's trial lawyers, there's contract lawyers, there's civil lawyers, and there's criminal lawyers, and there's defense versus, you know, prosecution. So I think network engineers is actually a subset of this bigger bucket of technologists.

And so if you look at it from that realm, it, it gets really interesting as like, where, where do you hang that identity? And why are you hanging it on the network? Um, and maybe it's because the amount of skill required, like you can't be a completely full well-rounded technologist.

I dunno if that's true or not. You know, can you, can, you know, can you actually be a, you know, a technologist in the way that you can be a lawyer? Um, and maybe that sounds just as silly to a lawyer as it sounds to us.

Well, I mean, it does sound silly because we have a term for that. It's called a full stack engineer Unicorn. Yeah, Yeah.

Yeah. I've also, you also hear the term the, the jack of all trades and master of none. You know, like that's, if, if we are working towards specialization, like we, but we can't ignore all the other things outside of our specialization or, or we're, like you said, we're at risk of being put out to pasture.

If that was that one thing that our entire existence depended on what happens when that one thing goes away. Telecom engineers. Let me ask you, uh, so I see this question pop up on Reddit, um, Shout out tell of our Reddit list.

Yeah. Uh, that, uh, people will go, am I a senior engineer? I'm like, I don't know.

What Does your business card say? Yeah, Really? Like what did it say On your offer letter?

Look? Yeah. Like, it's a title, but it's also kind of like something people identify as and Like Absolutely.

I'm more senior than that person. And I've gone, you know, in my, my roles, I've gone to a lot of different companies and like, I've met people that are just, they call themselves network engineer, no senior on it. And they're, they're rock stars.

But then I talked to other people that have senior engineer in their title, and it's like, nah, dude, They, they've only got called senior 'cause they've been doing it for two years. Exactly. They, they themselves are senior.

Right? Right. And, and that is an important point to bring up is because there's often a situation, and we've talked about this on the podcast previously, if you wanna check out the episode that we recorded back in February about technical management roles, sometimes people end up as technical management because there's literally nowhere else for them to go.

And senior engineers, senior architects kind of fall into that same problem. You've been here for 10 years, but you're a hands-on person and you don't wanna be management. So what are we gonna do?

We're gonna make you a senior. Is it really that case though? And I think that the difference between the two is very easy.

Who do you go to to ask questions of? And who goes to you to get their questions answered? If the answer to the first one is not very many people, and the answer to the second one is almost everybody, by definition, you are the senior person.

Mm-hmm. You know, it's, it's like being the top sergeant in a military unit. Your job is to solve everybody else's problems.

And that helps the identity problem, right? Because one of the things that we see quite often is we are so busy trying to keep our skills up that we might miss something unless it's staring us in the face. Maybe it's a new methodology for deploying a network.

Maybe it's a new technology that a vendor has told us about. Or maybe it's just the fact that we missed the boat on automation because we were so busy with our heads down typing that we kind of forgot that there's a better, faster way to do this, that we should have been learning all along. And it takes someone who's not as skilled as us asking the questions that make us stop and say, wait a minute, maybe there is a better way.

So could it be that one of the reasons that we're having an identity crisis, going back to what Ryan said is we do have that fear of missing out, and because of that fear, we really are missing out on things. It's interesting, and, and also to me, it draws into, it's a little bit, a little bit different, but this idea of, of kind of specialization versus generalist, right? Than Nate, you were talking about kind of that ma you know, jack of all trades, master of none.

I think there's also a lot of value in that. Um, and there's, um, there's a group, uh, of academics in, in Santa Fe, New Mexico called the Santa Fe Institute, and they study what they call complexity science. And a big part of what they talked about is like, Hey, the academic world, scientists have gotten so specialized.

They're like, you now, like get a PhD in, you know, the, you know, the, the a specific medical condition that happens to a specific flea that lives on a specific bird that lives in a specific area, right? And that's, and that's what this person knows all about. And they know everything about that, but they don't know anything else.

And these folks at this, uh, Santa Fe Institute are talking about this idea of complexity, which basically just means interconnectedness. And they say, okay, well actually, like biologists can learn from physicists. There's no reason why we can't apply the logical tools that biologists are using in physical sciences or in chemistry and this kind of cross pollination, which then, you know, kind of forces this idea of generalism, which I think to Tom's point, injects these new ideas, right?

If I'm, if I'm only focused on configuring Cisco Catalyst switches, then sure, I'm gonna miss some stuff. Now, one, you may, that person is very valuable, uh, at least as long as those switches are around, because they, they know that thing really, really deeply. But there's another piece of value, which is the person who can say, okay, actually though, this is how BGP works, no matter what you're using.

Mm-hmm. Uh, and there's another person who can look at it and say, actually what matters is getting the packets from that server to that person. And we don't care about bgp.

It could be anything in there. We just wanna make sure that connection happens. And In fact, you're going back to your argument of becoming more specialized, but having the not princes of mind to step back and not be as specialized to understand the greater goals that need to be accomplished.

We talked about like the T-shaped engineer, right? Where you, you have your depth of specialty in one area. Mm-hmm.

And then you've got this broad thing on the top. Yeah. Um, when I was working at Cable Labs, our, our CEO there, who came in, who was a big guy in innovation, Phil McKinney, and he talked about, well, you need to, you actually, the T-shaped engineer is not enough.

You need to be a pitchfork engineer, you need to have several parts of depth. And some of them are not as deep as others. And then this broad piece on top that kind of connects it all.

So you can see this big vision, you can dive into the areas that are, that are needed. Uh, and some of this just ties back to what are you doing right now? Mm-hmm.

Right? To your point, Nate, about, you know, am I gonna miss out? Which books do I need to read?

That kind of thing. Well, if you're working on a network and it works in this way with these tools and you get really good at that stuff, you're probably doing all right. It doesn't, you don't necessarily need to know what the guys over the fence are doing now at the same time, knowing what they're doing may help you improve what's going on here.

So it's, it's a really vague area. It's really hard to pin down like what's the right path. And I don't know that there is one.

So again, I, I go back to what you should identify as is a learning, growing human being. And in that case, like it's really hard to have an identity crisis whether you have to learn Python or not. True.

Yeah. I couldn't agree more. That's, I really like that the, the pitchfork analogy there.

'cause that the, it made me think about something, one of the areas that I was highly specialized, and it wasn't a, like one area was, it was more like a, like a three-pronged stool where if you didn't know all three of those things, you really couldn't consider yourself a, a specialist in this area. So it was getting deep enough in these three where I could, I could build the whole stool, but if it got something where it was over my head in one of the areas, like, like I'm, and I'm referring to like campus fabrics, where you have, you have a wireless component, you have the route switch component, you have a security component with your, with your N solution. And if, if you're not well versed in all three of those, it's gonna be a struggle for you to keep up with any of them.

But if there is like a, like a sure enough wireless issue that needs to be addressed, I'm not the guy that's gonna do that. I, I can get your APS online, I can get your endpoints identified, that sort of thing. So I, I, yeah, I like that.

This, this has helped me out a lot, really, like just sitting here at this table and talking through my, I've gotten a better, less insecurities. I, i, I would say, because it, it's something that may, okay, the three of us sitting here are not gonna have the exact same identity in, in the roles that we're at and the, and the point that we're in our life. So is that, is that necessarily a crisis or is it really just figuring out your definition?

Like what, what it means to you to be a network against engineer? I remember earlier, like the first time, I gotta put that on my signature, on my email title. I was like, I mean, it was, I think I've used a bigger font in my network engineer thing just because I was like, I all caps, I am it, I finally made it.

And now it's like, yeah, what does, what does that mean? But it doesn't, it doesn't have to be a data center engineer or a a, a network automation engineer. It could be a combination.

It could be something in between, but it's something that, that holds value. I mean, we're, I think if, if, if anything people have, uh, something I'm hearing fairly common is, you know, is the network engineer going away? No, it's not possible.

Is the network going away? No. So the network engineer is not going away either, but it's gonna, it's gonna change and evolve and Yeah, absolutely.

I was gonna say, um, the, the management of networks, you know, 15 years ago, you know, the early, uh, 2010s right? Was still very much at just about every company. Uh, you logged in via SSH to a, to a switcher or router, and you made a change, right?

Very quickly. It was then, okay, now we're, you know, you've got some script or, or whatever. Um, and then, you know, then there's, or NMS Yeah, you Got, you got some other tool now that's doing things on a, on a mass change basis type of thing.

But I mean, like that's changed. But like, it doesn't also change the fact that I still need to go back onto a CLI sometimes I still need to have all that base knowledge of how everything works. Like I can't automate something that I don't know how, how it works.

Like you gotta understand it to automate it. Yeah, understand. So has that fundamentally changed like my knowledge or my ability to do my job because I can't, you know, just 'cause I don't do it some way doesn't mean I just don't understand it.

I would argue that maybe the problem isn't that we're having an identity crisis as network engineers. I think the problem is, is that everything around us is changing so rapidly that we're just trying to keep up and to the point that a lot of these gentlemen made today, you can't stick your head in the sand and hope for the best. We've said the quote jack of all trades, master of none.

But I think the complete quote is just as important. Jack of all trades, master of none, but off times better than a master of one. So you have to make sure that you're being aware of everything that's going on.

Even if you don't have a full t or pitch shaped fork, uh, pitchfork shaped, uh, knowledge depth on it, you still have to be aware of it so that you're not caught off guard. Because one of the things that we've learned in network engineering is that all of those ideas come back around eventually, and that's when it's time to figure out how to use them. That'll just about do it for this episode of the Tech Field Day podcast.

I wanna thank h and every one of you for listening. Don't forget, you can subscribe to our podcast on our YouTube channel, on the tech Field Day plus YouTube channel. You can also subscribe in your favorite podcast application of choice.

Just check out the Tech Field Day podcast. com/podcast. And you can also check out the list of events that we'll be doing and uh, recording podcasts at.

We'll be back next week with another great episode. Until then, stay tuned and thanks for listening.