[mgaunard]

The example here seems to do with sizing appropriately the requirements of applications, which enables you to schedule more applications per machine, driving down costs.

This is useful for any company larger than say 10 people.

In general this is difficult to do, because there is more at play than memory, CPU and disk usage, especially if you have certain performance requirements.

I find that what's in Kubernetes (a Google product) pretty much useless, but maybe it works for web tech.

[n0n0n4t0r]

I understood their example more like: automating the scaling of servers is easy, having proper inputs for this scaling to be reliable is hard.

What they propose is to lend weeks if engineering time to perform analysis in the hope to find some relatable issues. Are both this engineering time and the issues fixing time relevant for non faang companies?

In other words: The lever effect of not having issues is fewer, so the rentability of such analysis decrease. Where does the rentability become negative?

[mgaunard]

In practice it's pretty much impossible to get precise requirements without automatically learning them from how the application performed in the past.

The problem is that it is high-risk to automatically perform those changes since they might affect the application in ways you do not expect.

[n0n0n4t0r]

I really don't think they are talking about requirements, at least not specifically. Aren't you focusing on your own level issues?

[mgaunard]

the example they gave is the quota rightsizer. Its job is to infer the right quota (requirement allocation).

[n0n0n4t0r]

Yes, but I mean that they shifted the focus to the input measurements over correct quota's value.