11–16 of 16 posts
Hasn’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.
Earlier quoted context omitted.
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.
Agree and also have to consider that there is a need for solutions for cloud providers other than amazon.
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,…
I think declarative should be the default, where practical, for pretty much anything.
If you can't do it in declarative, it's often not a good idea anyway, or the declarative engine just needs an extension.
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.
In the case of nitric we take the requirements given by an application and use a deployment engine we've written using Pulumi to deploy it.
There is potential here to allow hooking into custom deployment engines and internal platform implementations to help standardise the way application developers integrate with cloud resources while still giving platform engineers the control they need.
Earlier 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…
I think those days of magic-HCL-generators are more-or-less behind us.
All we need now is variables in backend config and delayed provider initialisation and we’re laughing !