Distributed Systems 4th edition (2023) – DISTRIBUTED-SYSTEMS.NET
Today, I bring to your attention review of this book. As always, trying to save your time, recommend good content, and provide some feedback.
Distributed systems are hard, and 10x more complex. They’ll be largely similar to each other, but have subtle differences that bite you hard enough to lose five months of development time if one of those subtle differences makes a use case impossible.
A distributed system is a task broken up and run on several computers at once. Big data frameworks and technologies are examples of distributed systems.
Management becomes more complex, too, because the staff has to reach across the organization at a level and consistency you never had before: different departments, groups, and business units. For example, analytics and business intelligence teams never had to have the sheer levels of interaction with IT or engineering.
The IT organization never had to explain the data format to the operations team. From both the technical and the management perspectives, teams didn’t have to work together before with as high of a bandwidth connection. There may have been some level of coordination before, but not this high.
Other organizations face the complexity of data as a product instead of software or APIs as the product. They’ve never had to promote or evangelize the data available in the organization. With data pipelines, the data teams may not even know or control who has access to the data products.
Some teams are very siloed. With small data, they’ve been able to get by. There wasn’t ever the need to reach out, coordinate, or cooperate. Trying to work with these maverick teams can be a challenge in itself. This is really where management is more complicated.
We can make our APIs as simple as we want, but they’re only masking the greater complexity of creating the system. As newer distributed systems frameworks come out, they’re changing how data is processed; they’re not fundamentally altering the complexity of these big data systems.
I really like some key concepts explained. For example:
Chapter 2 Architecture. One of the problems with service composition is that connecting various components can easily turn into an integration nightmare.
Chapter 5 Coordination. What are physical, logical clock, and vector clocks?
Chapter 8 Fault tolerance. What is a partial failure, and what is the diff between human, computer, and process resilience?
Chapter 9 Security. Highly recommended for those who want to understand the mechanics: threats, policies, confidentiality, privacy, encryption, firewall, GDPR, etc.
Enjoy.
Andrew Butenko 