What do you think?
Rate this book
The Art of Immutable Architecture: Theory and Practice of Data Management in Distributed Systems
This book teaches you how to evaluate a distributed system from the perspective of immutable objects. You will understand the problems in existing designs, know how to make small modifications to correct those problems, and learn to apply the principles of immutable architecture to your tools.
Most software components focus on the state of objects. They store the current state of a row in a relational database. They track changes to state over time, making several basic there is a single latest version of each object, the state of an object changes sequentially, and a system of record exists.
This is a challenge when it comes to building distributed systems. Whether dealing with autonomous microservices or disconnected mobile apps, many of the problems we try to solve come down to synchronizing an ever-changing state between isolated components. Distributed systems would be a lot easier to build if objects could not change.
After reading The Art of Immutable Architecture , you will come away with an understanding of the benefits of using immutable objects in your own distributed systems. You will learn a set of rules for identifying and exchanging immutable objects, and see a collection of useful theorems that emerges and ensures that the distributed systems we build are eventually consistent. Using patterns, you will find where the truth converges, see how changes are associative, rather than sequential, and come to feel comfortable understanding that there is no longer a single source of truth. Practical hands-on examples reinforce how to build software using the described patterns, techniques, and tools. By the end, you will possess the language and resources needed to analyze and construct distributed systems with confidence.
The assumptions of the past were sufficient for building single-user, single-computer systems. But as we expand to multiple devices, shared experiences, and cloud computing, they work against us. It is time for a new set of assumptions. Start with immutable objects, and build better distributed systems.
What You Will Learn Apply the principles of immutable architecture to your tools, including SQL databases, message queues, and the network protocols that you already use
Who This Book Is For
Software architects and senior developers. It contains examples in SQL and languages such as JavaScript and C#. Past experience with distributed computing, data modeling, or business analysis is helpful.
Most software components focus on the state of objects. They store the current state of a row in a relational database. They track changes to state over time, making several basic there is a single latest version of each object, the state of an object changes sequentially, and a system of record exists.
This is a challenge when it comes to building distributed systems. Whether dealing with autonomous microservices or disconnected mobile apps, many of the problems we try to solve come down to synchronizing an ever-changing state between isolated components. Distributed systems would be a lot easier to build if objects could not change.
After reading The Art of Immutable Architecture , you will come away with an understanding of the benefits of using immutable objects in your own distributed systems. You will learn a set of rules for identifying and exchanging immutable objects, and see a collection of useful theorems that emerges and ensures that the distributed systems we build are eventually consistent. Using patterns, you will find where the truth converges, see how changes are associative, rather than sequential, and come to feel comfortable understanding that there is no longer a single source of truth. Practical hands-on examples reinforce how to build software using the described patterns, techniques, and tools. By the end, you will possess the language and resources needed to analyze and construct distributed systems with confidence.
The assumptions of the past were sufficient for building single-user, single-computer systems. But as we expand to multiple devices, shared experiences, and cloud computing, they work against us. It is time for a new set of assumptions. Start with immutable objects, and build better distributed systems.
What You Will Learn Apply the principles of immutable architecture to your tools, including SQL databases, message queues, and the network protocols that you already use
Who This Book Is For
Software architects and senior developers. It contains examples in SQL and languages such as JavaScript and C#. Past experience with distributed computing, data modeling, or business analysis is helpful.
444 pages, Paperback
Published July 15, 2020
25 people are currently reading
264 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 11 of 11 reviews
January 11, 2021
A brilliant book, that will probably pass absolutely unnoticed by the wider audience.
Why is it brilliant and why it won't get the publicity it deserves?
It's brilliant because it presents an atypical approach to domain modeling - based on immutable facts and the relationship of predecessor-successor (w/o strict ordering). It is not event-sourcing (in fact it's very far from it), but a very smart technique I was using (in much more simple form, e.g. w/o location-transparency considerations) successfully in the past. I'm very glad someone has not just made a book about it, but had put so much thought into it - it went far, far beyond what I came up with. Kudos to M. Perry - who (according to the book's introduction) has been using this technique for ages.
Why will this book get practically unnoticed? There are a few reasons. First of all: it's a book about modeling, it requires a lot of abstract thinking and attention. Such books are really hard to get through. Additionally, it's tech-agnostic and "not sexy": it doesn't throw you to code, quite the opposite: it is a book about modeling. The only example of a successful book of that sort I can recall was the DDD "blue book", but that one has succeeded only because of striking tactical patterns. "The Art ..." has a chapter with patterns as well, but it's much harder to apply in practice AND that requires more thorough understanding of "Historical Modeling" concept.
What did I like most? I think I've enjoyed the whole book, maybe except the chapter "Security" and the final part (about "Implementation") - I'm not saying it's not useful, probably quite the contrary: but this knowledge is applicable only by someone who has already tries HM (Perry's concepts) in practice and has a deep understanding of implementation challenges (so there has to be a break before reading initial parts and the "implementation" one).
Solid 4.5 stars, just because the author has put so much honest effort in describing a very useful concept. Good stuff.
Why is it brilliant and why it won't get the publicity it deserves?
It's brilliant because it presents an atypical approach to domain modeling - based on immutable facts and the relationship of predecessor-successor (w/o strict ordering). It is not event-sourcing (in fact it's very far from it), but a very smart technique I was using (in much more simple form, e.g. w/o location-transparency considerations) successfully in the past. I'm very glad someone has not just made a book about it, but had put so much thought into it - it went far, far beyond what I came up with. Kudos to M. Perry - who (according to the book's introduction) has been using this technique for ages.
Why will this book get practically unnoticed? There are a few reasons. First of all: it's a book about modeling, it requires a lot of abstract thinking and attention. Such books are really hard to get through. Additionally, it's tech-agnostic and "not sexy": it doesn't throw you to code, quite the opposite: it is a book about modeling. The only example of a successful book of that sort I can recall was the DDD "blue book", but that one has succeeded only because of striking tactical patterns. "The Art ..." has a chapter with patterns as well, but it's much harder to apply in practice AND that requires more thorough understanding of "Historical Modeling" concept.
What did I like most? I think I've enjoyed the whole book, maybe except the chapter "Security" and the final part (about "Implementation") - I'm not saying it's not useful, probably quite the contrary: but this knowledge is applicable only by someone who has already tries HM (Perry's concepts) in practice and has a deep understanding of implementation challenges (so there has to be a break before reading initial parts and the "implementation" one).
Solid 4.5 stars, just because the author has put so much honest effort in describing a very useful concept. Good stuff.
February 18, 2021
It's hard for me to objectively rate this book, as it discusses a topic that overlaps with one of my favorite topics, described as Historical Modeling by the author and as Collaborative Eventsourcing by myself - there's no one established name for it so our naming conventions shows different aspects we focus on.
On one side author nicely introduces context of successor/predecessor relations, their non-linear timeline hierarchies in distributed systems. He brings up important technical topics like vector clocks, CRDTs and the mindset that allows to model them in exemplar scenarios. Idea of immutable architectures using analogy to well-known systems like Git, Docker or blockchain is also very good. These are very valuable. Also additional points for setting all that up in client/server topology as this topic is usually presented in terms of peer-to-peer architectures.
On the other side I have many problems with this book:
- In the intro author says this books is really about mathematics. It's not. It's primarily about business domain modeling.
- Some of the concepts have their actual well-known names in the literature, but are never mentioned eg. Mutable Properties and Multi-Value/Last-Write-Wins registers. If you want to make a follow up reading in other papers, you may get lost trying to connect the dots without being heavily experienced in the topic.
- Some of the described patterns are inconsistent eg. book introduced vector clocks, which are used to deal with uneasy notion of time in concurrent isolated updates. But then you run into Period pattern which seems to ignore entire issue, especially when it comes together with Occasionally Connected Clients few chapters later.
- Chapter 7 with deals with security didn't really answer for common questions about modern eventsourced systems like their compliance with GDPR and building state application with "right to be forgotten" in mind.
- Other advices, like versioning based on data structure hash rather than number, are not discussed deep enough (Greg Young made an entire book on that topic, here you have one paragraph) and they seem to be general ideas rather than actual advices tested and verified in practice.
- IMO the worst part is Chapter 10, which brings exemplar implementation based on PostgreSQL. What's worse, it's the only chapter that remotely touches actual implementation. While it may look tempting at the beginning, don't take it at face value. The complexity of proposed solutions is soul crushing. The ideas like implementing recursive successor hierarchies or generic graph `edges` in relational DB... I've been there. Literally. If your team wants to lynch you for implementing them in production, they're right to do so.
In summary, there are good ideas in there. It helps you to get familiar with interesting techniques and does so by presenting them in actual business context, which makes this book unique in comparison to other materials on that specific topic found on the web. However be very wary when trying to apply the proposed solutions in your daily life job.
On one side author nicely introduces context of successor/predecessor relations, their non-linear timeline hierarchies in distributed systems. He brings up important technical topics like vector clocks, CRDTs and the mindset that allows to model them in exemplar scenarios. Idea of immutable architectures using analogy to well-known systems like Git, Docker or blockchain is also very good. These are very valuable. Also additional points for setting all that up in client/server topology as this topic is usually presented in terms of peer-to-peer architectures.
On the other side I have many problems with this book:
- In the intro author says this books is really about mathematics. It's not. It's primarily about business domain modeling.
- Some of the concepts have their actual well-known names in the literature, but are never mentioned eg. Mutable Properties and Multi-Value/Last-Write-Wins registers. If you want to make a follow up reading in other papers, you may get lost trying to connect the dots without being heavily experienced in the topic.
- Some of the described patterns are inconsistent eg. book introduced vector clocks, which are used to deal with uneasy notion of time in concurrent isolated updates. But then you run into Period pattern which seems to ignore entire issue, especially when it comes together with Occasionally Connected Clients few chapters later.
- Chapter 7 with deals with security didn't really answer for common questions about modern eventsourced systems like their compliance with GDPR and building state application with "right to be forgotten" in mind.
- Other advices, like versioning based on data structure hash rather than number, are not discussed deep enough (Greg Young made an entire book on that topic, here you have one paragraph) and they seem to be general ideas rather than actual advices tested and verified in practice.
- IMO the worst part is Chapter 10, which brings exemplar implementation based on PostgreSQL. What's worse, it's the only chapter that remotely touches actual implementation. While it may look tempting at the beginning, don't take it at face value. The complexity of proposed solutions is soul crushing. The ideas like implementing recursive successor hierarchies or generic graph `edges` in relational DB... I've been there. Literally. If your team wants to lynch you for implementing them in production, they're right to do so.
In summary, there are good ideas in there. It helps you to get familiar with interesting techniques and does so by presenting them in actual business context, which makes this book unique in comparison to other materials on that specific topic found on the web. However be very wary when trying to apply the proposed solutions in your daily life job.
July 23, 2021
While the book started really strong and interesting explaining historical modelling , around the 30% mark it gets nasty , confusing and you don't really understand how the pieces fit together.
The author while most certainly knows alot of &$it about distributed systems and immutable architecture , he certainly didn't give much thought on how to put it all together and create some damn coherence for the reader.
Ex: we are discussing historical modelling on the first 5 chapters , then out of friggin nowhere i'm cramped in a chapter about security - assymetric keys/hashes.
Down the road another chapter is.about sql databases.
The chapters are tackled somehow relating to immutable architecture but there is no damn structure , no order and definetly no logic as to why they were pushed there and in that order , its more like reading a memo.
Really really dissapointed !
The author while most certainly knows alot of &$it about distributed systems and immutable architecture , he certainly didn't give much thought on how to put it all together and create some damn coherence for the reader.
Ex: we are discussing historical modelling on the first 5 chapters , then out of friggin nowhere i'm cramped in a chapter about security - assymetric keys/hashes.
Down the road another chapter is.about sql databases.
The chapters are tackled somehow relating to immutable architecture but there is no damn structure , no order and definetly no logic as to why they were pushed there and in that order , its more like reading a memo.
Really really dissapointed !
This entire review has been hidden because of spoilers.
March 7, 2021
2 out of 5 means that it's ok.
Even with the clear split between the roles of readers provided by the author, I still have a problem defining who's the audience for this book. It provides a lot of information and deals with various aspects of fact-based a.k.a immutable architectures, like public-private keys, queries, authorization, storage, making it RESTful and even bridging with existing architectures but still, I find it a bit to shallow to derive a working system out of it.
It mentions blockchain, CRDTs and other things but takes a different take on it. It might be fine for you. In my case I prefer to derive knowledge from bits of theory, like with CRDTs still being defined with "more mathematical" terms.
I think that if you had to choose whether to read this book or read some CRDT/blockchain book, if that's the first book you read about this topic, you should choose the latter.
Even with the clear split between the roles of readers provided by the author, I still have a problem defining who's the audience for this book. It provides a lot of information and deals with various aspects of fact-based a.k.a immutable architectures, like public-private keys, queries, authorization, storage, making it RESTful and even bridging with existing architectures but still, I find it a bit to shallow to derive a working system out of it.
It mentions blockchain, CRDTs and other things but takes a different take on it. It might be fine for you. In my case I prefer to derive knowledge from bits of theory, like with CRDTs still being defined with "more mathematical" terms.
I think that if you had to choose whether to read this book or read some CRDT/blockchain book, if that's the first book you read about this topic, you should choose the latter.
December 6, 2021
The first three high level overview chapters are good and the rest of the book isn’t. There isn’t any real math in the book - though mathematical proofs were promised. The organization of the book was off as there was just one basic example after another. In some cases the wording used made me question the size of systems built by the author. For example, RBAC was brought up and then dropped for pki and one off access to a blog. What about when you have hundreds of thousands of users? So many concepts, known by better names, are renamed and presented in a way that may confuse the reader as to their true potential.
There are some good ideas here. Immutable records and event systems are powerful. I think this is a book to skip as it’s not well presented.
There are some good ideas here. Immutable records and event systems are powerful. I think this is a book to skip as it’s not well presented.
January 13, 2022
این کتاب نحوهی تحلیل و طراحی نرمافزارهای توزیعشده رو با استفاده از یه سبک مدلسازی جالب به نام
Historical Modeling
ارائه میده. جدا از اینکه چقدر عملیاتی هست/میتونه بشه، از اون کتابهایی هست که یه افق جدید رو جلوی چشم طراحان باز میکنه.
Historical Modeling
ارائه میده. جدا از اینکه چقدر عملیاتی هست/میتونه بشه، از اون کتابهایی هست که یه افق جدید رو جلوی چشم طراحان باز میکنه.
November 29, 2020
Great book. The theory part is solid, however 1 star off for a lack of practical real world examples.
July 3, 2022
The author, Michael L. Perry is a mathematician. This book is a set of rules that you can use as an attempt to create a software project in a more mathematical, categorised, structured and automated way. I love it!
I got involved in a plot since very beginning! The book consists of three parts:
- Part 1 - Why immutable architecture - a lot of theory and explanations why do we even need such weirdo as immutable architecture.
- Part 2 - Application - description of the concept, some patterns, security issues and analysis engineering.
- Part 3 - Implementation - a practical, fully flegded help in the real building the software projects using Facts Historical Modelling.
Why my enthusiasm is so high?
- This is a new, modern but in the same time logical and reasonable approach for building distributed systems. Personally, as someone who has seen tens of projects built in the same way, using "The Art of Mutable Architecture" (...), I was feeling extremely refreshed while reading the book.
- As I mentiond, the author is a mathematician. It helps a lot. The terms that he introduces are precisely described (with a little help from some cool and concise diagrams). From time to time, he uses the simple equation to prove something. I think I remember the most the paragraph about the idempotence and commutativity. Well done!
- A concept of immutable architecture per se! (Location-independence and immutability + commutativity)
- Emphasising that everywhere it's possible, we should not rely on the developers' intuition and move forward automation and mechanical solution. The author provides many techniques that can do that. For example, a technuique named "Query Inverse" is a mechanical solution for updating Views / Cache (instead of trusting that a developer will pick correct fields to update)
Since my enthusiasm is so high, why haven't I rated it for five starts?
Well, the last part of the book is really practical. I mean, really. Queries in SQL (even with scripts for creating the indexes!), query inverses for all of the cases (nested subqueries) etc. I just wanted to gain some knowledge about the concept and those practical aspects were too detailed for me.
Anyway, I highly recommend the book. I have a feeling that I'll take it of my shelf more than once in a near future.
I got involved in a plot since very beginning! The book consists of three parts:
- Part 1 - Why immutable architecture - a lot of theory and explanations why do we even need such weirdo as immutable architecture.
- Part 2 - Application - description of the concept, some patterns, security issues and analysis engineering.
- Part 3 - Implementation - a practical, fully flegded help in the real building the software projects using Facts Historical Modelling.
Why my enthusiasm is so high?
- This is a new, modern but in the same time logical and reasonable approach for building distributed systems. Personally, as someone who has seen tens of projects built in the same way, using "The Art of Mutable Architecture" (...), I was feeling extremely refreshed while reading the book.
- As I mentiond, the author is a mathematician. It helps a lot. The terms that he introduces are precisely described (with a little help from some cool and concise diagrams). From time to time, he uses the simple equation to prove something. I think I remember the most the paragraph about the idempotence and commutativity. Well done!
- A concept of immutable architecture per se! (Location-independence and immutability + commutativity)
- Emphasising that everywhere it's possible, we should not rely on the developers' intuition and move forward automation and mechanical solution. The author provides many techniques that can do that. For example, a technuique named "Query Inverse" is a mechanical solution for updating Views / Cache (instead of trusting that a developer will pick correct fields to update)
Since my enthusiasm is so high, why haven't I rated it for five starts?
Well, the last part of the book is really practical. I mean, really. Queries in SQL (even with scripts for creating the indexes!), query inverses for all of the cases (nested subqueries) etc. I just wanted to gain some knowledge about the concept and those practical aspects were too detailed for me.
Anyway, I highly recommend the book. I have a feeling that I'll take it of my shelf more than once in a near future.
September 15, 2020
It might not be a bad book, but it's too heavy on theory and too light on practical applications. I see no point in reading it right now, as I did not see how to apply the described things.
December 8, 2020
Good and practical ideas around immutability of software builds.
March 26, 2023
I have expected much different content in this book.
There is even very little pseudo code in this book.
There is even very little pseudo code in this book.
Displaying 1 - 11 of 11 reviews