Live data from Hacker News

Terraform should have remained stateless

bejarano.io

261–270 of 329 posts

Re: Terraform should have remained stateless

#261

The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…

You can still store state but delegate it to a different system. One that is more robust and homogeneous like a kubernetes API. This is what crossplane does

Re: Terraform should have remained stateless

#262

Earlier quoted context omitted.

yeah, but then you DO have to worry about scanning every single resource you control, every time you plan and run

I built pretty much the system you’re describing for my company (a stateless terraform alternative) and this scan that you cite as a negative happens in… 100ms in parallel? Roughly the same amount of time it would take to download a state file? Dunno about you but ensuring state is always accurate and in-sync is well worth the trade-off to me.

I'm curious, and not antagonistically, about the size and variability of the infrastructure you're working with, on how many platforms it's running, and how many people are in charge of it.

Is this tool private or available for us to try out?

Re: Terraform should have remained stateless

#263
You couldn't do everything that Terraform does today without a local state, but perhaps that would be a good thing? Call it "Terraform strict mode".

As every application developer knows, duplication of state is a primary source of bugs. To combat this, React/Flux type of architectures became extremely popular where state flows in one direction only. They dictate that, no you can't just cheat a little and use jQuery to modify some element, it _will_ get bulldozed on the next render. And a lot of Terraform headaches do come from this analogous reconciliation of what really is (our cloud env), what we want (our TF code) and this intermediate state of what TF thinks the cloud state is.

So, by saying that you cannot have resources outside those defined by TF there is actually a massive simplification with far reaching consequences possible.

How I imagine the experience would be:

- You could say that your Dev env is a shitshow and always will be, of manually created resources and only partially TFed. But your Production and Staging envs are opted in to "strict mode". This means that if there is a conflict you do only have two options: import the offender or destroy it, and the critical mindset change is that this is a good thing and will save us a lot of tears later on.

- Caching is an orthogonal concern. Terraform mixes these two together to its detriment, but the nature of a cache is such that you can safely blow it away and perhaps the next reconciliation will be slow, but it will be accurate. I also don't believe it would actually be that slow, tools like Cloudcraft map the entire metadata of your account in seconds.

- I find the excuse that some resources don't support tags intellectually lazy. Of the top of my head thinking about it for a minute, could you tag a parent resource with the child metadata you need? E.g. individual DNS records don't have tags, OK tag the Zone with childA=value. Same thing with tag length limits, you can work around it, concatenate values or whatever. However, in a truly strict mode you wouldn't even need metadata in tags because the TF code describes the entire target environment.

I hope Terraform would entertain such a strict stateless mode. Unfortunately it will probably take another tool, because the problem is not so much technical as it is an entire mindset change.

Re: Terraform should have remained stateless

#264

Earlier quoted context omitted.

Yeah but then you don’t have to worry about the state getting out of sync which is one of the biggest problems. Also versioning is a pain

yeah, but then you DO have to worry about scanning every single resource you control, every time you plan and run

That does not seem problematic with modern APIs and concurrency. Two sources of truth is highly problematic

Re: Terraform should have remained stateless

#266
post #212

Earlier quoted context omitted.

That's not state information though, that's metadata.

If some state information is stored using metadata then we need that metadata to know the total state. The contents of TF state is more than what can be read from the provider APIs often.

Yeah but the extra stuff they add is a trade off and lots of people would rather not have two sources of truth to have it

Re: Terraform should have remained stateless

#267

The article misses a key bit of information TF needs when making a plan: 4. The previous Terraform configuration This is effectively stored by state. We need this because if a resource is removed from the new config then Terraform needs to be able to delete the existing resource from the world. If we don’t have the state then Terraform must either: 1. Not delete it from the world 2. Or risk deleting something not man…

You can still store state but delegate it to a different system. One that is more robust and homogeneous like a kubernetes API. This is what crossplane does

Terraform can use k8s as a state store. The issue is two sources of truth and everything that causes

Re: Terraform should have remained stateless

#268

Earlier quoted context omitted.

I'll play devil's advocate (because I understand the need for a state): What if terraform was able to perform a complete audit of your environment for each provider and say "this is what you've got, mate", then give you options for each resource: 1. Accept (turns it into terraform code) 2. Reject (removes the resource) Taken further, this idea effectively means that manually creating something like EKS could be a way…

That approach wouldn't work if your infrastructure is spread between multiple Terraform workspaces. (as is often done).

TF workspaces are one of the most complained about features at my company, hopefully a new tool would do something better

Re: Terraform should have remained stateless

#269
post #202
post #173

Earlier quoted context omitted.

I am starting on a journey to deploy resources in the big three cloud providers (AWS, Azure, Google) and could use your input. So far, we have been working with Ansible to provision our AWS resources. Because we find Ansible to be a pain to use, we are considering Terraform - especially when working with multiple cloud providers. Do you have any advice or best practices to properly deploy and manage instances using T…

I would suggest maybe bypassing terraform entirely and going to something like Pulumi or CDK.

Yeah and IME Pulumi is much easier to use, both are way better than half baked HCL though

Re: Terraform should have remained stateless

#270

You couldn't do everything that Terraform does today without a local state, but perhaps that would be a good thing? Call it "Terraform strict mode". As every application developer knows, duplication of state is a primary source of bugs. To combat this, React/Flux type of architectures became extremely popular where state flows in one direction only. They dictate that, no you can't just cheat a little and use jQuery t…

Yeah it wouldn’t have all the capabilities but would be a good tradeoff for lots of use cases
Post reply on HN