3 ms·

You can use terraform in a "stateless" manner! Define everything in like cdk (... I use ruby to generate the tf.json), generate the code, import everything you

You can use terraform in a "stateless" manner! Define everything in like cdk (... I use ruby to generate the tf.json), generate the code, import everything you can without error, and apply the rest. Performance will be _bad_ but that will completely eliminate state problems.

infogulch 4y ago
I think the reason why terraform did this is that if you have a medium-large deployment that you plan/run often you'll probably run face first into cloud management api limits, it's not just bad performance.
- ericbarrett 4y ago
  You're absolutely right. I started using Terraform around 2016 and it was pretty common to get barked at by the AWS API if you were repeatedly running plans, even with state. I bet the cloud providers have had to make significant infra changes to support the growing number of customers using TF.
  - scarface74 4y ago
    There are still plenty of services in AWS that have painfully low service limits for API calls. The first one that bit me was creating parameters in SSM Parameter Store using CloudFormation. CF tries to create as many resources in parallel as possible based on the dependency graph it creates. The only way around it was making each Parameter resource dependent on the other (using DependsOn) to force the resources to be created sequentially. Before the CF vs TF holy wars began, this is an API limitation that you would hit regardless of your IAC.
cmclaughlin 4y ago
cdktf doesn’t really help with state problems in my opinion. Under the hood terraform is still storing state and if you’re working on a team you’ll need to share state, e.g to s3. If you don’t have any state and try to make a change, terraform will try to recreate and fail. Importing is a pain. cdktf is great, but I would also rather do away with the state. I’ve gotten into too many problems that were only resolved by deleting everything and starting over.
- chucky_z 4y ago
  Oh I mean using the synth stage to write ephemeral code to disk to be applied against “to be imported state.” Disclaimer: this is a terrible idea if you aren’t using state. I use this today to keep very “wide” modules synced

infogulch 4y ago

I think the reason why terraform did this is that if you have a medium-large deployment that you plan/run often you'll probably run face first into cloud management api limits, it's not just bad performance.

ericbarrett 4y ago
You're absolutely right. I started using Terraform around 2016 and it was pretty common to get barked at by the AWS API if you were repeatedly running plans, even with state. I bet the cloud providers have had to make significant infra changes to support the growing number of customers using TF.
- scarface74 4y ago
  There are still plenty of services in AWS that have painfully low service limits for API calls. The first one that bit me was creating parameters in SSM Parameter Store using CloudFormation. CF tries to create as many resources in parallel as possible based on the dependency graph it creates. The only way around it was making each Parameter resource dependent on the other (using DependsOn) to force the resources to be created sequentially. Before the CF vs TF holy wars began, this is an API limitation that you would hit regardless of your IAC.

cmclaughlin 4y ago

cdktf doesn’t really help with state problems in my opinion. Under the hood terraform is still storing state and if you’re working on a team you’ll need to share state, e.g to s3. If you don’t have any state and try to make a change, terraform will try to recreate and fail. Importing is a pain. cdktf is great, but I would also rather do away with the state. I’ve gotten into too many problems that were only resolved by deleting everything and starting over.

chucky_z 4y ago
Oh I mean using the synth stage to write ephemeral code to disk to be applied against “to be imported state.” Disclaimer: this is a terrible idea if you aren’t using state. I use this today to keep very “wide” modules synced