I run infra that has dynamic scaling provisioned via Terraform. Guess what, we auto-scale from hundreds to thousands of boxes a day dynamically managed through TF and we have had no issues, since we bothered to figure out how to do it properly.
I run infra that has dynamic scaling provisioned via Terraform. Guess what, we auto-scale from hundreds to thousands of boxes a day dynamically managed through TF and we have had no issues, since we bothered to figure out how to do it properly.
Terraform works well for many cases, but the fact that you had to “figure out how to do it properly” kind of proves the point—it’s not inherently designed for dynamically changing infrastructure within a single apply cycle. If it were, you wouldn’t need external coordination to handle something as simple as "create DNS records for all instances, even if the number changes at runtime."
At the end of the day, Terraform is great for declaring infrastructure, but it lacks the flexibility of programming infrastructure. If you’re happy with the trade-offs, great—but let’s not pretend those trade-offs don’t exist.
Terraform data sources can read existing infrastructure, but they don't automatically trigger new resource creation based on real-time changes. That means your DNS records won't update unless you manually run terraform apply again, and they won’t be part of a single apply cycle. In contrast, a real programming language could handle this as a continuous process, responding to infrastructure changes in real-time.
So yes, you can query instances with a data source and use for_each—but unless you’re running Terraform repeatedly to catch changes, your DNS records won’t reflect real-time scaling events. That’s the exact limitation I’m talking about: Terraform isn’t imperative, it’s declarative, and it doesn’t react dynamically at runtime without external orchestration.