[mef]

- the situation: you build cloud infrastructure via CLI or console

- the problem: if something gets deleted, or if you make a bunch of changes and want to undo them, or if you need to make a change to a lot of stuff at once, or if you want to copy what you've built to a new region, how do you do it? or, if you're on a team, how do you as a team make and track changes to your cloud infrastructure?

- terraform as a solution: you describe your cloud infrastructure as yaml files. terraform can figure out what is different between what's in your cloud infrastructure and what your yaml files say it should look like. and, it can make changes to your cloud to e.g. build it from scratch, make wide-ranging changes, make a copy of it, etc.

- since your yaml files are code, you can also create a repo and do PRs to make and track changes to your cloud infrastructure as it evolves over time

[erik_seaberg]

Sometimes the detected differences are manual changes (“drift”) that shouldn’t have happened, and terraform will offer to reverse them.

[srsqsonyl]

Appreciate the answer. In hindsight my use of the word scripts was insufficient.

Looked at the TF code; my solution implements similar functionality to handle AWS CRUD ops. What I avoid is all the DSL parsing and such.

For me an AWS account is a struct with fields of AWS SDK resource types, which it seems is what TF resources map to (they handle a lot more so there’s more to it, but kind of sort of if I squint just right). Either going to duplicate the internal logic or DSL chunks per project, would rather avoid the context switch between syntax, “learning the TF ecosystem”.

Thanks again, though.

[friendzis]

The value of DSL is that the same terraform can run things on your local ESX cluster. I imagine few shops need multiple provider support