Using Actual Code for IaC
nitric.io
Using Actual Code for IaC
1–10 of 16 posts
Re: Using Actual Code for IaC
#2Unpopular Opinion:
IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall.
I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible, terraform) to tooling that allowed more free-form code to leak in (chef, cdk, unholy in-house nonsense), and every time I've watched the infrastructure description go from something that could easily be tested and reasoned about to an awful mess nobody wants to touch for fear of breakage.
Re: Using Actual Code for IaC
#3Unpopular Opinion: IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall. I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible,…
Counter Opinion:
Well-meaning DSL constraints very quickly evolve into hackish defacto "actual code". Every. Time.
I do understand the intent of a constrained DSL mapping to constraints of underlying resources, but more often than not those constraints are short-lived in the lifespan of the DSL, and quickly give way to it becoming a badly architected near-turing-complete programming language.
Ansible (which you've listed) is a prime example: it's not YAML, it's a frankenstein of YAML + logic-heavy Jinja-hacks that really remove a lot of the constraints of pure declarative YAML. The only thing holding it back from becoming a horrible logic mess is very deliberate and well-marketed community convention.
Re: Using Actual Code for IaC
#4Unpopular Opinion: IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall. I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible,…
Counter Opinion: Well-meaning DSL constraints very quickly evolve into hackish defacto "actual code". Every. Time. I do understand the intent of a constrained DSL mapping to constraints of underlying resources, but more often than not those constraints are short-lived in the lifespan of the DSL, and quickly give way to it becoming a badly architected near-turing-complete programming language. Ansible (which you've li…
Exactly. I've used Terraform, Ansible, Chef, and a couple of hybrids extensively and my current opinion is that for simple use cases a strict DSL is great, but as soon as you need to something higher (usually some sort of looping over a complex data structure and populating fields from those values) it gets real painful.
Terraform is getting better at the loops and stuff but I still have a bunch of code from older versions of terraform that are erb templates that output terraform files, thus allowing to use Ruby functions. That was/is probably the least evil solution I've seen. The worst is when the infrastructure or devops team (or someone else) decides, "we need to abstract this away with our own tool."
Re: Using Actual Code for IaC
#5Unpopular Opinion: IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall. I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible,…
> every time I've watched the infrastructure description go from something that could easily be tested and reasoned about to an awful mess nobody wants to touch for fear of breakage
We programmers have been dealing with this kind of complexity for a long time, why not use some of the tools normally used to manage complexity in code? For example:
1. Comments
2. Code reviews
3. Gated merge requests
etc. etc.
Re: Using Actual Code for IaC
#6Unpopular Opinion: IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall. I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible,…
Counter Opinion: Well-meaning DSL constraints very quickly evolve into hackish defacto "actual code". Every. Time. I do understand the intent of a constrained DSL mapping to constraints of underlying resources, but more often than not those constraints are short-lived in the lifespan of the DSL, and quickly give way to it becoming a badly architected near-turing-complete programming language. Ansible (which you've li…
Yes, from personal experience, it starts with a DSL. Then someone notices it has a lot of boilerplate / repetition and writes a shell script to generate the DSL. Then people complain that remembering the shell script parameters is hard so someone writes a DSL as input for the shell script. Then...
Re: Using Actual Code for IaC
#7Earlier quoted context omitted.
Counter Opinion: Well-meaning DSL constraints very quickly evolve into hackish defacto "actual code". Every. Time. I do understand the intent of a constrained DSL mapping to constraints of underlying resources, but more often than not those constraints are short-lived in the lifespan of the DSL, and quickly give way to it becoming a badly architected near-turing-complete programming language. Ansible (which you've li…
Exactly. I've used Terraform, Ansible, Chef, and a couple of hybrids extensively and my current opinion is that for simple use cases a strict DSL is great, but as soon as you need to something higher (usually some sort of looping over a complex data structure and populating fields from those values) it gets real painful. Terraform is getting better at the loops and stuff but I still have a bunch of code from older ve…
> as soon as you need to something higher (usually some sort of looping over a complex data structure and populating fields from those values) it gets real painful
I'd argue this is one such guardrail. Way more than once I've seen infrastructure resources exhausted (frequently cloud provider limits), because a hard line wasn't maintained between infrastructure code and application code. Frequently in the form of "It just makes sense for us to create one %s infrastructure resource for each %s in our application!" followed by a series of midnight conference calls weeks-months later.
Re: Using Actual Code for IaC
#8Unpopular Opinion: IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall. I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible,…
> every time I've watched the infrastructure description go from something that could easily be tested and reasoned about to an awful mess nobody wants to touch for fear of breakage We programmers have been dealing with this kind of complexity for a long time, why not use some of the tools normally used to manage complexity in code? For example: 1. Comments 2. Code reviews 3. Gated merge requests etc. etc.
Those things should all still be used with a dsl iac. They're not bringing anything new to the table in the argument of dsl vs general programming language for infrastructure.
Arguably this comment even demonstrates a bit of what I consider one of the biggest problems in the space. It's common for someone who hasn't bought in to dsl based iac tooling to imply dsl based tooling is from a less sophisticated place where modern engineering practices aren't applied, and it's better to grow up and use big-boy tools.
It's almost like they've forgotten the dsl based tooling was in fact built by other application developers with intense subject matter expertise in the space.
Re: Using Actual Code for IaC
#9Hasn’t Amazon been doing this with the CDK for a while? I really enjoy it!
Re: Using Actual Code for IaC
#10Hasn’t Amazon been doing this with the CDK for a while? I really enjoy it!
I think the difference is that CDK “compiles” down to CloudFormation. Whatever you do it still has to be valid compared to a random application that can do whatever whenever. OFC I’m ignoring the way CDK makes it easier to use (and sometimes encourages) custom providers backed by Lambdas.