6 ms·

One of the co-founders of Nitric here, and I'll bite on this one :) I hear the separation of concerns between IaC and application code argument quite a bit, bu

by tholm 3y ago

One of the co-founders of Nitric here, and I'll bite on this one :) 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-custom-provider 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).

lijok 3y ago
Application code sets infra requirements, not vice versa. If infra shapes your application, it suggests tech limitations or significant mistakes. 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.
- tholm 3y ago
  100% agree with your point on application code shaping infra, that's the standard pattern that tech like this is trying to achieve, by providing a standard by which those infrastructure requirements can be automatically understood. 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 https://nitric.io/case-studies/dropbio but I don't think this hits the mark for what you're after.
tekla 3y ago
> increase cohesion between an application and its running infrastructure > 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.
- tholm 3y ago
  Disagree on the contradiction but want your take on where you see it. 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.

by tholm 3y ago

lijok 3y ago

Application code sets infra requirements, not vice versa. If infra shapes your application, it suggests tech limitations or significant mistakes. 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.

tholm 3y ago
100% agree with your point on application code shaping infra, that's the standard pattern that tech like this is trying to achieve, by providing a standard by which those infrastructure requirements can be automatically understood. 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 https://nitric.io/case-studies/dropbio but I don't think this hits the mark for what you're after.

tekla 3y ago

> increase cohesion between an application and its running infrastructure > 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.

tholm 3y ago
Disagree on the contradiction but want your take on where you see it. 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.