Fork me on GitHub
#aws
<
2022-04-02
>
Max01:04:33

I’ve always been a little confused why people want to do IaC using a typical programming language. To me it seems like an odd match, IaC is essentially static data that defines infra config, whereas programming languages are more about defining processes. By lines of code, plain old config properties tend to dwarf the number of actual computations that need to be performed. So to me a Clojure IaC would probably want to start with EDN, and probably wouldn’t look all that different from HCL in the end

☝️ 1
lukasz16:04:02

Except that you do want programming language features like for, ifs and ability to create reusable modules - otherwise you run into hacks like Terraform's count attribute

✔️ 1
kenny16:04:01

Anytime you want to do something special (outside the bounds of the DSL), and in a big enough system this is inevitable, you wish you could “just write some code” to make it work.

Max16:04:27

I guess I've never run into a situation where I couldn't simplify my IaC to the point where that wasn't a problem by decomposing modules and refactoring. Optional resources via count is definitely ugly, I tend to take the Maybe Not approach and just include them or not. Terraform makes it easy to hang modules off of the outputs of other modules, let the user decide which ones to use

Max16:04:09

I think often the more advanced terraform features can be a bit of a trap. Certainly they should be used sometimes, but I think people overuse them trying to DRY out their code, forgetting that HCL is data, not code.

lukasz16:04:12

I agree, I wouldn't use a full on prog lang for managing infrastructure (I tried that 6 or 7 years ago with DigitalOcean, AWS and Ruby) but some of the recent additions to HCL/TF were absolutely necessary - I was able to simplify a lot of our manifests and merge modules together because we couldn't use dynamic blocks before. It's a balancing act, but anyobody who used Ansible will definitely say that "infrastructure-as-data" is not the way to go

👍 1
kenny17:04:32

fwiw, our v1 infra deployment was with Terraform HCL. We switched to Pulumi and the code size decrease by 1/3 and we were able to remove extra CLI based steps. This was ~3 yrs ago, so things could have changed.

Max17:04:53

Well I'd hesitate to call Ansible “data”. It's more of a programming language that uses YAML syntax. But yes I mostly agree. All the CDKTF examples remind me way too much of building up HTML using imperative DOM APIs, you're describing a process for building up your data, not the data itself.

Max17:04:30

Yeah, a lot changed in the last 3 years for terraform.

1
kenny17:04:52

Timeline seems about right. IIRC, simplifications for our code base were reusability of data maps (e.g., merging), inline lambda functions, arbitrary external api calls, EDN config reading.

🤝 1
Max17:04:34

If your infra depends on external API calls then we are definitely working on different worlds

kenny17:04:11

IIRC, it was to support creation of Datadog resources.

Max17:04:39

Isn't there a datadog provider now? Might not have been at the time

lukasz17:04:15

Yeah, the provider list ballooned in size - you can also pull in 3rd party ones . I need to try Pulumi to understand all the praise it gets