Techstrong TV July 7, 2025
Watch our live stream Monday through Friday, featuring exclusive news, announcements and conversations with IT leaders and experts on topics ranging from digital transformation to #DevOps, #Cybersecurity, #CloudNative, #Containers and deep-dives into specific technologies and best practices.
Transcript
Hey everyone, thanks to Microsoft. We actually compare into the black box. That's AI coding.
Maybe you're watching Textron game. Hey everyone. Happy Monday.
That's right. Monday for a lot of you is a long weekend on July 4th weekend. It's a pleasure when July 4th is on a Friday and you can get those great weekends though.
I prefer a Monday 'cause I like to get off Mondays. There's something about getting off Mondays that just gets me off. Anyway, um, happy Monday to you.
We've got a great text on gang for you. Let me introduce you to our fantastic panel. Most of them have been on the gang before, so you know them is the one and only Lisa Martin, the infamous famous man about town.
Ira Winkler, our man in Silicon Valley. John Swartz, the Dean, Mike Ard, and a new gang member to introduce you to today. And I hope I say her name right.
I've practiced, but you never know. Chaa Gun. Am I close?
Chaa? Hi. Yes, that's right.
You got it. Alan Chaa. Tell people a little about yourself.
Sure. So hi everyone. Thanks for having me here.
Uh, I'm a DevOps interest over 18 years now. I graduated back in 2007 and luckily I entered the industry when DevOps was still evolving. We used to known as Build Engineers that we got converted into sre, then it was DevOps and now it is ML Ops and secure Ops and whatnot.
Um, so I'm here at Amazon for five years now. I worked with various industry companies, for example, NetApp. I worked through Chatter partners for Cisco and back home Bosch, uh, for a couple of years.
So that's kind of little bit about my background. Fantastic. Welcome to the gang.
You're gonna be a great member. We appreciate you. Mm-hmm.
Ira, Mike, you, I'm sorry you hear people graduated 2007. Yes. You know.
Good for you. Alrighty, let's move on. So Mike, uh, our first article to, or our first, uh, our first segment today has about an article up on Dev.
com stuff today, but this one is regarding a big news from Microsoft. Uh, they open sourced, uh, a piece of a piece of software that lets us peer into how AI actually does code, how AI produces code. You know, this has been a bit of a black box and a, a sticking point for a lot of people who don't under who wanted to understand how is, why is AI writing the code the way it is?
What, how is it writing the code the way that it's writing for good or bad? Mike, I'll throw it over to you. Yes folks, it's hard to believe I know.
But Microsoft is setting an example. Things that we should follow, things we should consider here. There is this AI editor that they are now making available as a under an MIT license for that matter.
And that's the AI editor that they use to create the AI coding tools. So now you can see exactly how this thing works and how it's actually constructing that code. And more importantly, I think, I think the tools that we have out there are gonna want to peer into that so that we can observe what's happening here.
And it's gonna be consumed more by, uh, observability tools that we use to kind of see what's going on all across our pipeline. Not sure how much each individual person wants to dive into that level of code, but the level of transparency is improving. Alan, is there hope for us?
Well, let me give you the good, the bad and the ugly. You know, the good is, as you said, code, kudos to Microsoft, right? They open source it and not only did they open source it, they put it out under an MIT license, which is one of the most open, if that's not too many, opens in one word sentence for you.
One of the most open licenses there is, it virtually allows you to do just about anything with it. Um, so kudos to Microsoft for doing that. And as I said before, I threw it over to you, Mike, you know, a lot of people have been wanting to get peer into the black box of how AI actually thinks of how it does what it does.
If, I don't know if thinking's the right word. I don't think reasoning is the right word either, but how does it work, right? How does it, you ask it to spit out code that does this?
How does it know what to write and how does it write? So now we actually can peek in and, and maybe see what, you know, what goes on behind the black curtain. There is the wizard pulls the, the levers.
The bed is like most open source code. No one's gonna look at it, right? It, it's almost, maybe it'll be comforting to know that we have it available, but who, you know, looking at it, uh, and then understanding it, that's even a smaller percent.
You probably count the people on like your fingers and toes. So, you know, it, it's a great thing for freedom. We just had July 4th, you know, so freedom, like Richie Haven said in Woodstock is a motherless child.
And, um, but how many people are actually going to, you know, use it, I think will be remain to be seen. I think, Mike, you're right, people who may be like collecting analytics and wanna see, you know, broad percentages of how code is derived via ai, they may use it for sort of research projects, if you will. I, I, Yeah.
Alan can I, oh sorry. Can I jump in quickly? Sure.
Do it. I think you're missing a complete group of people who are gonna look at it. And these are criminals.
You're gonna have a bunch of people who now, since it's open source, are gonna look at it to find vulnerabilities. That's number one. 'cause if you have open source, you know, it's easier to find the vulnerabilities.
Also, if it's open source, um, you got people fixing it, you got people enhancing it, but the security checks going in sometimes don't take top priority in fixing. More important though, I can promise you that there will be criminals who take this open source software, do the features that are supposed to help the community and then embed malicious software using those same features and then put it out and distribute it like it's a legitimate code base. And this has happened with library programs, it's happened with other open source compilers and everything like that.
And even if somebody takes it writes an enhanced version, somebody can compromise that legitimate good enhanced version and put malware into it because ugly, There's not check. Well that's ugly. There you have it.
That I should have thought of that actually, IRA, but there you have it. That's pretty ugly, right? And it's why we can't have nice things.
John, let me ask you about this 'cause you're closer to this than all of us, but what's your take on what's going on here? Um, my take is, um, I think they should have done it earlier because this is not the first company who have done the open. So we have had deep seek, had their model out right from the day one.
So I personally feel they should have done it long ago. Uh, the model outsourcing. And the other thing is I feel they have taken the financial advantages of being upfront in the AI for a long term.
And now they're looking for more ideas to make it better in terms of the features that the developers are looking for. And the reason I've been, um, giving this feedback is because I've been talking to a bunch of college grads who are entering the workforce for the first time, and they asked me, CHAA, we have not coded without ai, so how do we code with the air? You know, a world where we are not allowed to use this model because not many companies are going to allow the open source AI model within the workforce until it's scrutinized.
So that is a mixed conversation about it in terms of the open source versus the responsibility of it. I I, it's an interesting point. I Think one of the things that I've consistently heard from folks is that it's very hard for them as humans to debug code written by the AI because they don't know how it was constructed in the first place.
So let me come back to CHI on that. But can we maybe get better at at least understanding what the AI is doing and make it easier to debug? Because folks are, a lot of people are saying, I just assumed right it myself, at least that way I know how to fix it.
Chi is that question to chi or mic? Yeah, I thought so. But Chaya thoughts?
Yes. So the thing is now the space is getting slightly better. People are trying to understand what the models is looking for examples to get the code trend right.
And that's why when we have multiple such co-pilots, such co coding assistance, they can pick a model that will help in the right direction. So I feel there is a, there is a information out there and how to make the right judgment call in terms of the usage. So I, I wanna distinguish though this compared to let's say open seq, yes, the researchers behind Open Seek did open source, open seek, but I don't believe they open source something here that gives you a picture into how it actually reasons in, in terms of developing code.
I think with open seek, the, the, it was about how it was trained, right? And how it was, uh, you know, they did it with less ener, less energy, less hours, less time, right? It was a, a more efficient model, but I don't know if they gave you, if the, if the code generator, if you will, was was in fact open sourced.
To clarify, you're talking about Deepsea, right? Deep Seek. I'm sorry, what did I say?
Opens seek, was that an open, open seek? I was wondering. Yeah, no, it was open seat.
Wasn't that one of like the search engines before Google or something? I don't remember. Oh yeah, no idea.
Yeah. No. Anyway, deep that's that, that was it.
Yes. Deep sea. But, so I don't know if, if they in fact open source this aspect of, of the model of the John, I Have a question for you.
Does this force all the other players, and especially open AI to kind of come around on this same issue as well, and will everybody fall in line? I think because Microsoft's doing, and I think it's naturally we'll see open AI probably follow the same path in terms of as, as a competitor. Um, yes, I think it will.
And because what this is a, uh, me too race in a sense. We have people jumping from one track to another, whether it be acquisition, whether it's philosophy. And I mean, one thing I I just wanted to point out just ki kind of looking from it as at a higher kind of far away level, this passionate level is, it's interesting to see this evolution of Microsoft from this, you said earlier kind of like this me too company to JRI say almost a trends setter of sorts.
Although the open source approach here leverages the same community dynamics that made BS code a success. But again, um, I think the change of tactics, and I think what we're seeing, and this is a microcosm, are these companies trying to find some sort of advantage, some sort of edge to, to get a step ahead of one another and then they're gonna follow one another and it's gonna be this kind of path race that goes on and on. And we're gonna see this in other developments involving DevOps, security, whatnot.
So this is gonna be part of a, a larger trend, I believe. And it's interesting to see Microsoft for ones trying to lead in a certain area when usually they're the followers. I agree with John, I think that's what it is about.
It's, uh, the thing that I also wanted to add with this open AI and Microsoft partnering, uh, kind of going in a different direction. There are resources moving around. There are a lot of open AI engineers going towards meta.
And then because OpenAI is stepping away from, uh, Microsoft, they need to come up with more ways to handle this, which they have built over the years. All right? So as a guy who writes a lot of these articles, I'm kind of hoping everybody will just do this all at once.
I mean, save me a lot of time and trouble next week and around noon would be good and everybody just, and then announcement and call it even, alright, That gonna happen over like a par Mike, this is gonna happen over a period of six to nine months. And you're gonna have do a story that updates what happened before and, and it's not like gonna all happen in one fell swoop. Is this gonna, and they're all gonna do it at different timing and try to present it as if it's something unique that only they thought of.
Come on, if we all know the end of the moving, can I just fast forward? Let's go. Yeah, I wish We could, makes life easier for us.
Yeah, You want, it's the journey, not the end. Sometimes it's a repetitive journey or derivative, it seems. Yeah.
But again, everyone could rush headlong into open sourcing this. Mm-hmm. But as Iris said, it, it may just benefit the, the ones who benefit the most may be the people we least want to have access to that.
So Yeah. Ira, do you think the security people or the bad guys at least will contribute fixes to the project once they get to know how it works? Let me tell you a true story.
I once had a, a CSO from a Fortune 20 company give me a call and they're like, IRA, I think I have China all over my network, but I don't know what to do about it. I'm like, why do you think this? It's like all of a sudden all my vulnerability reports are coming back clean.
So, and it wasn't the network operations team, it was like, uh, you know, a malicious actor basically came in, updated all the systems so other hackers couldn't come in. But also they needed the systems updated for their, the latest version of the malware they were implanting. And they thought that people would never notice this.
And frankly, they didn't notice it until the security manager noticed this. And I think what's gonna happen is, unfortunately the bad guys are the people who have the most to financially gain. Everybody's gonna pat themselves on the back.
The open source people are gonna be rah rah, rah. But the bad guys are gonna be seeing dollar signs or intelligence data in their shiny little eyes. And they're gonna go ahead and put out their own versions of this, if not figure out how to exploit the code.
And I'm telling you, that's gonna come a lot quicker than you think, Unfortunately. All right, let's take a break here on TechOne Gang. We're gonna come back and talk about DevOps in the age of ai.
Got a lot of articles behind this one you're watching Textron Gang Discover Textron Group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us will access editorial websites, streaming videos, virtual events, custom content analyst research, and more.
Join our satisfied clients, let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group. Hey folks, we're back in.
We're gonna have a little conversation about DevOps and the age of AI because we've been debating this back and forth, and fortunately we got to talk to some folks about what they're actually doing in real life. Sean Tyer, who is on a previous episode of the Techstrong TV channel, so go find this, but we're gonna run a little segment of this interview where he talks about how Mondelez his company, or at least the one he works for, is using A WSQ inside their software engineering workflows to think make things more efficient. But it doesn't sound like maybe we're replacing DevOps engineers anytime soon, at least from his perspective.
And by the way, if you don't know who Mondelez is, look in your kitchen cabinet, you'll find Oreos and Cliff bars, and those are the guys who make those. Anyway, let's see what Sean says. Everybody's talking about one of the implications for the future of application developers.
And um, on the one hand, some people will say it's just gonna make the developers more efficient and they'll still be with us, but they'll be in a different kind of role, more of an architect. And more, and much more of the code might be written by a machine and others are saying, you know, eventually the machine does everything. But where are you on that spectrum?
I think I'm probably leaning more towards the, we're always going to need people who are really good problem solvers and are able to define problems in a way that they can be solved effectively and securely and efficiently. Um, the actual work of a software developer or a cloud engineer on my team has already begun to change where we're relying on AI agents and assistants to do more of the work with us and for us. And I think for me, in many ways, I'm seeing my team use these tools to help automate kind of the boring, tedious work, right?
Reapply the things that we've already learned. It's hard to predict. I don't think anyone can where this is going to go in the future, but I'm leaning more towards the, uh, uh, side of I'm always going to need engineers.
I'm always gonna need people who know how to solve problems, how to define them well. And regardless of the tools that they're employing and I'm providing them with, I'm gonna still need those kinds of individuals in my organization. All right, we're back in China.
You two are close to this. And the question has been going around all this time is, does AI replace DevOps engineers and software engineers or is it just gonna change the way we think about building software? And if so, how?
That's a good question. And I do feel that there are, the changes are coming there, there are two aspects of, uh, agent ai, not just AI about the agent care. And in DevOp it's going to help and it is helping a lot immensely with troubleshooting network debugging, security aspects of it, federated learning, but there's also other side of it, which we still have a lot of work to do, where we want this agents to handle the infrastructure dynamically.
And that's where I think, um, the experienced specialized DevOps engineers are still needed in terms of what automation we actually need so that we don't blow up the infrastructure, right? You can have an agent AI go and spin up hundreds of in instances when as a customer you may not even need it. So there is a need of supervised learning.
There is a need of, uh, structuring the process, but it is definitely, even, I am a extensive user of it, it is helping a lot in terms of debugging, in terms of collecting the information from different sources. For example, I'm a heavy MCP user, so what I did is I build various MCP servers and connect it with q and it is giving me a summarizing information, which is helping me a lot to kind of debug in terms of any event that I want to take a look at it, Right? So if we think that through for a minute now, and we've talked to DevOps engineers for years, and every one of them always says the same thing is basically, I'm overwhelmed and I can't keep up.
So at the end of the day, does AI kind of just make this a job that you can actually accomplish because there's gonna be more software than ever, but it seems like all the AI advances lately are for the developers and not much for the DevOps engineers. Uh, that's not true completely. If as a DevOps engineers you are very well aware of the capabilities of ai, it helps, it helps a lot, uh, in terms of summarization part especially.
So you can, uh, place automation in place to collect your logs, to have your network monitored, especially in the observability aspect, it is helping, it'll help a lot if having said that, it does require a little bit of ramping curve in terms of the knowledge base, especially DevOps deals with. Absolutely. And look, here's the thing, right?
And, and I'll mention, uh, not last week that we prefer as a platform con in New York. And, you know, there's a lot of where they started off a little adversarial. There's a lot of overlap and cooperation now between the platform engineer and DevOps engineer and and so forth.
When it comes to ai, it's, it's a gen AI that's gonna help the DevOps engineer and the platform engineer. It's having these autonomous agents that are doing some of the work, but they're not replaced, at least not in the foreseeable future, which in our world is 18 months, right? In, in, in the next 18 months, let's say two years.
They're not replacing the DevOps engineer any more than they're replacing the platform engineer or the SRE or, or, or these people. They are helping, they are the co-pilot to the pilot, right? They're enhancing the DevOps engineer.
And Mike, to your point, maybe it allows these folks who are always kind of playing catch up, right? Too much work to do, too little time to get it done, to get out ahead of this and actually increase our, uh, deployments, speed up our deployments, better secure our deployments, right? And that might be the single biggest thing is can we use ag agentic AI to help with compliance and, and not just compliance for compliance sake, but for security, right?
This is, I mean, you know, a, a great, again, I got into DevOps from security because I thought DevOps was a great opportunity for security. Agen AI for DevOps in my mind. Another great opportunity for security where we can build this in here.
These agents can do things that maybe a DevOps engineer is not a security person. It can enhance their security, uh, capabilities. And Ira, I know you, you would like to see better security.
I I would like to see better security and it, this is a catch 22 because so far when you look at ag agentic ai, ag agentic, and writing code and everything else, security has not been well embedded in anything. Like, you know, I'm dating myself, but the first version of the Mozilla and browser had no security in it whatsoever. 2 'cause nobody even thought about putting a password on the system and you know, so all of a sudden it took a few revisions to get there.
Now, when we're talking about agent ai, I promise you again, there's, let's make something functional first and maybe we'll think about it later. And even when you think about it, I mean, let's just consider the number of vulnerabilities that are being announced on a daily, weekly, monthly basis already of regular software where people are already well aware of security issues now, you know, it's like, what's the word, you know, um, to air as human to really screw things up. Takes a computer, you know, and this is what's gonna happen, especially with security vulnerabilities.
You're gonna have people doing essentially an agentic ai. They are gonna try to secure the code that's written and maybe they're gonna go ahead and they're gonna also be able to do security reviews as well. That's another function perhaps built into DevOps.
But I still think that this is, this is gonna be a, there is gonna be a nightmare resulting from security built in. And much like we talked about on the previous se you know, segment. You know, I do think people are gonna start embedding malware into this and so proactively, like into APIs that are pulled, that's gonna be a future segment as well.
And so anyway, I'll, I'll stop my monologue, but I'm just more, I, I just think we need to do this because productivity is not gonna stop. But at the same time we really, really better have a fail safe mechanism as best we can built in. Lisa listening, Lemme let me call, let me pull Lisa into this chat since we haven't quite gotten there yet.
But, um, we talked a little bit about this in the past, but there is so much noise being handed over to investors and Wall Street talking about how, you know, we're gonna reduce the size of companies and lay this one over and that, and yet I've also start to see is a message now where people are rehiring folks that they thought that they were gonna lay off. And it turns out that they maybe have different jobs and roles, but, um, maybe the sum total here is I have the same number of people that I always had. It's just that they're more efficient, but it's not necessarily gonna be fewer people.
And do we need to change our tenure and tone? I think the tone needs to be transparent. It's like we talked about in, in the prior segment and Alan was talking about the good, the bad and the ugly.
And Ira you commented on the ugly. And that's just a fact where companies need to have the, the messaging really straight and, but it has to be transparent. I think that they have to understand how AI agent, it's augmenting the DevOps engineers, um, the developers, how it's augmenting other role functions and roles in organizations.
Um, but then we have conflicting messaging like Andy Jssi about 10 days ago that talked about AI replacing jobs at Amazon. So I think we're seeing kind of a mixed bag here and what needs to be, what we need to have is that transparency, but it has to be consistent. Um, where we really identify what are the benefits of gen ai, agent ai, ai, where are the challenges and the concerns that everyone needs to be aware of?
And the security front needs to be front and center and a constant reminder to organizations that this is something that needs to be, um, continuous in the ba in the foreground, really. But I think that the messages are conflicting between different companies. Um, I'm hearing a lot of things here in Silicon Valley that a lot of, um, folks are saying, well, well, if AI is gonna replace my job, how can I get AI skills?
And we're seeing companies rehire, as you mentioned. Um, and the message there is that folks that have AI skills or know how to use AI to some degree are more desirable. But I think, um, we're just gonna see an inconsistency of messaging as different companies are treating it differently.
And, um, I think that's just a, a what we're seeing and what we're going to see for the foreseeable future now, probably, I'm sorry, go, go ahead Joe. I'm sorry. Just I was gonna say, sorry, Alan.
To Lisa's point, you know, Microsoft just announced 9,000 layoffs and Cisco's been letting people off, which they have not announced, but it's dribbling out 'cause I have several friends who just lost their jobs. So it's, we're starting to see it, um, among the largest companies, the ones you think would be the best positioned. And again, what these companies do through technology waves is not, not just with ai.
They, they move to the cloud, they move to it to mobile, whatever. When they do, they shed a certain number of workers and hire new ones. So there may be a net of zero in the ends, but they're constantly shifting the employment.
It's not, it's not great for the workers, but what the companies have to do if they're gonna maintain their, their edge and, and and their competitive stance. So we're gonna see, we're gonna see a lot more of it. I wouldn't be surprised if, I mean, as you mentioned, Amazon, there'll be layoffs there.
They'll, it will just go across the gamut. In, in a year, half the people got laid off by Microsoft, they're gonna be working for Cisco and the other half In Cisco be working for Microsoft. Yes.
Yeah. What happened before, right? Yeah.
This is happen. Another, another way, You know, there's a loan out perfume ai, you just spray yourself with that and you become very desirable. Um, wow.
Oh, sorry, I just, I I hate to do this and put a damper. 'cause in many ways what you're saying is true, but I have a lot of friends who have been out of a job for an extended period of time. So we really, I, I don't wanna downplay it because you know, it between the tariffs taking a hit on retailers as an example where I obviously have a lot of friends who have been laid off due to that, you know, to all, you know, different shifts.
I think we've been doing, I mean this is a definitely a different topic for some other time, but I think, but It's a, we've discussed, yeah, they're laying people off under the guise of AI when what they're really doing is laying people off. 'cause they hired like drunken sailors during COVID. Yeah, during COVID.
They overhired. Yes. They, And now it's very hard, you know, like you are right?
I get friends every day riding me to help them with jobs. And these people are outta work eight, nine months and more. And they're not, they're highly skilled, highly skilled, very, I mean, great people to put in an organization.
It's Just hard. Yeah. And I wish I could create a company of just laid off people.
'cause the fact of the matter is at this point, if you hire somebody who's been laid off, they are gonna be as loyal as hell. If you treat them decently, they're gonna do, they're gonna work their asses off. I hope I could say that on here, but I, I mean, you, you know, they are gonna, I I I just want to keep it real because it's easy to say like, you know, there's this whole Silicon Valley, it's, it's like fairytale land out there with like, people jumping around from one of the, you know, fang companies to another or something similar without courage, salaries and things like that compared to the rest of the profession that's out there.
And there's a lot of people who are not gonna be as, let's just say mobile as some of these other Silicon Valley companies that are like hiring and firing people on whims. So anyway, I just want to just have to keep it real for there. 'cause I just have a few people in my inbox today that, anyway, sorry about the damper.
No, you're You're absolutely right. It's, it's, it's like Logan's run here. I mean, I'll be honest, it's a lot of ages.
And, and, and, and, you know, the cycle is becoming to the point where, you know, you used to be considered old if you were in your forties at a one of these companies. Now if you're in your thirties, you're considered on the cusp. So that's just Something here.
So what I wanted to add is, yes, people are losing jobs, but there are also an opportunity here, there are a lot of jobs coming up in prompt engineering. I, the reason I say that, because I'm an immigrant for over 13 years now. I'm on, I'm on a visa here.
So losing a job, being an immigrant is the worst fear that anybody would have. So at, but that's the best side about me because I have this sword hanging on my neck. I'm constantly evaluating, am I on the edge of things?
Am I learning new things? Am I exploring it? And it, the, the side of it also has it, the industry is changing.
When I started my career, there were a lot of jobs for manual testing. And now those are gone. There's automation, there's DevOps.
So now I feel the dev is getting automated. So in there is also an opportunity here in terms of skillset that people can have. And whenever I talk to people, there are still a lot of people who are not aware of many of the things in what they can use to improve their skillset.
So I think the responsibilities also on the workforce to keep up with the skillset that are coming up. And the AI is not that we are talking about it today. It's it that it, the, I think chat came up in 2020, uh, I believe November.
So it's been like four years now. We need to kind of train ourselves to untrain the things the way we've been doing over the years. Yeah, Chad, that's a great point.
You know what kudos to you is Trying to figure out what Logan's run is, John. Well, they, when they graduated in 2000, you're done. Yeah.
But, but no kidding aside, chia, congratulations and kudos to you, right? Because you just hid a really important piece, right? We, we see the headlines about immigrants, we see the headlines, people on visas.
We, we see the headlines about layoffs and about AI taking jobs and, you know, part of the American dream. And we just passed July 4th, right? Go west young man, we, anything is possible in America.
That's what brought immigrants here is that you, anything is possible in America, but no one gets handed a free lunch. Or at least they're not supposed to be. You, you, you, you, you work for it and you get it.
You make yourself better and you become more valuable. You, you can't sit there and think it's coming to me and I don't care. That frankly is whether you're an immigrant or you were born here and your people came over in the Mayflower, if you're sitting here thinking you're entitled to something, that's not America, that's not the us You, you have gotta be constantly honing your skills, sharpening yourself, making yourself more marketable, more valuable.
And I think that's the message to take out of this. I agree. I think it's a shared responsibility model.
And Treya, I'm glad that you brought that up because we, I, I talked about the Andy ssis statement from a couple weeks ago that we actually dissected on, on this program that ai, and it's just feeding the fear that the, that the general population has of ai, it's gonna take over everything. I've got family in the entertainment industry who are terrified of it taking over jobs for them. But you bring up a great point chair in that it's, it's shared responsibility that you had this impetus within you.
And more people need to be aware that they need to take responsibility in educating themselves and upskilling themselves and learning how to use AI tools to make their jobs better, more productive, ultimately making their products and services better for those folks that are consuming them. But they've gotta, they've gotta have stake in the game. That's a, that's a mindset and a message that needs to be out there.
So I, I have to play devil's advocate here. Not to say that people shouldn't be motivated and keep on the cusp and everything like that. But you mentioned prompt engineers as an example.
Yeah. If you're in Silicon Valley and prompt engineering jobs are out there, you know, I look at the jobs around me and you know, not in the FANG type of group and prompt engineering isn't really that popular and then, or isn't that available? I also look to people who have been in the profession, you know, like for 20, 30 years, God bless you for 2007, but you know, I know people who started around 2000 earlier and even, you know, at your level, I mean, I don't think a prompt engineer, unless you get some mythical job at open AI is gonna pay the same as somebody who's been work in the workforce for 25 years who has been doing a good decent job evolving for the needs of an organization.
And then all of a sudden the organization just says, Hey, we don't need you because well, you're doing an important job, but we could not need that important job 'cause we have to have cuts. And then saying for example, that you're gonna replace somebody at 2 25 a year with a prompt engineering job, which could be handled frankly by somebody offshore is not a realistic thing to say. Like, to become, hey, I want to be trained in a salary for a job that pays half the salary I'm currently making.
That's the problem people are having. I mean, there is some, But let me, lemme turn it around and we're over time on this, but let me quickly turn it around on you. You know what, I think auto factory work has said the same thing in the seventies and eighties, right?
The, those, those factory jobs were going away and all of a sudden they could go work at Walmart as a greeter or something, right? For, it's about retraining people, whether it's prompt engineering or some other skillset. If, if your niche is being amalgamated, for lack of a better word, you've gotta do something about your skillset to make yourself marketable.
Whether it Yeah, I, Yeah. You know, I don't know if it's prompt Engineering percent. No, I a hundred percent agree.
Um, there's just like, you know, for example, factory workers factory closed down, they have to move. You know, luckily we're in the knowledge industry, so perhaps there's a few more remote jobs that are available to us and I know people are taking advantage of that. But, um, yeah, I mean, I just wanna say it's not as simple as just saying, Hey, you haven't been staying up to date on what are now low paying jobs and therefore it's, i I just Don't like, but that's an merit.
So is that people's problem? Is that a, is that an American problem where, you know, an economy problem where, look, we're, we're eliminating high paying jobs for people to take low paying jobs? Well, I think that's a personal responsibility.
I mean, frankly, at the end of the day, you could say it's the economy, it's everything else. You know, as, I forgot who he sets the analogy, but you know, there's always a wind. How you set your sail is how successful where you're gonna go.
And that's what I think I'm saying, whether it's prompt engineering or whatever else the next thing is, Right? But I'm just saying it's, we're, we're sorry, we're changing. The problem is the mindset that people have got complacent because complacency, I hate to say has been a beneficial thing for companies and the people themselves.
I work for the government, I work for NSA where people are like, I've only, I asked, I had a friend who hated his job and then I'm like, why don't you leave and get paid 50% more? He is like, IRA, I only have 15 more years until full retirement. And I was like, And he's, I got his countdown the Hell outta there and then No, but you're right.
I've seen that at the government. Anyway. Hey guys, we've got last, last, Last, last comment on this.
It is gonna be America's problem and we see it because there's a socialist who's gonna wind up running New York City. This is an example Thereof. Yeah.
Alright, we got to, I hate to leave on that, but we're gonna take a break. We're going to come back. Let's change the subject Trust in AI search, not lls.
This sounds like an IRA thing. LLMs uh, exploited by phishing. 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 there's a report out from a company called Ned Craft and it's highlighting the fact that the bad guys are using LLMs to craft phishing attacks and they're doing it more efficiently and they're harder to detect.
And it's kind of building what feels like maybe a tsunami of these phishing attacks that we're gonna see that are not only gonna come in higher volume but are gonna be more sophisticated. Ira, is the cybersecurity game fundamentally changing here and maybe the bad guys are benefiting more from AI than the good guys? So I think there's a couple issues here.
First off, I really don't like the concept of calling this a phishing attack. It's not a phishing attack. What this is essentially in large part is a data poisoning attack against LLMs.
And there is a distinct difference 'cause phishing implies you are pushing out information into people's inboxes. So for ex in the, in the example cited in the referenced article, you know, a phishing attack would be, Hey, this is your bank. There's a problem with your credit card, please click on the link or call us up at this number and it's the wrong number.
That's a phishing attack. In this case, what we're talking is LLMs spitting out the wrong information where LLMs are giving people the wrong customer service type of thing. And I'll, I'll give you an exam.
People know, you know, I run cruise con, people know I love cruising and I'm an active on the cruise, um, boards out there. And what happens is somebody replied back saying, I wanted to like update my reservation and Royal Caribbean said there's a $400 port fee they didn't charge me for. And everybody's like, where'd you get that number?
'cause what the person did was they searched the internet, came up with a fake number for Royal Caribbean because that's what a criminal put out there on an LLM or whatever else, which is exactly what the attack is. And they have the person calling a fake call center because the LLM or the website was malicious that they looked at and got a fake number. This is the essence of the attack in question that we're referring to.
Now, the reality is how do we address this? You know, the people who are running LLMs like chat GPT, are not necessarily looking for poison data. They're not looking for criminals who know, hey, I could go ahead and say I am in the article, it's eyesights Wells Fargo.
I'm Wells Fargo, here's my new numbers and feeding in fake customer service numbers. And this is not unique to users. Users really have to just know, uh, and this is nothing new that you have to go to the actual company website or the number on the back of your credit card to actually get this.
But anyway, to that extent it's this and it's just a matter of data poisoning that, you know, people have to be aware of. Lisa, will people stop trusting AI search tools and go back to, you know, good old fashioned Google search engines? That's a great question.
I I think we have this, we've got people that are pro ai, a lot of us in tech that, that know how to use it properly and responsibly. And then we've got the, the consumer, the, the general population who's terrified of it. I think those are two very distinct populations.
I rarely find people that are in the middle. Um, I think that certain populations, like students for example, there's studies that, that I think I've talked about on, on iHeartRadio before that show that students between, I wanna say the ages of 18 and 25, who are leaning too heavily into like chat GPT and LLMs like that to do their homework assignments and are not even, uh, second guessing, questioning, verifying the information that's being spit out. I think that's gonna continue, but I think the message overall needs to be one I said earlier, transparent, there, there is, as you guys talked about earlier, the good, the bad and the ugly, let's just be upfront about that.
Help people understand where AI is already being used for good. Um, and when it's being used. Nefariously, uh, I talked about that on iHeart this morning about the transportation industry, the FBI and cybersecurity firms are saying now airlines are being targeted by potentially scattered spider.
So let's make people aware so that they know how, what, what's happening, where the attacks might be coming from and what they can do about that. But I think for the foreseeable future, we're gonna see those two groups, pro AI de maybe three groups, pro ai, those that are dependent on LLMs, like the students I talked about, and then the folks that will touch it with a 10 foot poll. Yeah.
Could I also, uh, I I, yeah, sorry. I was just gonna quickly say, I do think that there is, the banks and other large organizations periodically put out phishing awareness and stuff like that. They need to start doing this with LLMs as well, saying, you know, much like that, please look at this information, not that information.
So Ira, as you distinguished between phishing and LLM poisoning, I feel compelled to distinguish between poisoning and just the Seward that is the internet. Okay? When you talk to me about poisoning, I'm thinking of a malicious actor deliberately going into a chat prompt, putting some information in that makes its way into the LLM that open ai or the body of knowledge that this LLM is using to answer the next person, right?
And to me, that's poisoning. I am intentionally going on there and, and putting in this data. One of the big changes I've seen in using AI, and I use it to help write and do stuff, is originally, you know, these LLMs were trained on a subset of the internet that was three years old, four years old, two years old, whatever.
What I've seen take place over the last couple months, year, whatever, is it actually pulls data live from the internet now, right? It, these are pulling data from the internet. And I think a lot of, especially like this article says 65% of the domains are wrong.
You know why? And it's Google search isn't gonna help you. The internet itself is so polluted with soundalike domains, fake domains, you know, malicious sites.
And they get on a Google search too. If you ever get through all the sponsored ads in Google and go to the actual search, you'll click on things that are not real there too. They don't do a great job of, of filtering it out.
So when these LLMs are going out onto the internet, that's where they're getting poisoned. The environment is poisoned. This is like water in Flint, Michigan, right?
It's poison out there. And so they're just a reflection of, of the internet at large. I don't even think it's, it's necessarily intentionally by people saying, Hey, I want to poison the, the LLM No, it's the internet itself that's poisoning em.
Well, the the, yeah, the internet. See, the internet is the, these LLMs are poisoning themselves because here's what we, you know, l like you mentioned chat, JPT three years old data. Now they have built in agentic AI that for example, says, I want to know who won the sports game.
And it will pull an agent to query the internet to get the data back. And then at some point, are these LLM, you know, like chat GPT and all these other ones, are they gonna take or be held liable for feeding bad information and not filtering this out if people become reliant upon this? 'cause you're absolutely right.
com and that's where I should get the data. Should LLMs, much like we were talking about the in the past segments, Well, is Google do the same? Is Google Li is Google liable for putting bad data in search?
Um, are they legally liable? The answer is no. But if you are, Google's not saying give me Wells Fargo, you know, you could say, I'm searching for Wells Fargo and it says this is all the data.
But if I ask chat GPT, I have a problem with my credit card, who can I call at Wells Fargo? And they feed Me a different, who doesn't say this is all the data. Like, you go on to Google and say, Wells Fargo, you're going to get sponsored ads by Chase City and you know, three other banks, then you're going to get some, what we used to call Google search results that may have fake Wells Fargo domains in there.
Then you're going to get some more sponsored stuff, then some videos and some other thing. I I would hold Google to the same bar that we would hold the LLM companies to. Well, I, I will play devil's advocate slightly and, and pass this on, but I do think that if I, there's a difference between me saying I am asking you a very specific question and one, a specific answer and doing a broad search the way it previously was.
I'll leave it there. Semantics. All right guys, we're we're, we're over time.
I gotta pull the plug, but what a great discussion, Lisa, it's so great having you on. Thank you, IRA. Always bringing it.
I appreciate you, Chaya. I hope we didn't scare you away. You're gonna come back 'cause you were valuable here.
Well, I had so much to learn from all of you. Thank you very much for Having me. Oh, no, it's, it's our pleasure.
It's great to have you, John. Keep doing what you're doing. Keep an eye out there on the valley, make sure all's well hold up.
Two if by land, one if by sea. But you know, we'll go from there, Mike. Let's hope the Yankees, uh, you know, have a great after Allstar break.
I hope so. It's been an ugly mu it's been an ugly June. It was an ugly June, but it's still July.
All right. Hey, we're outta here. Thank you for watching.
We've got Textron TV coming at you immediately following. As usual, we'll be back on tomorrow with even more Textron Gang and some more gang members. But for now, this is Alan Hummel, we're outta here.
Hey everyone. Welcome back here to Tech Drunk tv. You know, my, my next guest just reminded me, I didn't see him at RSA this year for the first time in 20 something years, he wasn't there.
He was out celebrating a, a big, a big day, a big year in his life. Let me introduce you to my friend Jim Revis. Jim is the CEO and co-founder of course, of the Cloud Security Alliance.
He's almost become, it's synonymous with the CSA. Jim, it's good to see you. I'm sorry I didn't see you at RSA, but welcome to Tech Drunk tv.
Oh, it's, it's my pleasure. And I'm, I'm sure it would've been worse for RSA if you weren't there because you are an icon at the coffin. Ah, stop.
Thank you. But eh, it, it, you know, it'll, it'll go on without both of us, Jim, let's face it. Right.
Um, anyway, Jim, you know, I, I said your co-founder, I still remember the initial CSA kind of formation meeting at RSA, you know, and, and coming together with the working groups and everything. But beyond CSA, there was the Jim Res before there was the CSA tell, give people a sense of kind of your, your, your life journey. Yeah.
So, you know, a small town kid, um, you know, working class roots, went to the local public university up here in Washington State. Love loved computers. Had computer first one.
Um, I had when I was 12, which, um, was a commodore. And, um, so I did, did the computer science thing and then went to work for a bank. Um, and they made me the IT manager, which ended up being how I started, like having to get involved with security, which was in 1988.
And I decided, hey, I really like tech and security more than banks and finance. And so I just went through this, uh, journey of, of what are the interesting security issues. And then in, in the early nineties, you could see, well, the big security problem for the rest of our lives is gonna be this internet thing.
And like the first time I actually saw the internet was in college, and it wasn't called, I think it was called nsfnet, that iteration. And the first use case I saw was that people in computer science would go download a program from a hospital, which for some reason was designed to change the dates on object code. And I found out the reason they were doing that is so they could backdate back Bill Their compiled code so that the professor on the due date would pass.
He would post the perfect source code and then they would just take it, compile it, turn it in before he noticed get a hundred percent. Uh, the professor figured that out. But the lesson, like later when I found out, hey, that was the internet, is that it was, it had a bad, had an evil use case from the beginning.
And so, um, so, you know, just, just from there and, you know, I did a startup and I've done a lot of like, consulting for a lot of the, the startups that make up the cybersecurity industry now, we call it. I just, I've always loved the community aspect of cybersecurity and people like knowing they've gotta help each other. They're very much a first responder mentality.
And that was part of like what had me create cloud security alliances. Like, let's, let's really capture that first responder mentality in communities and help each other. Let's raise each each other up in different communities.
Just be better. And by doing that we'll raise the baseline of security, get the bad guys. And so that's kind of, it's, it's been, you know, it's, it's, it's been some twists and turns, but a pretty sort of consistent theme of like loving the, the art and science of cybersecurity and then loving, like the collaboration that happens within it.
Absolutely. You know, Jim, I'm sitting here listening to you talk about security in the late eighties, the onset of the internet, the commercial internet. I realize, and you've probably realized this too, a lot of people out here watching it, watching this video, the Cloud Security Alliance has been a constant in, in the industry since they first got involved in the industry, right?
They're, they've been in the industry for decades. Yep. Yep.
We have. And and you know, I had a, a conversation with a mutual friend last year, Tony Sager at Center for Internet. Sure.
At NSA or used to be at NSA. Yeah. And, and he said, you know, Jim, the, the nonprofits we're actually the really conservative choice because you have regime changes, you have government changes, you have all these things that will change in, in the corporate world, but us nonprofits, we actually stick around and our best practices are the, the most enduring.
And that's always my, my aspiration. You know, I want, I want CSA to be a hundred year old company and, you know, maybe my chat bot will be around to observe that, my digital twin. But yeah, I'm open to get Yeah, we'll, we'll download you.
There you go. And let's not even laugh about it. It, it's, it's coming.
Uh, so Jim, you know, the CSA charter and mission of course kind of changes with what, what, what we're dealing with, with the attack surface, so to speak, of, of, of the world out there, you know, the whole cloud. Like when we first started with the CSA, I don't know if we really thought about hybrid cloud and multi-cloud and, and all of these, you know, different flavors. The edge, you know, we were still talking about perimeters, remember, right?
The Jericho, uh, uh, uh, I forgot the organization, but they were all about the shrinking perimeters and stuff like that. But I, you ai I don't know. I mean, we, we talked about AI maybe, but it, it seemed very sci-fi Skynet ish and you know, what the heck.
But it's real, it's having a tremendous impact. You guys recently, uh, announced, announced two different initiatives around AI governance and security. And, and God knows we need it.
Tell us about them, if you don't mind. Yeah. Ab, absolutely.
So, you know, I, I like to say to people that, uh, the, the cloud and AI got together and had a baby and called it chat, GPT. And it was the fact that ai, I like to talk about was sci-fi forever. And this was actually the sort of democratization and the opening up of AI technologies, which big companies have had for decades, and not, not what we have now.
Not this generative ai, which is amazing, but now it was available to everyone, which very transformative. But also it's, with that obviously comes a lot of risks. So, so we started our AI safety initiative kind of the same way we started CSA, almost like a company within a company.
And we've been cranking out like research like crazy. And we've been using that to sort of formulate what the strategy is around how we think about governing this and how we communicate to the whole world that people who are developing or highly leveraging AI systems in their businesses can actually communicate that they're doing the right thing. And so, so, so one of the things we are doing is this AI trustworthy pledge, which now I'm shameless, um, th theft of other ideas.
And I really liked what Jen Easterly did at CISA with the Secure by design pledge. Me, me too. Yeah.
It's like we, we, we don't always, um, need to audit every little detail, and it can be different ways you do things, but it's really important that we capture the commitment and the earnestness that people and organizations have towards doing the right thing. And so I really liked how she did that. And so it's, well as, as we are, as we are rolling out all the programs that we need, let's, let's make sure that we build a community of committed individuals.
And so it's just, it's really simple. It's about safety and compliance is one of the, the pillars of it. Committing to that, committing to ethics about how you are rolling out AI systems, transparency is really important.
So that's the third one, because we have to be transparent knowing that, hey, if even the inventors of these AI systems can't predict and are often very surprised by what it's able to do, how can anyone else? And so we should be really transparent so we can go back and look at why did the AI system do what it's, it's, it actually did. So transparency is really important.
And then the fourth one is privacy protecting. Let's just have this commitment to the privacy of citizens, employees, customers, everyone as we go through this journey. So, so we, we've put that out there.
Uh, last I checked it was, it's, it's only, it's been, I think less than a month. And we've, uh, already got over a hundred companies that have committed to it from all, all walks of life. And so that's great to see.
And so hope to see a lot more. And it's really, it's a precursor to then what we're gonna be doing is, is updating our whole star program. So we have all of the audits and all of the, uh, controls ad uh, adherence inside of the, uh, the AI assurance systems.
We have that, that we can measure this in a more quantitative way, in addition to this sort of qualitative pledge. So all those things are coming, but the trustworthy pledge, it's, it's good for people to stand up and, and be accountable. So, so we're real appreciative of that.
And so the, the other thing we just announced, which is kind of on the different, different side of the spectrum, but all sort of leading towards the same direction is something we're, we're calling validated. And, um, it's spelled a little bit different. Valid.
A I, Ted, so valid is good. You got AI in the middle, and Ted, they have those TED conferences, smart people. So I just thought that's a good name.
Anyway, Uhhuh, um, the, the idea we had was that hey, as these, these large language models get very sophisticated, and they're very good at doing a lot of language tasks. If you gave them, you train them with very specific auditor guidance, implementation, guidance on how to implement systems securely that they would actually do in a very fast and and low cost way. They'd be able to analyze, uh, uh, assessment and information, self-assessments, and be able to provide guidance on, hey, are, are we doing the right thing?
So, so we launched that. We were really surprised at, um, how good, actually the first iterations of this are on how it's able to analyze and give you really detailed guidance and, Hey, this is not really a good explanation of value to key management. Have you thought about like, doing this?
And so, uh, so a lot of companies going through it. I know that Google has had their star entry in our program validated, and I know there's several more, several more working on it, several more waiting to get approval to be able to announce that. But, um, you know, I see this as being something that as we talk about cybersecurity risk management audit, we, we are going to have this technology.
It's going to do some automation, it's gonna do as assistive things. We need the human in the loop, but we need to embrace it because I think cybersecurity people, they need to know more about ai and they need to be the best AI experts in their company. That's how we're gonna do, do things, right?
And that's what I'm encouraging cybersecurity people. So, so this validated, uh, capability, it's something that it exists somewhere on the spectrum between a company doing a self assessment of their security controls and then having a really good experienced auditor somewhere in, in that middle ground. But hey, that's all about that, that mission of let's raise the baseline of security, uh, everywhere, everywhere we go.
So right now that's working on our cloud assessments, and then we're finishing up our AI controls framework next month, or actually later this month, it's gonna be released. And then we are going to, uh, start doing the same thing for AI companies. Let them, um, um, get assessed with this technology.
So we're, we're pretty excited about that. We're pretty excited about, let's, let's go, let's go secure ai, let's embrace it to help secure it as well. You're telling me you guys are not really very busy on this AI front, huh?
Don't, don't, don't talk to me about the robots yet, because Yeah. Know it. I don't have an answer that no, we, that's physical ai.
Yep. Yep. Right's physical.
So gotta Think about next. We gonna, it's this is, we're gonna have to go figure, figure that out. How do we like, have the controls for catastrophic things when it gets kinetic?
So, you know, we don't have the solutions for that though. Well, we'll, you know, can't make wine before it's time. We'll get there.
That's right. We'll get there. Jim, we gave people a lot of information here, fast and furious.
Where can they go to maybe digest it at a one spoonful at a time and, and think on it, what, what's the best place on the CSA, uh, sites to go to? org/star. ai has got, um, a good launching point there.
We're not too hard to find. And as always, research is all free. Please use it, consume it.
There's a lot of the questions you have in your mind or the pain points. Someone's already figured it out and solved it. So don't, don't reinvent the wheel.
Go, go look into the research. It's already there. Agreed.
Jim Rivas, thanks for coming up here on techstrong TV and, and giving us a little education about what the CSA, the Cloud Security Alliance is doing around ai. Just like it seems everyone else, AI is having a major impact in, in the CSA world as well. And you guys are, as one would expect responding to, to the challenge.
Well, thank, thank, thank you for that, Alan. And, and thank you for what you do and amplifying the voices that are out there in the community, it's really important that like, what, what you are providing is a lot of great information for people from all, all walks of life here. So keep doing what you're doing.
I appreciate it. Hey, who would think I can make a living doing this? It's all good.
Anyway, Jim, I hope to see a black hat. We'll definitely see you at RSA, God willing, everybody's there. But until then, keep doing what you're doing seriously.
And keep, and feel free to come on and keep us posted with any new news out of, uh, the Cloud Security Alliance. I won't turn down an invite, I tell you. I'll hold you to that.
All righty. All right. Jim Vis, CEO Co-founder Cloud Security Alliance here on Tech Drunk tv.
We're gonna take a break. We've got more coming at you, so stay tuned. Hey everybody.
We're back at the open source summit in Denver. We're talking with Mitch Ashley, who's vice president and practice lead for Software Lifecycle engineering at the FU Room group. And we're gonna have a little chat about, well, what's going on in the open source community, because I gotta tell you, there's more projects than I can shake a stick at.
I cannot keep track of all of them. And sometimes I feel like they're a little overlapping. So you're the analyst who keeps track of this stuff for Futurum.
How do you kinda sort this out a little bit so that it makes some sense? Well, you know, when I lived in New York, we used to go to the festivals on the weekend, and there is a plethora of every kind of food you can have, depending on which neighborhood you go to. It's kind of that way in open source.
There's neighborhoods of different kinds of projects and who you talk to, whether it's Steven Chen from over in and Neo four J you know, used to be with, uh, JFR or Tracy Reagan. It's kind of, you know, know some, know some people who know some people and keep track of it that way. That's, that's at least to find out what new things are going on.
I mean, you can read the announcements, you can try to follow the, the Discord servers or the, you know, the email distribution lists. What I do is I try to assemble that into what's important to follow, what's really kind of, not every announcement is worthy of Oh, I need to take 30 minutes to read and investigate this. So I just produce the, uh, agent AI top 10 agent AI open standards to follow, meaning things that are happening in open source, like the A two A announced it yesterday about the Linux Linux Foundation, taking that over, starting the project for that on GitHub.
So that's certainly one way. Um, I read tech strong sites and things like that, of course, you know, little self-promotion here, shameless mm-hmm. As well.
So, you know, I think that's, that's one way you have to have an area of interest too. 'cause there's just so many things. Like I tend to follow Open telemetry and anything to do with agents and things like that.
So right now, what are, say the top three open source projects that got your attention and feels like they're doing the most to move the proverbial needle? Well, you know, open, open telemetry is still kind of the, in a good way, the behemoth, it's the model of talk about vendors cooperating and, you know, building a really great ecosystem of open source and then differentiating in their own technologies. So I stay abreast, abreast of that.
'cause there's developments happening around AI observability and things like that we know we need. But then there's, you know, new developments, even open source project, but it's not part of a foundation or organization is like NCP servers that anthropic is still supporting. Now you might ask why does anthropic not need to donate it to a consortium?
Or maybe they will at some point. And why did Google do that? I think it's probably because Google's in a position to, uh, wield a little bit more power.
And so putting their software a two A in a consortium really does help with sort of the neutrality and blend it up well. We have a good tracker record with things like Kubernetes and Istio to somewhat and things like that. So one of the ongoing conversations in any sort of open source event is this tension between wanting to contribute to the community and somebody needs to make some money here and justify the return on the initial investment.
And mm-hmm. I feel like that subject has not quite dissipated. It's still floating around here.
Sometimes projects get forked and then, you know, the community ships and moves over, but there's somebody running an enterprise IT organization somewhere who's like trying to wrap their head around, how do I manage this chaos sometimes. So are there tips for enterprise folks as they kinda look at open source and say, how should they be thinking about whether to dive into a project to use something or not? I mean, should it be like, number of contributors to the project is, is there more than one vendor?
What are, what are some of the things you look for? Well, there's different flavors of it. I, but I think the rule of the road is, it's kinda like in college it's a great party until somebody breaks something and then your parents come home, right?
Soon as somebody messes things up for everybody, that's when it gets a lot of attention about, is this the open source we should be using? So changing a license, being, making it more restrictive, maybe having too much control over open source. I mean, generally there are companies who build, have their business model around an open source of some part of their product.
Maybe a lot of it like a GitLab and others that are kind of much more, well, we're really here to make money and kind of just do open source to do open source. So you can pretty much ferret those out pretty quickly of who's contributing. So mostly the company and yeah, there's open source, but you're probably gonna be using the commercial version.
And then there's ones that have a lot of people contributing to it and are very healthy and have a lot of, lot, lot happening with it. So I would look at really companies that are heavily involved. More importantly, who's the governance of the project, who's making those decisions around, okay, these are all things submitted, we're gonna work on next and we'll take these contributions from these people.
As opposed to, well, we're this company and we don't like Microsoft. We're this company and we won't work with Google's code. That's not gonna help anybody.
Oh, one of the things of course that's top of mind here is ai, and I can't help but feel like we're, it feels like the early days of proprietary OSS and databases, right? For a long time they were the dominant players and they were their proprietary vendors. And then the open source community caught up and arguably surpassed them.
Is that about to happen here with ai? I mean, we've seen some open source AI projects here, but there's not that many yet. And so is that like the next wave?
I, I definitely think so. And for one reason, developers and developers, they're gonna create things. They're gonna find problems to solve.
And now you can argue whether that's gonna come out of a vendor like MCP from Anthropic or you know, HOA with Google. But people are gonna create projects. They're gonna see needs that they're gonna build open source and start a project and do that.
It's just that they're now doing a lot more development around ai or at least starting to. So in the, in the AI community, I don't know that it was as big of a factor of to develop open source software, probably. 'cause there's a lot of proprietary investment and intellectual property that you're controlling, uh, in, in that environment.
So I think as it gets to the broader population of software developers and communities, absolutely we'll see a lot more AI open source projects. Alright, so you get that little crystal ball, you pull it out every now and again, the eight ball, that's a eight ball, that one, and you rub it. As you look into the second half of this year, what do you think you're gonna see?
Well, the, the first part of this year, of course, was sort of in, in the AI space, was dominated by MCP and A two A. You know, there's some other things coming up behind it like agent DNS and agent communication protocols and some things like that that are in the wings. I think we'll see those development.
I think we're gonna see more projects that we don't know about yet that are just kind of get sprung on us. And two months later, a hundred companies are saying that they're adopting. It doesn't mean that the project or the spec or the software's mature yet, but I think, I think we're gonna see more of that kind of innovation very short, uh, in cycles, innovation cycles happening, just like we see with new versions of models and new companies and releases and tools.
So I, I wouldn't make any bet on one technology at this point. I'd look at what people are making big bets on, uh, in terms of open source, but also keep in mind that what may be cool today may get sur surpassed or supplanted in nine, 12 months from now. Something the next generation may come along.
Uh, Yeah. And the other thing I look at too is the stack. Mm-hmm.
It keeps getting bigger. Mm-hmm. At some point, will this stack start to compress a little bit?
You know, there's a lot of overlapping capabilities and you know, it takes a small village, maybe even an army these days to actually go build something that always struck me as not necessarily sustainable. So can we like find another layer of abstraction to simplify all this? Maybe?
Well, there, there's a lot of, there's some talk about should we focus on bloat? Should we focus on taking out all the extraneous stuff? Would that solve a lot of our vulnerability problems that 'cause the cup code?
We don't need code we don't use. That's always a tough proposition to pay somebody to go do that or somebody to go through the toil in software world of doing that kind of work. I, I tend to think not, I think people are more practical about, well just keep adding to it.
Maybe AI helps us bring down some of the technical debt on our software. I'm not gonna say that's the panacea to the answer, but I don't, I don't see the pattern changing. Not significantly.
You mentioned technical debt and of course you can't come to this conference without somebody, you know, basically having a, a moment of silence that to mourn the fact that we have so many vulnerabilities in open source code and we don't always find ways to easily fix that. And it's, it's a problem, but it, it gets a little bit better. But, and do you think at some point we might solve this problem?
Or is this gonna be like, you know, death and taxes and it's always with us, It's always gonna be there. But I think if, if the, if the models that we used to generate code really get trained and emphasize secure code, either fixing or generating secure code instead of, we've heard about different models creating lots of vulnerabilities in the code generated, otherwise we're relied on scanning and tools and people to catch things earlier in the cycle. All those things help.
But, so if you're gonna create more software faster, you better create more secure software faster. And I think that's, that's the answer. To get the most benefit, make the biggest dent in, in security and vulnerabilities.
Alright. You go to a lot of these conferences, as do I, and I'm often amazed at how many actual open source consortiums there are. So between them all, do we need like, um, an orchestrator for all the different consortiums so that somehow or other they can kind of work together?
Because I feel like there's still a significant amount of duplication of effort running around. Well, I think it's all determined by the sponsors who will fund those projects and who will fund those organizations and how that works. You can usually kind of, you know, follow the money they say, right?
I think that's, that's what makes it tick. And I know it's not a commercial venture, but still you have to have financial support to do all these things. So until there's a reason for either not creating another one or a downsizing one or combining them, you know, we'll operate on the path we are and I think we'll see more things pop up rather than less.
All right folks, you heard it here. Hey, even in the open source community, money still talks. We'll be back in a minute.
Hey guys, thanks for the throw. We're here with Shai Gbe, who's CEO for, trust Me. And we're having a little chat about how the bad guys are starting to weaponize AI in the forms that might be taking.
Hey Shai, welcome to the show. Hi. Hi Michael, how are you?
I'm well, I'm well. I think everybody's kind of conscious of this point that the AI that we see is a double-edged sword and the bad guys are certainly up to something, but nobody knows exactly what. So what are you guys seeing, because you're kind of on the front line of this thing.
Yeah, you know, it's, um, really interesting because, uh, almost any conference, any meeting that I'm going, almost any place that you go, everyone is speaking about gen AI and what you can do with that. And obviously if you're speaking with big enterprises, and that's most of our customers, basically, uh, everyone tell us that they try to experiment, they tried different things. And you know, I think that in general, most of us are still in the basic care to try to experiment what we can achieve using gene ai.
But on the other side, cyber criminals already started to utilize those type of capabilities. Long time ago, uh, we've seen much more sophistication in the attack, much more, uh, scales in those type of attacks on the automation, a lot of defects, uh, campaigns. And they basically really take everything that they did before but leverage it in a very efficient way.
So obviously we're speaking with a lot of customers, all of them seeing it like, uh, uh, you know, the most classic example will be basically emails, right? Part of email, email attack will be, uh, what we did before. We always tell, tell people and educate them that they can try to find typos or mis contacts or different problems in the email.
But today, when they use chat g PT or those type of tool to write those emails, you won't going to see any problem with gar mail, any typos, any lack of context. It's going to be very clearly and very easy to see that it's written by a, Anytime there's a new innovation, we tend to use it to do what we always did a little bit faster until somebody comes up with some actual brand new use case for it. So in the case of cyber criminals, have you seen them do anything truly innovative or are they just kinda leveraging up on the scale to do what they always did faster?
So I think it's a combination, right? Uh, at the end of the day, there is attacker. You always try to maximize your profit and minimize your, uh, effort, right?
That's how it work. At the end of the day, they doing business as part of what they do. Now, if you think about how payment works today and what's the process around it, it's a very complex process because first it involve a lot of different people, uh, that part of them inside of the organization, part of them outside of the organization, most of the communication based on email.
And there are a lot of different manual controls that are part of this process. Now, for data care to compromise the process, they try, they need to find different holes that they can exploit and just change bank details, change contact details, and do those type of things in order to hijack the conversation and basically change the destination of the funds, right? Because that's the angle they want to make sure that you send the money to the own place that what they'll, um, basically try to achieve.
Now, if you think about those complexity and those contours that are highly manual, so for the attack, they can do simple things to automate those type of, uh, attacks to make it much more effective. And they don't need to take it full blown to very sophisticated attack to be able to overcome, you know, a very common manual controls. Are we therefore looking at a world where the attacks themselves are increasing both in volume and sophistication?
So how do we combat that? Are we essentially gonna need AI to fight ai? Is this evolving into something that feels like an arm's race?
Yeah, uh, it's always like that, uh, you know, cyber criminal and cyber in general. It's a, a cat and mouse game. You do something the other side doing something else, you always try to, uh, stay ahead of them.
But at the end of the day, that's exactly the point. If they're leveraging AI today in a very effective way, we need to start to, uh, use those type of tools as well in order to mitigate some of those cases. You know, when we are looking today, what's the most common controls in the organization?
I'm gonna say that there are two types. One going to be callback procedures. Basically try to authenticate if someone asks you to change your bank Beatles, okay?
And the other type of that will be, uh, someone going to do an, uh, type of, uh, there are different services today. They try to offer a bank account validations, okay? Now, in both cases, the attacker today used different gen AI today to make it much harder for the defense to do those controls effectively.
So if it will go back to the callback procedure. So obviously this is a manual process, right? You are basically trying to verify that you're speaking with that person.
So you call him in out ofAnd verification, but that's also relying on the fact that you know, who are you're going to call. Now think about, I, I dunno, you are working with a vendor, you set it up five years ago and after five years someone ask you to change your bank details. That's really realistic scenario, right?
It's something that happened. But businesses a lot of time need to change their vendor details. Um, but now for example, five years later, you can't, you can't really call the, the person that you set up the vendor because probably is not in this organization anymore.
And then it's like, well, are you going to call, call, just go, going to do a simple Google search? I'm just going to, uh, call the number appearing in the, uh, email. A lot of times also what we'll see that data attacker do today, first they will do social engineering attack to make you change the contact details first or even, uh, they will do a DFA call and they will reach out to you to try to, um, basically bypass that type of controls.
So that control become very, how to make it effectively. It's not only because it's manual, it's much more because the other side have much more better tools and technology available for him to make the change nap Pam. So if we'll take the other side folks, uh, for, for now if we'll speak about bank account validations, you know, we see different services that provide those type of, um, validation.
Now, there are two problem of that approach as well. First, no one really has all the data. Banking is not a place that churn all the information.
So no one really have good coverage of all the bank details around the world, right? So inside the US you can probably get to 60% coverage outside of the US you can probably get 20% of coverage. But even that, even if you have the right coverage, we saw a lot of sophistication in the last two years.
Basically when the cyber criminal is going to compromise your suppliers, a lot of the time they're going after the finance people of the supplier and they're going to try to find proven previous, uh, communication and documents that they used to open their bank account. And after they will steal those type of documents that are going to take that and they're going to the bank and they will pass the accuracy of the bank. They'll open a legitimate account of behalf of the supplier, meaning same Aries send everything, but probably it's going to be a different location.
So the only thing that you are verifying when you doing those type of validation, you basically verify that the person that you communicate with has access to this account. And a lot of times organization also add to that micro transaction, meaning I'll send you a small amount of few cents and I'll ask you how much money did you get? You know, the fraud will have because they have a legitimate account that you basically, uh, go going to verify it.
So basically saying that, uh, you don't really verify that this is the right account for this business and it doesn't say this is the right contact that you need to reach out to. We also have seen the rise of AI agents and of course deep faiths. Oh yeah, yeah.
And will the bad guys take a more, um, measured approach to that because they'll create AI agents and DeepFakes that seem like they're normal users and run them for months before they do something bad. And so it looks like it's just a normal transaction when it's not. Yeah, and and that's exactly the point.
Like if you look about most of the attacks, um, the attacker will try to exploit a trusted source with a really a lot of, uh, trusted relationship. Basically what we, they're usually doing, they're going after, um, a vendor that you already working for a long time ago. And when you, they will ask you to change a band, they will impersonate someone that you know very well, you feel very comfortable with them and they're going to exploit that type of relationship.
So it's not like, okay, it's going to be the first payment that they're going to, uh, make the fraud happen. It's going to be along the way. That's exactly the, what they try to exploit.
What can be done about this? Uh, is this just a fact of life or do you think law enforcement and governments will get savvy about something? Is there something to be done that we should be doing as a society, but we're not?
So a, a again, I think that yeah, obviously, uh, law enforcement can do a lot, but it's all about it's global problem. It's not something that it's only local. And I think that part of the problem is that a lot of places are not really showing information and there is no type of tools available today that you can really authenticate or speaking with how we doing it.
And you are relying on a lot of all technology that try to do that. But at the end of the day, think about it even more, it's a classic people process, tech technology problem, okay? Basically the attack here are expert in a very complex process with a very old technology, and people are the lowest link at the, at the end of the day because it's much easier to tweak them and tweak technology.
Are we a little overly obsessed with defending the platforms and not enough on the processes, which are the very things that, And the people itself, it's not only that, But By the way, it's also, uh, very interesting area. Think about like, when I came from long time cybersecurity and defensive and the defense side, I was practitioner for a long time and you know, I remember when I started in cybersecurity, there wasn't a lot of tools for, uh, the classic employees. And a lot of the time it was blaming if the employee click on malicious link.
It was, why did it and stuff like that. And that changed because today we, we, we need to provide that the employees much better tools to be able to protect the organization. But that happened in general, it didn't happen in the finance area.
Okay? Think about the tools available today in most of the organization for the finance team, when they do run in their payment cycle, they don't have a lot of great technology available for them to help them mitigate tho those type of fleets. So does the role of the cybersecurity professional need to evolve then where they are a little more cognizant of the workflows and the processes because those are the things that ultimately need to be defended and are of the most value.
I think that at the end of the day, any business need to understand what is the con jewels and what's the really critical part of their businesses? And I think that part of the reason that the attacker or cybercom are really like the problem that we're tackling is because they realize that, you know, it's much easier going after the people that has access to the funds itself and still the money directly from them and try to do different type of attacks and won't get the same result at at the same level of efficiency. So what's that thing you see organizations doing today that just makes you shake your head and go, folks, we need to be a little bit better than that.
So again, a lot of manual controls, a lot of manual, uh, processes. You know, one of the thing that we see a lot is each time that they, that organization have an incident, they doing like a what cause analysis, try to understand what, what was broken in the process. Okay, and what, what, usually you'll see that they will add another manual control to try to make sure that the previous attack or previous incident won't happen again.
By the way, it's make the process so complex that it's very hard to really understand what's really up and going on. So I, I'm, I, I think that, that we need to, uh, create and use much more holistic approaches, really connecting the dots, really have full visibility to the entire process and remove go, going back from silo system, a lot of different people, each one doing their own thing. We need to have a much better understanding on the process end to end.
And to your point, the processes themselves are more complex. They're running at levels of scale. And it's not clear to me that humans can keep pace with it anyway.
So we need to automate. So I think it's also opportunity, um, you know, every time that you think about gen AI and what you can leverage, I think that the area of finance in a lot of, uh, places has a lot of opportunity for those type of improvement because there are a lot of repeatable task that can be achieved very easily, uh, by automation. Um, but again, it's really cool, uh, important to be able to, while you automate those type of things, you need to have the right controls because sometimes it's just quite and much more damage.
All right, well folks, you heard it. Here we are at some seminal point, but the one thing we can point to is, hey, the more manual processes there are, the more trouble you're likely to be in. Hey, Shai, thanks for being on the show.
Thank you so much. All right. And back to you guys in studio.
Hey, everyone. We're back here live at Platform Con Day in New York City, part of Platform Con virtual event. Well, this isn't virtual, the rest of the event's virtual, but you know the people you run into.
So I'm standing online for lunch and I say, you know, that looks like Ian, but I'm, and I'm trying to read his, his, uh, tag, but he's in front. So it's one of those parallel line lunch things. And he's a little in front of me, but I don't wanna skip the salad.
Of course not. But I had to skip the salad to, to get a, a, a good angle. But then he saw me, he said, Alan, anyway, let me introduce you to my friend Ian Amit.
I know, I know. He, if you knew Ian, like I knew Ian. I first met Ian, I'll tell you when I remember Las the very first besides Las Vegas.
Correct? I remember you giving me a ride back. Yes.
I gave you a ride back. And, and you know, a butterfly flies on that side of the world. I know.
I, I was the, uh, what the heck. The next year as a result of that, I was the wrangler, the for sponsors, right. And me and this guy, gene Kim mm-hmm.
Was also on the board that year trying to help make besides, uh, Las Vegas successful. And then Gene says, Hey, you wanna grab dinner tonight? And I, I went to dinner with Jean and we had about two bottles of wine.
And he says, I'm working on this book, I'll show you an early, like, manuscript, right? And tell you who I, who, who is mm-hmm. Who are the characters based on, well, that book was the Phoenix project, of course.
com and everything else that's happened in my life in the last 12 years, 14 years, is thanks to me, basically. Thank you. You're the butterfly.
Yeah. There you go. Butterfly on the other side of the world.
That was fla, its Wings. So, Ian, Ian, you're a well, well known legend in the security business, right? What are you doing here on Platform Con?
Great question. So, you know, as you alluded to, you know, my background is in security, that's where I grew up. That's where I spent, you know, over 25 years.
Mm-hmm. Uh, everything from a practitioner hacking, pen testing, red teaming, you name it, I've probably done it in security twice and three times over my last couple of roles were as a ciso. Yes.
So, you know, you just stick around for long enough, you end up at those positions. Mm-hmm. And, and guess what the last, you know, four or five years of that kind of executive roles, I realized that one of the biggest problems that I've ran into, uh, kinda speaking about the butterflies and DevOps uhhuh, it came around was were filled with frustration.
Yeah. That, you know, security got to a point where we're really good at pointing out stuff and finding everything that's wrong and fixing some of it. But specifically in cloud environments, the frustration came to fruition when I realized, again, I, I have too much visibility, but I can't really do anything about it when I'm dealing, when I'm trying to fix things, I run into a brick wall that's called DevOps.
Yeah. These guys are overworked, security is only one of their concerns. Yep.
And, you know, sliding into their schedule, you know, kind of dripping a little bit of, of alerts and tasks just didn't, you know, it, it was, it's untenable. I can, I'm finding more stuff that they can ever fix. And in the back of my mind, I'm still, you know, hands on.
I'm like, look, this is an engineering problem. It's not even a security problem. These cloud environments are highly codified.
Why can't you just automatically fix it? And I was looking around, I was looking around no solutions. Everything around security was all about alerts and pro and, and automating the process of pushing tickets, I was like, it doesn't matter if you can, you know, push more tickets, that's not gonna solve the problem.
You gotta solve the bottleneck. And that's what led me to basically start this. So under that realization that, you know, we gotta shift truly left mm-hmm.
And fix the problem where, where it lives. And on the engineering side, I started Goba. And that's what we're trying to do.
That's what we're actually doing. So that's what I'm doing here. Got it.
We're gonna dive more into that. You know, I'm reminded when I still secure one of the companies I co-founded, right? So this is when we thought IDS was ready to go to IPS.
I remember that. Yeah. And to me it was a no brainer, right?
Because the fact of the matter is, you know, the average attack, I think I have many bits, but by the time it hit the firewall or passed through, that router went to you. Mm-hmm. You had to make a decision.
Right. It was over already. They were in, they were out, they were out, they were in, and it was done.
Yep. If it was an obvious thing, and back then obvious things were like code red. Right.
Or, you know, those kinds of worms, why wouldn't you just block it? Why, why not just block you're walking into dangerous territory? No, this is, this is the problem.
This is my second startup. My first startup back in 2004, Uhhuh. That's when this was, was in that confluence of IDS versus IPS.
Guess what we did? We realized that you had hundreds of rules Yes. Enabled on the IDS, however, on the IPS.
Exactly. Six. I know, man.
And you know why I lived the same life. Exactly. Because there's no confidence.
High rate of false positives. Yeah. And that startup back then was called B Defense.
We literally sat on that precipice between IDS and IPS validated their alerts so that we can deal with them on the IPS side. Yeah. Fast forward 20 years, we have the same situation.
Now it's in the cloud. Uhhuh, I have hundreds of alerts from I-C-S-P-M and CNA and all the fancy things that I can buy for a lot of money. A lot of them are false positives still.
That's a big part of that lack and the whole deens desensitization. Exactly. Exactly.
Like overworking the sock worker. Except as you mentioned, it's a little worse now in that it's not just confined to the security guy. Correct.
We're pushing it on the DevOp engineer. We're pushing it on the developer. Correct.
Who doesn't necessarily want that aggravation. They just wanna develop, they want to Yeah. Deploy stuff.
Exactly. Exactly. So is platform engineering the answer?
I don't know if it's the answer, but it's another milestone in Okay. You know, in the journey it started with DevOps, as you know, and then DevSecOps, right. And platform engineering in, again, the way that I see it is just another step towards that Correct.
Direction. So we started DevOps, DevSecOps, PE is really where it's at these days where everything is, is, you know, kind of embedded together security and operations and the door metrics. And so yes, it's, it's, you know, this is the proof day.
This is the proof, you know, I'm here, I'm meeting, you know, my, my customers where they're at, not just with the product. Where again, we, we started as a security product. We ended up being a DevOps product.
Great. What a great story It is because I had that understanding that, again, this is not a security problem. Security doesn't have a problem in the cloud.
They can detect whatever they want. It's an engineering problem. It's, it's a bandwidth problem.
It's a knowledge gap problem. Yeah. There's that.
And, and there's also a scalability problem. Exactly. Scalability.
Right. com. Right.
And because I, to me anyway, I saw it as, as you scale up that DevOps job mm-hmm. Mission becomes much, much harder. Mm-hmm.
And you can't just say, oh, well we'll shift left, we'll shift. Right. We'll, we'll shift more left.
We'll keep shifting left. Eventually you come to the precipice and you, I don't know, you know, this is it. Yeah.
Like the movie Wall Street man looks in the precipice and that's when he knows he's a man bud. You know? But, so you can't just shift left your way out this, and to me, platform engineering is instead of just putting it on a developer, instead of the security guy banging his head on the wall until his head or the wall gets soft.
Right. Can we pregame it? Can we pre engineer it a hundred percent so that it, it is finally built and not bolted up.
It is. It is. And that's exactly the approach that we're taking.
As I mentioned before, we're meeting our audience where they're at. Mm-hmm. Not just here physically in New York, in platform engineering with our, you know, with our audience, the engineers, but also with a product.
We don't open tickets. We're done with tickets. The world has enough tickets.
We're opening the world's got enough tickets, we're opening prs. Here's the fix. I did the work for you, by the way.
I'm not taking your job. I did that work for you so that you can free yourself up to deal with architecture, with functionality to the things you're supposed to do. Exactly.
The toil goes away, the knowledge gap gets closed in a PR and even further left in your IDE as you develop, as you vibe code. Right. And ta you know, and get, get, and you know, what you ask is, is platform engineering the answer, I'm, I'm not sure you know, what next up is going to be, you know, this whole IAC thing, this whole deployment thing is gonna move completely to the developer side because DevOps is gonna go away, right?
Because it's fully democratized. You know, you're gonna have copilots and, and, and cursors and duos and things like that, generating the environment that the developer wants to support the application that they're building. But again, the problem right now with those gen AI tools is that the environments they create aren't really grounded in reality.
They're generative. And that's, but they'll get better. They'll get better.
They'll get better. I agree. They'll, they'll get better.
But as long as they're not deterministic. Right. And this is what kind of we set ourselves apart.
We're using deterministic AI rather than generative the ai, we, I know this is live, but we literally RTFM for the developer, for the engineer based on the cloud documentation, based on the IAC, based on the security policies and the general DevOps policies, including finops included optimization. We align those IAC platform that those IAC templates to what you actually need to accomplish or to the, the constraints. And where does this live in?
So this lives either in your ID or in your git pipelines, in your DevOps pipelines, where it should live as a reviewer that produces those remediations. And I mean, it's not like a person reviewing it, it's a process automated. It's a fully automated process.
You know, you don't have to wait for someone to review it. It gets done within seconds. I love this.
All you have to do is again, you can either vibe code it, or you can, you can manually code it or use your existing code. The second you introduce us, we come in, we review and we provide those remediations, those fixes. Nothing is done automatically.
So you still have full control. Mm-hmm. Just like a DevOps architect should have someone, you know, instead of of it being a junior DevOps engineer, it's us.
Comes up with a pr, fully explained, fully reasoned, fully documented, here's what we're doing, why we're doing it, here's the gaps. We're closing fully contextualized. Again, this is not template based.
This is not paved roads as much as a lot of paved roads. Mm-hmm. We're paving the roads, right?
Yeah. We're not forcing you to, oh, you have to go to get from here to here. You have to go from here to here to here, to here to here.
That's paved roads. I just wanna go from A to B. We'll pave the road for you.
We'll provide the specific code that supports what you are trying to accomplish with the combination of meeting all the security requirements, all the policies that you are management set, bam, there, there's the code. Review it. If you like it, merge it.
Great. If you don't make some modifications, that's it. As I said, we're meeting the engineers where they're at.
No tickets. What about scalability here? Easy.
We're operating at the code level. So it's, that's it. It's happening on its time.
It's happening as, so there is no backlog. Exactly. There's no backlog.
I'm not bound by the scalability of your, your cloud platforms. Even better, you know, at code you can describe an environment using five 10 resources that might show up as thousands of resources in your cloud environment. That's exactly the scalability.
We're operating at the code level. We're making sure that that is done precisely and correctly so that your actual deployments are going to be precise and correct. Let me ask you another question here.
It lives in my, it could live in my GI pipeline, correct? As you say, in the IDE, depending what IDEI use, I guess. Sure.
But is it sort of an agent that you're doing here and it's talking to your mothership out here? Is it To a degree, yes. So obviously we, we enforce the, or deploy the deterministic AI in a localized fashion on, on your end.
And I, I can probably kind of preempt what you're asking. No, we don't really need your code. I'm not learning from it.
This is a big difference between generative AI and theistic ai. I don't need to learn from other people's mistake to push them into your code. Right?
That's how YP kinda works. Yeah. So yes, it does live in your localized environment, and yes, it does speak with the modern ship.
The modern ship typically, you know, provides the constraints. It provides the policies. So, you know, if you're working for an organiza or an organization that wants to meet NIST CSF or CIS benchmarks or AWS, well architected whatever policy it is that lives in the mothership, okay.
That gets applied to your localized version of your code. That's where the fixes are being applied back to your Git environment. So yes, it is a SaaS product, right?
It's very lightweight. Uh, it is operating in, in sort of an agent AI fashion, whereas it, you know, it mimics the behavior of an agent of Sure. A developer.
And hence the integration. We're almost outta time. But what, what's the website?
ai ai. We've just recently released a community edition, so Oh, really? Go check it out.
Go check it out. ai, you'll see the community edition, uh, sign up. It's completely free.
We don't ask for anything, no strings attached. Uh, the only limitation is that it only operates on Terraform Code in GitHub. It's a GitHub app.
So again, you can just deploy it, fix your code, experience it, and if you like it, you know, we can keep talking. I love it. Ian, it's a pleasure meeting you as always.
It's too long. I love the karma. All right.
Goba ai. Correct. My friend Ian o meets company.
Check it out. We're live in New York. We'll be back in just a moment.
Hello and welcome to the latest edition of the digital CXO Leadership Insights series. I'm your host, Mike bza. Today we're with Nick Mistry, who's CSO for Lineage, and we're talking about, well, what is it gonna take to secure the software supply chain for autonomous vehicles, which are essentially our well computer platforms on wheels.
Hey, Nick, welcome to the show. Hey, Mike, good to be on the show. Again.
We've been talking about the need to secure software supply chains in general, but what makes securing them for autonomous vehicles different or any more challenging? Yeah, no, that's a great question. Obviously, uh, I think we can all appreciate the potential risks of somebody compromising software within, uh, autonomous vehicles.
Uh, and, and the reason we, you know, that becomes even more complicated is just like any other, uh, software producers, and in essence, as you mentioned, you know, these vehicles are, uh, run on software. Understanding all the third party and all of the components that are being brought in to bring together all of these different capabilities from autonomous vehicle perspective is incredibly challenging. Uh, we're, we're talking about hundreds of different suppliers, you know, bringing in, uh, different software components into a vehicle, understanding each one of their components and the supply chain and the supply chain risks can be daunting.
Theoretically, at least as I understand it, there's supposed to be some, uh, safety level in your software that you're supposed to retain when you're building these vehicles. So, um, is that being universally applied or is it kind of like, well, the operating system secure, but maybe not so much the component sitting on top of it? Yeah, no, that's a very good question.
I think the challenge for the, uh, automobile industry is that, uh, they're relying on their third parties, right, to do that level of testing and assurance, uh, when they bring them into the vehicles. Uh, and I think, you know, one of the issues is do they have the ability to understand supply chain risk? And also, as you mentioned, historically, the testing has been done, uh, really at the, at the software level, but not necessarily fully understanding the supply chain risk.
You know, one of the things that points to this is the US government, uh, you know, recently, uh, issued a mandate saying that any software embedded within, uh, vehicles sold in the us uh, must not contain any Russian or Chinese, uh, contributors or entities involved in developing that software. And that just points to the potential risk that a state actor, uh, make, you know, take, take control, uh, or take advantage of software that's inside, uh, these autonom vehicles. The other thing that comes to mind here is that there's a lot of updates being made, not just to the vehicle, but over the air, to the entertainment systems and everything else that happens around there.
So, um, as that becomes a more dynamic experience, how do we know that that software is secure? Because, well, mistakes can be made A hundred percent. So one of the things that, you know, the auto industry, uh, is actively building and driving is, you know, focusing on software build materials, understanding what are all the components and the, the software that they pull together from thousands of third parties.
Uh, but equally important, not just at the time of acquisition, if you will, right? Getting software, build materials, understanding the risks, uh, but equally important during every one of these updates, how do they now manage and keep, if you will, accurate software bill of materials for every update of software that is, you know, being incorporated through, uh, hundreds, if not sometimes thousands of third party vendors that provide these services. So that is, uh, a, a huge challenge.
Um, and then the other part of that challenge is the continuous monitoring. So it's, it's great. Let's say you understand all of the, the components through software build materials, you understand the existing risks, but risks are always evolving, right?
And, and we know that. So add to that, what you just said over the air updates and constant updates to software that you've kind of created a very complex ecosystem of trying to understand exactly what software is running on these vehicles and, and understanding the risks and how to safeguard those risks. You mentioned SBOs, who's gonna read these SBOs because, uh, you know, I bought the car and I barely read the thing that came on the sticker as it is with all this, uh, features and elements thereof.
And I'm sure if somebody gave me an sbo, I'd be like, thank you very much, but I would have no idea what that meant. So, um, where does this become something that represents actionable intelligence? Yeah, so really the, the SBOs are, are, are right now at least the way it's being discussed, being used by the actual auto manufacturer so they understand all the software that's going into cars, understand the risks, and then can, can provide, you know, demonstrated evidence that, you know, they've done their due due diligence on securing that software.
And so it's really, the auto manufacturers are gonna be managing and maintaining those SBOs and then working with regulators globally so they can, you know, provide proof that, you know, they are, uh, managing and maintaining the safety of software. Uh, that's in the, How strict are these regulations gonna be? 'cause we've seen most recently, the administration has turned, at least for federal agencies, the notion of having an s bond as more of a suggestion than a requirement.
So will this become a another suggestion, or is it gonna be more of a requirement in the automotive context? Yeah, so it's, it's yet to be seen, uh, how stringent these, uh, regulations are. We are seeing the fairly stringent regulations in the eu, uh, with regard to open source and use of open source software, uh, across the board.
Uh, you know, and, and speaking with some of our, uh, automotive industry counterparts, uh, my understanding is they're, they're getting ready for that to, because a significant amount of third party and open source is used in, in their vehicles and software wise. And so, you know, they, they need a mechanism to demonstrate that, uh, they are managing secure practices of use of third party and, and open source software. Uh, so I know it's happening in the EU now in the us we're just starting to see some regulatory requirements.
To your point, how far will it go? Um, I'm not certain, but we are seeing, uh, the push of liability, uh, to the software producers ultimately. So these car manufacturers are gonna have to also figure out how to manage the, the software producers and in their, in their vehicles, uh, software build materials is one effective way to do that, whether it's regulated or not.
And we are seeing the automotive industry, um, uh, really, uh, I guess supportive of using SBOs to manage their third party. Ultimately, they hold a liability. And so, you know, they have the responsibility of knowing what's in their software.
How dangerous is this in reality? I mean, am I gonna see a situation where malicious actors are hacking in the systems and cutting the brakes while people are driving? I mean, how, yeah.
How much can this become a very serious problem? Well, we do know there's, uh, there's already been several incidences where, uh, you know, uh, let's say just threat actors have been able to, uh, take control of vehicles that are connected to the internet via a software that's vulnerable so that we know is possible. And we know the, the risks are there.
Now, how far and to what extent these threat actors will go. We're not certain, but we do know that, you know, they've already been able to do that. The other aspect to this is, uh, is, is safety, obviously, but then the other aspect is with all the cameras and other sensors these vehicles possess, what other information could they potentially also gather, right?
Uh, as the vehicles are traversing different locations and targeting potential individuals and their sensors. So that's, there's another aspect beyond safety, which is also the data that's potentially, you know, somebody's able to, to, to garner from, from the sensors. We're also starting to see conversations about using AI in autonomous vehicles.
And, um, might not that data wind up getting poisoned if somebody hacked into the supply chain. Yes, a hundred percent, right. And so there is a big push, uh, with, uh, with the AI in general.
Uh, it's being loosely called AI bill of material. So AI bomb. And the purpose of that is to be able to track not only your software lineage, but your data lineage that's used in ai and then what we call the model lineage.
So understanding all of those and fig, you know, being able to track and detect, uh, potential poisoning. Um, so those are very early stages. By no means are there any, uh, I would say, uh, clear cut ways of detecting and preventing, uh, poisoning, especially in the data models that are being used.
But, uh, a lot of work is being focused in that area within the industry. And also, uh, I do know within the government as well, I Think it's been about 50 years, but Ralph Nader wrote a book called Unsafe at Any Speed, do we need to update this thing? You know, that, that's probably a good idea.
Uh, we should, uh, probably update something like that from an awareness standpoint. Yeah. So what's your best advice to both the folks who are building autonomous vehicles and the folks that may wind up, you know, trying to manage or drive them or even a fleet of them?
No, I, I, I think, you know, just like most other industries, the automotive industries, uh, you know, run on software, right? And AI is only accelerating that the benefits are there. Um, and so the automotive industry, both the manufacturers and those are responsible for managing, and, you know, the autonomous vehicles themselves really need to understand basic software security principles and incorporate those, and also software bill of materials as part of that, uh, I'll give you a good example.
Autonomous vehicles, uh, and autonomous vehicle fleets, let's say in agriculture have become extremely popular for obvious reasons. And, uh, just now we're starting to realize, well, a compromise of one of those, uh, tractors could also have devastating impacts, not only to, uh, the agricultural industry, but to human safety as well, right? Because we have humans working alongside machines in these different, uh, environments.
And so really this, when we think about autonomous vehicles, it, it really spans not just individuals and their cars, but to your point, you know, fleets of autonomous vehicles. Uh, and so as I mentioned, it's early days, but really a strong focus on software, bill of materials, ai, bill of materials, understanding risks and mitigating those risks. And un and the last part I'll keep with this is I'll, I'll end with this, is doing this continuously.
It's not a onetime thing. It's not only enough to know, uh, this information at the time the software is pulled, pulled together and deployed, but continuously assessing the risk based on that information is, is critical. And this is a subtle point, but I'd love to get your opinion on it.
Um, is it the autonomous vehicle that we're trying to protect, or is it the robot driving the autonomous vehicle? Does those two things become one? Yeah, very good question.
Um, you know, I, I believe those two things become one, right? I, I don't think separating those two, uh, is going to matter in the future. Uh, there it's gonna be mostly, uh, the vehicles will be autonomous and the, and the robot at the same time, right?
I, I don't think we'll see any separation. Hey folks, you're hearing it here. Our cars, vehicles and all kinds of stuff are now computing platforms, but if we don't think about how to secure them, well, we may turn out to be more sorry than safe.
Hey Nick, thanks for being on the show. Thank you, Mike. Appreciate it.
All right. Thank you all for watching the latest addition of the digital CXO leadership series. You can find this and others on our website.
Please check those out. Until then, we'll see you next time. Hey guys, thanks for the throw.
We're here with Ryan Gross, who's head of data and applications for calin, and we're talking about the challenges that organizations face when they need to migrate databases, which is happening a lot more often than it used to, for sure. Ryan, welcome to show. Yeah, thanks for having me.
I think one of the challenges we've always seen is when it comes to lockin and the, the, the part of the stack that gives us the most amount of trouble has always been the database and the formats and the data and everything that's locked into that. Um, and I guess everybody's kind of hoping, you know, is that gonna get easier to move from one database to another? Because that seems to be the crux of the matter and the reason why so many people are running legacy platforms from far longer than they probably want.
Yeah, absolutely. That is something we, you know, I've been hearing throughout my career leading data and AI teams for a long time. You always hear the phrase data has gravity, right?
All of the cloud providers and everyone wants to get your data onto their platform because they are relatively aware that once that data is sitting there, it's gonna be much, much harder to move off of that plan. What people don't often talk about under that is that the data itself, because networking and other things has gotten so good over the years, it's not that hard to move like the raw data from one place to another place. What is much harder though, is that you have all sorts of processing over top of that data.
And so the combination of both of those things moving, both the data itself and everything that you do to gain insights from that data across platforms is really difficult. I've talked to some people where, you know, they can migrate the virtual machine and even the database, but the data itself might take them years after in that effort. And that's kind of goes into all kinds of weird calculations as to whether or not it may be worth migrating off a platform versus sticking with it, even though the licensing costs may keep going up.
Yeah, exactly. And that for the longest time, I'd say that that ROI equation was upside down for most companies that that fit the profile of starting with a database oriented infrastructure, maybe like 2005 to 2010 timeframe, where that was the primary way you built any application, maybe even earlier than that. And then 10 years of building up more and more and more logic and processing and analytics around that data made it such that the cost and the risk of changing the underlying platform was so high.
You know, you're talking projects that would last two years with very large teams and then, you know, maybe you're saving a million dollars, but a two year 10 person team is a lot more than a million dollars. So how do I foot that equation and get right side up? Yeah, I, I think the key thing here that's changed over the last year, year and a half, is the advent of generative ai and specifically generative AI's capability to understand process in right code.
And, um, that gets coupled with its ability to understand and process and analyze data. Because really in a database code, application layer or in the database, you are trying to process both the data and the code together. Typically, you would need to go have a team of, you know, 10 people each out there paralleled across lots and lots of different data processing logic, each going through reading all of the code, trying to understand what it's doing, remembering the differences between the platform it's on today and the platform it needs to move to tomorrow.
Rewriting that code, installing the, you know, the newly rewritten code, moving all of the data across onto the new platform, realizing they got something wrong, going back to the drawing board and trying that again. And, and it just became this very cumbersome and tedious process. And the key thing that that really changed is generative ai.
You know, agents, if you will, can do a lot of that rote work, not as well as humans. No, you're not as well as human database data engineering experts, but at such a larger scale, at a lower cost that it makes it possible to take all 5,000 database queries that need to be rewritten and process them all in parallel, understand what went wrong, iterate on only the chunk that didn't go well, and continue to go down that path. And what I've seen in experience is that you can go somewhere between two and a half and five times faster with the average kind of being three times faster in terms of effort required when you use an AI driven process versus a manual process.
I think everybody's had at least one bad experience where they tried some sort of modernization project and they called in a global si and then a busload of graduate students pulled up and moved in for two years and the cost went up through the roof and more than a few people probably lost their jobs and as a result, but is this getting now down to a point where I can take on a project like this and get it done in something I can measure in maybe weeks and months rather than years? Yeah, it is. And I think the team size too, like you don't need the bus.
Maybe a, a small van will get the team there these days. And so both a smaller team and also a shorter project duration obviously leads to significant amount of savings, but it also really dramatically reduces risk and overhead. So I think the, the biggest problem that actually stopped companies after they had, you know, they got burnt once by the scenario you just described, was not that it took a boatload of people at the beginning of the project, it's that there was so much undiscovered complexity that ended up making it take a boatload of people for two years instead of one or two boatloads of people in order to get it done.
So they, their costs that they estimated and budgeted for upfront ended up ballooning by the time they actually got done with the project. And so the AI get driven approach because you're able to actually analyze all of the code in parallel using AI in the same way you can process it in parallel using AI both gets it faster because of the, you know, processing as described earlier better because you have to drive, uh, you know, a test driven approach into this. Uh, you, you need to verify what came out and, you know, compare the data on the old platform and the data on the new platform and, and much more reliably as well in terms of estimates that you come up with upfront are much closer to what the actual outcome looks like.
So you're talking, you know, a team of four to five people for four months for a big complex database that's been built up over 10 to 15 years. You also hear a lot about smaller projects, but they're just as annoying. And it usually goes something like this.
A developer creates an application and they downloaded some database that they built it on and then, uh, you know, they're running it for a couple of months and then they gotta move on to the next project and they're looking for a DBA to dump it on, and then the DBA looks at it and says, well, I'm not supporting that particular database and now I gotta go convert that app into the databases that we are using. And that requires effort as well. So can we turn that down into something that maybe we can do in days?
Yeah, on, on something where you've got a limited amount of processing and especially where that processing was done, you know, with more recent technology, if the application layer is using ORM object relational mapping and the database code itself is written in some, you know, if it's multi-step processing using something like DBT, it's much easier to understand and translate those types of code than these, you know, stored procedures that have a thousand lines and call five SQL functions that are typical of, you know, a decade old or more projects. So in those cases, yes, you can oftentimes go much faster. And also you can take the risk down by using a little bit more of like the AWS schema conversion tool approach, where you've got a little bit more of a, um, rules-based approach versus an AI driven approach to doing some of that translation where it's more modern code.
What will be the incentive to kind of consolidate or shift from one database format to another in the age of ai? 'cause I'm asking the question 'cause some folks are thinking, well, I don't have to worry about that anymore. The AI agent knows how to access all that stuff and we'll pull it and then they'll share it amongst themselves and gimme some sort of output.
But is there some benefit to be gained by modernizing the underlying database structures? There certainly is. So ultimately the AI agents will allow you to generate whatever queries you want these days quite effectively, but it doesn't necessarily mean that those queries are going to run efficiently on the underlying data and the way that that data is structured.
So oftentimes natural language query opens up a whole new audience of people who can then come in and write queries that end up knocking your database over in, you know, proverbial terms there. And the DBAs are getting calls about the CPU being on fire, that storage is, uh, continually getting churned 'cause you're out of memory. All of those types of things that DBAs have been dealing with forever.
Maybe in a more cloud modern platform, you can just scale up the compute that's allocated here that just leads to the CFO coming and, you know, banging down your door saying, why are you spending, you know, millions on this underlying database platform. So there is certainly something to be said for AI actually exacerbating the problem of some of these legacy structures, legacy databases, because it brings so much more accessibility to a wider audience to be able to bring queries versus the DBA driven approach of the past. Mm-hmm.
And then I, I will say that the licensing costs in this case are not solved by ai, right? The, if your underlying data is sitting on a platform like Microsoft SQL DB two Oracle, that has significant per core licensing, AI does not magically make that go away. Do you think that as we get into the age of ai, the volume of data that we're gonna be playing around with is certainly gonna exponentially increase?
And is that also gonna force a database consolidation conversation just because it will be too un wheely to manage across so many different formats, especially if they're older formats? Yeah, I think that's a lot of what we've been seeing is, uh, the companies that want to undertake these projects, the licensing cost helps it get over the, the hump right now of being able to justify the project cost in a pure simple to understand financial means. But really the teams that we're, that I'm working with are out there trying to do this for agility reasons.
They wanna move on to a cloud native platform. Oftentimes you've seen more and more, even over the last couple of months, consolidation towards Postgres as the defacto standard there with, you know, Databricks and the acquisition of a Postgres given company, uh, based company, snowflake doing the same thing. Obviously Amazon has for a long time with Redshift and Aurora had a strong footprint in that space.
And the reason you want to go there is because it can become very scalable. You can scale horizontally, you can replicate the database without any licensing constraints. You can look at rewriting the backend, how you store the data in different ways to take on analytical processing versus transactional processing in a way that still optimizes underneath the hood so that your end users don't need to care about how the data's structured.
And so that move from per core licensed databases towards open source databases is both to save the money of not having to pay those per core licenses, but also to be able to get the agility and flexibility to scale to that expected onslaught of AI demand for data. So is there something that organizations should be doing today to make sure they don't get locked in tomorrow when it comes to databases and data file formats and everything that goes with it? Because I think it's pretty easy to still, you know, find yourself locked into something, but are there particular formats that I should be saying, Hey, we need to make sure we adhere to this, otherwise we'll pay a hard cost tomorrow?
I do think that the, like I mentioned before, the two standards that seem to be becoming defacto if you're starting a net new project today are for database protocol. The, you know, the Postgres Pro protocol and the various implementations of that are now supported across most major database platforms for both applications and analytics. And then for the raw storage of mass volumes of data, um, Apache Iceberg seems to be becoming the defacto standard.
And so in those types of greenfield scenarios, you oftentimes can just start building out on top of those protocols. And then again, you still need to think through in both of those cases, how do you actually structure the underlying data in order to be able to support both efficient queries with lots of filtering as well as, you know, machine learning and AI type use cases where you want to get data in bulk and to see that as somewhat orthogonal to the targets here of moving onto that modern platform. But very few companies are out there really truly starting Greenfield.
It's almost always that you have to maybe set that up as your platform of the future and then move your current legacy footprint towards that platform while also building the new things there. So what's that one thing you see organizations doing over and over again that just makes you shake your head and go, folks? I think we need to be a little bit smarter than that There.
There's certainly a couple of them that come to mind here. If I had to pick the number one thing that I've seen, it's starting the process of building something without actually thinking about it from a data first lens. So we're going to build this application, mainly we care about the screens or the way that that AI agent is going to be able to respond in the, you know, the tone it's going to use, and then the data is just at whenever.
We'll, we'll throw it in there however we need to right now, and then over time we'll just keep hacking a layer on top of that and a layer on top of that and a layer on top of that until we're able to meet the end user functionality that we want to deliver. And that's what all these companies that we're talking to today about trying to modernize these platforms that they basically thought that they had gotten themselves trapped into, that was the exact pattern they followed that led them to be in that scenario. And so it's interesting to still, still see companies doing this today.
Just take the, you know, the latest trend on vector database. Oh yeah, we'll just throw everything in some JSON, we'll throw a vector store on it and that should solve all of our problems. And then as you need to make that perform, taking that same data set and taking a process where you are packing off little bits of it and storing it structured and continuing down the path of keeping that all in one database, you're just setting yourself up for a tech debt remediation problem four or five years down the line.
Hey folks, you heard it here. All good and bad things stem from that initial decision you made about the data. So be careful out there.
Hey Ryan, thanks for being on the show. Really appreciate it. Really enjoyed the conversation.
Thank you. And back to you guys in the studio. Modern AI servers are loaded with GPUs, but if you spend too much time, uh, waiting for data, then you're not getting much out of them.
This episode of utilizing tech focused on AI at the edge with soy features Kelly Osborne of grade technology discussing the latest in data protection and acceleration. Welcome to Utilizing Tech, the podcast about emerging technology from Tech Field Day part of the Futurum Group. This season is presented by soy and focuses on AI at the edge and related technologies.
I'm your host, Steven Foskett, organizer of the Tech Field Day event series. Joining me today from SOY as my co-host is Mr. Scott Shaley.
Welcome to the show. How's it going, Steven? It's great to be, uh, have an opportunity to join you this season.
So I'm excited about what we're gonna be talking about today and for the rest of the season as well. Absolutely. And um, you know, what we're talking about is basically all the various components that are required to build AI applications at the edge, AI applications in the cloud, AI applications everywhere.
But really we're gonna focus in on the importance of basically the full stack under ai. Yeah, it, it's a great opportunity to kind of talk to that point. 'cause you know, AI is our shiny object today and we know that it's here to stay, uh, for the foreseeable future, but we still have to start looking at, you know, 2025 is a year we start to optimize our infrastructure around all the AI stuff that's been booming for the last year and a half, two years.
So, uh, taking this opportunity to meet with folks like our, our guest today on ways to manage, manipulate, protect, and take care of all that data that we're dealing with around all these AI workloads is very important for us. Yeah, as a storage nerd, uh, it always gets me when people don't take storage seriously, because the truth is, you know, you can't just assume that it's gonna work. You can't assume that it's gonna be reliable and redundant and performant and so on.
That's why we've invited, uh, Kelly Osborne, senior director of OEM and channel business at, uh, grade Technology Inc. As our guest today. Kelly, welcome to the show.
Thanks Steven and Scott, appreciate the opportunity. Um, as, uh, Steven mentioned, my name is Kelly Osborne, I'm with Grade Technology and I'm in business development. You can find me on LinkedIn at Kelly Osburn.
Not hard to find. Um, just make sure you put the E and the URN and you can find me. Kelly, tell us a little bit to kick things off.
Um, what is grade technology? I mean, I think most people have heard of RAID technology. What is grade technology?
Um, so we were founded about three, three and a half years ago to solve, uh, a problem in the space around NVME, high performance, uh, flash storage. And essentially the problem is when you develop a server or install a number of these drives in a server, um, once you impose some sort of raid data protection on them, you create bottlenecks that don't allow you to achieve the full performance of those drives. And when you spend a lot of money on drives like that, you want to get all that performance.
So we identified that as a problem in the market. So G Grade is actually kind of a twist on GPU raid and that's exactly what we're doing. So we have a product called Supreme Raid, and that is a software rate stack that deploys on Nvidia GPUs to accelerate the rate operations and allow you to achieve very close to a hundred percent of the performance of those expensive drives.
It's very interesting, you know, to that point 'cause uh, you know, soy being the solid paradigm on storage and being a, a self per lamed storage geek, much like Steven. Uh, one of the unique things about NV ME drives when they first came out, and you know, with soy being one of the pioneers in that front with our long history was NVMe stripped out a lot of what you could do with some of the other interface technologies. And so having to find a new way to work at a, you know, formerly existing problem is nice to see that, uh, g rates coming in and doing some of that work.
Yeah, we, um, I think identified two problem areas with traditional hardware rate where you plug your drives into a controller that's sticking in a slot, you artificially create lane limitations. Think of a toll booth on a super highway. Um, when you think of these solid dyne drives, each of them can maximum performance.
You need four PCIE lanes. So if you connect four of those to a card that has 16 lanes, you've already hit a hundred percent of the performance of that card. So how do you go past that?
Um, we allow that because the drives in our world are connected directly, directly to the motherboard. And if you have 10 drives, you need 40 lanes. We deliver that 40 lanes of performance because we have a patented, uh, technology that is out of path we call peer-to-peer DMA that allows the data from those solid nine drives to make it to the CPU or the GPU directly across the mother board without going through a gate, if you will.
The other side of that is software raid, where as you have more and more of these drives that are really fast, they're, they're real, uh, uh, really want a lot of attention. So you get a lot of interrupts and the CPU gets really, really busy CPUs are, are also are not very good at mathematical calculations compared to A GPU. So you start to choke on the parody calculations for rate five and six in those kind of environments.
And so the hardware rate scenario doesn't scale and the software rate scenario doesn't scale. We really shine when you get beyond four or five drives in a server and go all the way up to 32 in a single chassis. Yeah, this is really a, a big trend in the HPC and AI sector overall is, uh, basically having direct, uh, as you said, DMA direct memory, direct access between, uh, peripherals and chips generally.
And I say chips as rather than CPUs because that's also what's going on in many cases with, um, a lot of the, the GPUs and other, uh, AI acceleration sy you know, engines in, in modern systems instead of being, you know, sort of a, a star topology with the CPU at the middle and everything going through the cpu, it's almost a mesh or fabric technology where, uh, topology where things are going direct. It's actually more like a web where the CPU is still at the center, but there's links that go sort of around the CPU, is that right? Very much so.
So the, the way NVME works, it plugs directly into the motherboard of the server chassis. So the CPU, the memory, the PCIE slots, the drives, everything can see each other. We call that a, a peer-to-peer, uh, direct memory access, if you will.
So what we do is act more like a traffic cop. When a read comes to us, we know where the data is and we know where it needs to go. So we just tell that drive, send the data over here, we don't have to read it in and forward it, that would introduce latency and create hops and other things in your data path.
So, um, in the GPU world that's called, uh, Nvidia created something called magnum IO or GPU Direct storage, and that allows, uh, drives to send data directly to, um, A GPU and bypass that host, which eliminates that extra hop for those high performance workloads. The problem is when you impose read and data protection into that, you, you still have to force everything to go through something else. And we now have that built into our new version.
Yeah, that brings up some interesting ideas. I mean, you, you mentioned earlier, you know, kind of the idea of how many slots, right? And we look at new reference designs and things like that, and all the fun stuff that's getting put out there around, you know, how to fit so many of these chips to, uh, Steven's point into a system.
There's still a limited number of slots that are associated to that, whether it be, you know, PCIE slots in the hole where, where the, uh, product you guys are developing is at, or even the number of slots where a number of drives we can put in those are in place. So we get into those conundrums of, okay, how do best stuff the box and make sure that we're getting the maximum use out of that from both the storage technology, the partner technologies, like the, the raid, uh, Supreme Raid product and things like that. And you guys have recently worked on something new too that, uh, has recently made the press, so I'd love to hear a little bit more about that as you kind of started down that path just a moment ago.
Sure. Uh, we created a product, um, called Supreme Raid. Once again, that's our product.
Uh, the new edition that we have is called Supreme Rate ae, which is AI edition, and it implements several new features like GPU direct storage, uh, intelligent data offload, um, and that peer-to-peer. We also are incorporating a lot of NVMe over fabric and incorporating our product into, um, parallel file system environments like SAF and BGFS and Luster and providing that local data protection for those storage nodes. The other thing, uh, that we've done, uh, our traditional product is required to dedicate A GPU, um, and these large GPU servers like a DGX or like you see some of these, uh, servers from big manufacturers that have, you know, eight Hopper or Blackwell, um, SXM chips that are, you know, envy linked together.
There's not a lot of real estate to put another card in, but you have so much GPU performance, we now have a version of our software, the AE version that can run on one of those GPUs you already have, so you don't have to have yet another GPU in there powering our software. So, um, you know, that AE version, uh, we just, uh, demonstrated and showed it off at GTC, um, in San Jose. So, um, that's getting a lot of attention because when you buy servers like that, that have so many GPUs, if you are not feeding that data to that beast fast enough, you're not getting the full utilization out of that.
And those are typically very expensive and you want to get very close to a hundred percent utilization if you can. Yeah, we were recently, uh, at AI Field Day, uh, we had a couple of presentations focused on that at very topic, and one of the things that was pointed out was a study that showed that, um, the majority of, uh, enterprise, uh, AI deployments, and this is not hyperscaler ai, this is not, um, you know, sort of wannabe ai, this is the actual enterprises running AI workloads was, uh, the, the GPUs were utilized a very low percentage. Uh, if you had asked me, I would've said, you know, during actual work, you know, a production GPU cluster, you know, yeah, you're probably, you know, getting 50, 60, 70% utilization outta those things.
No, 35% of the respondents or the not respondents. 'cause this is actually a me a a metric based survey too. So it was actually measuring it.
35% of the respondents were getting less than 15% utilization outta their GPUs. Can you imagine if a factory bought a $30 million, you know, stamping machine or something and they let it idle, all, you know, 85% of the time somebody would be fired. And, and, and, and, and yet that's what we're looking at when it comes to these GPUs.
And there are a lot of reasons for that. But again, this was during active use, so the main reason was those GPUs were not being fed with data. Exactly.
And so what we, what we see in those environments, a lot of times, uh, those GPU servers will have local NVME eight or 16 drives. They'll run that scrap space in RAID zero, and that'll give them the best performance they can possibly get because they don't have any RAID bottlenecks. Um, but then the issue is they have to start a whole job over again if there's a dry failure, and it's not a negligible situation that you could have nonrecoverable errors or A-P-C-I-E error or an actual dry failure.
And so then you have to roll back to a known checkpoint. And so it may look upfront like you're getting better utilization, but in the long haul you may not. So, um, our, our theory is let's provide raid five or six or 10 or one or even erasure coating protection of those drives in that machine, but let's not impose a bottleneck to do it.
So you get close to raid zero performance, and yet you have that protection being able to lose the drive, continue running, rebuild the drive, um, the kinds of things that we're used to with raid. Um, and, and so that's really our focus. So it's an interesting step too.
'cause I mean, as the drive guy, right? I, I'm gonna sit here and tell you I have a, I have a high quality product, but there's always those situations where you do need that protection. We know you can't get rid of it.
And so you have to do something to manage it and, and eliminate the overhead to your point of what you're trying to do with those particular products. And as the data sets grow, there's always this term of blast radius. And one of the focuses of what rate has always been about, uh, the, the idea of raid, not your product, but just rate in general, is to prevent those things like that blast radius and other issues.
But even with these high quality drives, to your point, there's fewer of them in the system and you still got the legacy infrastructure that's around them. NVMe has definitely taken over the world a little bit, which is nice to see, but it, it's not, you know, all in everywhere and system still aren't optimized for it. So having solutions like yours tied together with the products and things like that, you know, we recently showed off a fun new toy at GTC two, so it's exciting to see how, you know, our advancements in technology combined with your advancements in technologies aren't just there for fun, but to actually help our end customers solve problems.
Yeah. And that's one of the interesting things, isn't it, Scott? Um, you know, you and I go way back in this, in, in history storage has been a bottleneck for a very long time.
And in many ways, you know, I'm sorry to say this, but storage is still the bottleneck, but it's not the storage's fault. It's the way the storage is being used. That's the bottleneck.
You know, I mean, these, these systems have incredible amounts of bandwidth, especially when you take, I mean, these modern SSDs. And as, as Kelly was saying, you know, the, the, you know, NVME drives with, you know, four, you know, PCIE lanes, you know, that's a lot of bandwidth, especially when you have multiple ones. But the problem is most people don't have the capability to actually use these things efficiently.
They don't have the capability to use all that bandwidth, or as Kelly was pointing out, they're strangling it behind a controller that kind of, you know, acts as a bottleneck on it. Um, it's a little frustrating it, isn't it? 'cause we finally have all this incredible performance and yet people are still not using it.
Yeah. And then that's another aspect of kind of as we evolve this ecosystem and these reference architectures and, and putting companies together like we are with, with grade and soy and even, you know, the GPU guys, you know, if you want to, you know, owners of GCC nvidia, um, as we evolve these ecosystems, the need to isolate the bottlenecks and solve them is one thing that we're actually starting to see with things like the new E-D-S-F-F form factors that SOY has been a, a kind of a big leader in, because adding this new form factor, which makes it flash only you can start to realize that now I know I'm not killing the hard drive. It'll still be there.
It has its reasons, but in the performance bottleneck situations where you really do need to really make those systems work better, truly DeVol developing that system to work with this new interface and the subsequent technologies that are tied to it, because we wanna make everything work well together, is, it's nice to see. I mean, to your point, Steven, we go back far enough that I remember putting one SSD in a box was a huge success, and now we're talking about let's a little, you know, put 32, 64, however many they can start shoving in these boxes. So it's, it's a great evolution.
I'm excited about what's next. And I, I wanna call attention to another thing that Kelly said and, and make sure that people heard it. Um, one of the things about these modern, uh, AI servers and, you know, and, and frankly, AI servers are gonna be everywhere, not just in the cloud or in training or anything.
I mean, especially at the edge. One of the interesting things about these is that they have a ton of compute power on the GPU or, you know, AI accelerator side way more than they do on the CPU side, and yet many, many supporting systems, I'm just gonna say that generally. And that would include storage, uh, use the CPU to do the work.
Kelly, you said that you're actually doing the RAID calculations in the GPU. Tell me a little bit more about that. Are you really doing them in the GPU in the right, right there in the course?
Yes. So we, we have a technology that's intelligent, um, basically intelligent parity production and what we're, what we're doing when a, when a right comes in, we actually allow that right to go straight to the drive across PCIE. It doesn't flow through our cart.
We do have to get a piece of that data into the GPU, the NVIDIA GPU, and that's where we calculate the parody. So then we lay the parody down, and then, so only a tiny piece of data's being written that comes from, uh, the GPU itself. And then we acknowledge back.
So that's how we achieve very high rate performance and very high iOS per second. On the read side, um, I mentioned when reads come in, we just do a redirect and tell the drive, send the data straight across PCIE, um, to improve that performance. CODA course, um, on GPUs are far faster at mathematical calculations.
Raid parity is nothing new. It's based on Reed Solomon, uh, depends on which level you're using, but those are just intensive mathematical calculations to generate disinformation that allows you to create data protection around these drives and around your data. Um, and we're not doing anything different in the algorithm, we're just implementing it in a way to maximize performance of these MVME drives.
When you, when you look at hard drives, we mentioned hard drives, hard drives benefit greatly from things, things like right cache. So, uh, traditional hardware rate controllers, um, that you see out there, you'll have batteries on 'em, you know, or capacitors. And what that is, is for right cache.
So the data comes in, we tell the application, the data's down on the drive, and then it gets written to the drive on the side, and then if a power goes out or something, you need to, you, you need to be able to have, you know, that cache backed up because the application thinks that's all written to disk. Ironically, in our world, we identified that, that kind of thing, caching, right? Caching actually introduces latency into the data path.
That's why we allow the data to go right from the CPU or right from the GPU straight to the drive. All we're doing is writing a parody. And so that, that improved performance greatly.
Um, and, and so that's, that's why we do it the way we do it. And it's, it's a very simple, very simple concept once you start to understand what we're doing. Yeah, those of us who've actually done some, some work on AI at the edge, um, I know that we've experienced the, the joy of tensor processors and GPUs and offloading this stuff.
I mean, you know, you go from trying to inference on A CPU to adding in a moderately powered GPU or a, you know, TPU module, and suddenly you're able to do not just a little bit more, but an order of magnitude more inferencing using basically the same hardware. In fact, many of us are using pretty low powered systems at the edge with pretty high powered GPUs there. And so it's analogous to e exactly that.
So you're doing, uh, object detection or, you know, facial recognition or whatever it is using the GPU cores. Well now you're using those same cores to do the raid. It's the same thing and it's offloading that CPU and it's allowing you to use a smaller, lower powered, you know, less cooling, et cetera, um, in the CPU side, and you're able to leverage that as well.
And as we said, in many cases, the GPUs are not maximally loaded in many cases. There is a little bit of bandwidth there, there's a little bit of, of slack space that you can use to do these calculations. So that's, that's a big, a big benefit.
Um, and, you know, from all the way, all the way out to the edge, do you have many people using, um, this sort of technology there in, in, in edge and inferencing use cases? Oh yeah. So I, I'll even mention some real customer scenarios.
Um, we have one, uh, this is a company that does, they've kind of started to blend AI machine learning with CFD, computational fluid dynamics and, and simulations. And they specked out a server from a well-known server manufacturer, and it had 24 NVME drives Gen four, so that should be seven times, uh, three and a half times 24. So, uh, somewhere around 80 gigabytes of a second at rate zero from for right performance the customer needed for, to get their application to run properly.
They, they needed around 40 gigabytes a second to write to those drives. So they bought the server, set it up, tested it with raid zero. It was great.
They set up, uh, the software raid that's built into Linux, Linux MD raid, not picking on any one Linux because it's a ubiquitous freeware. Um, and once they set up rate five on these drives, they got one gig a second. So the drives are theoretically capable at writing at 80 in, in total.
Um, and they were only getting one. We demonstrated 68 out of 80 with our technology. And so the customer has solved that problem.
We have another similar situation in, uh, a customer that's got a large high fre frequency trading model database. They actually have, um, 22 servers that happen to have 32 solid dime QLC drives in each one. They're writing huge amounts of data really, really quickly.
And they have to keep this for analytics and forensics and, and historical, you know, logging and similar problem. They were only getting one or two gigabytes a second with, uh, this traditional software array. So in that kind of environment we've come in and, you know, helped out the customer or the customer sat, retrofitted, whatever you wanna say.
The challenge now is how do we, how do we start to condition server manufacturers like this to understand where, um, the performance bottlenecks are and how we can solve that with great technology. And we're making a lot of inroads with these server manufacturers. That's, that's great to hear.
And, and to that point, like we, I've talked a couple times now about the ecosystem. It's good to hear where that's, you know, seeing some traction from your perspective as far as those efforts and things like that. When we, when we kinda shift back to kind of what Steven was mentioning about the edge environments, there's also the concept to keep in mind that the throughput capabilities, he mentioned underpowered CPUs, for example, in those systems, being able to do anything to relieve that stress is definitely valuable to these customers.
I love the, you know, between the two of you, you had the, the super highway with the, you know, the pinch points or the manufacturing company that spends way too much money on a stamp maker that makes one stamp an hour instead of a million stamps an hour. It, it all shows to what we're trying to do here in this, uh, amazing new ecosystem we're developing and excited to see how the AI train continues to move forward and gets more properly utilized, I guess is the best way to put it. We've thrown a billions, you know, the companies have thrown billions and billions at it.
And recent s uh, you know, snippets between, you know, the, the fat, the fight of G chat, GPT and deep seek and all that kinda stuff have thrown us all into a little bit of a loop showing that, you know, what we're working on, the stuff that we're doing under the scenes, behind the scenes, under the hood, whatever you wanna call it, really does make a difference in what's going on in the world. And it's, it's almost thankless in some ways because we don't necessarily expect the recognition but real, we can see what we're doing as having a major impact. You bet.
I, we're working with some medical device companies that bill CT scan machines and MRI machines and things like that. And one of their gating factors is how quickly can they take the information that's generated from these, uh, scanners? How do they get that down onto, you know, media where it's stored securely?
How do they get it done quickly? If we can double the speed that machine can handle twice as many patients, you can help more people, the clinic can pay for that machine more quickly 'cause they cost millions of dollars. And the real thing that we keep seeing over and over in, in our market, and it's not just storage.
Anytime you put something faster, anytime you improve the performance of one component in a system, you rarely get the full performance of that component because it just exposes a bottleneck somewhere else. Um, I kind of think of it as, you know, you put a bigger, faster engine in your car or supercharger on your car engine and then you find out your brakes are really bad, so now you gotta go upgrade your brakes so you can stop the thing, or you need a better transmission to handle the torque. You can't just make one thing faster and expect the whole system to be faster.
And so, you know, we're specifically focused on protecting data. That's our a number one. You know, your data is more important than anything, but if we can do it and get outta the way and allow that data to flow and allow you to achieve higher, you know, performance, then that's even better.
Yeah, that's actually a, a key point there too. We've spent so much time talking about performance protection is critical as well, and in, in, unfortunately what I've seen is many, um, use cases, especially in edge use, unprotected storage instead of, and, and, and that's a big risk. You know, that's a big challenge, you know, there's constraints.
Sure. Uh, you know, you, you may not have as many drive bays, you may not have want to invest in raid cards. You may have been, uh, burned by software raid or whatever, you know, uh, that didn't work and didn't perform as well as you had hoped because it was, you know, reliant on old technology and CPU cores and things like that.
Uh, but with a lot of those problems are being, are being solved, you know, we're kind of in a new, in a new world, uh, you know, flash and SSD based computers are kind of like electric cars in a way. You know, it's, it's sort of a, a completely different paradigm of, um, of the same, the same thing, but you have to treat it somewhat differently. And, and when it comes to data protection and, uh, and storage, you know, as Scott mentioned, there's new form factors that would allow you to pack multiple drives into a compact form.
There's, uh, you know, new technologies that would allow you to, uh, very, very efficiently, uh, serve data and, and also protect data in those environments. So I could see this as really a transformative technology while maintaining that sort of compact and less expensive form factor. Right?
Yeah, absolutely. Yeah, I mean, to your point, we did kind of gloss over to some aspect. I mean, raid by definition is of course a protection scheme, but for those that may not be as familiar with it or the implementation challenges, hopefully through the course of the conversation, Kelly's done a great job of explaining a lot of that to us too as well.
But, uh, data protection is absolutely paramount. There's things that you have to do at all the different levels to, you know, preclude all the wonderful things we're hearing about cybersecurity problems and whatnot, let alone just data integrity problems for the base hardware. So it, it is gonna be an interesting ride for the, the foreseeable future, and we're excited about the partnerships that exist with, uh, with great and, and a and the whole solution stack that we're working together on.
So Yeah, you know, we've, we've talked about a lot of the high performance features we're adding like GP direct storage, but there is a slew of data protection features that we've added, like, um, right, journaling. So, um, in a right, right in a rate degradation mode where you're rebuilding a drive, we now journal every right. That way if you have another failure, you eliminate, uh, a corner case known as right hole, uh, which call comes from a double fault where it's unrecoverable.
Uh, we now have, we can always go back to the journal and say, this is where we can pick up where we left off. 'cause we know that was written. Um, there are transient errors that can happen across PCIE and even in these drives you can have something called an unrecoverable error and A URE happens when something's changed in the data and the data's now no longer what you wrote.
Uh, maybe a gamma ray hit that cell in the flash and it's flipped a bit, you know, okay, if you are running raid zero, you are having a bad day now because you have a URE and it can't be recovered from, well, we can go reach across the drives with the striped parody that we have and recreate that on the fly. So we have now built a unrecoverable, uh, URE recovery on the fly as the application doesn't even know what happened. Um, and we just rewrite it somewhere else and then pass it on to the application.
We have customers that they believe they can run read zero because they're looking at just MTBF, um, and drive right per day specs from a drive manufacturer. And those are really, really good. But when you have 20 of those, you increase your failure potential by 20.
But a lot of things can happen that aren't the drive's fault. Um, many of my customers that are doing edge type things, we're talking about military battlefield installations, we're talking about harsh environments like, um, ships, you know, mapping the sea floor like data collection in an airplane. And drives can fail in that scenario through no fault of their own.
But it could be because of, um, EMI interference. It could be because of heat, it could be because of vibration, it could be because of corrosion and assault environment. So you've gotta take that into account as well, because, um, you know, the drive specs are fantastic if you're in a hermetically sealed data center that's at the right temperature all the time.
But that's not always the case. So, uh, if you don't protect your data, you're just asking for, you know, asking for a problem at some point. Yeah.
That, that's a great way to kind of segue us right into, you know, what's coming, coming soon in the, in the rest of the series as well around as we start focusing on AI and Edge and getting further away from those, you know, perfectly cleansed environments that a lot of these systems sit into. So I really want to thank you a lot, Kelly, for taking the time to join us, and I'll hand it back over to Steven here to kinda wrap us up. Yeah, thank you so much.
Um, and that is exactly what we're gonna be talking about. That's actually, that's why I love Edge Field Day and all these edge companies. You know, it, it's, in a way, it's kinda like the real world.
Uh, you know, it's when things get real, you know, it, it is, it is all well and good to, to build these systems in an environment that will never face challenges. But, you know, edge by definition is systems that are not in the conventional spaces. They're not in data centers, they're not in cloud.
In the cloud, they are everywhere. And they could be, uh, under the friars, they could be on a battleship, they could be in the back of a self-driving car. They could be on a, on a oil, uh, exploration, uh, site out somewhere out in the middle of nowhere.
And in, in all of those cases, um, you know, we have to think about all the things that can go wrong. And in all of those places, AI is making a tremendous impact on how people are, you know, what people expect and how people are using these, this data, these sensors are, are, are pulling in way more information than ever before. They're processing more information than ever before.
And that demands better and better capabilities in terms of, of GPU Sure. But in terms of storage especially, and that's really what we're gonna be talking about all this season on, on utilizing tech. Thank you Kelly, so much for joining us today here on, on Utilizing Tech.
As we wrap up the episode, where can people connect with you and continue this conversation? Absolutely. com is our website.
We have a number of, uh, parts of the website where you can look at different use cases, uh, customer case studies, et cetera. Um, we also go to lots of the big shows. I we mentioned GTC, we're gonna be at cloudfest, uh, over in Germany.
We're gonna be at the Super Compute show over there called ISC. We're gonna be at SC 25, which is in St. Louis this year.
I'll personally be at NAB, um, I'll be at Dell Tech world. So we're, uh, we're gonna be at a number of different, uh, events like that. And, uh, would love to re you know, connect with anybody who, uh, is gonna be there and would like to speak with us.
Just reach out to me on my LinkedIn, uh, page and I'd love to talk. Well, it's great to have you. How about you, Scott?
Uh, where can people catch up with soy? com/ai, uh, you'll find all kinds of cool stuff there related to what we're doing across the entire AI pipeline. Myself, I'm SM shaley at on the different social platforms.
And Scott Shaley, of course on LinkedIn. So happy to chat with anyone about what's going on in the world as uh, we start to move this stuff forward. And so I will also be kind of tramps in the world with Cloud Fest and, uh, data Center World and Dell World and sc all the, all the fun shows where we can kind of showcase some of the really new innovative stuff we're doing together with all these great partners.
And as for me, uh, you'll catch me, uh, most Tuesdays on Techstrong Gang. Most Wednesdays on the Gestalt it rundown. And of course, on the tech field a and utilizing tech podcasts.
Uh, look for Steven Foskett. Thanks for listening to this episode of the Utilizing Tech podcast. You can find this podcast in your favorite application as well as on YouTube if you wanna see what we look like.
If you enjoyed this discussion, please consider leaving us a rating or a review. We would love to hear from you. This podcast is brought to you by Soy and by Tech Field Day, part of the Futureum Group.
com, where you'll also find the previous season, uh, focusing on storage, uh, with, so you can also find us on x Twitter, uh, mastodon and blue sky at utilizing Tech. Thanks for listening and we will see you next week. Alright.