(no title)
jcusch | 1 year ago
- 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.
What other designs/tools do you recommend?
No comments yet.