I did browse the docs and repos[0]. I'm saying that "IfC" as formulated here[1] is an anti-pattern and what I refer to as misguided.
> IaC tools like Pulumi, Terraform, AWS CDK, Ansible and others bring repeatability to infrastructure by giving you scripts that you can use across different environments or projects to provision infrastructure. This code/config is in addition to your application code, typically with a tight brittle coupling between the two.
If there is a tight and brittle coupling, this is not an issue stemming from either the IaC approach or any of those tools. It's an issue of poor design.
I'm curious what designs you use to avoid the issues. For example, if your code needs to access a resource (e.g. making a call to send an event to a cloudwatch event bus or SNS topic on AWS), how do you deal with things like:
- Consuming AWS client libraries (or APIs) in your application code
- Avoiding writing cloud specific mocks/etc. for testing that same code
- Avoiding env vars with resource names/ARN/etc. to use with that code, that then need to duplicated in the Terraform/other IaC without typos etc.
- The code not knowing whether it has the permissions needed to make those calls, so it's can't be guaranteed to be correct before deploying and testing in a live environment
- No longer needing that topic in future, but it lingers in the IaC because the two are unaware of each other
To me those are all examples of the application code "getting involved in the infrastructure it's running on", which I agree it has no business doing.
Nitric deals with these things by separating that code into another module that's sole responsibility is dealing with the cloud, exposed by a common interface for any cloud/environment.
