3 ms·

Agreed. IaC has become another gated bottleneck; rather than waiting on an admin to change a server, we wait on an admin to write and test the IaC to change a s

Agreed. IaC has become another gated bottleneck; rather than waiting on an admin to change a server, we wait on an admin to write and test the IaC to change a server. One reason it's this way is poor design of cloud tech. Cloud tech isn't immutable, idempotent, and versioned, most of the time. Often there's arbitrary limitations and conventions that are not obvious which cause changes to break unexpectedly ("we don't know the result until apply" seems to happen every single apply, and success in dev is no guarantee of success in prod). And there are very few turn-key solutions, so we're left to keep rebuilding the same things and running into the same problems. We need people creating SaaS/PaaS/IaaS to create systems that give us what we really want, without having to hire somebody to write really crap fake code to work around what those systems lack. We need GUIs that allow anyone to safely make changes without being an expert. We need turn-key solutions. We need advanced best practice deployment methods to be the first option, not implemented 5 years down the road. We need security to be easy. We need multitenancy to be the default. We need simple billing limits. ..... Ok a lot of that has nothing to do with IaC. But it's clear to me that a lot of what we do do today is an unfortunate side effect of how these systems were designed, and what they still lack. Somebody built a railroad, and we're still trying to force the railroads work like real roads.

falcolas 5y ago
> 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).

falcolas 5y ago

> 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).