Zero trust seems to be very unrelated to this issue. The issue seems to have been a poison config breaking fastly stack. Zero trust is about verifying authentication of devices/users. Unrelated things really.
I wish they'd rather use python or Julia. GNU Octave is great. But as a clone of Matlab it's constraint by compatibility and doomed to always be second* and at worst an enabler for Matlab. I'd rather break the dominance that Matlab has in many fields and replace it with free software.
* There are a few aspects where it is better. For example I believe the variable editor introduced one or two releases ago is nicer as it allows inline evaluation.
Yep. Having each front end needing to scale with the overall size of the front end sounds is obviously going to hit some scaling limit. It's not clear to me from the summary why they are doing that. If it's for the shard-map or cache? Maybe if the front end is stateful that's a way to do stickiness? Seems we can only guess.
From the summary I don't understand why front end servers need to talk to each other ("continuous processing of messages from other Kinesis front-end servers"). It sounds like this is part of building the shard map or the cache. Well in the end an unfortunate design decision. #hugops for the team handling this. Cascading failures are the worst.
Canarying should detect this. Not clear if they do this or the canary failed to report this.
Sharding by customers could help reduce blast radius. But maybe not by much of this was a very big customer.