This book started out as a wordy chat on what could go wrong in mission-critical web applications, such as airline or shopping systems. The author picks his examples only from the Java world, and many examples rely on what I assume to be idiosyncracies of old Java versions. It surely cannot be that the default Java HTTP connection class does not allow a timeout value on read operations. It is also a bit surprising that asynchronuous IO is not widely discussed in the context of service-oriented architectures and fault-tolerant socket connections. But whatever, I thought, because the sample stories were interesting and written in a witty style.
Things started to get unpleasant at a certain point, though. First of all, did I mention the Java-only examples? Further, the author starts talking about utility computing (i.e. cloud computing) on page 75, and somehow talks himself into a corner while trying to find excuses why it’s not a “thing” and why “barring crises of the most extreme sort, you are more or less stuck with the amount of resources you have” (p.76). Well, I don’t know about the environment the author works in, or would like to work in, but utility computing has been a reality since nearly a decade now, and nearly every new mission critical online system is being built on AWS or something similar where a new computing unit can be started within a few minutes, without the full paragraph of excuses the author concocts to make his point valid.
What really broke the book for me was on the next page, though. In a discussion of how the request-handling threads of an application are distributed, the author speaks of how one could do a calculation of “how many threads could be making simultaneous calls to the scheduling system”. At this point I was expecting a simple calculation based on performance characteristics or something similar, and was hoping to learn a little bit about the maths of predictive profiling. But the next sentence was like an overview of so many books on programming these days: “The math is not hard, though it does rely on statistic and numerous assumptions, which is a notoriously easy-to-manipulate combination” (p.77). That was it? Not a single equation, not even a reference? So it’s “the math is hard, let’s go shopping”? I have difficulty understanding the math aversion of the majority of programming books; is it because they fear the “difficult to read” review on Amazon? I couldn’t take the book seriously after this point, unfortunately. The fact that it got even wordier after this page, and the concrete points and examples got fewer in between did not help either.
In today’s publishing world filled with so many well-written and interesting books, this one is a waste of time; I would recommend everyone to spend their precious time on another book.