Separation of concerns thrown out the window. Nobody show this to Bob Martin.
I hear the separation of concerns between IaC and application code argument quite a bit, but always see an inherent coupling between the two. If changes to your IaC require changes to your application code for your application to continue working then where is the separation of concerns? If its just deployment and runtime, this separation still exists within Nitric: https://nitric.io/docs/reference/providers/custom/building-c... (this is the same way we build our own deployment providers).
With Nitric the primary goal is to increase cohesion between an application and its running infrastructure without increasing coupling to that infrastructure. With current IaC application and infrastructure cohesion is inherently very low, while giving the appearance of low coupling (despite it being quite high).
And I'm sorry, but without some concrete drawings you can't just claim current IAC creates low cohesion and strong coupling without making people suspect you don't know what those terms mean.
What would be very useful is an article covering the points of how testing works with Nitric, exactly how it saves you time and why the cost/benefit analysis of adopting Nitric makes sense.
Fair point on the second, can I ask what you specifically mean by concrete drawings? I'd really like to understand your perspective on separation of concerns between IaC and application code better.
Thanks for content takeaway as well I really appreciate the feedback. The closest thing we have right now is a published customer use-case: https://nitric.io/case-studies/dropbio but I don't think this hits the mark for what you're after.
> without increasing coupling to that infrastructure
These are contradictory. I don't know what people are doing to fuck up their TF so much, but I've never seen an issue where TF and application code were coupled in a way that wasn't trivially solvable.
Of course, that depends on people not being really dumb.
I don't know what your experience is but "never" having seen any issues could also be bad thing, seeing the "don't" is just as valuable as the "do" when it comes to building experience.
Some concrete examples to demonstrate where coupling is trivially solvable would be good if you have some that you can share, where it wouldn't be trivially solvable what are the common mistakes that would be made in those cases?
If you have time to share your experience I'd really appreciate it.