This is more about company culture, not IAC. I write IAC, not a sysadmin. They don't even test it, that's what our test environment is for. There's a few things they don't let us touch, and a few enforced best practices but those are handled in code, and I can incorporate those checks as part of my usual unit test cycle.
> And there are very few turn-key solutions, so we're left to keep rebuilding the same things and running into the same problems.
That's what IAC can do for us. IAC is, at it's heart, providing a desired state, which Terraform (ansible, etc) checks to see if the environment state matches what I requested, and if the answer is no, changes it to match the provided state.
If I was writing code to do this myself, it would do the exact same thing.
> We need GUIs that allow anyone to safely make changes without being an expert.
Amazon has a GUI that, for most operations, is perfectly acceptable. And I'd still rather use IAC than make changes via a GUI in production. And the reason is simple: I'll make mistakes. I'll forget or fat-finger one of dozens of required options for setting up a secure S3 bucket.
If everyone uses IAC against production, then it will work most of the time (the exceptions that I've run up against are very rare).
