[mtalantikite]

"The idea is reuse."

That's what Terraform modules are for. If I need to bundle up things for, say, multiple environments, I can just write it as a module and configure it through the variables I've exposed.

There's also a registry of community maintained modules if there are some common patterns I don't want to write on my own (https://registry.terraform.io/browse/modules).

[throwaway894345]

I can't speak to Terraform because I haven't used it, but I'm skeptical that modules are sufficient for many of the same reasons that CloudFormation templates are insufficient. I think at some level you need the ability to programmatically generate arbitrary static configuration, and you end up needing something very like a real programming language to do that.

If you need something very like a real programming language, you should just use a real programming language instead of a tool that accidentally reinvents programming language concepts and the corresponding unnecessary learning curve that that implies for developers. I think the reason these tools are surviving in the "marketplace" is because they market is inexperienced and they conflate "generating static configs (to be passed into a tool that can apply the configs) with an imperative language" with "imperative provisioning of infrastructure". The market sees static/declarative solutions like Terraform and CloudFormation as the only alternatives to "imperative provisioning of infrastructure".

I think as our industry gets more experience and tools for generating YAML/static-configs improve, it will be clear that these are the ways forward.

[mtalantikite]

"I can't speak to Terraform because I haven't used it"

Well, then maybe you should try it before you decide it doesn't work! I'll definitely be giving Pulumi a try, but honestly Terraform works really well and I'm happy using it.

It's a nice idea to be able to have a programming language you're familiar with available to do infra work, but deploying and managing infrastructure is a totally different problem domain than writing an application. If the concern is letting developers that don't have much ops experience architect an infrastructure, or you have recent graduates that "don't know HCL", then you have quite a higher learning curve than you actually think you do.

I've never once thought "I really wish I could just use TypeScript for configuring my infrastructure". If that's you, great! Call me when you hit scale and your ops team needs to refactor it.

[throwaway894345]

> Well, then maybe you should try it before you decide it doesn't work!

Based on the assumptions I called out about it, it necessarily can't work as well as a general purpose language. I intend to try it to see if my assumptions are correct or not.

> It's a nice idea to be able to have a programming language you're familiar with available to do infra work, but deploying and managing infrastructure is a totally different problem domain than writing an application.

It's not a hard domain. Developers can write a program that evaluates to YAML--it's not hard. The hard part is applying that YAML to the infrastructure in an efficient way, but programmers don't need to worry about this because Terraform, CloudFormation, Kubectl, etc do it for them.

> If the concern is letting developers that don't have much ops experience architect an infrastructure, or you have recent graduates that "don't know HCL", then you have quite a higher learning curve than you actually think you do.

"Learn Ops + HCL" is a bigger learning curve than "learn ops". Notably, learning two things at the same time is a bigger problem than learning them both individually. But you're right that using a standard programming language isn't a substitute for learning how to architect infrastructure--I never said it did--only that it removes the unnecessary complexity and unfamiliarity imposed by HCL.

> I've never once thought "I really wish I could just use TypeScript for configuring my infrastructure". If that's you, great! Call me when you hit scale and your ops team needs to refactor it.

Ha! If the industry hasn't moved past Terraform in 5 years time, it will only be because HCL has adopted enough of the general purpose programming language featureset as to remain competitive. That's certainly its trajectory.

[mtalantikite]

"It's not a hard domain."

Are you really arguing that deploying and managing infrastructure is not a hard domain? Please. The very existence of tools trying to solve these problems speaks to this difficulty.

I'm going to drop it at this point because it's starting to feel like you're either trolling or have never run a substantial application in production before.

[throwaway894345]

It seems like you’re violently agreeing with me. Like I said, rectifying the infrastructure is the hard part and generating YAML is not. Let the tools do the hard part. They’re good at that. Not so much at the expressiveness and reusability part.

[cheese4242]

> Ha! If the industry hasn't moved past Terraform in 5 years time, it will only be because HCL has adopted enough of the general purpose programming language featureset as to remain competitive. That's certainly its trajectory.

Quite a statement to make for somebody who has never used Terraform.

[throwaway894345]

I've been keeping tabs on it for a while. Feel free to point out where I'm mistaken.

[juliosueiras]

want to point that ever since Terraform 0.12, all terraform params and modules etc are transformable in objects, what I mean by that is you can use functions like yamldecode or jsondecode to decode any yaml or json into terraform objects and pass into modules or resources or locals, also "real" programming language is always funny to me when ops are going to be much more comfortable with HCL. JSON/YAML are not in the same class as HCL. YAML maybe can do nesting with & but they can't just create simple config style interface, where the user facing side is a simple yaml file, and the terraform code underneath take it in and pass it to its modules

[throwaway894345]

> want to point that ever since Terraform 0.12, all terraform params and modules etc are transformable in objects, what I mean by that is you can use functions like yamldecode or jsondecode to decode any yaml or json into terraform objects and pass into modules or resources or locals

This sounds like an important development for Terraform, but it also sounds like it's proving my theory that TF is reinventing a standard programming language badly.

> also "real" programming language is always funny to me when ops are going to be much more comfortable with HCL.

Maybe (and I think it's a big maybe), but if you want to empower developers to do their own ops (read "DevOps"), then HCL is a strict loss over a language they're already familiar with.

> JSON/YAML are not in the same class as HCL. YAML maybe can do nesting with & but they can't just create simple config style interface, where the user facing side is a simple yaml file, and the terraform code underneath take it in and pass it to its modules

Right, as previously mentioned, HCL is accidentally reinventing a programming language. The YAML-based infra-as-code solutions also reinvent programming languages but they build them by building out programming language features on top of YAML (instead of extending the language layer itself) or by generating YAML via text templates. If I had to choose between these, I would pick HCL for sure, but thankfully I can just generate static configs with Python or similar.