4 ms·

> The point here is that while Terraform and similiar technologies have existed for the past decade, providing Ops and Infrastructure teams with the tools they

by 3np 2y ago

> The point here is that while Terraform and similiar technologies have existed for the past decade, providing Ops and Infrastructure teams with the tools they need to cleanly document their infrastructure, application development teams have had access to no such tools in this time. ...Don't they have access to the same tools, though? And if they don't, it sounds more like an internal policy issue or operational inefficiency of whatever org they're in? Terraform is Terraform for developers. Besides, I believe the promoted approach is fundamentally misguided. Application code has no business getting involved in the infrastructure it's running on. They layers of abstraction should be separated. It's fine if your team manages their own Dockerfiles, k8s schemas, helm charts, terraform/CF templates or whathaveyou. Cohost them in the same git repo even, if you must. Use all the platform-specific APIs and integrations you want. The application itself should be competetely agnostic to all of that, though, and has no business interacting with any of those APIs. You use common interfaces like environment variables, filesystem, and CLI flags to communicate between upper and lower layers. You do not have your services go and read k8s secrets over API, interact with the container runtime, or make direct API calls to ECS[0], for example. You keep those layers abstracted away from application code. That has nothing to do with the "who". On a language level, there are _very_ good reasons to prefer a declarative DSL over any turing-complete general-purpose language. Not saying you should use HCL specifically but scripting your infrastructure provisioning in JS doesn't seem like a step forward compared to ye olde bash scripts... [0]: I'm sure you have a valid counter-example. The point still stands in general.

jcusch 2y ago
The application is agnostic to that with nitric, more so than usual. It could be worth reading the docs on how it works, I don't think you got it.
- 3np 2y ago
  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. What am I missing? [0]: Props on great examples repos, fwiw: https://github.com/nitrictech/examples https://github.com/nitrictech/examples https://github.com/tjholm/multiboy https://github.com/tjholm/multiboy [1]: https://nitric.io/docs/concepts/introduction https://nitric.io/docs/concepts/introduction
  - jcusch 2y ago
    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. What other designs/tools do you recommend?

by 3np 2y ago

jcusch 2y ago

The application is agnostic to that with nitric, more so than usual. It could be worth reading the docs on how it works, I don't think you got it.

3np 2y ago
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. What am I missing? [0]: Props on great examples repos, fwiw: https://github.com/nitrictech/examples https://github.com/nitrictech/examples https://github.com/tjholm/multiboy https://github.com/tjholm/multiboy [1]: https://nitric.io/docs/concepts/introduction https://nitric.io/docs/concepts/introduction
- jcusch 2y ago
  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. What other designs/tools do you recommend?