4 ms·

My opinion is that these tools for most companies are the perfect footguns. How much time a developer will think about the right instance size, fine tuned IAM

by aduwah 2y ago

My opinion is that these tools for most companies are the perfect footguns. How much time a developer will think about the right instance size, fine tuned IAM permissions, naming conventions or tags? I would wager a substantial amount that most will just copy-paste and get done with it, which eventually leads to the creation of a devops/sre/platform team to do the refactor and cleanup and we are back to step one.

zukzuk 2y ago
Okay but what's the alternative? Seems like the real problem is not the tool, but the thing the tool operates on.
- orisho 2y ago
  The alternative is making it possible for developers to only think about code, not permissions, or at least specify the permissions in terms of what you want to do, not what permissions you need. Think iOS, you write "I need fine grained location access" into the manifest, you don't configure the permission system to allow you to call the API. Another poster touched on another important point: it's important for this to be changeable independent of the code. The reason for this is actually kind of subtle. Obviously, you don't wanna have to need to rebuild in order to regenerate permissions. But the real reason, imo, is that it should be easy to parse for a human, easy to locate for a human, and also easy to parse and adjust for a machine, that might determine a permission is no longer necessary, or who is trying to build a dependency graph in order to determine who to wake up during an incident. That means it should go into configuration that is versioned and deployed alongside the code, but not in the code. If you make this hard to understand and change, people will just copy it, and the you're back to square one. It's gotta be the easiest thing to do the right thing, because at scale, people are gonna do the easiest thing. I feel like I'm kinda going on at length about this, so instead I'm gonna leave you with a link to a blog I wrote about the same concepts, if you wanna read more. It's about Kubernetes network policies, but really the same concepts apply to all kinds of access. https://otterize.com/blog/network-policies-are-not-the-right-abstraction https://otterize.com/blog/network-policies-are-not-the-right...
  - jcusch 2y ago
    How you're describing iOS is similar to how nitric works. Developers indicate in code "I'm reading from this bucket", it's a request not an order, they're not actually configuring the permissions system. That request is collected into a graph of other requests (for resources, permissions, etc.) and passed via an API to a provider to fulfill. If you want to change what "read" means you're free to do that in the provider without changing a single line of application code. But you also get the benefit on the Ops side of not needing to read the application code to try and figure out what permissions it needs to work, that part it generated so you can't miss anything. If you want to output Terraform or config files or something else like you do today, to enable audits and keep it alongside the code, you can do that easily.
jcusch 2y ago
That's actually something nitric helps with, it provides an API for deployments, separating it from application code. Those other teams like devops/sre/etc. are free to customize that process how they see fit. They can enforce naming standards, tagging, sizing, etc. all through automation.
- cryptonector 2y ago
  It'd better make it possible to change permissions apart from the code.
  - tholm 2y ago
    Interesting take, what would be the benefit here? If the application code writes to a resource and you change the permissions externally without updating the code you've essentially broken the application.
- stackskipton 2y ago
  Ops type person here. We have these tools now, Terraform and cloud specific tools (Bicep/CloudFormation). What devs tend to miss is benefit to this approach puts up guardrails against common dev mistakes. Stuff like Nitric and Pulumi can end up with some really nasty deployment because there is multiple nesting, dead ends and other things that result in difficult to debug infrastructure deployment. Also JS unfortunately is not a common language for us DevOps types. We lean towards Python and Go because they are most useful for our line of work.
  - jcusch 2y ago
    Nitric is a layer on top of Pulumi/Terraform. It also supports Python, Go and Dart. Other language support is also possible. The Ops side of nitric (the providers) can be written in any language, but the out of the box providers are all built with Go, interacting with Pulumi or CDK for Terraform. You can just as easily write the deployment part of nitric with Terraform HCL to avoid the nasty issues you mentioned.
klysm 2y ago
It’s step one except now you actually have a record of what’s deployed

by aduwah 2y ago

zukzuk 2y ago

Okay but what's the alternative? Seems like the real problem is not the tool, but the thing the tool operates on.

orisho 2y ago
The alternative is making it possible for developers to only think about code, not permissions, or at least specify the permissions in terms of what you want to do, not what permissions you need. Think iOS, you write "I need fine grained location access" into the manifest, you don't configure the permission system to allow you to call the API. Another poster touched on another important point: it's important for this to be changeable independent of the code. The reason for this is actually kind of subtle. Obviously, you don't wanna have to need to rebuild in order to regenerate permissions. But the real reason, imo, is that it should be easy to parse for a human, easy to locate for a human, and also easy to parse and adjust for a machine, that might determine a permission is no longer necessary, or who is trying to build a dependency graph in order to determine who to wake up during an incident. That means it should go into configuration that is versioned and deployed alongside the code, but not in the code. If you make this hard to understand and change, people will just copy it, and the you're back to square one. It's gotta be the easiest thing to do the right thing, because at scale, people are gonna do the easiest thing. I feel like I'm kinda going on at length about this, so instead I'm gonna leave you with a link to a blog I wrote about the same concepts, if you wanna read more. It's about Kubernetes network policies, but really the same concepts apply to all kinds of access. https://otterize.com/blog/network-policies-are-not-the-right-abstraction https://otterize.com/blog/network-policies-are-not-the-right...
- jcusch 2y ago
  How you're describing iOS is similar to how nitric works. Developers indicate in code "I'm reading from this bucket", it's a request not an order, they're not actually configuring the permissions system. That request is collected into a graph of other requests (for resources, permissions, etc.) and passed via an API to a provider to fulfill. If you want to change what "read" means you're free to do that in the provider without changing a single line of application code. But you also get the benefit on the Ops side of not needing to read the application code to try and figure out what permissions it needs to work, that part it generated so you can't miss anything. If you want to output Terraform or config files or something else like you do today, to enable audits and keep it alongside the code, you can do that easily.

jcusch 2y ago

That's actually something nitric helps with, it provides an API for deployments, separating it from application code. Those other teams like devops/sre/etc. are free to customize that process how they see fit. They can enforce naming standards, tagging, sizing, etc. all through automation.

cryptonector 2y ago
It'd better make it possible to change permissions apart from the code.
- tholm 2y ago
  Interesting take, what would be the benefit here? If the application code writes to a resource and you change the permissions externally without updating the code you've essentially broken the application.
stackskipton 2y ago
Ops type person here. We have these tools now, Terraform and cloud specific tools (Bicep/CloudFormation). What devs tend to miss is benefit to this approach puts up guardrails against common dev mistakes. Stuff like Nitric and Pulumi can end up with some really nasty deployment because there is multiple nesting, dead ends and other things that result in difficult to debug infrastructure deployment. Also JS unfortunately is not a common language for us DevOps types. We lean towards Python and Go because they are most useful for our line of work.
- jcusch 2y ago
  Nitric is a layer on top of Pulumi/Terraform. It also supports Python, Go and Dart. Other language support is also possible. The Ops side of nitric (the providers) can be written in any language, but the out of the box providers are all built with Go, interacting with Pulumi or CDK for Terraform. You can just as easily write the deployment part of nitric with Terraform HCL to avoid the nasty issues you mentioned.

klysm 2y ago

It’s step one except now you actually have a record of what’s deployed