#141 Helm 4 - Plugins, OCI and Why Nothing Broke

Andrew "Andy" Block writes books and reviews pull requests at thirty thousand feet over the Pacific, because as he says, he can sleep when he's dead. Between Red Hat's services organization and four talks at KubeCon Amsterdam, he sat down with Ronald Kers and Jan Stomphorst to talk about the first major Helm release in almost five years.

Helm 4 is a story about restraint. Helm has become load bearing for an enormous number of enterprises, and a strict versioning policy left technical debt with nowhere to go. Helm 4 clears that debt without breaking anyone. Replace the binary, keep your charts, notice almost nothing. After what the Tiller removal in Helm 3 cost teams like Jan's, that is the achievement.

Underneath sits more than the version number suggests: a Wasm based plugin model that finally makes Helm properly extensible, a serious API and logging cleanup, and better status handling built on libraries contributed out of the Flux community. Charts v3 comes next, letting you swap Go templating for Jinja or Rust, and opening the door to downloader and signer plugins.

That plugin model matters most for signing. Andy asked a room of roughly three hundred people how many sign their Helm charts. Three hands went up. GPG is painful enough that even a security specialist avoids it, so Sigstore behind a plugin becomes the realistic path to provenance. On the OCI side, per repository credentials and transparent mirroring mean organizations can stop forking charts just to repoint them internally.

The conversation widens from there: why Kustomize and Helm complement rather than compete, why European organizations are moving back on prem, and whether AI now produces code faster than any maintainer can honestly review it.

Andy's crystal ball isn't about features at all. It's about approachability, and lowering the barrier for the newcomers who made up well over half the room at KubeCon.

Dutch Cloud Native Day 2026

Two days of cloud native talks, workshops and community in Utrecht, exploring how AI is changing the way we build, run and scale modern platforms.

Like and subscribe! It helps out a lot.

You can also find us on:
De Nederlandse Kubernetes Podcast - YouTube
Nederlandse Kubernetes Podcast (@k8spodcast.nl) | TikTok
De Nederlandse Kubernetes Podcast

Where can you meet us:
Events

This Podcast is powered by:
ACC ICT - IT-Continuïteit voor Bedrijfskritische Applicaties | ACC ICT

Transcript

Speaker 1 0:38

Welkom bij een nieuwe aflevering van de Nederlandse Kubernetes Podcast.

Speaker 1:01 Speaker 1 1:05

Andrew, can you please introduce yourself to our listeners?

Speaker 3 1:22

Absolutely. Hey everyone, my name is Andy Blok. I'm a distinguished architect at Red Hat. I work in our services organization, so I'm on the road constantly. We were talking in the pre-show just about my travels. And part of the reason that I love working in the community is because I get a chance to see and work with different communities around the world. So seeing everything from North America here in Europe and over into APAC, everyone wants to learn how to get more involved in open source and being able to get out there in the community is some of the things I'd love to do, in addition to, you know, my daily my day job.

Speaker 1 1:51

And what got what got you started in the IT? What's your debate?

Speaker 3 1:54

Honestly, just out of university. I've always had kind of uh an affinity to just tech, etc. I had a great programming teacher back in high school, pre-university days, who really got me involved and really excited in technology. And it was really him that got me just in ingrained to not only software development, but also just learning about kind of how these systems work together and I guess eventually help others in the community.

Speaker 1 2:18

Okay. But even before university, were you a little kid? You want to say, I want to be a software developer?

Speaker 3 2:22

I wouldn't say software developer, just computers just got me interested.

Speaker 1 2:25

That's right. Yeah.

Speaker 3 2:26

Computers are fun. They are fun. Until they're not.

Speaker 1 2:31

We've all experienced in that. Yes, we have. So you have a talk here about Helm 4. Can you tell our listeners what the talk is about?

Speaker 3 2:41

Yeah, uh Helm, uh, for those of you who do not are not aware of Helm, is a package manager for Kubernetes. It basically is the de facto package manager for Kubernetes.

Speaker 2:48

Yeah, it's getting more and more.

Speaker 3 2:50

It's it's interesting because I've been with the project for about four years now, and I got in at a time that was kind of in a lull from the community perspective. The cloud native community ebbs and flows in terms of the projects. Projects get a lot of interest in projects, dies, interest dies, etc. And when I got into the project, it was kind of in the down, I kind of wouldn't say downward phase, but it was definitely in an area that definitely could use a little bit more. So a lot how I got involved was around a feature of Helm called OCI. It's a store Helm charts in a location other than traditional Helm repositories. So you can store them in container registries. And it was an experimental phase for about a year and a half, two years, and it just needed that little extra home oomph to get over the over the line. Yeah. And I was basically helping the community and helping the Helm community basically get it over the line. I have a lot of experience working in the OCI space around because I do a lot of work around security and just container technologies because of my background at Red Hat. Red Hat is a large contributor of a lot of the container tools that are in the community, like Podman, it's a CNCF sandbox project. I I've had a lot of interest in a lot of working with our teams at Red Hat, and I wanted to see if we can enable new opportunities with Helm, because I've been using Helm as an end user for a while. So that's how I got into the community. And actually, as a result, I actually got involved in the now maintained three additional communities on top of that. All very similar around the container space, but also the security space. So they're all kind of related.

Speaker 1 4:15

Okay. And all that doing all the flights and trying to get all that.

Speaker 3 4:18

Now people ask me, Andy, what do you do on those long flights? Because I fly long places. We're not talking like 20 kilometers down the road. We're talking like 20,000 kilometers down the road. I write books and I work on software and build communities from 30,000 feet over the Pacific. You've got a lot of time for that, Tony. That is true. You get a chance to people say, Do you sleep on planes? Do you watch movies? Like, no, I just end up putting the map, the little map that moves, tell you where your plane is, and I go ahead and just jump online and work with the community and just try to get innovation moving. Because you have time, I can sleep when I'm dead, honestly. I I'd rather go ahead and make progress.

Speaker 1 4:57

Yeah, right.

Speaker 4:58

Yeah, but that's that's awesome because uh nowadays you have uh Wi-Fi or internet in the planes, and then you can do something.

Speaker 3 5:05

Is it gonna be the best Wi-Fi? No, but many cases you just need enough to for your Slack channel. A Slack channel or pushing a commit or two.

Speaker 5:13

That's it. Yeah, but in the in the past we had to watch movies or sleep or it's all we had.

Speaker 3 5:18

I mean now those screens screens went down. And nowadays we have our own little personal stuff. We have power, it's nicer than some apartments in some in some cities.

Speaker 2 5:27

Right.

Speaker 5:28

So, yeah, Helm is a packaging tool. Yep. De facto packaging tool. Are there any competitors?

Speaker 3 5:35

So there have been some competitors that have been out there that have come, and we talked about the ebb and flow. There's always gonna be that we're gonna be much better than Helm because Helm has challenges and we want to be better than that. The closest tool that's out there that's similar to Helm is around is called Customize. Customize is because, and it's interesting because you have many different camps of individuals who I love customize, I love Helm, I like one or the other. Traditionally, I always say that infrastructure teams will probably lean more towards customize, mainly because customize is built into the Kubernetes command line. They don't have to get in additional tools and they may become more familiar with it. It's also, I think, a little easier to get started. You just go ahead and just take your manifest, flip dash F and dash K in the kubectl command line, and you can get moving. For instance, Helm, you have to worry about templates, values, different partials, etc. The on-ramp's a little easier, but I feel that Helm is a lot more extensible and more scalable than customize. And is the goal maybe different? The goal I wouldn't say is different. In the end, you want to be it is somewhat different. So there is a little bit of a difference because Helm does have state. You can basically a Helm release gets stored as a secret by default in Kubernetes. Yeah. Customize has no attributes whatsoever. Once you it they they just render manifests, that's all it is. So there's no way to man maintain a current version or rollback very easily. You have to manage manually manually manage that yourself. What I typically find is that people start with helm. Or start with customize, pardon me. And then at some point they'll hit some kind of limiting factor. It's gonna be a scalability challenge, it's just gonna be just a limiting factor of the tool itself, and then they lean themselves more towards Helm. Helm is not perfect. I will tell you that. Helm is definitely not perfect. However, you can use customize and helm together. And actually, it's a very powerful tool you can use, even though Helm does have some advanced features that you can leverage that might be able to do what you want to do. Customize actually provides a good way to manage it, manage some resources more effectively because if you're coming and grabbing a Helm chart that comes from the community, it may not have all the bells and whistles and toggles that you might need. Customize can sometimes fill in that gap where Helm may fall slightly short. So there's an ability that you can use customize and helm together that you can get around that and open up new opportunities. You can, as I said, you can do most things with helm, anyways, but it usually requires a little more advanced knowledge and intuition, as they say. Otherwise, usually I always lean more towards helm.

Speaker 1 8:03

Okay, so they complement each other.

Speaker 3 8:05

They in in certain ways, yes, because I always say helm is gonna probably be your primary tool, but you can almost think of customize as being a way that you can kind of make that last top layer even better.

Speaker 1 8:18

Okay, okay. So your talk is about uh Helm 4. What problems does it solve if you look at Helm 3?

Speaker 3 8:25

So Helm 4 is was the first release that occurred in the Helm community for almost five years. It's not breaking? It's not breaking. Okay, yeah, yeah. That was our that that was actually one of the goals that came out of Helm 4, was that we did not want to break anyone. We wanted to. That was the last release that broke the the the transition from Helm 2 to Helm 3 was quite drastic because you had a primary component of Helm that was basically ripped out. Tiller, if you remember. Yeah. It basically you could manage state in the server. And that's the key difference between two and three is that we wanted to remove that because coming from someone like myself at Red Hat, we work in a lot of enterprises, and having that server-side component was a security risk. So we wanted to make it so that the community did not have to worry about that and could bring it into more communities and organizations around the world. From a Red Hat perspective, no, we were very almost somewhat anti-Helm for a while because of those security limitations. And after the Helm 3 release, we came around, we started to embrace it. That a lot of it a little bit was due to myself pushing it internally, but there was a lot of bias there. No, but there was a lot, there was already a lot of momentum that the team had already been doing, anyways. So I just kind of kept pushing it along and got it moving. But yeah, I mean, the the way Helm has been adopted in many organizations is actually great. I mean, you see Helm, I mentioned this to de facto package manager. There's a reason for it. It's so ingrained to many organizations, many enterprises, how they do business. And we take that very seriously in the Helm community. We have a very strict version control policy in terms of what is breaking, what we can and cannot do. It's one of the reasons why we had to and wanted to create Helm 4, is that we were limited. We had a lot of basically tech debt that had bubbled up because we couldn't get rid of it because of our versioning policy. And anytime we make a change, we are triply quadruple everything because we do not want to break anything. Because we have a lot of folks who are very connected in the cloud native community in the Helm community.

Speaker 2 10:25

Yeah.

Speaker 3 10:26

If anything breaks, guess what? We're gonna get called. It's not gonna be just a GitHub issue. We're gonna get called. I got called a couple times, and some of our team members got called because of certain things that have happened in the Helm community. Some good, some bad. Fortunately, most of it's been good, but we do take things very seriously, and that's one of the things you kind of have to do when you become basically part of the glue of the cloud native community, is you have to be very cognizant of everything you're putting into your software.

Speaker 10:53

Yeah, but personally, the transition from three uh two to three, that was a lot of work for us. It was and so they fixed it.

Speaker 3 11:03

Over time, over time.

Speaker 11:05

It took it took a lot of a lot of time also to to to fix that with customers because you're it it it's running in their pipeline, so you have to it's a trust factor, honestly.

Speaker 3 11:14

Everything in the community in cloud native community is a trust factor. If you lose the trust, it's over. I mean, think of it like any business. If a business treats you badly, are you gonna go back to it first time? Or no, that's your number one choice. Airlines is a great example. If anyone treats you bad or you have a bad experience with them, are you gonna go back to it? I'm I'm not gonna say anything about Ryanair or EasyJet, but you know, American Airways.

Speaker 11:37

No, American Airways, you want to have uh some space. Exactly.

Speaker 3 11:41

You want to you want to not, you know, you want to be able to check your or carry on your bag and not have to go ahead and I'm sorry it doesn't fit exactly into that baggage compartment there and the baggage hold baggage sizer at the gate. I'm sorry, I'm gonna push it in a little farther. Yeah, I've seen people break off the wheels of the uh just to go ahead and make the point instead of going ahead and paying the 10 euros for the bag, I'll go ahead and trash this bag. It would probably cost me 40 euros to replace.

Speaker 2 12:04

Yeah, exactly.

Speaker 12:06

So going back to Helm 4, what did it is it is it going to solve from three to four?

Speaker 3 12:14

So it's interesting because that was the kind of the crux of our talk here at KubeCon. Was okay, now that we've released Helm 4, everyone's like we're so excited. Okay, Helm 4 finally, thankfully, is out. Now what? What do we do? What do we look forward to? And a lot of it was what was delivered with Helm 4 and what wasn't delivered with Helm 4. Uh, Helm 4, we wanted, we had a lot of aspirations. However, a lot of us are busy, so we couldn't get everything in as part of Helm 4 because we didn't want to keep pushing it down the road and down the road, and 2027 comes along, and we still don't have Helm 4. So we went ahead and we just said, okay, we're gonna go ahead and cut this. This is this is gonna be the release of Helm Helm 4, and everything else just comes after the fact. The big thing that was that what came out of Helm 4 honestly was plugins. We expanded our plugins because we now have a WASM-based plugin model. So that allows us to be a lot more extensible and be able to scale a lot better than our more limited plugin system that was pre-Helm 4. A lot of it, honestly, in terms of what came out of Helm 4, was under the covers. It was a lot of the APIs and cleanup. We basically cleaned up a lot of code. We had a couple different ways that we had handled logging previously. We now handle logging better. We also handle statuses for releases and different statuses of different resources better. We actually leveraged a library out of the flux community. A lot of our member uh community members were members in the flux community. And we worked and got a couple of libraries that came from the flux open source community into Helm, working with them, making sure the licensing was good, making sure all everything came together. Because we also saw challenges in their library and we made some enhancements to their libraries. This is how the community works together. It's awesome. Yeah, yeah, yeah. Is that you're able to start working together? Exactly. I mean, similar on the OCI side, you know, I mentioned previously, um, Aura's is the project that we're leveraging out of OCI to be able to do manage OCI content in Helm. We found some limitations there, and members of the community, myself included, did a lot of contributions over on the OCI side with Auras. And we have another feature coming out, we'll speak in a minute about it, about a way that we can increase the extensibility of OCI and Helm, and that comes because of changes in the Auras project. And now we have members of the Helm community contributing there because they want to get a feature and you have to go get it there first and then get it into Helm afterwards.

Speaker 1 14:31

So if you want to upgrade to Helm from 3 to 4, is it just like uh replace three and you're done?

Speaker 3 14:39

Yeah, you're done. That's it literally, you can just replace the binary, and we didn't want to break anything. All the charts are gonna be compatible. I think it's quite impressive. It is. We spent a lot of time making sure we didn't break anyone. I can't think of anything that we broke in Helm 3 to 4. We broke, we we did break something, but it was in the Helm 3 release as we were starting to go ahead and get some new features. I mentioned Auras in the past. Auras, we were on V1 of Auras for the longest time. We really wanted to get to V2 because there were a lot of features that were A, missing out of Helm, but also features that were enabled in in V2. So we spent a lot of time and we had a bit of hubrist when it comes to how popular and how much Helm is used, because I always say it's very much like plumbing. Nobody ever talks about plumbing until it breaks. It just works. Yeah, it's like Helm's the same way. Many of the projects in the CNCF and open source community are like that way. If they don't break, everyone just takes it for granted. However, when it does break, like what occurred you know about six to eight months ago, you hear about it. It was when we switched over to Helm V2, there were some ways that some individuals were using it that we didn't think about, we didn't test it, and then we had to basically all hands on deck go ahead and get the group together to do a little bit of firefighting.

Speaker 1 15:53

So if you replace a binary, do you get access to all the features immediately, the new features?

Speaker 3 15:57

Yeah, you can just go ahead and leverage them immediately. A lot of them, as I mentioned, are not gonna be enabled until you start using them. So if you want to start building your own plugins and start to using the new plugin system, that you just go ahead and start leveraging the Helm 4 binary because it's enabled there. Charts will work the same. Everything should that was our goal is we're not gonna break anyone. Everything should be kind of like you shouldn't notice. Like the only thing you're gonna notice is hey, it says Helm 4 instead of three. Oh, very cool. That should be it. It's very much like a cell phone upgrade. It upgrades to the new version. Ooh, look, I have a different UI. But hey, I can set up like a phone call. That's how it should be.

Speaker 2 16:33

Yeah.

Speaker 16:33

Hey, and and the plugins, you're talking about plugins.

Speaker 3 16:36

What kind of plugins could we so this is where some of the features around that we didn't get into Helm for yet, but is coming soon is what we call Charts of V3. Charts of V3 is basically a new way of managing charts themselves. And plugins are a way we're trying to enable that. So right now you have different capabilities of Helm that you may not think about, but are just there. So how you download certain certain resources, how you go ahead and render certain resources. Right now, the rendering rendering engine of Helm is Golang based. There's been a lot of people who say this sucks. I want to go ahead and bring my own templating engine. We now have a re we now have a rendering plugin that you can bring in as part of Charts V3 that you could use Rust. You could use you can basically just change it completely so you don't have to use you can use Ginja. So I'm you know from Red Hat. We have we have an automation tool called Ansible. Uh, it's very ginja-based. Yeah. So if you happen to have affinity for a certain tool that's more comfortable to you and your teams and your organization, go ahead and use that. But then, as I mentioned, aside from OCI, security is an area that I focus on. And signing. We asked the audience as part of our talk, how many people are actually signing your Helm chart? I think there were three hands that came up in an auditorium probably full of 300 people. How can we make it easier to sign content? The CNCF and Kubernetes use Sig Store quite a bit, the Sig Store ecosystem. And by having a signing plugin, you can then easily bring in Sig Store and its set of tools. So you can see how a plug-in engine and the new Charts V3 is going to help enable a lot of the gaps that have currently lived in the Helm community for the longest time. But we're taking the onus off of Helm, the actual core, and we're basically offloading it to others because they have to implement the rendering engine. We're not going to do it. We're going to say we're going to give you the hooks to integrate with Helm. And it's up to you to create your own tools and plugins on top of it.

Speaker 1 18:28

So I can make my own plugin and integrate it with Helm.

Speaker 3 18:30

Correct.

Speaker 1 18:31

But there should be a check somewhere. There is not mess up something like that.

Speaker 3 18:34

There's going to be there, there's an once again, we're still in development here. There's an interface that you're going to have to a type that you're going to have to basically confide to. And as long as you comply to it, you'll be able to just pop it in. Now, once again, it's not perfect. It's not really complete yet. So this is where we're looking for community contribution. What areas do you see might be interesting use cases for plugins in Helm? Is it going to be a downloader plugin? Is it going to be a signer plugin? Is it going to be a renderer plugin? Is it going to be some plugin type we haven't even thought about? We don't know. But we want your input. That's why we're here. That's why we're here for you. Without you, we're just going ahead and developing software in a bubble. And I can do that now and go sit into a padded room and go yell. But as but if no one wants to hear it, that's not going to do much for the community. So that's kind of where we're looking to get some input from the community on. We're already starting to make momentum on Charts V3. That's kind of the biggest area of consideration. There are two primary areas of Helm 4 that I'm excited about and really what we're focused on. The Charts V3 is number one. And the number two is the container tools support. So right now, OCI, as I mentioned, is probably the most is becoming the more popular way to distribute and consume Helm charts. There are limitations to what you can and cannot do with OCI charts right now. There's issues with credentials. There's issues with how you handle it in like enterprise organizations. Let's just say you have a chart, a couple charts. You have one at like quita.io slash foo and quita.io slash bar. You can't have separate credentials right now. You can only have a credentials for quita.io. You can't have one for different parts of the organization. So at an organizational level. There are some libraries and basically capabilities that are enabled by the containers tool project that enables you to basically pick it so you can have a set of credentials for these sets of repositories and these sets of repositories and have them be independent. That's one. Another one that's going to be very popular in many enterprise organizations is the ability to mirror content. So if I have content coming from, let's say a chart coming from quid.io slash foo slash my chart. Yeah. But in an organization, you can't talk to quit.io. No. You have your own repository of content. You can transparently mirror the content. Oh, that's awesome. And basically on the fly, it will go ahead and rewrite the content for you.

Speaker 20:54

And that's also because Docker implemented rate limiting and probably some other companies are going to do with Helm repositories also.

Speaker 3 21:03

They want to go ahead and bring everything internal, especially if we talk about the sovereign cloud. The keynotes yesterday here at KubeCon were all focused on sovereign cloud, being able to manage everything independently from any public system. So being able to go ahead and bring everything internal, but not have to do too much onus on your side, make some small client configurations to be able to basically swap the content, basically proxying. You're basically going ahead and saying, I'm going to mirror the content. And whenever I see a request coming from quita ioslash foo, rewrite it to my repo slash bar. And it does that transparently. Oh, that's awesome. That's that's that's a it's a feature that's been long asked about because you basically are stuck with what's currently hard coded into the chart.yaml file. We're gonna make it so it's all transparent, and the best part about it, especially if you're already a container tools user, you already have it configured on your system, you're done. Nothing else has to happen.

Speaker 21:54

What we do is we download all the charts and put them in our repository, change the change the chart.yaml so it points to a different location.

Speaker 3 22:02

Yeah. But now you don't have to. That's the best part about that, is that you can basically copy it and there are tools in the community like Zarf, for example, that can easily pull in the content and mirror it into your systems. And then if your systems are already like your your operating system and your on your like your Linux and your Windows and your Mac operating system already has it configured to do the mirroring for you, the proxy, you're done. Nothing else has to change. And you can just consume the charts as is. Sure, there's going to be some educates we haven't thought about, but that but at least we're thinking about ways to enable more uses of Helm in more places and make it easier for users to actually use the content. And but we're not, and the best part about that is we're not reinventing the wheel. We're going ahead and taking existing paradigms and practices in the CNCF and cloud native community and just bringing them into Helm for others to use.

Speaker 22:52

Yeah, that's awesome. Yeah, in the past I was against Helm because I I'm an old school YAML guy.

Speaker 3 22:58

Hey, I know. I I I have I mean nowadays you go to Chat GPT or Gemini or Claude, it would be more than happy to give you YAML like crazy. Helm's a little more challenging. You have to go ahead and teach it a little bit. A skills file will help, just some Claude MD agents file. However, it's happy to just spit out YAML any day.

Speaker 23:18

Yeah, it's it's it's getting more extensible and more easier. And signing, and for me, signing your hand files, it's yeah, that's it's huge. It's that's huge.

Speaker 3 23:29

It's Providence. And especially mentioning digital sovereignty, you need to have those those guarantees that the content is coming from trusted, reputable sources.

Speaker 23:38

Yeah, we did that already a long time ago in l in Lilo's land. We we were signing everything or or checksums.

Speaker 3 23:45

But the challenge right now is that the current signing mechanism of Helm is GPG-based. And if you ever worked in GPG-based signing, it is a pain in the butt. It is a pain in the butt to get going. Even someone like myself who even does security for a living, it's still a pain in the butt. And if it's a pain in the butt for me, how is it gonna be how is it gonna be for any typical user? Not easy. I mean, I I I I've been walking around the Padre Pavilion in the showcase most of the time here, and there are a lot of new community members here at KubeCon, and you need to take a step back, especially if you've been in the community for a while and just realize that yeah, you've been here for a while, but there's still a lot of people who are just getting on board with this technology.

Speaker 24:24

Yeah, and last year it was 50%.

Speaker 3 24:28

It I mean, I think they had everyone stand up yesterday to see who is oh yeah, who's your first KubeCon, who's here? Once again, it was a lot of people. Oh, that's awesome. Had to be at least 50 to 75 percent. And it's once again just surprising, but in the end, not surprising because as more and more organizations really start to focus on cloud native, they're leveraging AI as they can to be able to help upskill their teams. They still realize that there is that human factor. They want to be able to get people to be able to control can not only collaborate but learn more in a venue like help like um KubeCon, like we are here in Amsterdam, is a great way to do so. Because you have some of the experts in the community all here under one roof.

Speaker 25:10

Yeah, and uh everybody's open, willing to talk, and and I think that's the best thing.

Speaker 1 25:16

Yeah, because all all you know you need the contributors, right? To uh move forward.

Speaker 3 25:21

And that's a challenge we're seeing in the open source community is contributors. One of the biggest benefits and detriments these days is AI. AI is great because it can help enable you, enable new opportunities. One of the downsides of AI is it's the ability to create content. AI can create content so fast. So, guess who has to review that content? It's still the maintainers. You still have a human factor behind that. But the problem is not only are you increasing the load on maintainers of these communities, you're also putting a lot of bad code out there for the community because it's gonna be vibe-coded, it's just gonna be stuff that AI generates.

Speaker 1 26:01

AI slop stuff.

Speaker 3 26:02

Exactly. So it's getting better. It is getting better, but still you just the amount of content is still limiting from a maintainer perspective.

Speaker 26:10

I see it in presentations. And we we see a lot of presentations. It's always an a sum up from things doing this, that, that, and then at a catchphrase. Boom! And if you hear that, that's an AI-generated presentation.

Speaker 3 26:25

I'm old school. I actually enjoy creating presentations, so I will always create my own. What I I I think in my four talks I had here at KubeCon, I had one AI assisted image, which I put a nice little caption at the bottom, AI generated assistant, you know, just so I had it there, just so because I like I I can't draw for crap. I I can't. I can't. I cannot draw at all. I'm I I I do my best. I have I use icon sets, etc. But I had one great infographic that I showed the difference between uh long-lived credentials and short-lived like workload identity. And Jem and I put together a great infographic. I'm like, this is great. I would never be able to draw this myself. Let's use it, just make sure I attribute that I created it. And that was perfect. And the audience loved it.

Speaker 1 27:08

Yeah, but isn't so with the with if you look at the contributors uh there's so much to choose from to contribute to. If you didn't look at the CNC and the landscape, it's insane.

Speaker 3 27:17

It's an eye chart. The I the CNCF landscape is always an eye chart, and it gets worse.

Speaker 1 27:22

You can almost put a put a map on the on the board, pick a dart. Okay, I'm gonna help with this one.

Speaker 3 27:29

And that's the problem too, is that if you're getting new into cloud native technology, where do you begin? I mean, it was easier a little at when I first started because there weren't as many projects. There are so many projects to choose from. Where do you even begin?

Speaker 27:42

Yeah, it's something, something I think it needs to be something where your heart is.

Speaker 1 27:48

Well, even then, if you go to look at my heart is in the networking, yeah, pick the 21 uh Honestly.

Speaker 3 27:54

For the community, the collaborators are usually going to be working in a community where they work on their day on a day-to-day job. For me, I did do a lot of work around Helm as part of my job at Red Hat. So that's why I got even more ingrained in the Helm community. It's usually the contributing the contributors will come because they want to get a feature or get a bug resolved in some of their daily day job or their side or side hustle or just passion.

Speaker 1 28:19

Yeah, but there I I think there's an emerging problem there because if I'm a junior, I've been just starting out, and I'm I'm raised with AI, and I'm doing everything with AI, I don't need to understand the uh the language on and all, and then how do I put it?

Speaker 3 28:40

And that's what concerns me is that AI is helping enable others, but you're missing a lot of the primitives, the key science, the in the compute the computer science fundamentals. We're kind of skipping over those in many ways just to get an answer.

Speaker 1 28:57

Yes.

Speaker 3 28:58

And yes, you get an answer, but that's where AI AI is great for getting you an answer, but is it the right answer? Is it the most optimized answer? How did it get to the answer? Exactly. So the 99% always right. I mean, what you're gonna see is one of two things has to occur. One, the models have to get smarter, two, we have to do better with testing and verification so that we can get in the new features that AI might be helping out with, but we know that whatever the content they're giving us is gonna be good because maybe it looks good on the on the surface, but maybe under the covers, it does AI does not account for all those different edge cases, and that's where I hate to say it, we're seeing a lot of those edge cases in the community these days, and not just the community, but in like public services. I mean, GitHub and AWS, they've had outages and Azure, they've had outages, major outages, and I feel like they've increased in in recent times. I don't know if if you or your listeners have, but I definitely have seen more of an increase. And even I think it was AWS that said, hey, we're gonna kind of tone things down a little bit in terms of the AI, just because we know that we need a little bit more verification and review just to make sure that we're not risking our systems and our and our members.

Speaker 30:11

Yeah, half a year a year ago, that was really a lot because we had AWS outage, we had Azure outage, Cloudflare outage, and half the internet was down.

Speaker 3 30:22

I know. I mean, you realize how in reality the internet's made of like four companies. So you you take one of those companies out and you're done. I mean, Amazon goes down, especially US East one goes down, might as well go ahead and grab coffee because it's gonna be a while.

Speaker 1 30:37

Yeah, what's the redundancy in that, by the way?

Speaker 3 30:40

Well, I think more and more individuals, and this actually out of here, out of Europe, they're thinking about the redundancy factor. Many regulations these days say you have to be in multiple cloud providers. You need to be not only in the US, but you need to be in Azure. But in many cases, they're also mandating that you have cloud providers that are located in different regions, not only from a regional perspective, but who owns your data. Yeah. So let's say you have Azure and you have AWS. Guess what? They're both based out of the US. That's not going to work really well. So you're seeing more and more and more of the niche cloud providers starting to come up, the Hertzner clouds and the ones out of the Middle East or the ones out of APAC, just as an alternative so that if something happens in one geographic location, you can go ahead and get your data and have it stored certain places.

Speaker 1 31:26

Yeah, because uh sovereign is the key word at the moment. And of course, Microsoft says it, Amazon says it, but uh in the end they're still an American-based company.

Speaker 3 31:35

I I will say that the sovereign topic is nowhere near as popular as it is over here. In in the US. Like for I I'm based out of the US and the sovereign topic is not as popular as it is here.

Speaker 1 31:49

No, because I think the US only looks at itself briefly, and Europe needs to look at itself.

Speaker 3 31:55

You're dead on exactly right. It's because US has a bit of well, it doesn't affect me, it's not my problem. Versus a here in Europe, it's like, wait a second, we're putting all of our eggs in basket in companies that are located in one national area. If something happens there, where's my data? Is my data safe? Is it protected? So you're seeing more and more entities actually bringing things back on-prem because they just don't trust anyone, they trust themselves because they can control the full world of the world. I like that on-prem. Me too. So being from Red Hat, a lot of our customers are on-prem. One of the ways that I contribute in the community is that I bring kind of an enterprise view to many open source projects. It's like, guys and gals, you're not going to always have access to Docker or Quay or your public internet services. You need to be able to point to a more local location, your own registry, your own package repository, being able to deal with the idiosyncrasies of enterprise life, DNS proxies and firewalls. Everyone's bane of everyone's existence. I know my existence.

Speaker 32:57

So moving forward, how do you see the new features of Helm 4? What can can we expect?

Speaker 3 33:06

So a lot of the work around container tools, as I mentioned around like the redirection of locations, the registry credentials, have actually gotten upstream into Auras. So we actually had a talk uh about a week ago about how we can easily integrate that in. And one of our maintainers is like, let's go ahead and let's release Helm 5. And we're like, We just released Helm 4. So we're working it took you five years. It took us five years. Like, we need, I mean, if you work with organizations and large enterprises, it's not fast to adopt new technology. So there's still gonna be a while for them to adopt Helm 4, even though it's been around for about six months now. So we're gonna do what we can to comply with our versioning policy and for semantic versioning and seeing if we if we can bring this in as a minor release instead of having to do it as a major release. If we can do that, which I think we can, I see us getting that support in in the next few months. We need to get a release on the Aura side, but we have a lot of members in the community there that we can probably get a release out of them.

Speaker 1 34:04

And if you look far, far what more further in the in the future, what would you like to see Helm evolve into?

Speaker 3 34:10

Helm, honestly, it's all about usability. How can we make it easier for users to be productive with Helm? Is it going to be easier integration with IDEs, making it easier from because I want to make it so that users don't have to worry about having to generate content? Can we use AI and use AI accelerators to make it easier for users? Skills files, for example, making it easy for these AI tools to be able to help users. That's where I see us having the best opportunity to help enable those who want to be fluent with Helm, but maybe just aren't there or just don't want to. So that's where I see us being it's always beyond the tech. Uh going in and making in approachability is always a number one attribute for open source software. So whatever we can do to make the onboarding process, usability process better is how you how you get better adoption.

Speaker 1 35:00

Yeah, we have heard usability is key more times than once. Yeah, that's that's during the other conversations.

Speaker 35:06

That's uh coming back topic.

Speaker 1 35:10

Yeah, yeah, yeah.

Speaker 35:10

Yeah, Kubernetes is hard.

Speaker 1 35:13

I think it's also like um people change, right? Uh, it's not all command line based. You want the one still people based on it. Oh, I like command line.

Speaker 3 35:22

I I'm the same way. I'm I'm very old.

Speaker 1 35:24

We also need to look at the news interest. I can give you a quite good example, actually. It's not like Helm or Kubernetes-based. I'm really a PowerPoint guy. Oh, yeah. I can I can do everything in PowerPoint. But we have um we have new people coming in the company in the marketing side, and you look at PowerPoint, you think, What is this? Why do I do I need to click there? Yeah, and they go to Canva, right? Because that's like very intuitive in their design and usability. So even there you can see where people are looking at.

Speaker 35:52

I can't find my way in Canva.

Speaker 1 35:54

It's I mean we It's not designed for you. No, you grew up with with the interface of Word and for the Microsoft. I'm in the same space.

Speaker 3 36:03

I mean, I I I I I I still have PowerPoint and Word, they're big and they're bloated in many ways, but honestly, I feel more at home with them because very much like yourself, you've used them, it becomes kind of second nature to you. It's like driving a car. You don't think about driving a car anymore, it just works. Or here, riding a bicycle.

Speaker 1 36:22

Yeah, so that that's this it's not word perfect.

Speaker 3 36:25

Oh now that now that brings back memories. Shift of seven, then uh wow, yeah, yeah.

Speaker 1 36:33

I got my typing degree in there.

Speaker 3 36:34

Now the question is how many of the you listeners out there have ever used word perfect these days? Probably not a large amount of people and and the original one, not the choral one.

Speaker 36:45

No, yeah, yeah, yeah.

Speaker 1 36:48

Well, are you ready for the final question, Jan? Or do we have other questions?

Speaker 36:52

No, yeah, man. You can ask the final question.

Speaker 1 36:54

Okay. So if I would put a crystal ball here on the table, what would you like to see for the future of Kubernetes and also maybe help?

Speaker 3 37:03

Honestly, it's gonna be reaching new areas. How do we go ahead and touch communities, touch in users where we haven't touched before? Is this gonna be greater extensibility into these regions? So I look into places that are just getting the internet now and being able to just adopt the technologies, or in organizations where cloud native technologies hasn't really had a had an ability to influence change. Not only are you gonna help innovate their organization, but you're gonna then bring up new individuals. How do we get individuals to be able to adopt cloud native technologies better, but also start to integrate more of the technologies that are coming out in the market? AI, for one, how we make it easier for users to use AI for Kubernetes. Everyone says managing Kubernetes clusters is painful. How do we make it easier? Don't want to make it easier. I think it's easy. Well, that's how that's how many organizations make money, is making it not easy.

Speaker 1 37:54

Yeah, don't make it too easy. Okay, thank you so much for joining us in our podcast. And uh, we'd love to have a follow up conversation in the near future.

Speaker 3 38:02

I love it. Thanks, guys. I had a lot of fun.

Speaker 1 38:04

Thank you, Andrew. Bye bye.