Well, this sure de-escalated quickly and my unusually high level of irritation is probably triggered by the fact that someone with intimate knowledge of both Kubernetes and Azure internals should have produced a seminal book on distributed systems and not this dud. The rational part of me knows that it's both unfair and unrealistic to expect a great engineer to write an equally great technical book but still, the emotional me that is knowledge-hungry can't but feel betrayed.
I had my suspicions when the author pointed out that the patterns were going to be exclusively container-based - containers to me are just a way someone chooses to package and distribute theirs software, i.e. it's an aspect that should be completely orthogonal to the way you actually design and decompose your distributed system so that statement felt like a weird flex more than anything else. It slowly but steadily went downhill from there, until it drove off a cliff that are the last three chapters.
While I can't say that the patterns and ideas presented in the book are bad - in fact, if you've worked with k8s you've probably already used most of them - it's just that the focus of the book felt to be less on its titular topic and more on showcasing some well-known patterns in a Kubernetes setting. To add insult to injury, not only is the Kubernetes focus misplaced but even that aspect is clumsily covered, and the writing in general is often lacking as well.
One of the most irritating is the fact the author took what I call the teleshop salesman approach (a modern variant of the strawman argument). To present the container-based patterns in a more attractive light, the least favourable way of achieving the goal without the use of containers is often used, and its shortcomings miraculously solved by the pattern, huzzah! The fact that a mainstream non-container approach often has no such shortcomings is conveniently left out. For instance, lack of reusability of traditional approaches is mentioned for every other pattern, but those patterns are most often developed as reusable libraries available in lots of languages but for some reason that fact rarely (if ever?) gets mentioned, much to my chagrin.
Barring the single-node patterns, which are actually decently argued and discussed when compared to the rest of the book, the use cases for a pattern always seem to be among the simplest. For instance, load balancing is either round-robin or sticky, other approaches aren't even discussed. Sharding is only discussed and used in a context where the data associated with a shard is transient, i.e. the impact of a change in cluster topology is low but what of stateful systems that need to avoid data loss? How does the pattern, as described here, help the developer then?
The level of detail varies greatly from pattern to pattern, and the quality of discussion is inveresely proportional to the complexity of the described patterns - the further we progress and as the patterns become more complex, so do we get fewer and fewer considerations of the pros, cons and trade-offs of such an approach, its alternatives, its more complex use cases, etc. The batching section of the book is particularly abysmal in that regard, especially the later chapters - not even a whisper of a reason anyone should prefer described event-driven and coordinated patterns with their staggering overheads to a regular message broker+EIP framework, or a full-fledged streaming system like Kafka Streams (or, if you're into the heavier stuff, Spark)?
All in all, it's a short read and the Kubernetes bits are decent, but I can't see anyone gaining any use of the book except the most junior devs.