Hacker News Reader

Comment by witcher | Hacker News Reader

I might be fanboy of the type safety and having a quick feedback loop, but I cannot imagine a better configuration management system than just straight configuration as code e.g. in Go: https://github.com/bwplotka/mimic

I really don't see why so many weird, unreadable languages like jsonnet or CUE were created, if there is already a type safe, script-like (Go compiles in miliseconds and there is even go run command), with full pledged IDE autocompletion support, abstractions and templating capabilities, mature dependency management and many many more.. Please tell me why we are inventing thousands weird things if we have ready tools that helps with configuration as well! (:

View on HN

I agree. I wish we could just use EDN and Clojure, but your DevOps guy is not writing Go or Clojure code.

They are also not doing code reviews to enforce security policies.

If you have DevOps guys who are also software developers, more power to you, but if I approach my DevOps team with:

Hey just code your scripts in this turing-complete languages, they will ask me "what's your username again?" BOFH-style ;)

Hah, true.

I totally see this being difficult. To enforce DevOps/Ops to actually do code reviews, and versioned, type-safe configuration, but once you accomplish it - the profits are really worth it!

I find this post very condescending. You are not better than your devops guy at managing infrastructure because you can code in Clojure or GoLang or whatever other programming language.

Holy gods yes! Please let me use a real programming language instead of an unholy mixture of yaml and jinja. Clojure would be such a dream!

Check out Spire,

https://github.com/epiccastle/spire

Please consider that you're a principal engineer with a BS and a Master's. And you've achieved all those things quite quickly! You're on the far end of a bell curve.

A full programming language is the natural choice for people who are full programmers. But for people who aren't, they're intimidating and add a lot of complexity. Templating systems are much more approachable for people who have a lot of experience configuring things via big blobs of text.

As a programmer, I would personally rather express everything in a programming language, so I get your perspective here. But it isn't an accident that there are so many ops-focused systems that are different takes on just automating the things people were previously doing manually.

I totally understand that, but why not aiming high? Why we just say "you have experience configuring stuff, so we will just give you some extended json with templating, you won't be able to code....". I think this is bad approach (: We should always aim high and mentor those less experience to use programming languages for this. They don't need to know complex algorithms, distributed systems and performance optimization. It's really just more smart templating that is actually can be easier to use! (:

> Templating systems are much more approachable for people who have a lot of experience configuring things via big blobs of text.

I have mixed feelings about this statement. How reading or using jsonnet is easier? I am a principal engineer and I am struggling to work with this, how less expierience people can deal with that efficiently? (:

They can deal with it more efficiently because its model is closer to their current mental model, and so requires less cognitive load to achieve initial results.

Gabriel talks about this under the label "worse is better". [1] I agree your preferred approach is better in the long term and at scale. But that only matters in the long term, and only if scale is eventually achieved. Tool adoption is generally a series of short-term decisions, and most projects start small.

I agree mentoring people is great, but neither you nor I have time to mentor all the people just configuring things into becoming good programmers.

[1] https://en.wikipedia.org/wiki/Worse_is_better

Interesting view, thanks. (:

Secretaries at Multics sites not only used Emacs in the 70s -- they customized it with Lisp. They were only ever told they were customizing their editor, not programming it, so they never got intimidated!

Haha, that's actually amazing fact, lol.

Let's create a CONFIGURATOR language (and secretly hide Go underneath)!

Go is pretty dumbed down as languages go.

I take it as.. yes? That it would do good for configuration as it is simple? (:

The tool you link recommends "kubectl apply, ansible, puppet, chef, terraform" to actually apply the changes, at least 3 of those I'd classify as configuration management. Generating the configuration is only a small part of it, and the traditional tools typically have some way to do that too because they were designed to be used by non-/almost-non-coders too.

Sounds like you may be interested in Pulumi: https://www.pulumi.com/

Thank you! I've seen that and I don't fully like it. I am not interested in deploying the configuration. I believe that generating configuration, versioning it, baking it, should be a totally separate process to deploying, rolling out, reverting etc

That's why IMO we should separate those. (:

We are writing Pulumi in node (far more mature then their Go offering, but that has been recently improved) and version our releases into private NPM packages. That isn’t strictly necessary, as every update Pulumi pushes gets versioned internally along with associated code changes, and is always accessible in the stack’s history.

If you’re a K8s dev, they recently announced the ability to output Helm3 files rather than deploy directly.

I am k8s dev, but also I think Helm is antipattern. Still thanks for sharing your experience, who knows, maybe worth to look again on Pulumi. (:

I misspoke - it generates straight yaml not helm https://www.pulumi.com/blog/kubernetes-yaml-generation/

Nice!

Reply on news.ycombinator.com