Terraform should have remained stateless
bejarano.io
Terraform should have remained stateless
1–10 of 329 posts
Re: Terraform should have remained stateless
#2Thank you OP for answering a question I’ve been long curious about but never bothered to look into, and sharing here.
I love/hate Terraform. It’s better than any other tool I’ve used for what it does, but the abundance of subtly leaky abstractions is tedious. And then when you mess up your state occasionally, yea that’s super annoying too.
Re: Terraform should have remained stateless
#3Completely agree. Thanks for writing this up. Specifically because I've always thought this, but also don't value my opinion on the topic. I was first exposed to devops a few years ago, and as a result was learning docker, k8s, terraform, salt, &c. at the same time. (I hated it, and now I'm happy writing C++ again)
What I could never wrap my head around was why the heck the tools had to expose so much complexity. I want the description of my infrastructure to be a single, or set of text files, written preferably in JSON or YAML like everything else, and I want to run a command that behaves in the same way as GNU make.
Re: Terraform should have remained stateless
#4When was Terraform stateless? I've been using it since 2015 and it has had state files since then. Must have been a very brief period!
Re: Terraform should have remained stateless
#5You 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.
Re: Terraform should have remained stateless
#6You 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.
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.
Re: Terraform should have remained stateless
#7Completely agree. Thanks for writing this up. Specifically because I've always thought this, but also don't value my opinion on the topic. I was first exposed to devops a few years ago, and as a result was learning docker, k8s, terraform, salt, &c. at the same time. (I hated it, and now I'm happy writing C++ again) What I could never wrap my head around was why the heck the tools had to expose so much complexity. I w…
>... want the description of my infrastructure to be a single, or set of text files, written preferably in JSON or YAML
That's CloudFormation, there is a reason that people migrated away from it.
Re: Terraform should have remained stateless
#8State or Idempotency. Pick one.
If you want stateless, then you can use Ansible and use their providers. Enjoy spawning new instances everytime you change your infrastructure, rather than having existing ones change.
Re: Terraform should have remained stateless
#9Completely agree. Thanks for writing this up. Specifically because I've always thought this, but also don't value my opinion on the topic. I was first exposed to devops a few years ago, and as a result was learning docker, k8s, terraform, salt, &c. at the same time. (I hated it, and now I'm happy writing C++ again) What I could never wrap my head around was why the heck the tools had to expose so much complexity. I w…
Have you tried Pulumi? You can use TypeScript, Python, C#, Go, Java, YAML etc to define your infrastructure.
Almost all Terraform providers are ported to Pulumi or have Pulumi-native alternatives.
Re: Terraform should have remained stateless
#10You 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.
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.
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.