Techstrong Gang – April 2, 2025

Hey everyone, I'm a cube con. You're not, you're watching Textron Game. Hi everyone.

It is Wednesday out there and, uh, I am in Jolly Old England here in, uh, well, it's still London, but it's a little bit outside of Central London, let's call it, at the Excel, which is an amazing convention conference center. Uh, I haven't seen one. I think this is one of the best ones I've seen.

I mean, in terms of the, the, uh, just everything, the size of it, the, the layout of it. Uh, it's just a well done, well done place built out here on the Wharfs in, in London. Um, but we have, well, I'm joining in, in it in our Q con, uh, presence by our chief content officer who, uh, is missing Yankee games, though I think they're on at midnight London time tonight.

Uh, Mike Huard. Hey Mike. Welcome to London.

Actually, you've been here a watch. Yeah, I've been here since last Friday, but I am missing those Yankee games 'cause you know, you gotta, like what they did with the lumber, you know, they kind of moved all the wood to the middle of the bat. It's the torpedo bat.

The torpedo bat. There's going to be heck to pay over this. Anyway, Mike, it's good to have you here.

It's good to be in London with you joining us. Not from London, but he's home. He's back home at his base in, in Boulder where, you know, we, we should mention this, uh, we've had Andy, Andy's been on our gang now a couple of times, and you know, Andy had some time to be on the gang with us here because he was kinda deciding, plotting what his next global adventure's gonna be.

He's still kind plotting his next global adventure. If any of you watching out there are in need of an amazing strategist, leader, thought leader, CTO, he's, he's done it all. He can tell you more.

I don't wanna embarrass him, but do check out Andy Mann's, uh, LinkedIn profile. You can see how his name is spelled there. Um, hey Andy, welcome to the gang.

How are you man? Al I'm doing great. I mean, I wish I was in London and caving around the world with the old guys, but I'm just keeping it down on the home base here.

Alright, well it's probably about as cold here as it is in Colorado. I'll bet. So a little colder than I'm used to, but anyway, um, let's jump in.

Mike, what do we got up first today? Well, we're talking heavily about platform engineering at the CubeCon Show. I think I went to a Kubernetes show and a platform engineering conference broke out.

But, um, today the CNCF, otherwise known as the Cloud, cloud Native Computing Foundation will be formally launching their cloud native platform engineering certification, of which there will be two. It's heavily based on Kubernetes and they're positioning this as kind of the glue or even a job role wrapped around a certification rather than historically all their certifications have been around in particular platform or technology such as Kubernetes. And the platform engineering certification will include some stuff around the platforms, but also observability.

You gotta know something about security and you know, you have to really think about managing the platform. This comes after yesterday's platform engineering day at the show, which I think was the largest of the mini camps that they seem to have had at this show, or at least got the most number of people there. But there's still a lot of confusion of what is a platform engineer.

And some people are like, you explain it to them and they're like, yeah, we already do that. And other people are like, we don't wanna do that. So there's like this between, there's this whole spectrum between these two extremes.

Alan, I know you've been talking about platform engineering a while, but what's your take on, what is the, is there a difference between what the CNCF is gonna be up to and what other folks are trying to do with platform engineering certifications? I'm glad you asked Mike. Uh, so look, you, you are right, the platform engineering, uh, they don't call it zero day here at Q Con anymore.

It's, I, I forget their name. I was down in Excel today walking around and uh, but you know, basically all, most of the projects and then a lot of different areas have their own sort of conference within the conference day. And the platform engineering one was in fact, I think the biggest, if not certainly one of the biggest, but I think the biggest of them all.

And they were expecting that, uh, Chris a, the CTO of CNCF telegraphed that on LinkedIn a couple weeks ago. Um, it's interesting, right, because they came out with these two certifications, but the certifications still in CNCF form are, are very Kubernetes specific. org is doing, for instance, our friend Luca Ante, uh, those are more general, right?

They're more general, not necessarily Kubernetes centric or specific. It kind of reminds me, Andy, you remember back when I started help, you know, co-founded DevOps Institute and you know, Jane and Lisa and um, DevOps Institute, DevOps Certification Foundation, right? DevOps Foundation was the initial one.

It was very general, it was sort of soft skills. It didn't make a difference whether you were on AWS or what have you. Um, and then AWS for instance had a DevOps certification, but that was very technical and specific to AWS's platform.

I think we've got the same thing here with the CNCF certification. It's very specific to a Kubernetes cloud native stack where platform engineering, you know, recognizes the platform engineering dot orgs training recognizes more of a brownfield world where not everything's on Kubernetes quite yet. Um, now there is some, I will say there is a little friction maybe between these organizations here.

And a lot of it goes back to what you were saying, Mike, what exactly is platform engineering? Is it a bunch of old stuff, repackaged with a fancy bow? Some might say, yeah, it is, right?

A lot of what we're doing in platform, and this is outta Luka's own mouth, is sort of reactionary, right? Silos are good, silos are good. We don't need to bust down silos.

They just want to communicate. They take a lot of what we used to call ops CIS stuff and build the platform. They, the biggest thing about platform engineering is hey, maybe this is what we've been doing all along, but we kinda lost sight of that and instead tried to shift it onto the developer.

And the developer shouldn't have to build their own platform to develop on. And so whatever the dis discipline is, is that you're going to need, the disciplines are that you're gonna need to build that platform. So be it.

It's part of platform engineering. But there does have to be, I guess some team or some folks who are responsible for pulling in all the disparaged parts, not disparage, that's the wrong word. Um, disparate parts and uh, and putting it all together without disparaging anyone.

Um, but anyway, that's my take on it here. 0 and we never got that part of the equation right in the first place. 'cause a lot of the CI scripts don't lend themselves to that.

And so we needed a different approach and we're calling that platform engineering. I got other folks who were saying, uh, platform engineering is, you know, I put up an internal developer portal and now I have self-service so therefore I'm done. Um, then I've got other extremists who are like, you know, and I don't mean extremists in the sense that it's bad, but just that they're like wanna encompass everything including OpenStack and the storage systems underneath that is managed by the platform engineering team is as one wagon put it, you know, right now, today it's like instead of having an airport, we've got 36 lanes of traffic for airplanes to land on.

And each one is his own individual landing zone. And they're like, we need an air traffic control system for DevOps. And this is what that is.

So Andy, any of that makes sense to you? Yeah, look, I mean I think the first thing you need to do is look up the XKCD Comicon standards. You know, uh, uh, we have 12 standards.

Well we need to bring that all together. So now we have 13 standards. It's like that with these certification programs.

Look, I actually think the DevOps Institute one was really interesting because it was independent. It didn't have that focus on one lane or another. I concerned that CNCF is not necessarily gonna do the right thing by CTOs by taking a very specific view on what platform engineering is.

And look guys, I'm old enough to remember where infrastructure is code. I'm old enough to remember when it was operations automation, right? I mean, is everything all new?

Again, look, private cloud is just mainframes, right? Well of course it isn't. Uh, platform engineering is not infrastructure as code, it's not operations automation.

But I think it's really important to stop offloading all this ops work onto devs. Uh, you know, we tried to upload a lot of operations work in terms of the SRE and we, I think we got to good balance on that. If we continue to think that developers need to do their own system architecture and automation programming, then I think we're undervaluing what they deliver and we're undervaluing what architects and operators deliver.

So it'll be interesting to see where that all flows out. But as a CTO, I wanna see certifications in all of this stuff. 'cause it's too airy fairy to not have learning paths that give some level of knowledge that I can rely on my staff know what they're doing.

So I think this is good all over, but I'd love, I'd love to see it expanded into more of a holistic view of what platform engineering really is. Yeah, I wish there was some sort of maturity curve. 'cause I think there's gonna be tiers of, uh, activity along this growth path, but there are other folks out there who are saying this is flat out heresy.

We, uh, embraced the whole notion of you build it, you own it. And, uh, each of those teams went out and built their own little platform person who helped those developer teams work on that particular platform. And if you're dependent upon a platform engineering team, you can't own it anymore, is what they would say.

And that may be a minority point of view right now because you know, you have to have a lot of engineers to really support that. You build it, you own it, you gotta be like a Netflix. I don't think it necessarily works in the average enterprise because it's just too expensive.

But we have all these opinions out there. Alan, I think, you know, we need a United Nations of platform engineering conference. Well, it's called Platform Khan.

I don't know if it's quite the United Nations, but they're expecting 40,000 people to register for Platform Con. It's virtual, well, it's hybrid, it's virtual, and there are two in-person days. One in London and one in New York City.

Uh, tech Strum will be at the New York City one streaming live all day. I'll be up there in the end of June, looking forward to it. But here's, here's the, the bottom line, whatever it is, it's proving to have some real legs, right?

It is the biggest sub sub conference here this year. org is two or 300,000 people strong. Two to 300,000 people involved there.

org folks, uh, party tonight is probably the biggest party here at CubeCon. And that's always an indication of how popular something is, right? Who has the bigger party?

Um, so whatever it is, hate it, love it. Like it or not. It, it's certainly proving extremely popular and attracting a lot of attention, not just to Q Con, but in the market in general.

And look for mine, it makes sense too, right? Because when we look at cloud computing, especially we look at DevOps, um, a lot of this is based around agility, speed, time to market flexibility, infrastructure as code platform engineering now gives you that level of flexibility and speed repeatability, it builds in values around security, uh, around process efficiency. Uh, auditability, you know, I love automation.

It's been a thread throughout my career. And so I, I think this is a logical next step, especially when you think about it as a enabling technology for cloud DevOps and just agility. Agreed.

org folks and stuff is yeah, there's nothing that matter. If you have one little DevOps team and they're building their own platform, the problem you get is exactly, Mike, what you described, but you didn't describe it as a problem. When you have dozens of those little teams and hundreds if not thousands of developers, and they're all building their own platform, what you have is chaos.

And maybe that's next year's thing. Chaos engineering, right? Um, We have that.

It's for testing applications, Right? That's not the chaos engineering you were looking for. And, and so, you know, cloud formm engineering tries to make sense of that, Right?

So are you saying that like Maxwell SMART is the patron saying of platform engineering and you know, 'cause he is gonna battle chaos. Well, he did, he did work for control. Oh, there's a reference and let's lower the cone of silence.

We'll take a break here on, I don't know how many of you get that reference, but we'll take a break here on Textron gang, we'll come back. We've got more for you. Discover Textron Group, the epicenter of tech innovation.

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

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

Hey folks, we're back and we're moving on to our B block, which is a topic we frequently discuss. DevSecOps. There's a new report out from Jfr talking about, well, sadly, we don't seem to be making as much progress as we might have hoped.

And one of the key items in the report is 70% of the folks that they surveyed work for organizations that still allow developers to directly download software packages without any kind of centralized review. And Andy, we've been banging this drum now and telling people to do the right thing here for every day. And yet when I do talk to folks about why they're not doing the right thing, they're like, Hey, it's too many damn false positives still in all these security tools that people put into my pipeline, which is not exactly, uh, robust to begin with.

Just keep breaking everything and everybody starts complaining and says, I'm not doing it. Or I'll do it maybe at the end of my cycle when it's too late to actually do anything meaningful. But Andy, can this get better?

Oh, look, Mike, this has got to get better. How, how long have we been banging on this drum? This is crazy talk that we're still allowing some of these functions.

And you know, this is one of the challenges I get when we start to add on all the work to developers to do all the things right? And let's face it, DevOps was never about developers doing operations. We've had devs and ops collaborating.

DevSecOps is not really about developers doing security. It's about having that at least first level understanding and starting with the basics. But it seems from this research that that's not even happening.

Look, we've gotta get security up early in the process. This is what DevSecOps is about. It's about shifting left with your security practices and processes.

So starting with planning, getting it into the testing phase, you, you're using things like chaos engineering even to make sure that your penetration attacks aren't working on your test environment, that you're doing all the testing and the work upfront. You, you, you are so, right. So many developers and others say, oh, we'll get to security when we, when we need to, uh, because they see security as a roadblock.

And this is a big challenge for the security professionals out there to make security a, a, a launchpad, not a roadblock, right? We, we understand that security is absolutely essential, but what we don't need is for it to be friction. I actually believe that good security, and this applies in DevSecOps absolutely is an accelerant.

You know, good breaks let you go faster 'cause you know you can stop, right? And so I think that we need to dedicate a lot more to this. Leaders like myself, CTOs, CIOs, uh, heads of product need to dedicate a little bit tighter to what is security, what is the policy, what are the tools you're going to use?

And, you know, some of it's gonna be paying for some of the people who don't wanna do it. That's always the case, but it, I don't think we have a choice anymore, can we? The idea that even now, 2025, uh, we are finding through J Fox Research that we we're just not doing the thing.

Oh, save me, Mike, You know, I was talking to Paul Davis as this CISO over at Jfr or the field ciso, and he was putting a lot of the blame for all of this, not on the developers, but on the security professionals. And his point was, look, it's not enough to come up with a list of vulnerabilities and throw them over the wall and hope developers are gonna do the right thing. You gotta like go spend time with them and kind of encourage them and provide the right incentives for them to do the right thing and explain to them that, hey, that app's just gonna get kicked back to you anyway, so you might as well do the right thing now.

But his point was that the CISOs weren't, I guess, exercising enough the leadership. And I don't know, Alan, what's your take on that? Well, First of all, I should mention Paul, I like Paul.

Davids a lot, smart guy. He's gonna be speaking on, uh, one of our panels on the DevSecOps event, AI, cyber, and, uh, app dev at RSA next month. And, uh, so if you're a fan of Paul Davis and Jfr do, do come and you're at RSA, it's Monday all day our event there.

But here, here's the thing, and you guys know this, I've been, I've been a DevSecOps advocate since before when it was rugged DevOps. I think today though, there's a new battlefield in the DevSecOps War. And that battlefield is, is the supply chain security.

And, and you know, and Jfr is a big player in that supply chain. Obviously they control Artifactory one of the largest repos for downloaded codes and and so forth. Um, a lot of what we, a lot of the, the battles, a lot of the, you know, that have been fought over the last couple years have been around SCA software composition analysis because all of these applications are, are Frankenstein's built with a lot of open source components.

And the fact that just that they highlighted in this thing that developers are still able to just go out there and willy-nilly download components or, or container images or, you know, what have you from any artifactory they want, whether it's GitHub or the Docker wants for containers or artifactory or, or any of the, you know, name the contain name, the big, uh, repos out there. Um, and, and you know, consistently they download out of date packages, out of date components that have known vulnerabilities and the repos just let 'em download whatever they want. The, the organizations don't have centralized defense against this or, you know, looking at what's being downloaded until it's too late and this has to stop.

That's, that's where the DevSecOps battle is now. We need SBOs that are updated with, with what these components are and everyone can see. And if it's a a a, a vulnerable one or an out of date one, it needs, you know, the component or artifact or what have you, needs to be flagged, right?

We, we need some discipline here, otherwise we're just, you know, the definition is stupid, is doing the same thing over again and over again. Well, there's actually rational thought in the stupidity it turns out. So you go talk to some of the developers and they're like, well, we download not the latest version of something, but actually something that is maybe two or three revs old.

'cause we perceive that it's stable and we think that that one's gonna work better than the other one. And the fact that the newer one has fewer vulnerabilities there just into their minds. I think that's what the Equifax guy said about Stretch two, the look how that worked out.

So yeah, I don't buy that Mike, I mean, may maybe they tell you that, but I don't buy that. That's like saying, you know what, let me, let me use the defective product because it's a little older. Yeah, gimme the defective one.

I'll take the defective one. At least I know it's defective. I I think they rather the defects, you know, than the defects.

You don't, that that's the logic right there. And, And never occurred. Then there was a defect in the first place.

They were just like, Hey, this one seems to be more stable. That's it. You know what I remember, I, I remember a Sona type report that came out around the Equifax breach, uh, like a full gear after the breach and the spotlight that had shown it sh shined on the strut two vulnerability, the vulnerable version of struts two, something like 37% of strut two downloads was still the vulnerable version, the version that caused it.

Now I'm gonna tell you something, I don't blame developers, right? I Blame The repo, uh, people. The people who run these repos, why can't they have a firewall at something at the repo that says, Hey, Mr.

Developer, you're downloading this. It's been, it has live exploits known vulnerabilities. There's a new version.

When I go to Amazon and look at a product right over at the product always says there's a newer version of this product. Why? Why can't I have that in my repo?

Is that too much to ask? I'm gonna point out that it, you know, there are times when you actually do want to get older versions, especially when you're looking at backup and recovery. You know, you're looking at, you know, potentially, uh, legal action.

You need to reinstall old software to pull that back. Maybe you're doing it within a DMZ, and so you're not, you know, exposing those vulnerabilities. Um, you know, I think there's a lot more we could do with automation.

There's a lot more we could do with AI to understand the impact of vulnerabilities, you know, observability around those vulnerabilities so that developers know what they're getting into. Um, I think the idea of having a package that actually a bright red lights will say, you know, warning, warning, new version available, this version is compromised. Um, I, I would say that isn't that what developers should be doing though?

And isn't that what our security administrators and, and our security programmers should be doing as well? This, look, I keep seeing the reinvention of existing discipline in cloud and DevOps and automation and what are we going, are we going back to the old mainframe days where you'd have to raise a system request to get changes done? Because if you don't, then it doesn't get done right?

You open up vulnerabilities. There's a real cost of business here that I worry about, that when you are working on vulnerabilities, you're not working on new features that are gonna make you money. Um, you're obviously exposing your business to risk, uh, to loss, to damage.

Um, but you're also spreading the load across multiple different platforms and environments that all create this, you know, star Wars effect, uh, death star effect of interconnections. And it's really hard to track. Believe me, my team worked on the log for J thing and all of a sudden my team's not delivering new features, but they are fixing this problem.

Uh, look, I I think you're on the right track, Alan, with automation. I think with ai there's opportunities for developers to not have to worry so much to code in this knowledge about vulnerabilities directly from the security team. Um, but look, we've still got a long way to go and I'm distraught that we continue to talk about this and try to figure out ways to do it.

I'm just trying to figure out what these developers are doing. 'cause you'll see other reports that say, well, they're only spending a quarter of time writing code, then 3% of their time fixing bugs and vulnerabilities. So you know, what's going on with the rest of that block of time that seems to be not allocated to what, you know, manually navigating a DevOps pipeline that they're not actually gonna deploy.

I don't know. Uh, look, as an IT ops professional, I'm, I'm pretty sure that they're, uh, they're compiling and playing foosball, aren't they? I'm, I dunno, I'm, I'm not touching that one.

I'm letting go. I, I don't, I have enough enemies. Um, but good, good.

It is a good survey By, by Jake Farwell. Good stuff there. Good Stuff.

All right, well, I just wanna know how many versions of Log four J do you think were downloaded after the patch was? They're still probably using the bad versions of it. Some folks, it, it, this is, you know, this is this whole s bomb thing.

And like Andy says, look, sometimes you, there's a good reason why you want to use it. To me, it's like you, you know, when you go to a potentially unsafe site in your browser and your browser says, Hey, this is potentially unsafe, you should turn back now. But if you wanna go at your own risk, click here.

I, I'd like to see stuff like that happen. So, so in defense of developers though, and what Jfr did point out was that, hey, most of the so-called CVEs that people are calling severe are not actually severe. And that very few of them are actually in, are severe as people think.

So I think developers have gotten a little, um, they're De Well desensitized. They're desensitized, but nevertheless, you know, there's an argument to be made. And, you know, and this again goes back to the platform engineering thing, that, hey, let let the platform engineers worry about that stuff, whether it's, or let the security people worry about whether that is truly, you know, radioactive or not, and we shouldn't be using it.

All right, I'm, I'm getting a case of DevSecOps. Wi whiplash, man, I, everything shifted left and now it's flipping the other way. It shift everywhere, my friend.

Alright, this shift everywhere we are, we're gonna take a break. Let's come back for that third, uh, topic for today. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

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

com. Home of security bloggers network. Hey folks, we're back.

And we're talking about Q Con again in the sense of there's, uh, a shadow over the show and the shadow is VMware and this whole licensing thing. 'cause just about every vendor as you go into their area or booth is talking about, you know, their great thing and then they'll go and, Hey, did you know that you can use this instead of VMware because of what VMware just did with, and Broadcom did with changing the licensing agreements. The latest is Platform nine, which has a community edition of their platform for managing virtual machines.

It happens to be built on Kubernetes, but otherwise it does everything else that VMware does, or so they claim using a SaaS platform. Alan, I swear I've had this pitch tossed at me and I know you have had it as well at least two dozen times in the last three months. Yeah.

Does this, does this dog really hunt? Yeah, so interesting. So I don't think it's a shadow, I think it's a gold rush, right?

Every event is trying to, you know, cash in on the, the, the, uh, VMware immigration that's with an E, right? They're immigrating away from VMware, they think, and I've seen some interesting numbers on this, right? Because let, let's figure out what we've got here.

So under the Broadcom licensing changes to beat VMware, I've seen estimates that, you know, you are looking at perhaps a three x increase in your VMware licensing, which sounds three x is three x 300%, right? That's crazy. Um, however, what I've seen or what I've heard from folks is that a lot of the companies that are migrating off of VMware specifically, uh, price, price is, but one of several factors, right?

Other factors being, hey, I read VMware when I, you know, I, I wasn't on a cloud, I was kind of just in my own data center, but I've always, you know, we talked about going to the cloud. Now's a good a time as any, and so we're migrating to one of the big hyperscaler clouds, and I don't need VI don't need, I can run VMware on that certainly, but I don't need to. They have alternatives that are cheaper, better, more, you know, more to that public cloud.

Um, other, other folks are saying, Hey, you know, this is a great opportunity, me opportunity for me to rethink app modernization. So not just whether I'm gonna run it on a hypervisor or what hypervisor, but should I move to a microservices architecture and, you know, containerized and, and you know, Kubernetes and all that entails. And, you know, so you have this, this confluence here of, of these factors that are playing out and every vendor is lining up to sell the picks and shovels, right?

Because those are the people who make money in gold rushes. I think some of it too is they realize that locking is a real thing and that somebody can turn around and increase your licensing fees in ways you can control. So a lot of them are looking at open source platforms and Kubernetes and other things that they perceive give them more control as a buyer.

Yeah, I mean, I'll tell you what, I'm, I'm gonna throw a spanner in this wrench though. And yeah, I, I agree it's a gold rush and the pick and shovel vendors will win. Uh, but I think that a part of this has been the, uh, uh, a lot of leaders in it are being disappointed by the promises of cloud.

And maybe they misunderstood the promises of cloud, right? I mean, we, we always talked about how it was not necessarily about saving money, it was about agility, flexibility tied to market, these sorts of things, but disappointed by the promise of cloud, A lot of people are moving back to private cloud. We're seeing a lot of chatter about it.

This is not a mega movement, but it absolutely is. With the licensing changes of VMware, uh, under Broadcom now, it gives people extra incentive to review that cloud spend, to have a look at that cloud efficiency. Have a look at that productivity and delivery pace that they're getting, or maybe not getting from cloud computing.

And especially for larger enterprises, they've already got a lot of infrastructure and they can go back to that. Look, there's a, there's, there's an argument that you could rewrite all of the social security administration's COBOL in ra, but there's also an argument that it works. So why break it?

And so I think as we move forward in this, in this, you know, this discussion, being able to do this is not easy. And look, I'm a big fan of private cloud, you know, I read my book, but everything hold is new again. And it'll be interesting to see how we innovate some of the leadership and management structures back to a more pragmatic hybrid model.

To your point, Andy, once you start thinking about one thing, then everything's on the table and you're gonna evaluate everything. I don't think, Um, There's a wholesale rush back to on premise, but I think people are looking at certain workloads where the cost of running that in the cloud is higher than on-premise. And that's an opportunity for repatriation.

So maybe there's something larger at work here where it is just this entire reassessment of what software should run where based on its attributes and cost. I, I don't disagree. Um, you know, we, let me just, I have one thing I want to add in here.

My experience is everybody always says, oh, it's not about the money. It's not about the money. It's not about the money while they're reaching their hands in their pockets and holding those dollars really tight or pounds or whatever we've got here in London now, right?

While they're holding that really tight, it's not about the money. Of course, I'd spend a little extra money if it was a great product and it did the right things I want to do, and it checked all my other boxes. You know, Ken, my money's not the most important thing.

Bull crap. Money's always important. And so I, I think at the end of the day, we could talk and, and wax poetically here as long as we want to, A three x increase in licensing costs is still a three x increase in licensing costs.

And I'll tell you, one of the drivers I suspect is very much a AI and compute costs for AI in the cloud and the ROI that people are or are not seeing from cloud-based AI experiments and looking at that compute cost and thinking, you know what? I got some spare servers. Let me throw some Nutanix on it.

Uh, let you and see how I go. Agreed. Agreed.

Anyway, it, it's going to be interesting. And this isn't just a cube con particular thing or even cloud native though. Cloud native is definitely a factor in it.

You know, I, I you said Mike, over the last three, four months, this thing has come up over and over and over and over again. I, I think what you said an interesting conflicts, conflicts of, of factors that have a lot of companies saying, is this the time to change, right? I mean, Yeah, it won't happen on the flip of a switch, but I think a lot of people feel burned and they're, they're looking at their options.

Look, VMware when you look, if, if in 1998 I would've told you that hey, most, most people's infrastructure is gonna be run on a hypervisor. Here, here are the, here are the hypervisor candidates, and there were, you know, a half a dozen of them. Uh, I don't know if you would've picked VMware as the dominant one back then, but it, it certainly gobbled, you know, gobbled up just as Kubernetes became the orchestrator of choice.

There were plenty of options for container orchestration. So, you know, these things don't unravel in a day either, but the market moves on And bringing it full circle. All those VMware administrators got a certification so they could get more money rather than being just your classic IT admin.

I wonder if that whole thing is gonna play out again soon with platform, No platform engineers. There you go. Um, alright.

Hey guys, I think that's gonna wrap up our coverage for today, Wednesday, we, uh, I think we're going to try to do something on the show floor at CubeCon tomorrow, Mike, right? That's the plan. We are set up there.

We'll, we'll bring it to you in the meantime, cheers from Mary Old England, Cheerio, all that stuff. Andy, I hope someone out there watching this realizes wow, man's available. I need to talk to him.

Check him out on LinkedIn. Mike, I'll see you hopefully in a little bit here in, uh, for dinner or something. Something.

Alright, until next time, this Alan Shimmel for Textron Gang. We're out.