Techstrong Gang – November 13, 2024

What can be better than a Textron gang? From our studio headquarters in Boca Raton, coming at you from CubeCon in Salt Lake City, you're watching Textron Gang. All right.

Hey everyone, it's Alan Hummel and I'm here in Salt Lake City for Con and Textron gang. You know, we have a lot of our gang members here in various places around town here at Salt Lake City. It's, it's a busy cube con.

I think there's like 24 tracks going on today and more. But Mike Ard and I are here bringing you a, a special edition of Techron Gang and, um, happy to do it. We've got some really big news, but I'm gonna turn it over to Mike.

Yeah, I would argue we have the biggest news of the entire show. com. com all over again for me, Mike.

You know, I, there's something to be said for a good domain, And it's, it's deja vu all over again. Did you like that? That was my yogi.

Matt, did they know Yogi is in Salt Lake City? I don't know, but I think there's a couple of Yankee fans out there that were All right, that was my yogi. It's deja vu all over again.

So we launched this site, be off of some research that we did for the DevOps Next project, and one of the things we found there was, and it surprised me, but 61% of respondents said that they were involved in some form of a platform engineering project, might not be across the entire organization, but they were sounding benefits included. Things like developer productivity, standardization of configurations, reducing costs, and reduce complexity and even improve security. We're all drivers of this thing, and the numbers weren't very far apart for all five of those things.

So it seems like there's a, a big benefit total, and I'm not sure anybody's hanging their hat on one thing, or is it five things? First of all, 61%, not 56, but you did cite the source for that. Yeah, so I'll, I'll go with it.

All right. com. You know, not to get all Barack Obama has shown you, but I've gone through my own evolution you have on platform engineering.

Look, when it first came out, I, I'll admit it, you know, these guys were the, the, the, some of the folks in the community were trying to make their bones by saying DevOps is dead and pla long lived platform engineering. And you know, I hear that word trying to make their bones, I was making bones when you were dating cheerleaders as more Greenwood say. com, but over time I came to realize that that's clickbait marketing stuff.

com. No, I don't think that was ever the issue. No.

Well, some people were saying that, but what I think we've seen is what your numbers bear out. And, and it's not your numbers, it's the research we did in our DevOps next report, right? DevOps has done amazing things in breaking down silos between dev and ops and bringing security into the whole SDLC software, supply chain, security, s bombs, all these things.

It's done amazing things working in a cloud native environment, right? In this whole stack. But it's also put a big burden on developers.

True. That, That whole shift left thing of Yeah, the developer will do good, the developer do. So you're taking your highest paid resource in many cases and putting more non-development work on their plate.

And that to me is the reason why platform engineering needs to be, we need to give these developers an environment that allows them to go fast. To me, it's like, if these developers are mag left trains, we've gotta put in those mag left tracks and guardrails so that they can go as fast as that mag left train can go. Right?

And that's what platform engineering does. It, it it sets the environment. Now, is it truly, truly new?

No. I think a lot of our platform engineering ops folks, were already doing system architects. Were doing, you know, but it, it's put it all together in the context of a modern software development lifecycle.

And I think platform engineering becomes the, the architect of the new software factory, I think about it in a similar fashion with some other, um, caveats wrapped around it. I think part of the DevOps revolution was kind of, um, a reaction against overly rigid centralized IT teams and CIOs that were limiting productivity because people were stuck in these platforms that were not extensible. They couldn't add new tools when they wanted.

So developers went out and created their own platforms to go do that and decided they were gonna manage that. That in many regards to your point, became too much of a good thing, right? Because then they got saddled with all this stuff that had nothing to do with writing code.

I feel like we're trying to find the medium between two extremes now, where we had DevOps shifting everything left, and we had CIOs where everything was gonna be run from the right hand side. And I think we can get to some sort of middle here that makes everybody happy. And that's the challenge.

It's not easy to do. You gotta create everything from internal developer portals and self-service systems around that. So it takes work.

The thing I don't know for sure is gonna happen yet, and I'd love to get your opinion on this, is how big is this? Because at some point, do we bring together all the IT operations folks so that DevOps and ITSM are all part of the same platform engineering team? I mean, how big can platform engineering get?

So I think you're looking at it wrong in some respect. It's not that platform engineering subsumes all these other things. I think you gotta look at it, I'm gonna use a big word here, I hope I don't scare you, but you gotta look at it as a pantheon of, of frameworks, of processes, of, of ways of doing things.

Wait, I see some Greek gods. Yeah, that was sort of, that was from the Greek. I'm about to take out my Windex here.

It's not square eggs, but, uh, there's a pantheon that includes platform engineering that includes DevOps, that does include ITSM, that includes, I, I, uh, agile. Maybe it even includes a little waterfall. It includes SRE.

Yeah. DevSecOps. All of these things are pieces, components of the software factory, of the IT factory that modern organizations need to run to run at the speed of business today and what customers expect.

So it's not that any one of these swallows the other, it's this continuum of these are all the pieces. I will agree to disagree on this one point. Okay.

'cause I'm also looking over my shoulder at all this AI stuff. And as I see that coming down the pike, the one thing that's consistent about it is we're looking at the democratization of it, and it's gonna be easier for people to manage more complex systems. And not all of those folks need to be engineers, right?

We have armies of IT administrators now who can manage a Kubernetes cluster with the right tool. We have folks who are, um, administrators that may be able to stand something up and apply the patches without being a developer. So I think that there's some room here with this platform engineering thing.

I don't, without sounding too much, like Kumbaya might actually bring everything together. So to me, you're asking the macaroni and spaghetti question, right? All spaghetti is macaroni, but not all macaroni and spaghetti.

Mm-Hmm. Do we, do we get to a point because of AI and things that all platform engineers are engineers, but we don't need engineers to do platform engineering. I'm not quite saying that.

I'm saying that administrators can function like engineers. We'll still need higher end engineers, but we'll never have enough engineers as it currently stands. So we have to elevate the IT administrators to let them manage More.

Should they become platform engineers. Yeah. Junior platform engineers might be one way I would think about it.

So we can make an official junior platform engineer. That's something I aspire. It's a Little badge, Right?

What do you wanna be when you grow up? I wanna be a junior platform engineer, sir. Um, I, I, you know, I do.

I look, it's going to, it's real. There's a sizable community. I think most of the, most of the folks who work around the factory of recognize this now as a real need.

Um, I think what we'll see, and I, I wrote this in one of the articles. I forget which one on platform engineering is what effect AI will have across all of these disciples. All these disciplines, excuse me.

All of these disciplines. And I think in some ways it'll bring them together in some ways it'll maybe drive a wedge. I mean, overall, I think it'll be a good thing.

But platform engineering is real. That's what I want people to take out of this platform. Engineerings real.

It, it's a real thing that's needed and it's working. I want to talk about the site though. What can people expect?

com, Mr. Chief Content Officer. The site itself, the articles are gonna be more thought leadership generated.

So there'll be articles from practitioners, IT leaders, folks who are, you know, what are the challenges of implementing all this stuff? I don't think it's gonna be so hardcore news driven, per se, although there'll be news stories on that site. But it'll be more about let's kind of build a community to have this conversation in the first place.

'cause I'll continue to stand, pat, I believe we're on the cusp of the great convergence here. I think platform engineering, the site is the place to have that conversation. Okay.

And the, the site is there to have that conversation. I'll also add to it though, Mike, we'll be doing webinars and tech strong learning events around platform engineering. Of course, we'll be dedicating some real resources here to on Techstrong TV to platform engineering, as well as the Family of Techstrong, uh, podcasts.

We'll be, uh, having a platform engineering entree into that. So, you know, I'd like, and again, I wrote it in my articles. I text strong, we're about busting down silos.

Yeah. What I did there. Mm-Hmm.

Always. com, cloud native now, security Boulevard Tech, strong AI tech, strong do, uh, tech strong. It SM and of course digital CXL.

Yeah, I'm not sure we need to knock down every silos. Silos have a purpose and a platform and separation of engineering concerns is helpful. But right now, I can't navigate all these silos.

You know what I'm doing right here. I'm ducking. So the DevOps gods don't hit me with the light they're gonna strike you with.

But I think there's a lot of room to bring all these silos together in a much more federated fashion. And I'm looking forward to It. Fantastic.

Hey, Mike, we're gonna take a quick break. We'll be back. We might have a guest team joining us.

You're watching Textron Gang. All right, folks. We're back.

And as Alan mentioned, we're at CubeCon, which is one of the biggest gatherings of the open source community. Maybe the biggest is hard to measure these days, but I kind of feel like every time I look at open source, it's like looking at the best and worst of times, everybody's having an argument about, gee, we're having an awesome time, and others are saying we're not having an awesome time. And, um, it starts to feel like a Victorian novel in my mind.

But I thought you were gonna say it's the US political landscape. Could Be, could be. It's too soon.

Too soon. Too soon. Too soon.

Alright. Sorry. Too soon.

Well, we Got, we got Brian Fox, who's the CTO of Sonatype joining us for this little chat. And I, you've been looking at this as long as we have maybe longer. I mean, what is your sense and what's going on here?

Because there's been a lot of high profile forks Yep. And there's a lot of arguments about the role of vendors in this space. And at the same time, without vendors, there's no ecosystem at all, because there needs to be money in this system somewhere.

Yeah, I mean, I think we're, we're entering probably a new phase in the ma maturity curve of, of open source. I mean, open source is more popular than ever. Um, everything we use, any piece of software has open source in it these days.

And a significant amount of open source, you know, uh, 90% of the code base is often made up of open source components. And so it's more critical than ever. Um, you're seeing increased attacks on the ecosystem, on software in general, on technology in general.

And, and where open source is such a critical foundation of that by extension. You know, uh, there's a lot of focus on, on that underpinning. And I think, um, as we, as we move forward, it's, it's going to get worse before it gets better.

You know, we're seeing legislation in the EU from the Cyber Resiliency Act, the product liability directive. I think those things are gonna cause, um, organizations that are consuming open source to focus on the underpinnings even more. Um, they're gonna have higher expectations, which at first might not be welcome.

I predict that will become the new norm. Um, but when you think about vendors in open source and some of the forks you mentioned, I think what we're grappling with is the sustainability of some of these things, right? I mean, it's one thing to create a project that is sort of a pet project solves a problem for you and put it out there and work on it willy-nilly.

But you get some of these big huge open source projects that we see represented at this conference. Um, those cost real money, uh, to produce. Uh, I heard a stat, um, I was at AA sponsored thing earlier than the year where they got all the package registries together, and I heard that, um, one of the major, um, database, uh, uh, uh, federated database open source projects, it costs something like $60,000 each time they do a release to run the CI infrastructure.

Somebody's paying for that. The open source project's not paying for it. The users of that project are not paying for it.

Somebody's kicking in that bill. That party will come to a stop at some point until we figure, unless we figure out the sustainability. You know, I was a political science major in college, and one of the things they taught us when we looked at modern political theories and systems was that democracy was the best of the worst.

Yeah. And the same thing, I think applies to open source. Yeah.

It's not perfect. Yeah. We're running into scalability issues and, and market issues and government and, you know, uh, regulation issues.

But there really isn't anything better out there. No, I, I think that's a right, perfect analogy. It's not, it's not great, but, But it's the best of the Worst.

It's better than, than closed source and most dimensions for sure. So if you have something better, let's hear it. But if not, let's just try to make this the best it can be.

Yeah. And, and I think just like in democracy, you know, you, there's a bit of a chacha one step forward, two steps back kind of thing. Mm-Hmm.

There is fits and starts. Yeah. Starts and stops.

And, and, but through it all, you learn and you progress. And I, I think that's what we're seeing. Not all democracies are the same though.

And some of them are not as quite as open as others. Mm-Hmm. Same thing seems to be applying in the open source world.

And we're seeing now in the AI world where they're arguing about what's an open source AI model and what's not, depending on how much access you have to the weights and the data. So are we just gonna continue to have this conversation forever or End? No.

I, like I said, I think, I think, you know, using, using the lens of any other mature industry, open source is still sort of in its teenage years, let's say. Right? As compared to auto food.

And you've heard me use these analogies forever. I was best behaving my teenage years. Anytime.

Yeah. Yeah. We All were, At least we thought.

Right. Um, but, uh, so I think we're going through that. I mean, some people have, have coined, you know, the phrase post open to kind of represent some of these things.

And I, I think that's an interesting way to think about it. You know, I think, you know, you, you start from the beginning with like the, the really, uh, dogmatic, um, you know, uh, copy left and, and everything is free. You know, the free software foundation, and then you get a little bit more liberal with, you know, a Apache and some of these other things as, as these evolved, right?

We started in this, everything should be free for the public good. But I think we've now struggled with multiple different models over the last couple decades of companies being able to be successful building on open source, whether it's the open core model or the Red Hat providing services model. And those work to an extent.

But I think now with some of these forks that we're seeing, we're seeing that real tension between how do we create something that is really good for a, a, a set of users to build upon. Um, but, but how do we also make it in a way that is fundable, like VC fundable? You know, because these big projects, if a company can't exist behind them, most of them won't exist on their own.

Like, that's not true. It's not a perfect model. In some cases they will, but in a lot of cases they're not.

And I think we have to be a little bit more open to, like you said, there's different flavors of democracy. Things can be open, but still have companies behind them. And, you know, Sonotype, we've been doing this now for almost 20 years.

18 years. Yeah. And, and we have a little bit of mix.

You know, we have stuff that we do that's pure open source. Right. We run the Maven Central repository that's not a profit center.

We spend a lot of money for that. We have Nexus open source, which is mostly an open core model because we sell pro on top of it. Sure.

And then we have our, our supply chain stuff that's pure commercial. Right. So I've kind of had to live all of these different models.

And so I feel like I have a unique visibility into like the dogmatic versus the, the purely, uh, capitalistic side. Well, go ahead. I wanted to ask you this question.

The times that we've seen people change their licensing models, it's doesn't seem to work all that well. What happened? One with high profile case led to an acquisition.

The other one retreated and came back around and said, uh, nevermind. So yeah, a lot of people look at this as a signal of financial distress when these companies do that. So how would you possibly change the licensing terms after you've already established the community anyway?

Well, There, first of all, there are rules in open source that allow you to do this. You could take something, you know, I'll go back to the security industry. And Brian, you know, this, when we first got into security, there were some fantastic open source security tools run by f some fantastic people.

Our friend Ron Gula, tenable Nessus was open source, Marty Rush, snort Clam, AV Nmap. And the list goes on. And they, they ran into the same issues that Hashi and, and some of these other companies are doing at today.

It's not just, am I not making money or I'm not making enough money. Part of it is, Hey, I'm shouldering a large percentage of the cost of maintaining this project. And then there are other people who are just taking my product, putting it under the covers and building a project on top of it.

And they don't contribute anything back to the community. They're kind of para, It's unfortunately the norm. Right.

You know, it is, Are there cloud service providers that are just running The customer? They're doing it as well. And, and so now I'm going to disagree with you on changing licenses can be bad for business.

'cause you know what, Ron Gula is not hurting and neither is Marty. Yeah. 6 billion years and years ago Cisco to Cisco.

Yeah. So you can't, and and Hashi Hashi sold for a couple billion dollars too, didn't they? Yeah.

But I think that it felt like it Mitchell, it felt like a little bit of a distress situation. Well, there was pressure to do something. But that being said, Brian, you said something before that's important.

And that is about the cost of running a large open source project. I mean, I've, I've had a chance, I, you know, we work with a lot of the foundations within the Linux Foundation, and I've had some insight that I can't really share on here and what it costs to run some of the major CD products out there. Yeah, for sure.

It's, it's, it's seven figures. It's Shocking. It was shocking to me.

Like that stat I shared before, I was like, wow. No, no, I thought about that. It's seven figures a year to maintain these things Yeah.

Infrastructure. And It's gonna get worse. You know, because, you know, go back 20 years.

It was totally the norm when I was actively coding on Maven that I would do the work. I was a release manager. I built it on my laptop.

Yeah. The version that got included in OSX snow Leopard was signed by my key and built on my personal laptop. That was the norm.

Right. It was kind of cool to be able to say that. No, it was also, that was the norm.

Now you look at that and go, wait, this person that I don't know know, just built something on hardware I can't trust, that's not You want me to trust. Right? Right.

That's not, that's not acceptable anymore. Well, okay, fine. Let's put that on a ci cd system.

Great. Who's paying for that? Right.

So it's not as simple as it was 20 years ago where the donation was my time to write some effectively text and then maybe run a short build. Now the expectations are high. They're going to be higher as we're expected.

Critical. That's right. They're running more, more and more tools, those things that while they're in the cloud, they're still not free.

Right. So, so you're telling me that this hat that he's wearing, if I pass it around, that's not gonna work. Well, probably not.

Let's, let's talk about, but that's the next thing I wanted to, so that's the beauty of the Linux Foundation model. A little socialism gets added to this democracy mix. Right.

We, we, we bring in everybody, we bring a community together around a particular open source project. And the idea is people who have the deeper pockets and have more of an investment in that project and are profiting from it, maybe they should pay a higher share of the cost of maintaining that project Mm-Hmm. Than a smaller company or a, a certainly an individual or anything like that.

And, and so that, I think that's a, a valuable function of what the, the foundations, the Linux Foundation and all these cncs and all the OSSF, what they all do is they try to bring that community together. Not just to make the project better, but to have those who can afford to pay into it. Pay In.

Yeah. They're paying into the infrastructure and, and the governance and some of those things. Yeah.

I think, like I said, as as the world expects more and more of open source, those funds are gonna become even more important. Yes. Uh, to it, it may not be paying the developers.

Yeah. It may come to that in some cases. Right.

But, but it may, but, but at least the infrastructure has to be become What about the maintainers? Yeah. Yeah.

These maintainers, I mean, it's a, it's a thankless job in many ways. So what do you say to the, using your metaphor, the radicals who go off and build a fork and then undercut those companies? I mean, that's all Look in democracy and freedom of speech, they're entitled to go do that.

I Agree. Yeah. Right.

And, and if it's a better mouse trap, the market will reward them in many cases. I don't know if it's a better mouse trap. Yeah.

In many cases it's not. Because the core, the core people that have all the knowledge, it's not just about the code base. Right.

You know, um, if you don't know anything about it, it's not very useful to you. Um, and so, but that's not always true. Sometimes, um, there can be successful forks.

I don't begrudge any of them. I think everybody is playing by the rules of the game. Yeah.

And, you know, some people will get upset about it, but I think that, that, that's how it's set up. If you don't like the model, you can fork it. And if you can muster the resources to make that successful, well, that was in the rules of the game, right?

Mm-Hmm. But it's also, nobody can force a company to pay for maintenance and pay maintainers to work on something they give away for free indefinitely. And if you, and if you insist on that model, then all of these companies, they're reasonable, become unfundable and we won't be able to have these innovative things available to us.

So it, it cuts both ways. I think there's also millions of forks that people don't talk about. Every company that downloads something, winds up tweaking it in a way that creates some sort of thing, But not the open source licensing.

If you change that code, you're supposed to make it back of, and you publicly, you've gotta make it available to the project. Depends, Depends on the license. I thought OOSI licenses, you had to do that.

No, No. Um, the Apache one, for example, you don't have to, uh, the copy left ones, you do GPL. Okay.

Yeah. El to some extent. Yes.

LGPL, not Apache. So like, like your democracy comment, there's the spectrum. Mm-Hmm.

So in some cases it's okay, some cases you're supposed to do that and people don't. And so that's not okay. There's, There's a lot of things we're supposed to do that we don't do.

But, but let's look, let's look historically, right. The fact of the matter is, historically companies with deep pockets like IBM or Intel, or not Microsoft, IBM or Intel, drawing a blank here, but they, they would have certain people on their payroll who really worked on open source projects full time. Yeah.

But it was kind of at their, at the, I forgot the right term that you use, you serve at the, at the what of the queen. At the, At the Pleasure. The pleasure.

That's the word I was looking for. You served at the pleasure of IBM Mm-Hmm. And they could change their mind and say, we don't like this project anymore.

There's, there's, um, That's not a good Yeah. It's not sustainable. Can't, you Can't do mission critical on someone's goodwill.

That's right. That's why you need, you need a real Brand place. You guys put out, found that there are people getting paid by companies, but it wasn't that many, not nearly as many as I thought.

Yeah. Um, that was, that was the state of the software supply chain. Yeah.

In combination with the tide lift data. Um, yeah. I don't remember the percentage.

It's a small percent. Right. Um, however, we also found that our study this year, uh, of the popular ecosystem, there's about 7 million components.

Only about 700,000 of those are actively used, downloaded, included in projects. So it's about 10%. That's a more tractable number to, to try to fund.

Yeah. You're Head around. Yeah.

And so, you know, I think there's a, there's a decent number of those that are getting funding, you know, and, and their, their data shows that, um, you know, maintainers that are paid are, are like three times more likely to do all the things we want. They have less vulnerabilities, they fix 'em faster. Yep.

Right. So it shows that it works. Yep.

Um, and, and you know, it, it, it sort of boggles my mind. Um, there was, I, I think it was, um, one of the Harvard studies recently, you know, estimated that the, uh, the outward facing economic value of open source, um, is something like $3 trillion. So in other words, if open source went, poof, all the commercial entities worldwide would have to pony up 3 trillion, have a 3 trillion hole to fill that hole.

1% of that would cover most all of it maintainers, right? It would be, it would be a windfall to change this game. And so the, the thing is, it's, it's such a small amount proportionately that we're, we're talking about here, could really move the needle.

Mr. Capitalism, he's saying compensation drives behavior. So I'm, I'm a free, I'm a free market person, but, you know, a pure market could be brutal.

Pure free market's. Brutal. You need a little socialism in there.

But let me bring up another issue. Orphaned projects. Mm-Hmm.

I think there were a lot of projects that maybe were originally sponsored by a handful or one company who then gets bought moves on whatever. Yeah. And now you've got a whole community that's using this software and it's kind of orphaned.

And, you know, in many ways, the Linux Foundation is the orphanage. Well, yeah, I was, as you were saying that, I was thinking of a bunch of cases where it's sort of like a, a cut and dump kind of model where, where those projects just dump 'em onto an open source foundation and walk away. Sometimes, sometimes they're able to build a community, sometimes not.

It's very hit or miss. And that's, that's an unfortunate model where they say, you know what? We're moving on from this, so let's just See.

So, so Dickens did have it, right. It's Oliver Twist, and please, may I have another Right. Thank you, sir.

May I have another? But, you know, if those got Animal House, If those companies that are dependent upon that were involved, we're putting in some funding or dedicating pe their own engineers to get involved, they would ensure that there was a, a succession plan for that project, right? Yeah.

Just by being involved. And that's kind of the point here. It doesn't always have to be money, but, but having your engineers be involved in the projects that you're really dependent upon can change the trajectory of that.

And it, it's, it's illogical to me why companies would put all of their eggs in a basket that somebody else holds. That's effectively what's happening. If you're using all this open source and you're not involved at all, you're, it's, you're, you're at the whims of whatever, f And and, and you wanna build your business around that.

And you want someone to invest in that business around that. That's right. That's right.

That's a scary prop. Hey, Brian, I appreciate you just letting us pull you in like this. I, yeah, this Was fun.

It's Always fun to have you on anything other big news, Sona type or you personally here at Q Con this week? Yeah, We're here. We have an activation zone.

Um, we're talking about open source malware, you know, open, we've, we've covered this a a bunch of times intentionally open source malware components. Um, there's 700,000 as of a couple months ago, um, that we've tracked. And, and this is an interesting stat.

Remember I told you that 10% of those open source projects, that's also 700,000. So we've crossed the point now where there are more intentionally fake, harmful components in the open source ecosystem than the ones that are actually used every day. And, and that's an under understood mal, uh, uh, milestone.

So an activation zone is a place I'm trying to avoid or go to. No, you want to come, come, We've got some That's You, you, you can pick between the different things and see if you found your malicious component or not. All Right.

You're watching this. Go check it out. Brian Fox Sona type here on Textron Gang.

We're gonna take a break. We'll be back. com is the number one online destination for DevOps education and community building.

com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery and more. com has the largest collection of original DevOps content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com where the world meets DevOps. All right, folks, we're back with our final segment and we're talking about, well, the relationship between Kubernetes and AI infrastructure. And I'm not sure people realize that most of all these AI platforms that are out there, underneath that, at the bottom of those things is Kubernetes.

And what the next big argument about is now is all those platforms, whether they were built by Microsoft or whatever, are kind of do it yourself projects. They built it from the ground up themselves, enterprise IT organizations don't really have that capability. So you see companies here, like Nutanix is showing the next rev of their AI infrastructure platform, and they're saying that that's gonna be a little more of a turnkey kind of platform, and we're not gonna see necessarily so much of this do it yourself infrastructure approach to Kubernetes and cloud native that we saw in the previous era.

I, I agree with you. So it's funny, we, we have an interview coming up later today, Mike, with a guy named Alex y from its, uh, GMI cloud, gmi, cloud ai. Alex's company, and I interviewed him on Text Drunk TV a few weeks ago.

Alex's company is doing just that. They have prebuilt GPU clusters, but on top of that metal using cloud native Kubernetes containers, et cetera, they have built stacks that include all the way, like true platform as a service, right? All the way up to the building blocks of your apps, your LLMs, your train models, your, your your stacks to do certain common tasks within an app.

And you could almost building blocks, build your app like it. I do think that's the future. No one, no one, well not no one, but very, very, very few organizations will have the resources to train their own models.

Everyone today says, yeah, I'll put it in a Vector database and train it up, and I'll have my own custom LLM doing custom LLMs from scratch, I think are going to be, uh, it's a dead end. It's hard work. I think this conversation comes full circle to our A block.

I think as people start to move down these AI models, and some will be large and some will be small. The only way we're gonna get to that is with some sort of centralized platform engineering approach. And I also think that part of that conversation then is also the melding of this whole ML ops framework that people use for building AI models and DevOps.

And that's gotta have to come together because ultimately all those AI models are just another type of software artifact that we're putting into the application. So all of this stuff has to converge. And I'm not sure if we're all gonna come up with some, you know, platform engineering for AI methodology, or we're just gonna say, Hey, it's all the next generation of software engineering.

I, I wouldn't confuse platform engineering with, um, what's the right word? When you have models pre-configured models. Well, there's the models that you get the Bing LLMs and you can either customize the LLMs or you can build a small No, no, but I, I think what we're gonna have is there will be, and whether it's platform engineering folks doing it or not, there's gonna be best practices for certain models for certain outcomes that are not turnkey, but like they're 80% baked and templates and you just do the temp.

That's the word I was thinking. That wasn't really the word, but, but templates is a good substitute, or the word I was thinking of. Well, you'll have these templates and that it's 80, 75, 80% baked and you just, it's do the rest Prefabricated house baby.

I think that's the future. No one wants to build from scratch. Mm-Hmm.

And, and, and quite frankly, that's the beauty of the whole cloud native model, right? You could take these containers like literally Legos and build your containers, you know, into your Yeah. This here that there and, and they're, they're pre-populated too.

I mean, what could be bad about that? I think it's getting a little hard to manage. What are you, you told me this number, there's like 180 cloud native projects these Days.

Yes, there are. I think that's too hard on the way to 200. Yeah.

Plus I think that's too hard for the average enterprise to absorb. So the needs to find some other way to consume all that in something that's easier. But that's the, you know, I don't know if you remember, it was maybe a year or two, they tried doing a flow chart of all the cloud native computing foundation projects.

It wound up, it looked worse than the spaghetti models on our hurricanes back home. Um, but that being said, you know, my grandmother used to tell me every pot of chicken soup has a cover. She say some other things too, but she said that, I don't think you have to use all 180 models Or Projects.

Or projects, excuse me, of of open source. But there's so many different use cases within that tech ecosystem that I think those 180 projects represent a diversity and depth of giving you so many options in how you want to build what you want to do. I, it's, it's a sign of health, not a sign of sickness.

I just might want somebody else to kind of make that decision and take some responsibility for it. And, and you know what, that's again, you know what a big democracy free market person I am. Uh, but that's the beauty of our system.

You wanna grow your own, roll your own, you can roll your own Mm-Hmm. You wanna buy a pre-roll? Have I been in Colorado lately?

You wanna buy a pre-roll? You could buy a pre-roll. Yeah.

That's, that's America. Or it used to be America. So if you were gonna bet, is the bulk of the market gonna be more of these integrated platforms or is it gonna be the do it yourself or is it gonna be the small percentage or 50 50?

What's your sense of how that splits? You know, it's gonna be about using the right tool for the job. I think it's gonna cut across big and small.

There'll be times where a big organization says, I just need this widget and this widget's already here. I'm gonna buy that widget and use it. There'll be other times where they'll say, you know what?

This is core and critical to our company. We gotta own this. And they design it themselves.

All Right, I'm gonna vote for the 80 20 rule. 80% will be, Well, you could never go wrong with 80 20, 80% will be pre-integrated and then the do it yourself was to make up the other 20%. They'll be big companies then, But they'll, no, I think they'll be a dumbbell of the 20%.

10% will be big companies who roll their own. And then the other 10% will be hyper small companies who wanna roll their own because they wanna do something they believe that's radically different. Right.

And then they're gonna change their minds when they figure out how hard that is and go to the integrated Product. They may very well, we'll see. Or maybe they invent something new.

Yeah. We'll See. That's the creative process.

Anyway, Mike, we're off to a great start here for Textron Gang at CubeCon. We have a full day of live at CubeCon content coming your way. And we'll have, and we'll be here the rest of the week.

We have Textron Gang from CubeCon on Thursday and Friday as well. Yep. As well as, uh, interviews and content all day.

So if stay right here by this dial. Same bad time, same bad station for Textron Gang. On behalf of Mike Ard and Alan Shimel, have a great day everyone.

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

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

Contact us today and tell your story to the world in the most powerful way with Textron Group.