Techstrong Gang – April 7, 2025

Hey everybody. Welcome to a special wrap up edition of the Textron Gang from the CubeCon Show in London. We're gonna just talk about some of the high points that we didn't get to last week and maybe add a little retrospective insight.

We'll be back in a minute. Hello everybody. I'm Mike Ard, and as I said earlier, we're still in London, at least we were last week when we recorded this.

com and all your favorite websites out there, guy. We've been here, or were here for three days in total. Yeah.

Um, looking back, what leap out at you? What's the thing that you're gonna go home and take away and remember? 'cause you know, there was a thousand things over the last three days.

Well, there's a bunch of things, Mike. Uh, I mean, I, I would say one highlight to me was the welcome edition of, uh, some, uh, or expansion anyway, of some virtualization names here. Um, that was nice to say.

I've been saying for years that, uh, uh, we can all get along virtualization and containers, uh, coexist should coexist, should not be put against each other. So, uh, Nutanix is here in effect. Now, granted, Nutanix bought D two IQ last year, and, uh, they've now renamed it What, uh, nk, they've gone through a few Renamings, nk e no, NKP, Nutanix Kubernetes platform.

Um, so that's a big reason for them to be here. But they're also here with their standard virtualization storage, virtualization story. Um, and then, uh, platform nine too, which I think, uh, you guys mentioned, um, on the show last week.

Um, they are not strictly a virtualization shop, but it's a private cloud shop. We're talking about resource, you know, resource sharing and pooling and utilization, uh, across networks, storage, and of course compute. Um, so that's, that's an interesting thing to see at a CubeCon To that.

And of course, you know, we see VMware is here. Oh yeah. So let's not forget VMware.

And, and the truth of the matter is, is they've Been here for a while. Yeah. The bulk of Kubernetes installs are running on virtual machines for the isolation.

Right? I mean, we've been talking about Kubernetes on bare metal forever, but, you know, most people still don't do that. And the primary reason is that they wanna be able to isolate those workloads and have some separation in case there's a breach.

Um, so when I look at this, I, I always, you know, it is been one of those things I scratch my head about. 'cause VMware is typically managed by IT administrators, and then you have Kubernetes managed by usually a DevOps software engineering team. And we've been talking about the collaboration of those two teams getting closer.

And I wonder though, in real life, it seems like maybe they already are, they just have pretty clear separations between who's managing the underlying VM and then who's managing the clusters for Kubernetes above. I don't know. I, so, so I think in real life actually, there's been a fair amount of separation.

Um, I mean, you know, what, what, what did I say last week? What is a platform engineer? A platform engineer is a coder, um, you know, uh, but is a platform, I mean, I was being a little provocative, I suppose a platform engineer is managing essentially a stack that provides services, um, to applications.

And, uh, it's important to know and be able to run and operate, whatever that stack is. Does that stack include a virtualization layer? Maybe, maybe not.

Um, I don't think though that, that there has been enough sort of, let's say, maturity, um, in, uh, the containers side of things. I mean, it's been growing and, and, and building and maturing rapidly. But one of the things I think we're seeing here is, uh, uh, a little bit more of emerging, a little bit more collaboration.

I, I guess what I'm trying to say is, no, I think it's largely been separate because of the strong association of, of containers, despite their capabilities, the strong association with cloud native, the strong association with, with DevOps and, uh, applications are not being recoded and refactored at a great case out of the older, more traditional models into that model. It's really new applications, which has allowed organizations to build new environments and run them, or let's say new estates and run them separately. I, I, I don't think so, Mike.

Not from what I've seen. Well, that's always been the big question, right? To what degree do I refactor an application to make it run on Kubernetes?

Or do I just kinda only use it for greenfield applications and go from there? Some folks have encapsulated, you know, massive applications and they just call 'em a big ass microservice. Yeah.

But so that's the whole point. That's the whole point. I was just talking to, uh, one of the vendors here about this.

Uh, you know, in, in originally we had what, we had infrastructure os, hypervisor OS app, right? It wasn't long before we were able to get rid of or just, just use the kernel and have bare metal hypervisor on the server. Right?

Now we add containerization. Where does that go? That goes, what you can do, like you were saying, bare metal hypervisor with, uh, os, container os you can even in some ways remove the os.

You can also, like, there's a lot of different stats that you can have to abstract the, the, the pools of re to pool and abstract the resources that are, you know, essentially hardware underneath. Um, don't we wanna be able to adapt those to the particular need in application, adapt that stack in order to really do that in a, in a, you know, a resource optimizing way, in an efficient way that also delivers whatever performance or availability or regional, uh, uh, you know, um, region geography you need, um, uh, you really need to comprehend the whole thing. And we, and I think the presence of Nutanix, the old presence of VMware, these other vendors, is really indicative of how, uh, uh, containerization and cloud native is moving deeper into the enterprise and being encompassed in an entire plan a lot better.

Alright. And, and just to add one more wrinkle to that, you can also use something, there's a project over here called Qver that started with Red Hat. And you can use that to take the VM and run that in a container.

Oh, yeah. Top of Kubernetes. Yes.

Yeah. No, that's, that's been going on for a while. So, okay.

So here's the thing. Which, which of it is sparkly bits that make things look sexy and interesting? Like, I would say, pardon me for everybody doing it, but bare, bare middle Kubernetes.

Okay. Versus what you were, what you were really alluding to, which is the reality of having to actually deliver applications not at perfect performance levels and all that stuff, but balancing like every enterprise needs to do, how much investment you're putting into it versus how much you're getting out of it. I'm gonna shift the gear a little bit.

There were a couple of, um, new emerging technologies that I saw that kind of leapt out at me. io. It's really a, uh, open source framework for letting AI agents communicate over this MCP protocol that the AI community is adopting.

I think, uh, MCP was originally developed at philanthropic, um, and it provides the framework that for all the communications, it's essentially the interoperability and networking between the AI agents that'll run over, um, service meshes and Kubernetes. 'cause most of these AI apps are being built on this cloud native framework. As we kinda get into that whole space.

Do you think networking in the age of AI is gonna be fundamentally different because we're gonna have all these AI agents and the level of scale required? The protocols seem like they're gonna be different. They may sit on top of our foundations, but there seems to be a new layer of abstraction between the AI agents that's emerging.

So networking is funda. It's, it's really diff fundamentally different. It's going to be fundamentally different all the way down to the, the hardware.

Um, it, they're starting to talk about. So you've heard of the smart nick, right? Sure.

The smart Network interface card, um, there's a subcategory of that, uh, called the AI nick. Um, there's two planes really to, uh, the, the impact are two planes of networking that are involved here. One is ingest and one is out, you know, service, right?

Ingest is really important. The, whether it's prompt data or, uh, um, uh, collection of data for training or any of that other sort of thing, the, the demand level is really high. And then on the back plane for training as well as for inference, the speed of communication and the quality of that communication from GPU to GPU or from cluster to cluster is really important, right?

These have markedly different profiles in terms of, um, how the packets are, um, uh, put together, uh, what kind of security or encryption is required. Um, and also the usage, let's say the usage levels, and, uh, uh, uh, you know, how those change over time. Um, obviously when you're training, you have a whole lot of bandwidth going on in the back plane.

And then in the front end, um, for usage and inference, that's where there's this huge ver one of the really interesting things that I saw here, another really interesting that I saw here, um, was a discussion by Google and by dance at one of the keynotes about how supporting, um, AI inference is an extremely complex thing from the standpoint of container orchestration and infrastructure orchestration that applies as much, if not more to the network. Because the degree to which, like the volume of different types of models and their usage and what they're being, what purpose they're being put to, uh, changes the profile of processing to a great deal. It also changes the profile of network usage.

And I'll just say one last thing about this. Why is this so important, and why is it so deep? A whole lot of stresses being put on the CPU.

Now, if you talk to the armed folks, they'll tell you, Hey, the CPU can do it all, and maybe with certain risk architectures, that's true. Um, but what we're seeing is this diversity of chips, diversity of processor units. It's not just neural processors, it's asics, it's, you know, uh, field programmable gator arrays.

It's the rise of the GPU, different types and styles of GPUs, different data types being used by GPUs. But one thing that the CPU has still had to do is traffic management, head node, all that other sort of thing. And that means network management.

And so another specialty processing unit is the data processing unit, or the network processing unit that pulls some of that duty away. So really, the attention on the network has always been pretty good. It needs to sort of be modified and go up in the age of AI for all those reasons.

I think what you're talking about also plays to this platform engineering conversation that's going on. Because when I look at that, I say, all right, great right workload for the right chip, but there's no magic compiler that manages all of that. So you have to know a lot about these different processors if I'm building software.

And that requires more of a team of people to go manage that. And I think that's part of this effort to centralize some of the services, because not only do I wanna make the developers more productive, but asking them to figure out, you know, what workload to run where optimally is, is it's a bridge too far. So I think we need some expertise in here that's Oh, yeah.

Step up in the middle of that and be the, you know, the, the infrastructure layer managers that say, all right, you built that. We'll figure out where best to run it. This is so funny 'cause you're taking me back to our E week and CIO inside days.

Um, when, uh, when, um, the, the, the mainstream chip vendors led by Intel, of course, were introducing multithreading. And, uh, we started to, we started to write about, talk about, and write about the fact that you had to understand, um, and program to the, you know, all the way down to the metal was how you put it. Um, because, you know, now you are, it's, it's not just in the compiler either, right?

I mean, you want the tool set that enables, um, you know, the outcomes that you're looking for as a, as as a developer. But by the same token, if you don't know what's possible in the platform, you can't really at least architect that application the right way, let alone code for it. AI or no ai.

Mm-hmm. And I'll turn to another favorite subject 'cause I, since I mentioned platform engineering in there here, but Spotify is here, and they built Backstage. Backstage is an open source internal developer platform.

Very popular among a lot of folks, but, um, they are now offering a SaaS version of this thing that they will host for you and run for you. And they had an interesting, uh, keynote presentation when they were talking about, uh, what a difference it is to build something for yourself versus now trying to build and maintain and update something for a community. Yeah.

And they had to change the whole back end, and now they're changing the front end. And all these factors changed the way that they think about it. I, there's only a handful of end user companies that I've seen that have ever built an open source project that gained any traction and handed it off.

And who knows, maybe they'll spin out backstage as an independent company one day, but what, you know, there are end users here and we talk about making contributions to the open source community, but it's not easy. So I'm so glad you're mentioning this. Yeah.

So, so I just said a moment ago, um, this, the, the, this, I, I really think this has changed just in the last six months that you're seeing a lot more focus on, on, uh, the enterprise open source for the, I mean, it's been a largely a domain. Um, not largely that's unfair, but, uh, the public sector in terms of, um, uh, and, and, and the organizations in terms of contributions to and uh, uh, uh, co-development in all the projects around, you know, open source generally, you know, uh, uh, uh, Linux Foundation and, and, and, you know, um, cloud native computing foundation particularly. Okay.

So, so all this activity, it's security related developments. It's, you know, large landscape, like multi cluster management, like that sort of thing. These are rising in interest in this community as what I referred to, I think yesterday as sort of the invasion of, of uh, uh, of the enterprise by cloud native is occurring.

And this merger, we, we were just talking about in the context of virtualization. But here's the problem, Mike, this is what I wonder. It's like, public institutions tend to have this sort of democratic flavor to them.

And people can work on open source, have their entire job be working, contributing to open source in an environment like that. It's democratic, it's collaborative. It can take a really long time to build up once it's built up.

It's an unstoppable force. Enterprise has a long and storied history now within open source of stealing for, I'm sorry, uh, utilizing open source without necessarily contributing to it. I, I worry that the two do not mix very well.

That engagement by the enterprise in order to help, uh, their adoption of cloud native is gonna be largely on the taking side and not as much on the giving side. Because at the end of the day there, there's not gonna be so many Xerox parks out there that are just doing things anymore. Mm-hmm.

And especially as the economic climate shifts, as it seems to be real time right now, um, that could be a really difficult relationship to maintain. Yeah, I was talking to some of the maintainers about that. And as much as they would love to have some additional contributions on the code side, you know, what they really want, they wanted feedback from the enterprises about how this thing is actually running in a production environment.

So they could use that to drive the next iteration of the thing. And apparently they're just struggling with it. A lot of the enterprises, they're using stuff, but they're not talking much about it and not even participating all that much inside of those communities.

And what they're desperate for is the feedback. That's a perfect example of it. That's a contribution to the community that would help, you know, who would help, it would help those enterprises competitors.

Well, and there's a, there's a culture against that in general, in a capitalistic enterprise. That's the nature of the beast. There are A lot of forks of different open source projects.

'cause somebody in that enterprise decided to add something or tweak something that they didn't contribute back to the community. So there's a lot of iterations of different things. I also think though, that there is this notion of there are certain things that are not, uh, trade secrets and you can share with the community.

You just gotta be smart about it. And, but I, I do believe that Coke and Pepsi can sit in the same room and have a conversation about Kubernetes. That would be helpful to both.

Yeah. It does not sound like something that, uh, you know, uh, the Federal Trade Commission would worry about. Right, Exactly.

If they were to collaborate on, uh, soda formulas, that might be a different man. Yeah. There might be some lawyers screaming his head off about this, but, you know, probably it would be just tell 'em to chill out.

It'll be okay. Don't You think that, that the way, uh, tech has developed, especially in the last five years, has ra and, and not just 'cause of AI has raised this sort of consciousness of the importance of tech among, you know, business management among enterprise management. And don't you think therefore they're gonna worry more about people sharing Kubernetes ideas than they would've in the past?

It is true. The business execs, That's wild to think about. But it, It cuts both ways, right?

So business execs are definitely more tech savvy than they were five, six years ago. Um, but as a result of that, they are conscious of the, well, what are we sharing? But at the same time, they also understand better what is differentiated value and what isn't when it comes to tech.

So, you know, they can have that conversation up front that says, yes, you can talk about this, this, and this, but not that, right? That I, that I did. I don't like that.

I don't like that. Let let your r and d folks, r and d, it's really part of r and d, it's part of r and d and you invest in r and d and you and people who are working in r and d, including the syrup formula for chemists or whatever, at Coke and Pepsi are going to conferences themselves and meeting other people and sharing, you know, uh, food chemistry Knowledge. I will give you a theoretical example.

If I'm a financial services firm and somehow or other I figured out how to make Kubernetes run a little bit faster, I might not share that because that's a competitive edge. You would definitely would not share that, but that's precisely what I'm talking about. So what, let, let me shift the conversation just a little bit here.

So that, that is one trend, um, that, that I feel I'm seeing in comparing Q con to Q con is, um, more, uh, more project focus on, uh, areas of interest to the enterprise and more of this enterprise slant, um, to, you know, the development of cloud native and enterprise adoption cloud native. Great. The other one though, and this could just be me and that's why I wanted to ask you, the other trend I'm seeing is, um, chaos.

Did we use that word yesterday? Chaos. I think what something at some point we talked about get smart.

So Yeah, I was, Yeah, there's, there's, there's this chaotic feeling to the, I I, I feel like there's a, there's something a little bit overwhelming and I'm concerned that it's overwhelming to the market, to architects, to adopters to users about how cloud native has developed. I, I think I felt it most with the addition of open infra into Linux Foundation, which is a great development, terrific development. At that point, I was kinda like, oh my God, what's going on here?

Have you, you, you just not, have you felt the same thing? There is, there's definitely a lot of chaos and uh, and you know, there's a lot of do it yourself kind of feel the stitch all this stuff together And so many things to do it yourself with. It's coming at you from every direction.

There are people talking about platforms more. VMware is certainly down that path. Uh, Heroku's here talking about PAs and Cloud Foundry is, is sitting in the back end of this thing waiting for everybody who's embracing platform engineering to figure out that a PAs does 80% of what they wanna do.

So, you know, what's old is might be new again soon. Yeah. Who was it?

It was, it was, uh, it was, um, Cisco on stage yesterday who was saying that one of the learnings from this whole endeavor of cloud native is don't build solutions, build platforms that a lot of things can plug into and, and, and interoperate. But she immediately said after that, the problem is that there is so much to choose from them. There's so many choices to make, right?

And, and not only do you have to make that choice, but then you gotta sell everybody else in your organization on your choice. And for IT people, they're not necessarily built to go and sell something. You mean you hear it all the time.

You know, go manage your platform like a product. Well, these aren't product managers by any straps. They're, you know, it people.

And then they're gonna go into a room and kind of try to convince a bunch of people that says, yeah, use my platform. 'cause they can't order people to do something. They gotta kind of convince them to do that.

But that takes a lot of effort. And so these platforms, you know, they're going in and one at a time and a different use case. And they're kind of hoping that by word of mouth, everybody will come around in their way of thinking.

Yeah. And then if they don't, that project does heads towards, you know, uh, uh, sunset or what, what, what's it called? Like decommissioning or something like that.

And they've invested in something that's not quite going there. What do they do with it then? I mean, I think that's called Darwinism at work.

It is Darwinism at work, but it's also DIY at work. It's also assemble yourself. So, so you know, there are these two, uh, kind of competing approaches to stacks.

Let's just say, let's get really parochial stacks trying to run an application has to run on a stack. One is the best of breed approach. This exemplifies the best of breed approach.

I'm not just gonna, and best of breed doesn't mean, you know, somebody's put it on a listing or in a quadrant or whatever. And it's number one, it means for my set of requirements and for my purposes and for the needs of the application, this is the best whatever it is. The other is the single source approach.

The single source approach takes all that complexity and gives it to a solution provider. And the solution provider offers you the application or maybe some maybe the platform or some layer within the, within the stack essentially as a service managed, you know, and, uh, don't worry about what's happening underneath. Um, that appeals to a lot of, you know, enterprises because of how they operate.

Well, Let's remember how we got to where we are, right? A lot of the teams that wound up building all these platforms embrace DevOps because they wanted to get out from under the thumb of centralized it. And so what they don't wanna see happen is, uh, somebody showing up, you know, waving a platform engineering flag to go back to the battle days of CIO totalitarianism.

And so they gotta figure out a way to reduce the number of platforms. So the cognitive load isn't so high. Yeah.

But we still have to, you know, have our cake and eat it too. And the developers are gonna wanna see some flexibility so that when they decide that they wanna use some new tool to go experiment with something, there isn't some IT guy telling them no. You remember when the cloud architect came into existence more or less.

Mm-hmm. It became, so that was a little bit pre hybrid. We almost sort of the cusp of hybrid and pre multi-cloud.

Um, the purpose of the cloud architect became a policy setting function. Um, you know, here are the 12 VMs you're allowed to use in this cloud. You're not allowed to use that cloud.

Like that sort of thing. Right. I wonder if if there's that, or maybe there is already.

You tell me. I wonder if that's in a sense where platform engineering is going as well. Yeah, it's, it's got its roots in that for sure.

I just think cloud architects drew a lot of diagrams, but nobody implemented them. So that was kind of where the, Well, the platform engineers won't allow that because there's only gonna be one place you get to run your sandbox and, uh, everything rolls out from there. So, so I, I think we're trying to strike a happy medium.

Um, it is a negotiation for sure. And it's not something that is a flick of the switch kind of thing. But I will tell you something that I was impressed by here.

And I, as I listened to almost every keynote had the same kind of, And then I'll give you one thing, I'm impre I was impressed by Yeah. One little vibe that was apparent. Almost every keynote that got up and said the same thing they said they were hiring.

And in this current economic climate, that was an interesting trend. And I'm starting to wonder if cloud native may be countercyclical borderline recession proof, because the, so the software development is becoming more strategic to all these companies. And maybe, you know, if you are looking for work, maybe you should get those cloud native skills.

'cause almost every company here looks like me. Like they're trying to hire some folks now. You know?

But you gotta have the right skills. That is, uh, I did not notice that. That's, that's encouraging.

That's encouraging. I'll, I'll give you something that, uh, perversely encouraged me that I noticed is not a lot of system integrators here. At least not in effect.

We know that it's been, it's given up the enterprise ghosts, let's say, when we start to see, uh, these, the, especially the globals here, the big ones. 'cause that's where all of this intellectual property, this, you know, quasi-public domain, intellectual property that everybody gets to contribute to and use, starts to really get pulled away and walled off. And yeah.

So I'll make a couple of predictions for next year things we will see. One is more of those sis. We'll also see more managed services around platform engineering where someone will say, you know, I'll manage that on, on behalf of you and your, and we will let your developers kind of build out.

You've already seen, you know, most of the consumption of cloud services in the enterprise is through some sort of managed service. I think it's just a matter of time before they start adding a couple of more layers, CICD, uh, IDPs, and they'll call that a managed platform service. Yeah.

And a lot of people will start to invoke that. And then I think this time next year, um, we'll all be talking about how to manage all those AI agents that are now part of the DevOps workflow as I go build all these cloud native applications. 'cause, and, and I can't tell you right now, are those AI agents, are those just another type of employee or is that just something that I'm managing and supervising?

Who knows? I, I, I agree with you. Those will be big tops of conversation here.

I can't make predictions like you can, so I won't. Um, I do think that, uh, the, the, what I'm calling the chaos, um, maybe that's the wrong term for it, but, uh, this, um, just, uh, let's say, you know, uh, increasing kaleidoscope of options and, uh, methods and everything, I think it will, um, grow. I think it'll grow be, I think it's gonna get more evident before, uh, any of it, you know, starts to sort of percolate and organize projects don't shut down particularly often.

And that means that there are a lot of, and that's, in a lot of ways that's a good thing. Have a lot of different options for doing some stuff that's similar or that's the same. But at some point it does need to start to normalize.

Projects do die though. They kind of, it's a slow death. And one of the things you have seen folks starting to really do is, um, they're measuring like, what is the active level of contribution into a given project before they bring it into the enterprise?

Because they're using that as a health metric to say, you know, is this thing active? Because if it isn't, I don't wanna, you know, be dependent upon something that is either A, gonna fade away, or b some vendor's gonna, you know, announce tomorrow that they got a whole different licensing approach for it. 'cause their investment in that strategy wasn't panning out for 'em.

But now I'm tied up in this, you know, uh, shall we say more restrictive licensing option that they're providing me. And then, you know, the response to the community is, well, we'll just build more forks and, and then all hell breaks this. Yeah.

Yeah. There's, there's gotta be a solution for that at, at, at some point. Um, what, what happens in private enterprise is, um, usually by contract there is some sort of migration or transition strategy.

I don't think that really exists in this community yet, but maybe there's, maybe it's time for it. Right? And there are vendors who, you know, shields you from all of that.

So whether it's a distribution of Kubernetes that comes from a vendor or, um, any number of, uh, yeah. Uh, platform providers, whether it's or somebody else, they vet all that stuff before it comes to you. And if it goes south, you know, it becomes their problem.

So one way to, it's like an insurance, and one way is to isolate yourself is, you know, that's primarily Red Hot's mission when you think about it, is to provide the enterprise with some level of, yeah, isolation from the chaos. That's the right model, right? No one's saying that nobody should make money off of this.

The, the, the greater, you know, choice an enterprise has or an organization has as to whether go full DIY or go full solution should depend on their goals, their business model, their culture, and their style, not on what's available. And I will say this, this is maybe my reason for apologizing a little, for using the word chaos. Um, what do you do in the face of chaos?

Uh, you, you know, you try not to get fomo. You not try, try not to worry about what you're not seeing, and you just pick what you're seeing and go with it and make sure you're understanding and measuring the results. And that's true of those different approaches as well.

So, um, at least you have those choices, at least this proliferation of projects. And, and, and a lot of it is really necessary. Multi cluster management, infrastructure, provisioning, um, secrets, uh, secrets management.

These are all areas that, that need a lot of development, uh, in, in, in cloud native, in an open source. All right. I'll give you, I'll let you have the last word, my friend.

The last word is, let's keep going, keep going. Strong. Text strong.

No, let's keep going strong. Um, let's make sure to breathe and have perspective and stay out of religious wars, tech, tech-wise, um, so that we can feel like we're making progress and we have opportunities. And as long as we are understanding what outcomes we're getting, we can deal with all of the, whether it's chaos or the invasions or any of those other alarmist terms that I've used.

All right. I'm gonna quote Michael Jordan, the shot never taken is always missed. Right?

So cloud native. Exactly. Take the shot.

'cause the, the opportunity and the upside is far greater than any potential nuances or inconveniences you might incur along the way. Yeah. And, and, and as usual, he said, I would've the last word, and then he took the last word, I guess.

Well, you know, uh, you had the next to last word. Okay. I'm happy with that.

All right. Hey folks, thanks for watching Thelen episode of the Text on Gang. You can find this episode another on our website.

We invite you to go look for all those past episodes as well as stay tuned for the next round of the shows that are coming up right behind us because well, it's tech, it never ends changing all the time. Yep. That may be chaos on one level.

I call it fun. We'll see you next time.