undefined

points

[-]

You’re torturing your own logic to make Azure the villain here. And it also sounds like you lack experience with capacity exhaustion. Things fail slowly, then suddenly.

by ivraatiems37 minutes ago|

parent|

[-]

No, I am calling Github disingenuous liars with poor motives, offering an unbelivable explanation. Not sure where the torture is, except in their statement.

If it was failing slowly, why didn't they fix it then? Why didn't they notice?

Could it be because they fired all the people who know how to monitor and identify such problems? That's what SREs are for.

by dcrazy37 minutes ago|

parent|

[-]

Baseless accusation made from a position of zero information.

by ivraatiems33 minutes ago|

parent|

[-]

Opinion based on stated facts.

Please share the information you have which contradicts the conclusions I have drawn from Github's statement.

(And we know they're liars. They report very few of the actual incidents they have; see for example https://mrshu.github.io/github-statuses/)

by dcrazy29 minutes ago|

parent|

[-]

I don’t owe you anything, much less a separately sourced counterargument. You openly admit that your opinion is not based not on GitHub’s proffered statements but on your self-admitted assumption that GitHub is actively lying in an attempt to cover up an Azure-related root cause.

by cyberax28 minutes ago|

prev|

[-]

This absolutely can happen in large systems. If some part of the system is at capacity, then slightly increasing the load can cause it to fall behind and start accumulating a backlog.

These backlogs can cause clients to make more retries, exacerbating the problem. Potentially further cascading through the system.

by Kinrany24 minutes ago|

parent|

[-]

I believe their point is that "system is at capacity" is something they ought to start fixing before the capacity is exceeded

by dcrazy20 minutes ago|

parent|

[-]

But then people like OP will claim that the capacity concerns are a lie manufactured to support an unjustified move to Azure.

by cyberax4 minutes ago|

parent|

prev|

[-]

Sure. But you might not even be realizing that something is just at the cusp if the load is spiky enough.

The art of large system design is to identify and avoid these kinds of chokepoints. And when something happens, propagate the "backpressure" up the stack to avoid queuing.

AWS got a fair share of similar outages, so the newer SDKs now try to not exacerbate these kinds of issues: https://docs.aws.amazon.com/sdkref/latest/guide/feature-retr...

The original AWS EBS outage is probably the canonical example: https://aws.amazon.com/message/65648/

by rcleveng23 minutes ago|

prev|

[-]

There's always a cliff, this part is fine. You sometimes know the cliff but often do not.