The Judgement of the Loop

Preliminary

On the jurisdiction of this court

The parties appeared before the Loop in seven rounds and the Loop declined to name a winner. That decision was reported as a cop-out. It was not. This opinion sets out the reasoning.

A court opinion is a strange form for a config management argument, and it was chosen for one property: it obliges the bench to state the losing case at its strongest before dismissing it. Almost nothing written about Helm and Kustomize does that. This does, and if the case for the tool you dislike reads better here than you expected, that is the form working rather than the bench defecting.

Findings

Findings of fact

1. Both parties agree that YAML is not the problem. Both parties are mistaken. The point was not properly before the Loop and is not decided here.
2. H3LM produces one versioned artefact with a recorded release and a rollback that does not require the original inputs.
3. Kust0mize produces the YAML you would have written by hand, with the parts that differ between environments lifted into a separate file.
4. Neither tool lies about what it does. This distinguishes both of them from several tools not party to these proceedings.
5. H3LM's templating is textual. It does not know it is generating YAML. This is the source of most complaints against it and all of its flexibility, and the two cannot be separated.
6. Kust0mize's patching is structural. It knows it is editing YAML and refuses to edit fields that do not exist, which is a feature until the day you need to set a field the schema does not know about.
7. A chart can be installed by a stranger who has never read it. An overlay cannot, because an overlay assumes you have the base.
8. Neither party produced evidence that its output is easier to review in a pull request. The Loop finds both outputs difficult to review and notes that helm template and kustomize build exist precisely because of this.
9. Every argument advanced in these proceedings about which is simpler was, on inspection, an argument about which one the speaker learned first.

For the appellant

The case for H3LM, at its strongest

You are not the only person who will ever install this. Somebody who has never seen your repository needs to run one command and get a working thing, and then run one more command and get rid of it. That is a packaging problem, and packaging problems want a package: a name, a version, a set of declared values, a record of what was installed, and a way back.

The rollback is the argument that is usually undersold. Reverting a commit gives you the inputs. A release history gives you the artefact. On the night when the repository state and the cluster state disagree, and they will disagree, the artefact is worth more than the inputs.

The templating is ugly. It is ugly because it is doing something genuinely hard: producing valid YAML for cases the chart author never saw. Every proposal to make it elegant has quietly reintroduced the same problem.

For the respondent

The case for Kust0mize, at its strongest

You have one application, four environments, and no strangers. Nobody will ever install this who has not already cloned the repository. There is no packaging problem here. There is a duplication problem, which is a different thing and does not want a package.

What you want is to look at a file and see the actual object that will exist in the cluster, not a program that will emit one. Structural patching gives you that: the base is the thing, the overlay is the difference, and the review is readable because a diff of an overlay is a diff of the decision.

And it is in kubectl. There is no client to install, no version skew with a server component, and nothing extra to explain to the person who joins in March.

Ruling

The ruling

The Loop declines to name a winner and finds instead that the question was wrong.

The parties are in different businesses. H3LM is packaging: it exists so that a stranger can install your thing. Kust0mize is configuration: it exists so that you can run your own thing in four places without keeping four copies of it.

A team with no strangers does not have a packaging problem. A team with one environment does not have a configuration problem. Most teams discover which they are by choosing wrong first, and the Loop finds no fault in that, because the choice is cheap and the discovery is not available any other way.

Where both problems exist, and they frequently do, the Loop notes without endorsement that the parties are not mutually exclusive, that a chart rendered and then patched is a real and widely used arrangement, and that anybody who tells you this is an abomination has not had both problems at once.

Concurrence

Concurring, in part

The Loop adds, separately, that the volume of argument devoted to this question is out of all proportion to its consequences. Neither tool has ever caused an outage on its own. The outages come from the thing both parties agreed to leave undecided in Finding 1, and from deploying on a Friday, on which the Loop has ruled elsewhere and at length.

Go and template.
Go and patch.
Only do not go on a Friday.