[kerkeslager]

> The only time I have used this myself was an expat style transformer for terraform (HCL). We had a lot of terraform and they kept changing the language, so I would build a fixer to make code written for say 0.10 to work with 0.12 and then again for 0.14. It was very fun and let us keep updating to newer terraform versions. Pretty simple language except for distinguishing quoted blocks from non-quoted.

I hear stories like this and I just wonder how we got here. Like, did this work provide any monetary value to anyone? It sounds like your team just got way too lost in the abstractions and forgot that they were supposed to make a product that did something, ostensibly something that makes money.

I mean, I guess if you can persuade people to give you money to do something, it's profitable. :shrug:

[lanstin]

Pre terraform it would take a half day to setup I new account, create buckets meeting our policies, replicate to backup buckets, etc etc. with terraform we could do same in thirty minutes so we could service many more development teams with same head count.

This work made it easier to keep terraform in sync with aws and so maintenance (e.g. adding a new policy to existing S3 buckets was just edit the S3 bucket module and re-applying to every account. The parser was way easier than manually editing the files manually (especially since I had so much terraform as a test bed of data).

[kerkeslager]

Nobody was saying Terraform is worse than configuring servers by hand--I certainly wasn't. Automation here is obviously right. If you're comparing Terraform to no automation at all, of course Terraform comes out ahead, but that's not saying much.

What isn't right is changing the language and policies constantly, and if your editing configs is so difficult that writing a parser to do it was easier, one begins to think that Terraform wasn't the right automation tool.