Hacker News Reader

Comment by Spivak | Hacker News Reader

I think the lesson people need to start taking is that any form of declarative form of configuration will spawn an ad-hoc ecosystem to turn it imperative. The complexity of situations that can be expressed is by a configuration system is proportional to the complexity of that system. Simple and declarative is an oxymoron for anything but simple cases. Imperative systems can express arbitrary complexity and you will need it. It's why troposphere, terraform-cdk, pulumi, a billion templatating systems over k8s yaml files, and Ansible exist.

View on HN

The lesson is that shockingly few people have realized is that the problem space is not, nor has it ever been, served by declarative solutions. You can describe the state you want a system to be in but there will inevitably be procedures involved to do some of the work. It is unavoidable. At the point people began developing templating around their configuration, ah, templates... which themselves have imperative language constructs awkwardly (and badly, cough Golang) embedded in them, it should have been clear to everyone with a shred of talent that it wasn't a good solution.

Declarative configuration is wholly expressible by imperative languages. The converse is not true. Declarative configuration is appropriate for declaring state (i.e., values), and not for describing procedures.

Stop using half-baked YAML crap and start using real tools.

I think the root of the issue is not that we need imperative languages for configuring cluster workloads - declarative state as an API contract between clients of the cluster and the cluster itself is a good thing. The reconciliation model is what makes kubernetes work, and that should be preserved.

But I do think we need better tools to generate said declarative state, regardless of its serialization format (yaml, JSON or other). Hand editing the raw declarative state is clearly untenable, hence the development of the various templating solutions. But I don't see an issue with using an imperative program to generate the declarative state either, as long as the declarative state is what forms the substance of the API to the cluster.

Imperative isn't really unavoidable, all imperative programs can be expressed as functional declarative programs which is much more natural to something that should be declarative in nature (I don't want to know everything you did to get/maintain your network.)

The problem is that people want to express functions as extensions to declarations in yaml, XML, etc, instead of in a functional language that is heavy on declaration.

Do you have any examples of deploying to Kubernetes with something you consider real tools? I agree with what you are saying but have found very few real world companies using real languages for this.

At work we use typescript to generate yaml files which are then synced to their respective clusters via Gitops. It works fairly well. All cluster/namespace differences are encoded into our typescript code base, so we can take advantage of a real programming language to generate cluster specific yaml all sharing a common “base”.

Pulumi, cdk8s.

Reply on news.ycombinator.com