Hacker News new | ask | show | jobs
by n0n0n4t0r 535 days ago
I wonder a what scale this very interesting approach start yielding more value than cost. What I mean is: is it a faang only as so many things they seeded or is it actually relevant at a non-faang scale?

I tend to be invest much on risk avoidance, so this is appealing to me, but I know that my risk avoidance tendency is rarely shared by my peers/stakeholders.

2 comments

It's definitely something that requires a high budget and a dedicated reliability team. In most orgs that have got as far as a proper post-mortem and analysis culture, they aren't even reliably draining the action items generated by the post mortems, so attempting to pre-emptively generate action items is kind of a moot point.
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.

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?

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.

I really don't think they are talking about requirements, at least not specifically. Aren't you focusing on your own level issues?
the example they gave is the quota rightsizer. Its job is to infer the right quota (requirement allocation).
Yes, but I mean that they shifted the focus to the input measurements over correct quota's value.