[eladbenisrael]

Elad here (the author). That's a very good point. If a developer decides to use `bucket.list().filter(x => x == myFile)` instead of `bucket.get(myFile)` the result will be fundamentally different both from a security perspective (e.g. `ListObjects` instead of `GetObject` on AWS), but also from a performance perspective (`list` is O(n) but `get` is O(1)).

If you think about this is primarily an issue of software engineering quality. The fact that today we are forcing the developer to go their devops team to request these permissions creates an organizational workflow that increases quality. That's why most of the teams I worked at requires code reviews.

I believe the right approach is to enable devops teams to put up boundaries and rules that will get enforced downstream (build => deployment => production). This will allow both developers and devops teams to be be more independent but still be in control.

Curious what people think about winglang's compiler plugin system as a way to help streamline these boundaries (https://www.winglang.io/docs/tools/compiler-plugins).

[gravlaks]

In my organization, we teach developers Terraform, and give them a reference Terraform setup (IaC repository) for running their apps in.

They also have broad permissions in their own, isolated AWS account.

There are some tradeoffs, but one pro is that they don't need to request permissions from a devops teams.

[deathanatos]

We have a similar setup: Terraform, and the repository is open to any eng to make pull requests against.

The problem we hit is knowledge: while Terraform is not a huge knowledge hurdle to mount … it is still apparently enough. While good engineers will have no problem picking TF up, … more mediocre ones seem to struggle with it¹.

We don't have a "reference", as things are still changing sufficiently that it isn't clear what a reference would be. (I know sometimes people have base VMs or similar, and write TF about that; we run on k8s, so the various teams essentially don't have to worry about the host VM at all — or at least, much.)

It all comes back to engineering quality, I fear.

¹with knowledge acquisition itself; TF is not particularly unique here. In fact, I'd argue skills in knowledge acquisition is what separates good engineers from not.

[gravlaks]

> The problem we hit is knowledge: while Terraform is not a huge knowledge hurdle to mount … it is still apparently enough. While good engineers will have no problem picking TF up, … more mediocre ones seem to struggle with it¹.

That sounds just like one of our problems too. Some engineers arent really to keen on learning it either.

But my platform team spends some time on going on 1-1 sessions where we develop new things together with them (mob programming), which gives us possibility to teach and get insights. That mitigates this problem somewhat.