Monkeynoodle.Org

Humble bundles are just a huge grab bag of roughly related stuff — which is tough to work with. They’re great for getting access to a bunch of stuff in order to find out what you’re interested in or get a quick overview of a field. Here’s short reviews of a bunch of books I got through one of these bundles. One other thing, I was halfway through the bundle two months after buying it, and if I hadn’t gotten a cold while enjoying a week off work, I’d have never reached the halfway point… it took three months, with a fair bit of skimming and DNF. I read the introduction and first chapter or two of every book. Remember this when thinking “oh, I’ll buy a humble bundle of textbooks.”

• Building an Event-Driven Data Mesh, Has this banger in it: “Unfortunately, the fundamental principle of storing unstructured data to be used with schema on read proved to be one of the costliest and most damaging tenets introduced by the big data revolution.” Can’t disagree with that. This book is like an extended version of the Bezos 2002 API memo, with some echoes of SOAP+WSDL… every team in the business should formally offer data products with well-defined schemas and behavioral contracts. And a catalog, of course. So instead of everyone hitting SFDC to export a list of current customers and prospects, sales ops should publish that list as a product in the data warehouse^B^Bevent-driven data mesh and help everyone learn how to use it and support them when changes are made. DNF at 26 pages in… I don’t disagree with the problems described and I agree that the described solution would be better, I just don’t believe in large organizations actually embracing a thing that would increase work in order to reduce risk.
• Building Event-Driven Microservices, EDM is Event Driven Microservices in this context, BTW. TLA overlap leads to WTF PDQ. There’s a McLuhan quote, Conway’s Law, “data communication structures”… I’m getting UML/Semantic Web vibes. OK, gist of this one is “use persistent queues in Kafka as source of truth and build ephemeral serverless stuff around it to do things”. I appreciate a call-out that if you aren’t explicit about schema you’re going to be dependent on a brittle implicit schema. Three chapters was enough of that, DNF.
• Building Evolutionary Architectures, 2nd Edition, not bad, not great. An abstract wrapping for pretty simplistic stuff with some handwaving around who’ll do it and at what cost. Use tests. Use synthetic transactions. Use feature flags. Use canaries/rings. If you’ve got observability then you can make changes more safely / if your change hurts you must need more observability. DNF at 50 pages.
• Building Microservices, 2nd Edition, DNF at 12 pages, seems more hands-on than I’ll really get use out of.
• Building Multi-Tenant SaaS Architectures, three stars, not really new but put some terms into a more useful organization. I read the first half, would recommend it for someone trying to get a grounding in architectural options.
• Communication Patterns, this is really good, high value book ranging from diagramming through tech docs, SDLC process, sync/async fun. Five stars.
• Designing Distributed Systems, that was actually useful. Learned some containerization patterns that I didn’t know. Four stars.
• Enabling Microservice Success, Begins with the traditional discussion of granularity levels and Conway’s Law, and a higher speed rip through justification. Early hints this book is going to be more useful though with a discussion of on-call realities: engineers having on-call rotations is the painful pivot in my experience, the intended outcome of “the software gets more reliable” is possible but so is “the engineers quit and the software still sucks”. I really like that this is written in first person. Interesting quote: “Once you have data stored in more than one place, you can’t rely on transactions any more.” Teams making paved roads to help other teams spend less time on the same infra stuff. Discussion about on-call and ownership is solid. This book is at the sweet spot between practical and theoretical, five stars.
• Flow Architecture, DNF after the foreword and first chapter… reads like boring sci-fi.
• Foundations of Scalable Systems, light, high-speed, but comprehensive and well-written introductory textbook. I like it, recommended if that’s a thing you need.
• Fundamentals of Software Architecture, Architecture isn’t just a blueprint or a roadmap, it’s a mesh of structural decisions, design principles, characteristics, and decisions. It’s a living iterative sociotechnical construct. Engineering practices are seperate but you can’t really iterate architecture if you don’t have iteratively improving practices, so… XP/Agile/Accelerate bandwagon. Everything in architecture is a tradeoff of optimizations: modularity and coupling presented as examples of same. Not a bad textbook, but not something I need to finish reading. DNF after chapter 3.
• Software Architecture: The Hard Parts, Followup to Fundamentals of Software Architecture, looking at the edge cases that were deemed too complex for that book. “Imagine an alternative world in which every project runs a deployment pipeline, and the security team has a “slot” in each team’s deployment pipeline where they can deploy fitness functions… when a zero-day exploit appears, having the same mechanism in place everywhere allows the security team to insert a test in every project that checks for a certain framework and version number; if it finds the dangerous version, it fails the build and notifies the security team.” I am rolling my eyes very hard over here; Edwards’ Law. Moving on into coupling and modularity discussions, seems cromulent. Setting this book aside though, DNF.
• Head First Software Architecture, DNF at 87 pages, don’t recall anything of value, I do not like this style.
• Learning Systems Thinking, first person narrative, always a good start. “My journey… has led me to one inevitable conclusion: technology design is communication design.” Linear, reductionist thinking is a fine tool but insufficient for the emergent behavior of the complex systems that we now work with. This is all right up my alley as a humanities major turned product manager, have been reading about chaotic emergence in sociotechnical systems for decades. Glad to see a solid text for introducing these concepts to software folks, it is sorely needed. Five stars.
• Learning Domain-Driven Design, a good follow up to Learning Systems Thinking, DDD is a practical methodology for applying emergent systems thinking to solving business logic problems. I like the emphasis on understanding if a subdomain should be in-sourced (core) or out-sourced (generic). Solid callout to the problem of product managers acting as a filter between customers and engineers: I do think there is value in a PM providing aggregated analysis but they should never be blocking (or “saving”) engineers from talking to customers. Discussion of difficulty in modeling, linguistic ambiguity… and oof, a dive into TDD and Gherkin, I’ve got a war wound related to that stuff. Some nice examples and exercises for discovering and understanding the boundaries of domains. I like seeing some logic implementations in code as well. Unsurprisingly given the levels of metacognition we’ve already visited, chapter 7 is about time. Five stars, quality textbook.
• Mastering API Architecture, decent foundational book. There’s some conversation about the history of APIs transitioning from a service for external users to the internal cross-service fabric. Fine introduction of required technologies and concepts. I have thoughts about GraphQL after having worked with it at two companies: in short, I think it’s fine as an internal cross-service fabric, but undesirable as an external user facing tool. OpenAPI specification and documentation, testing strategy with contracts, gateways and proxies. Full chapter on the service mesh pattern and its implementation. Observability and security. All in all a reasonable text, DNF halfway through.
• Monolith to Microservices, worth reading. Decent review of the whys and hows for making this sort of transition, or deciding not to. I enjoyed the discussions of how real systems were migrated (noting there’s a lot of “how to migrate” that doesn’t have anything to do with monoliths or microservices, and this book could be usefully rewritten in the other direction in the future). Four stars.
• Practical Process Automation, I really prefer first person narratives that support the more broadly applicable ideas, so off to a good start. I haven’t looked closely at process automation in the last ten years or so, learned about products that I didn’t know of. That said, the fundamentals appear to be the same as they were in the days of SOAP. This book looks like it’s going to focus on Camunda and the BPMN format, which I hadn’t heard of, while the BPA automations I’ve observed in the last ten years seem to be on Zapier and Workato. I wonder what cultural barrier that represents. Anyway, read half of it, DNF. Three stars.
• RESTful Web API Patterns and Practices Cookbook, skimmed first few chapters… hooboy. hypermedia and semantic web and late-binding schemas, oh my! And a quick detour into Licklider… I was expecting a practical cookbook, not an architectural acid trip :slightly_smiling_face: Some API design discussion… Jazz as a Workflow Analogy, oof. I’m thinking a lot of business do seem to operate along the lines of “Once is a mistake, twice is jazz”, but that’s apparently not what the author meant. This is probably a useful book for a student’s introductory seminar, but not today for me batman.
• Serverless Development On AWS, Pretty good — again, not new, but organizes stuff you’ve already learned. I snickered at the self-contradicting “we’ve got to write something about SBOM attacks” advice: automate and upgrade, but not without automating manual source code review or something? There’s some cool pattern discussion, I highlighted storage first, circuit breaker and gatekeeper event buses, outbox pattern, Jidoka. The cost chapter is interesting. Four stars.
• The Software Architect Elevator, tries to guide technology-first people to considering domain driven design, not a bad idea. Working the elevator metaphor pretty hard, with specific ties to Fritz Lang’s Metropolis: developers in the engine room, executives in the penthouse, architects creating value by mediating between them. Seems alright, but didn’t grab me, DNF after three chapters.
• Software Architecture Metrics, hands-on guide to implementing DORA metrics. Calls back to Building Evolutionary Architectures (as many of these books do). Some good advice about starting with practical and achievable items and engaging the whole team. Not bad, three stars.
• Software Architecture Patterns 2nd Edition, blessedly short and to the point, five stars, well organized introduction to the patterns and processes.
• Technology Strategy Patterns, What the heck is “strategy” anyway? Good question. This book usefully attempts to answer it, using the Gang of Four Design Patterns model as a framework to review business domains and technology fits. Great examples, useful patterns, enjoyable read. Five stars.