[HN Gopher] Using Actual Code for IaC
___________________________________________________________________
Using Actual Code for IaC
Author : tholm
Score : 13 points
Date : 2022-04-27 05:22 UTC (2 days ago)
(HTM) web link (nitric.io)
(TXT) w3m dump (nitric.io)
| antihero wrote:
| Hasn't Amazon been doing this with the CDK for a while? I really
| enjoy it!
| coredog64 wrote:
| 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.
| rk2 wrote:
| Agree and also have to consider that there is a need for
| solutions for cloud providers other than amazon.
| disposedtrolley wrote:
| Have a look at CDKTF [1]. It's a wrapper around Terraform
| that lets you use CDK-style semantics that compiles down to
| a Terraform plan. Every Terraform provider can generated
| into a CDKTF library.
|
| [1] https://learn.hashicorp.com/tutorials/terraform/cdktf
| arccy wrote:
| this works for them because there's a close mapping between the
| code and the infra it needs. For the more general case of IaC, it
| usually benefits greatly to being closer to data rather than
| code, allowing a wider range of tools to work with/process it
| over long term maintenance.
| naserbvqtery wrote:
| Unpopular 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.
| octopoc wrote:
| > 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.
| naserbvqtery wrote:
| 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.
| lucideer wrote:
| 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.
| freedomben wrote:
| 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."
| naserbvqtery wrote:
| > 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.
| Arnavion wrote:
| 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...
___________________________________________________________________
(page generated 2022-04-29 23:02 UTC)