18 ms·
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
by hellcow 4y ago
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.
- enobrev 4y agoI'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?
- hellcow 4y agoIt’s small, under 50 servers running OpenBSD and Linux under a wide variety of configurations (including gpu), 6 databases, and Redis. Though the system is easily extensible to other clouds and resource types, it only needs to work on GCP right now. Been running it in prod for the past 3 or 4 years—no outages, no downtime, no surprises. Doubled infra over the holidays then scaled everything back with no issue. The stateless approach has worked really well for us.
- shyn3 4y agoThis is the reason we didn't get Terraform. In a windows shop the state is never the same because most people will fix it via the UI and then the state file becomes useless
- ImPostingOnHN 4y agosounds like a totally reasonable decision
- bradknowles 4y agoAt small sizes, this probably works reasonably well. However, as you scale, the performance will get worse and worse, and you run the risk of hitting rate limits and/or missing stuff. So, fine for you in your personal small environment, but maybe not something suitable for Terraform in general.