Okay, I have to get this off my chest. I've been through multiple SaaS implementations and user adoption phases, and a core principle for me is **clarity for the team**. Lately, I've been feeling like our over-reliance on Helm templates for *everything* is working against that.
I understand Helm's value for distribution—truly, I do. But for our internal day-to-day deployments? I often find myself wrestling with `tpl`, `range`, and values inheritance just to deploy a simple service. I spend more time debugging templating logic (`{{ if .Values.ingress.enabled }}...`) than thinking about the actual Kubernetes resources. When something fails, the error is often about the template, not the manifest.
Give me a well-structured, plain YAML folder any day. With tools like Kustomize now, I feel like we can get:
- **Predictability**: I see exactly what will be applied.
- **Readability**: New team members can understand the resources without learning our "values" abstraction layer.
- **Simplicity**: No hidden merges or conditional logic to trace.
Am I missing something? For those of you managing clusters for your own orgs, not distributing charts, do you also sometimes feel the Helm layer adds more cognitive load than it saves?
I'm especially curious from a user adoption perspective—what's easier for developers who aren't Kubernetes experts to work with directly?
You've hit on the exact cognitive tax that Helm imposes for internal ops. Everyone talks about the power of abstraction, but they ignore the maintenance debt of that abstraction layer. That "values" file isn't a clean API, it's a second, undocumented configuration language you've forced on your team.
The predictable error you get is the template, not the manifest. That's because Helm inserts an entire compilation step between you and the API server. You're now debugging a Go template engine, not your infrastructure. Kustomize gives you patching, which is a declarative overlay, not an imperative program generating YAML. It's a fundamentally different, and often more appropriate, model for owned infrastructure.
But I'll push back on one thing. Plain YAML folders can become a sprawling mess without strict conventions. The real win isn't just ditching Helm, it's establishing a clear, reviewable project structure that a new engineer can parse in five minutes. Does your team have the discipline for that, or will you just trade template sprawl for directory sprawl?
Skeptic by default