Name: Software Architecture : the Hard Parts
ISBN: 9781492086864

Software Architecture : the Hard Parts

There are no easy decisions in software architecture. Instead, there are many hard parts--difficult problems or issues with no best practices--that force you to choose among various compromises. With this book, you'll learn how to think critically about the trade-offs involved with distributed architectures. Architecture veterans and practicing consultants Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani discuss strategies for choosing an appropriate architecture. By interweaving a story about a fictional group of technology professionals--the Sysops Squad--they examine everything from how to determine service granularity, manage workflows and orchestration, manage and decouple contracts, and manage distributed transactions to how to optimize operational characteristics, such as scalability, elasticity, and performance. By focusing on commonly asked questions, this book provides techniques to help you discover and weigh the trade-offs as you confront the issues you face as an architect. Analyze trade-offs and effectively document your decisions Make better decisions regarding service granularity Understand the complexities of breaking apart monolithic applications Manage and decouple contracts between services Handle data in a highly distributed architecture Learn patterns to manage workflow and transactions when breaking apart applications

What Hacker News says

gchamonliveFeb 2025

I think any attempt to distil hard earned experience and domain awareness will eventually devolve into misplaced generalisms.

This isn't to say that the article isn't good. It's well written and the teachings are valuable.

This comment is for the inexperienced dev that arrives at theses posts looking for ideological prescriptions: don't.

Give yourself time. Let yourself fail and learn from your mistakes. Keep reading the masters work like Clean Code, SICP, Working effectively with legacy code, software architecture the hard parts, mythical man month etc... but don't let anyone prescribe to you how to do your job.

Developing is ultimately managing an unmanageable and ever evolving complexity and making it work. Developing is art and experience. Developing requires great peace of mind.

thread

nyrikkiAug 2024

Document updates are atomic, with replica sets. Reads will be eventually consistent.

Professionals consider weigh the tradeoffs consistency vs partion tolerance, availability, synchronous vs asynchronous communication implications etc...

Nothing here is a silver bullet, it is about choosing the least worst option for a data domain.

We are in the cloud era, which is by its nature distributed.

The era of vertically scaled monoliths is mostly over for most people.

The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be.

Hint: even your ATM card doesn't use ACID, and many needs can improve performance, availability and resilience by not paying the cost of ACID transactions.

It is a far more complex subject than your posts suggest.

thread

wh33zleNov 2023

I really enjoyed: Software Architecture, The Hard Parts.

https://www.oreilly.com/library/view/software-architecture-t...

One part it discusses is in fact communication patterns along the dimensions of:

- sync/async

- atomic/eventual consistent

- orechestrated/choreographed

thread

caller9Oct 2023

You might like "Software Architecture: The Hard Parts." Though you already describe some of the points of the book. There isn't a magic bullet and every decision to split something apart or which parts to combine has various trade-offs.

The book isn't perfect. The use of afferent and efferent terminology and some of the arbitrary methods to put numbers on decisions weren't ideal. Most of the concepts are sound. The fact that almost every decision has cost/benefit and real world implications for a living product was refreshing. That a monolith can't be cut over instantly with zero effort to a perfect system is absolutely true.

It's good food for thought for anyone considering slicing up a monolith, but maybe don't follow it to the letter.

thread

playing_coloursDec 2021

Software Architecture: the Hard Parts https://www.oreilly.com/library/view/software-architecture-t...

thread

petcatAug 2024

> The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be.

I'll send you some books to read, too.

> Hint: even your ATM card doesn't use ACID

I guarantee you that the actual database handling those ATM transactions is ACID-compliant. The banking institution itself couldn't even be certified by the FDIC or the Comptroller of the Currency (OCC) if their database system wasn't, at the very least, ACID compliant.

Out-of-band transaction resolution is a completely separate topic and has nothing to do with databases, or ACID, or anything else.

You're kinda out of your depth here...

thread