One of the more interesting reads in the Software Architecture space right now is Diego Pacheco's and Sam Sgro's 'Principles of Software Architecture Modernization' (published by BPB Publications December 2023).
After introducing some foundational concepts of distributed software architectures, the book dives into a particularly interesting topic: "The Distributed Monolith." This term describes an anti-pattern in architectures attempting micro-services where the functionality is neither isolated nor modular enough to realize the benefits of decomposed micro-services. The idea was popularized by Ben Christensen (author of Hystrix) in his talk, "Don't Build a Distributed Monolith." At its core, the concept highlights a common misconception: distributing a monolithic system will resolve its inherent complexity. In reality, without proper abstractions, boundaries and separation of concerns, complexity not only persists but worsens in a distributed system. Modularity cannot be magically achieved—it requires skill, whether systems are co-located or distributed. This is something I completely agree with. It's both tragic and unfortunate as it is difficult to objectively measure how modular or coupled your system is and is something that just requires a well trained eye.
Sgro and Pacheco identify three key traits of a poorly designed system:
Lack of Isolation: Is there excessive sharing of libraries?
Lack of Independence: Can components evolve independently?
Distributed Complexity: Is there a lack of stable contracts and a clear separation of concerns?
However, the book argues, unless it's a very small company maintaining these principles with an Architect as "design and quality gatekeeper" just doesn't scale. That's certainly on the money. Instead, Pacheco and Sgro suggest that engineers should be "educated with the right principles". This is also on the money. As bringing engineers into the technical vision helps them creates a sense of collaboration and helps them feel more empowered. However, it also relies on engineers being good citizens and shouting for help when it is needed. That part can be easier said than done.
There is a whistle stop tour of many things hot in software right now: AWS Cloud, Sidecars, Container Orchestration, Service Meshes and Chaos engineering. Depending on your background some of it you will know, some of it will be a refresher and some of it will be new.
There are also flying visits to many software tenets that are longer established: Reuse vs. Duplication, Dependency Management, Build vs. Buy, Rewrite vs. Refactor, Backward Compatibility, SOA, Test Pyramid
No good book on Software Architecture is without a tidbit or two on technical debt. The analogy of flavours is used to describe slightly different versions of the same thing which tends to happen in larger code bases without sufficient governance. While the need to do something slightly different (or better) may be valid a better approach is described with another analogy: build another bridge. Imagine a bridge connected two parts of a city. As the population grows, at some point, the bridge won't be big enough anymore. But, don't shut it down. Instead, build one in parallel and gradually move traffic over to the new (the idea sounds very much like parallel contracts, or expand / contract). Key is that a flavour is an unfinished bridge. Instead of the gradual migration, things that are similar just proliferate and become impossible to govern. Yeah, full disclaimer: I've seen that too many times.
One excellent point is regarding embracing new technology: Don't do so without good principles. That seems to be a very common problem. Adopting Spring Boot & Docker led a lot of people to believe that building micro-services is going to be easy - sure doesn't Spring and Docker give you all the principles you need? By the way if you want to have a good laugh on that point, I recommend having a look at David Schmitz hilarious talk: 10 Tips for Failing at microservices
There are several industry anecdotes mentioned which I didn't know and found interesting:StackOverflow is a data center-hosted monolith on 9 servers and serves 2B+ monthly page views. They even removed their Redis caching layer without degradation
Uber reported 5 - 10% overhead by running Cassandra on Containers
LinkedIn migrated its REST APIs from JSON to Protocol Buffers resulting in a 60% latency reduction and an 8% improvement in resource utilisation
The recurring theme in the book is that things can be more complicated than they appear. Watch out for anti-patterns as much as you watch out for good patterns with many many tips to help you master that complexity and build a great architecture.
Overall, '
Principles of Software Architecture' is probably broader than it is deeper. The breath of topics covered is very impressive and that's why I would recommend this book. Usually Software Architecture books are a little narrower but go deeper into one aspect of Software Architecture. For example,
Domain Driven Design is more about abstracting and decomposing,
50 Rules of Scalability focuses heavily on one NFR and
Designing Intensive Database Applications is heavily focused on Persistence.
Principles of Software Architecture's wider coverage ensures there's something valuable for nearly everyone—whether you're looking to learn something new or simply refresh your knowledge.
