4 ms·

As someone starting with terraform literally this weekend, why did you move away?

SirensOfTitan 5y ago
Asking my engineers to learn a completely new DSL (HCL) with its own quirks to change infrastructure felt like it ran against the spirit of IaC. If they were tweaking infrastructure every day, that’d be one thing, but it’s fairly hard to commit a language to your long term memory when you’re interacting with it only on occasion.
- soco 5y ago
  You can do Terraform in Java. Or Python. Or... https://www.terraform.io/cdktf https://www.terraform.io/cdktf
  - p_l 5y ago
    CDK is reasonably new thing for terraform. A lot of us have cut our teeth on previous major version of terraform DSL, when it was even less capable than it is now (no maps, no for each, etc.) and it wasn't that uncommon to be told to generate terraform JSON directly to work around DSL shortcomings, generating essentially all of the provider objects yourself.
- nijave 5y ago
  If you have common changes like adding a new queue or storage bucket, you can pull the details out into yaml or json and have Terraform loop over them. As a (potentially) added bonus, you can have different Terraform projects point to the same yaml--used to do this for maintaining subnets
jgeurts 5y ago
Terraform as a language is a bit clunky and feels not quite complete. For example, to accomplish if/else logic, you have to hack something like: `count = var.is_foo ? 1 : 0` More than the language syntax, getting any response from the hashicorp team on their official providers is like rolling the dice. If your bug or feature pr is a bit on the fringes and not in their sights, it can sit for months/years without traction or even a non-automated response. With just the aws provider, there are over 3000 issues and nearly 400 open PRs. That team is understaffed or mismanaged. It has gotten marginally better over the last year or so, but generally speaking, Hashicorp doesn’t seem to care while they’re pouring all efforts into their own cloud. 1. https://github.com/hashicorp/terraform-provider-aws/issues/19583 https://github.com/hashicorp/terraform-provider-aws/issues/1... 2. https://github.com/hashicorp/terraform-provider-aws/issues/660 https://github.com/hashicorp/terraform-provider-aws/issues/6... 3. https://github.com/hashicorp/terraform-provider-aws/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc https://github.com/hashicorp/terraform-provider-aws/issues?q...
politician 5y ago
Terraform is amazing and is also very thin. It’s amazing to be able to commit your infrastructure to source control, but it’s nothing without effective well-maintained APIs that can be driven by Terraform providers. I’ve built custom Terraform providers to map to custom APIs, and the experience was just fantastic. I’ve also used scripts with AWS resources that were a chore to use because the underlying API was a trash fire. Specifically with respect to Terraform the language, the uniform adoption of functional programming concepts would be nice— right now providers expose varying ways of dealing with sets of resources in more or less confusing and incompatible ways (count, and the various times that you cannot use count). So the problems with TF are twofold: the language is not quite consistent, and the ecosystem depends entirely on the quality of contributed providers and/or the module shims built on top of poor providers. It can be easy to get frustrated during IaC development, but an absolute relief when you can rock deployments confidently.

Asking my engineers to learn a completely new DSL (HCL) with its own quirks to change infrastructure felt like it ran against the spirit of IaC. If they were tweaking infrastructure every day, that’d be one thing, but it’s fairly hard to commit a language to your long term memory when you’re interacting with it only on occasion.

soco 5y ago
You can do Terraform in Java. Or Python. Or... https://www.terraform.io/cdktf https://www.terraform.io/cdktf
- p_l 5y ago
  CDK is reasonably new thing for terraform. A lot of us have cut our teeth on previous major version of terraform DSL, when it was even less capable than it is now (no maps, no for each, etc.) and it wasn't that uncommon to be told to generate terraform JSON directly to work around DSL shortcomings, generating essentially all of the provider objects yourself.
nijave 5y ago
If you have common changes like adding a new queue or storage bucket, you can pull the details out into yaml or json and have Terraform loop over them. As a (potentially) added bonus, you can have different Terraform projects point to the same yaml--used to do this for maintaining subnets

jgeurts 5y ago

Terraform as a language is a bit clunky and feels not quite complete. For example, to accomplish if/else logic, you have to hack something like: `count = var.is_foo ? 1 : 0` More than the language syntax, getting any response from the hashicorp team on their official providers is like rolling the dice. If your bug or feature pr is a bit on the fringes and not in their sights, it can sit for months/years without traction or even a non-automated response. With just the aws provider, there are over 3000 issues and nearly 400 open PRs. That team is understaffed or mismanaged. It has gotten marginally better over the last year or so, but generally speaking, Hashicorp doesn’t seem to care while they’re pouring all efforts into their own cloud. 1. https://github.com/hashicorp/terraform-provider-aws/issues/19583 https://github.com/hashicorp/terraform-provider-aws/issues/1... 2. https://github.com/hashicorp/terraform-provider-aws/issues/660 https://github.com/hashicorp/terraform-provider-aws/issues/6... 3. https://github.com/hashicorp/terraform-provider-aws/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc https://github.com/hashicorp/terraform-provider-aws/issues?q...

politician 5y ago

Terraform is amazing and is also very thin. It’s amazing to be able to commit your infrastructure to source control, but it’s nothing without effective well-maintained APIs that can be driven by Terraform providers. I’ve built custom Terraform providers to map to custom APIs, and the experience was just fantastic. I’ve also used scripts with AWS resources that were a chore to use because the underlying API was a trash fire. Specifically with respect to Terraform the language, the uniform adoption of functional programming concepts would be nice— right now providers expose varying ways of dealing with sets of resources in more or less confusing and incompatible ways (count, and the various times that you cannot use count). So the problems with TF are twofold: the language is not quite consistent, and the ecosystem depends entirely on the quality of contributed providers and/or the module shims built on top of poor providers. It can be easy to get frustrated during IaC development, but an absolute relief when you can rock deployments confidently.