3 ms·

> we wait on an admin to write and test the IaC to change a server This is more about company culture, not IAC. I write IAC, not a sysadmin. They don't even te

> we wait on an admin to write and test the IaC to change a server 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).

throwaway787544 5y ago
You can make mistakes in IAC just like in the GUI. If the difference is having a plan stage (which, again, quite often you still don't know what the change is because it can't be known until apply), the GUI could offer a plan stage too. One of the things Terraform should have had from day 1 was automatic import of all existing cloud resources and generation of hcl. That would allow creation of infra in a GUI and then locking it down into a version controlled declarative configuration. Terraformer (written by a Google team) does exactly this, though it's rudimentary and lacks a lot. I still use it to quickly capture the state of legacy accounts and make changes later. Amazon should have had this for all its services by default, because it would prevent the need to manually craft code. GUIs exist to prevent people from having to slowly craft code by hand. I think people today still forget the entire purpose of GUIs because there's this cargo cult that says the only way to do anything good is to manually write lines of code. Personally I'd be happy if I never wrote another line of code in my life, if the GUI would just version the configuration. And even better, if the state were immutable and versioned and didn't need to be constantly "fixed" by a configuration management tool (Terraform).

throwaway787544 5y ago

You can make mistakes in IAC just like in the GUI. If the difference is having a plan stage (which, again, quite often you still don't know what the change is because it can't be known until apply), the GUI could offer a plan stage too. One of the things Terraform should have had from day 1 was automatic import of all existing cloud resources and generation of hcl. That would allow creation of infra in a GUI and then locking it down into a version controlled declarative configuration. Terraformer (written by a Google team) does exactly this, though it's rudimentary and lacks a lot. I still use it to quickly capture the state of legacy accounts and make changes later. Amazon should have had this for all its services by default, because it would prevent the need to manually craft code. GUIs exist to prevent people from having to slowly craft code by hand. I think people today still forget the entire purpose of GUIs because there's this cargo cult that says the only way to do anything good is to manually write lines of code. Personally I'd be happy if I never wrote another line of code in my life, if the GUI would just version the configuration. And even better, if the state were immutable and versioned and didn't need to be constantly "fixed" by a configuration management tool (Terraform).