4 ms·
That's still storing state, except instead of keeping it within a single file which you have full control over, you're instead sprinkling that state all over yo
by enobrev 4y ago
That's still storing state, except instead of keeping it within a single file which you have full control over, you're instead sprinkling that state all over your infrastructure and then hoping it doesn't get mangled in between invocations.
And also hoping that service's API has all the tools needed to find your scattered state within a reasonable amount of time in order to diff any changes you make in your declarations
- mountainriver 4y agoYeah 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
- ImPostingOnHN 4y agoyeah, but then you DO have to worry about scanning every single resource you control, every time you plan and run
- hellcow 4y agoI 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.
- mountainriver 4y agoThat does not seem problematic with modern APIs and concurrency. Two sources of truth is highly problematic
- rad_gruchalski 4y agoBut it is problematic when you deal with larger infrastructures due to rate limits.
- mountainriver 4y agoI can’t imagine you would ever hit a rate limit, how often are you deploying large sums of infrastructure? For me it’s maybe a couple times a day and the surface area is small
- tedivm 4y agoAWS API Rate limits are very surprising. I've hit them on new accounts when trying to deploy terraform based code, and that's without having to literally scan the entire account. If I have 3k machines running in an autoscaling group I think it would be ridiculous to have to hit each one of those with API calls to try and infer which were or weren't part of my state. Building a simple high availability VPC is about 72 resources just by itself. I don't think people advocating for "the cloud is the state" realize how big even trivial environments can get- let alone complex ones.
- mountainriver 4y agoHuh I've never hit rate limiting on GET with AWS, could just be my luck. This also might not be the answer for every problem, but could be nice for some
- rad_gruchalski 4y ago“I have never” doesn’t equal “it doesn’t happen”.
- pharmakom 4y agoYou do because the metadata on the resource might get changed.