Operators vs. Helm Charts: Why Not Every Kubernetes App Needs an Operator

Kubernetes Operators have become the shiny new hammer in the cloud-native toolbox. Every time a system gets even slightly complex — “Let’s write an Operator!” It’s understandable. Operators promise to automate day-2 operations, manage complex lifecycles, and keep your systems running like clockwork.

But here’s the truth I’ve learned after deploying dozens of real-world apps:

Most Kubernetes applications do not need an Operator. And many are better off with a well-structured Helm chart.

The Operator pattern is powerful, yes — but that power comes at a cost: complexity, custom resources, and opaque behavior that can bite you at the worst times.

Let’s break it down.

---

1. What’s the Difference Anyway?

Helm Charts are templated YAML files. They install Kubernetes objects (like Deployments, Services, PVCs) and make it easy to customize via values.yaml.

Operators are Kubernetes controllers, written in Go (usually), that monitor custom resources (CRDs) and take action — like provisioning, reconfiguring, healing, or scaling workloads.

Think of Helm as installation and templating. Operators are stateful automation engines.

So why not always use Operators? Because…

---

2. Operators Are Complex by Design

When you install an Operator, you’re not just adding a few manifests. You’re introducing:

• CRDs (Custom Resource Definitions)
• Controllers with their own reconciliation loops
• Stateful logic managed by someone else
• New API surfaces to debug when things go wrong

This might be justified for tools like Postgres, Kafka, or MongoDB, where orchestration is genuinely hard.

But for things like Prometheus, Keycloak, or Redis?

Spinning up a Deployment with a ConfigMap should not require a distributed control plane extension.

---

3. Real-World Example: kube-prometheus-stack vs. Prometheus Operator

Let’s talk about kube-prometheus-stack — a Helm chart that wraps the Prometheus Operator and gives you:

• Prometheus
• Alertmanager
• Grafana
• Node Exporters
• CRDs for rules and scraping

But here’s the catch: you now have to manage two layers of abstraction:

• Helm values that generate CRs
• Operators that reconcile those CRs
• And CRDs that must be updated independently during upgrades

At one client, upgrading kube-prometheus-stack broke alerting rules because the underlying CRDs changed. Helm upgraded the chart, but the operator silently failed to reconcile the new CRs.

Fixing it meant:

• Deleting/recreating CRDs manually
• Purging cached Helm state
• Reading controller logs to understand what happened

A vanilla Helm chart with Prometheus and Alertmanager would have taken minutes to understand and fix. The Operator-based setup took hours.

---

4. Day-2 Operations: Who Really Benefits?

The main pitch of Operators is automating day-2 ops — scaling, backup, recovery, tuning.

But most teams I’ve worked with:

• Have predictable workloads
• Rarely reconfigure Prometheus or Redis dynamically
• Do backups outside Kubernetes anyway
• Would rather understand YAML than debug CRD reconciliation logic

If your app doesn’t benefit from dynamic state reconciliation, a Helm chart is often cleaner and easier.

---

5. Transparency Beats Magic

With Helm:

• You see exactly what’s deployed.
• helm template shows you rendered manifests.
• You can diff changes, track versions, and restore old configs.

With Operators:

• Logic lives in the controller’s Go code.
• State is hidden in CRs and custom controllers.
• Debugging requires checking logs, CR statuses, and possibly code.

Magic can be helpful — until it breaks. Then it’s just... obscure.

---

6. When Do Operators Make Sense?

Let me be clear — Operators aren’t evil. They’re fantastic when:

• Managing stateful systems with dynamic topology (like Kafka or Elasticsearch)
• Automating failover, backup, or node-aware scheduling
• Providing multi-resource orchestration across services
• You own the Operator or can debug its code

In those cases, an Operator can replace brittle shell scripts or manual ops.

But using an Operator just because “the vendor provides one” is not a good reason.

---

Final Thoughts

Operators are powerful, but they aren’t free. They introduce abstractions, moving parts, and stateful logic that Helm intentionally avoids.

Before you add an Operator to your cluster, ask:

• What day-2 operations do I really need?
• Can I do this with Kubernetes primitives and Helm?
• Am I ready to debug another control loop in production?

Most of the time, a clean, documented Helm chart will take you further, faster, and with fewer surprises.

Just because you can use an Operator doesn’t mean you should.