May 14, 2018 was just another day at the office—except for this one thing. We were in the throes of a debate over whether to use Helm or stick with plain old YAML files for our Kubernetes deployments. It seemed like every other tech blog I read had something new and shiny about it: configuration as code, templates, and all sorts of promises.

Now, I know what you’re thinking—why does this matter? Isn’t Kubernetes just a big container orchestrator? Well, to us, it’s so much more. It’s the backbone of our microservices architecture, and getting the deployment process right is critical for maintainability and scalability.

The Helm vs YAML Debate

Helm was all the rage back then. Its promise was clear: abstract away the complexity of Kubernetes manifests with templating and charting. But we were hesitant. Here’s why:

1. Learning Curve: Helm comes with its own set of commands and a learning curve that adds to our already steep Kubernetes ramp-up.
2. Overkill for Small Apps: For smaller, simpler services, YAML files felt just right—they were simple enough for us to understand quickly without overcomplicating things.
3. Configuration Management: While Helm was great at templating values, managing secrets and configurations in a secure way still required extra tools like Vault or HashiCorp Consul.

But the bigger question was: could we justify the complexity? We knew we were in for a trade-off here—less configuration management overhead versus the flexibility and ease of use that Helm promised.

The Argument for YAML

In my experience, YAML files have been our go-to method. They’re straightforward to read, easy to debug, and work seamlessly with GitOps practices. Every time I’ve had to debug a Helm chart issue, it’s been a headache. With YAML, the configuration is right there in plain text—no hidden logic or templating issues.

The Experiment

We decided to do an experiment: use Helm for new services while keeping existing ones as YAML files. This way, we could slowly integrate and see if it was worth the effort.

First Issue: Dependency Management

The first thing I noticed with Helm is how difficult dependency management can be. Every time a package or chart has a breaking change, you have to re-deploy everything that depends on it. In contrast, when you’re using plain YAML files, dependencies are just other Git repos—you pull the latest changes and deploy them.

Second Issue: Secret Management

Secrets in Helm were handled with values.yaml files. But we quickly ran into issues where secrets were leaking or not being properly managed. We needed a more robust secret management strategy, which brought us back to tools like HashiCorp Vault anyway—adding complexity without clear benefits.

Third Issue: Debugging

Debugging Helm charts is a pain. The error messages are often cryptic, and you have to dive into the chart’s code just to figure out what went wrong. YAML files, on the other hand, let you see exactly what’s going on at a glance.

The Verdict So Far

So far, our experiment has shown that while Helm can be incredibly powerful for managing complex applications with many dependencies, it’s not yet worth the trade-offs for us. For now, we’re sticking with YAML files and adding some automation around them to make life easier—like using Pulumi or Terraform templates where appropriate.

Wrapping Up

In the end, the choice between Helm and plain YAML comes down to a balance of simplicity versus power. Kubernetes itself is complex enough—we need tools that simplify it without adding too much overhead.

For us, sticking with YAML feels like the right call for now. But who knows? As we grow and our applications become more complex, maybe Helm will come in handy. For today, though, I’ll stick to my YAML files and GitOps practices—there’s no shame in that!

---

That’s how it felt back then. Kubernetes was taking off, but the tools around it were still maturing. What do you think? Did your team end up going Helm or sticking with plain YAML?