What do you think?
Rate this book
Practical Microservices: Build Event-Driven Architectures with Event Sourcing and CQRS
MVC and CRUD make software easier to write, but harder to change. Microservice-based architectures can help even the smallest of projects remain agile in the long term, but most tutorials meander in theory or completely miss the point of what it means to be microservice-based. Roll up your sleeves with real projects and learn the most important concepts of evented architectures. You'll have your own deployable, testable project and a direction for where to go next. Much ink has been spilled on the topic of microservices, but all of this writing fails to accurately identity what makes a system a monolith, define what microservices are, or give complete, practical examples, so you're probably left thinking they have nothing to offer you. You don't have to be at Google or Facebook scale to benefit from a microservice-based architecture. Microservices will keep even small and medium teams productive by keeping the pieces of your system focused and decoupled. Discover the basics of message-based architectures, render the same state in different shapes to fit the task at hand, and learn what it is that makes something a monolith (it has nothing to do with how many machines you deploy to). Conserve resources by performing background jobs with microservices. Deploy specialized microservices for registration, authentication, payment processing, e-mail, and more. Tune your services by defining appropriate service boundaries. Deploy your services effectively for continuous integration. Master debugging techniques that work across different services. You'll finish with a deployable system and skills you can apply to your current project. Add the responsiveness and flexibility of microservices to your project, no matter what the size or complexity. What You
While the principles of this book transcend programming language, the code examples are in Node.js because JavaScript, for better or worse, is widely read. You'll use PostgreSQL for data storage, so familiarity with it is a plus. The books does provide Docker images to make working with PostgreSQL a bit easier, but extensive Docker knowledge is not required.
While the principles of this book transcend programming language, the code examples are in Node.js because JavaScript, for better or worse, is widely read. You'll use PostgreSQL for data storage, so familiarity with it is a plus. The books does provide Docker images to make working with PostgreSQL a bit easier, but extensive Docker knowledge is not required.
292 pages, Paperback
Published May 19, 2020
43 people are currently reading
254 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 - 10 of 10 reviews
July 23, 2021
I want to shout this message from the rooftops: Microservices are a data model, not a deployment strategy!
I've seen company after company claim to do "microservices" when it's really just databases behind HTTP servers, and they seem utterly blind to the problems and complexity that comes from that kind of model. I think the word "microservices" is kind of tainted now, so I appreciated how the author focused on using the term "components" instead (since that word isn't at all overloaded, heh). But vocabulary aside, I love the kind of thinking that this book encourages. When I got to the chapter about aggregators I almost cried imagining having to make a single database query to load all the necessary data for a page. Compare that to a project I'm working on where you have to make at least a half-dozen API calls to load a single page, every single time. I don't know why anyone thinks that is the right way.
Unfortunately I don't know if I'll ever be in a position to promote this kind of architecture at work. But it's nice to dream.
The examples in the book are admittedly a little contrived, but they're more realistic than a todo list. He tackles some important topics like registration and authentication. But then other things he says are really important while leaving them as an exercise for the reader. I don't think after reading this book that I'm fully equipped to go out there and build a full microservice-based system, but at least the book helps me start thinking the right way. That's something.
I wish more people knew about this.
I've seen company after company claim to do "microservices" when it's really just databases behind HTTP servers, and they seem utterly blind to the problems and complexity that comes from that kind of model. I think the word "microservices" is kind of tainted now, so I appreciated how the author focused on using the term "components" instead (since that word isn't at all overloaded, heh). But vocabulary aside, I love the kind of thinking that this book encourages. When I got to the chapter about aggregators I almost cried imagining having to make a single database query to load all the necessary data for a page. Compare that to a project I'm working on where you have to make at least a half-dozen API calls to load a single page, every single time. I don't know why anyone thinks that is the right way.
Unfortunately I don't know if I'll ever be in a position to promote this kind of architecture at work. But it's nice to dream.
The examples in the book are admittedly a little contrived, but they're more realistic than a todo list. He tackles some important topics like registration and authentication. But then other things he says are really important while leaving them as an exercise for the reader. I don't think after reading this book that I'm fully equipped to go out there and build a full microservice-based system, but at least the book helps me start thinking the right way. That's something.
I wish more people knew about this.
April 26, 2020
Poperly describes the core concepts and points out some common mistakes like using Kafka as message store.
However, I won't be choosing microservices architecture for any of my projects until the project becomes so big that tens of developers have to work on the code base. Even then, won't let them grow out of control (like what happened at Uber).
Just recently, I was unfortunate enough to work on one of these projects that supposedly used microservices architecture but it was one of fake ones that is described in the book too. I ended up replacing Kafka with a simple postgres backed queue for background jobs and merged all of the projects/microservices into a monolith. End result? Everybody is happy now from developers to ops.
To be clear, I would definitely use what I have learned from this book if I ever develop microservices but the kind of projects that I deal with now do not benefit from it.
However, I won't be choosing microservices architecture for any of my projects until the project becomes so big that tens of developers have to work on the code base. Even then, won't let them grow out of control (like what happened at Uber).
Just recently, I was unfortunate enough to work on one of these projects that supposedly used microservices architecture but it was one of fake ones that is described in the book too. I ended up replacing Kafka with a simple postgres backed queue for background jobs and merged all of the projects/microservices into a monolith. End result? Everybody is happy now from developers to ops.
To be clear, I would definitely use what I have learned from this book if I ever develop microservices but the kind of projects that I deal with now do not benefit from it.
April 19, 2020
What I personally like about this book, is that it does not use de facto tools to show the concepts of event-driven architecture but uses a rather simple low-level stack to present and show the concepts rather well. For anyone in the industry for some time, it’s definitely not a complex read, a nice conceptual reminder. Maybe too much of unneeded small-talk and “wow, well done!” for a more mature reader thus, -1 point from there. Could have saved some amount of pages on that :)
July 10, 2021
This book was recommended to me as a good introduction to the core concepts of event sourcing design and it delivered. Awesome read. Anxious to dig into the sample code and followup with other books / articles. For me, event sourcing is to MVC as functional programming was to object-oriented programming. Big (potential) game changer for me.
June 15, 2020
The book isn't really about microservices. It's more about the ideas and principles of writing modular software and a good introduction to Event Sourcing and CQRS. Read the full review.
March 14, 2023
I read this book to understand the principles of event sourcing and CQRS, and how to apply those to real-world problems. So the topic fit was good for me, but note that it's not a book about how to deploy and operate microservices. So the title is quite misleading.
The book teaches the fundamental concepts alright, but honestly it was no deeper than you find in an average blog post about the topic.
The practical implementation uses a single-instance Postgres DB for events and derived data (views) that are eventually consistent. Most of the benefits of the event-driven architecture aren't realized in the book, but are hypothetical and requires a lot more work, which is just covered lightly in the book. Postgres is good because it's battletested, but it's not reactive nor horizontally write-scalable. Most glaringly, using an ACID-compliant single-writer database to build an architecture that is eventually consistent feels a bit like using a Ferrari to build a Toyota.
Pros:
- It does actually build a real application. This keeps the book grounded and on track towards some practical use cases, such as user registration, content submissions and procedures with side effects like email and video encoding.
- End-of-chapter summaries provide good recaps that can be useful for skimming.
- The fundamental concepts of commands, events, categories, streams and projections are explained reasonably, and provides a good base for reasoning about these systems and building new abstractions on top.
Cons:
- There are very few pointers to existing systems or where to learn more, which is particularly needed in a book that covers only a few aspects of these systems. In fact, it explicitly cautions the reader about Kafka, which seems like the most natural fit for an event-based system. The motivation for that is very shallow (something like "Kafka is a message system, not a message store"). Well, perhaps initially, but Postgres is definitely not designed primarily for storing JSON blobs either.
- Horizontally scalable persistence would need fundamental changes, since the design relies on a global counter for all events.
- Minuscule coverage of data deletion, which can be important to reclaim storage and for regulatory purposes. Since everything else assumes that the event log is immutable, deletions are actually non-trivial and deserves at least a section, probably more like a full chapter.
- The model isn't taken to its natural destination, which is an end-to-end stream of events both starting and landing in the UI. In other words, there's no reactivity, which is a huge potential benefit of the architecture. It could have been implemented with e.g. websockets, but instead, we get hacks like an "operation in progress page", even for simple mutations like changing the name of a video.
- Related to that: derived data, i.e. projections, is simply data. There's no way to get a stream of the current state, or a change stream, which would have been useful for reactivity. Postgres has triggers and notifications, which is used in e.g. Hasura. If you insist on using Postgres, those features should at least be mentioned.
- The section defending registration of multiple users with the same email makes me cringe (something like "Well, how likely is that in practice?" and "We can add another boolean for duplicates"). Eventual consistency may be required for massive data ingestion but each individual component should be able to have internal consistency, at least by default.
- I like that the book stresses that idempotency is critical, but it fails at mentioning the implications of this as you change your software. For example, if you change the way you validate an email address, you'd be at risk of invalidating an existing user, depending on the structure of your events and commands. This isn't unsolvable, but these invariants need to be taught in a coherent way.
- The diagrams in the book are so simplistic that they're virtually useless. There is tremendous opportunity to use diagrams to quickly and accurately explain how the system works–for instance what operations are concurrent and where there are clear-cut happens-before relationships. There's not a single sequence diagram, or a data flow diagram. There's not even a component dependency diagram. This means it's very tedious to get a system overview.
- Not a single mention of circular dependencies and its dangers. If you don't know what you're doing, it's very easy to accidentally cause an infinite loop of commands/events that would flood your db.
The book teaches the fundamental concepts alright, but honestly it was no deeper than you find in an average blog post about the topic.
The practical implementation uses a single-instance Postgres DB for events and derived data (views) that are eventually consistent. Most of the benefits of the event-driven architecture aren't realized in the book, but are hypothetical and requires a lot more work, which is just covered lightly in the book. Postgres is good because it's battletested, but it's not reactive nor horizontally write-scalable. Most glaringly, using an ACID-compliant single-writer database to build an architecture that is eventually consistent feels a bit like using a Ferrari to build a Toyota.
Pros:
- It does actually build a real application. This keeps the book grounded and on track towards some practical use cases, such as user registration, content submissions and procedures with side effects like email and video encoding.
- End-of-chapter summaries provide good recaps that can be useful for skimming.
- The fundamental concepts of commands, events, categories, streams and projections are explained reasonably, and provides a good base for reasoning about these systems and building new abstractions on top.
Cons:
- There are very few pointers to existing systems or where to learn more, which is particularly needed in a book that covers only a few aspects of these systems. In fact, it explicitly cautions the reader about Kafka, which seems like the most natural fit for an event-based system. The motivation for that is very shallow (something like "Kafka is a message system, not a message store"). Well, perhaps initially, but Postgres is definitely not designed primarily for storing JSON blobs either.
- Horizontally scalable persistence would need fundamental changes, since the design relies on a global counter for all events.
- Minuscule coverage of data deletion, which can be important to reclaim storage and for regulatory purposes. Since everything else assumes that the event log is immutable, deletions are actually non-trivial and deserves at least a section, probably more like a full chapter.
- The model isn't taken to its natural destination, which is an end-to-end stream of events both starting and landing in the UI. In other words, there's no reactivity, which is a huge potential benefit of the architecture. It could have been implemented with e.g. websockets, but instead, we get hacks like an "operation in progress page", even for simple mutations like changing the name of a video.
- Related to that: derived data, i.e. projections, is simply data. There's no way to get a stream of the current state, or a change stream, which would have been useful for reactivity. Postgres has triggers and notifications, which is used in e.g. Hasura. If you insist on using Postgres, those features should at least be mentioned.
- The section defending registration of multiple users with the same email makes me cringe (something like "Well, how likely is that in practice?" and "We can add another boolean for duplicates"). Eventual consistency may be required for massive data ingestion but each individual component should be able to have internal consistency, at least by default.
- I like that the book stresses that idempotency is critical, but it fails at mentioning the implications of this as you change your software. For example, if you change the way you validate an email address, you'd be at risk of invalidating an existing user, depending on the structure of your events and commands. This isn't unsolvable, but these invariants need to be taught in a coherent way.
- The diagrams in the book are so simplistic that they're virtually useless. There is tremendous opportunity to use diagrams to quickly and accurately explain how the system works–for instance what operations are concurrent and where there are clear-cut happens-before relationships. There's not a single sequence diagram, or a data flow diagram. There's not even a component dependency diagram. This means it's very tedious to get a system overview.
- Not a single mention of circular dependencies and its dangers. If you don't know what you're doing, it's very easy to accidentally cause an infinite loop of commands/events that would flood your db.
August 3, 2022
This was just the right book you need for this until it isn't. You can't write an enitre book on Practical microservices skip concurrency & snapshotting(scaling & cost) altogether. The last chapter needs to be 3 more chapters.
1. Handling concurrency in such architectures
2. Snapshotting to reduce cost & improve performance
3. Event data update & migration
I hope the next version of this book considers it.
1. Handling concurrency in such architectures
2. Snapshotting to reduce cost & improve performance
3. Event data update & migration
I hope the next version of this book considers it.
September 14, 2023
- อย่าคาดหวังเรื่อง microservices (เค้าทำ modular monolith)
- อย่าคาดหวังเรื่อง message broker (เค้าใช้ Postgres broker)
- อย่าคาดหวังเรื่อง code (มันเก่ามาก และมันไม่ใช่ microservices)
- อย่าคาดหวังเรื่อง pattern และ practices (เค้าเน้นทำ project ในหนังสือ)
- อย่าคาดหวังเรื่อง message broker (เค้าใช้ Postgres broker)
- อย่าคาดหวังเรื่อง code (มันเก่ามาก และมันไม่ใช่ microservices)
- อย่าคาดหวังเรื่อง pattern และ practices (เค้าเน้นทำ project ในหนังสือ)
December 22, 2020
Good practical introduction to Event Sourcing and CQRS, which enabled me to grok the concepts involved.
December 27, 2020
This book has what looks like a good trajectory into Microservices topics but has a very terrible start that made me give up on the first chapter. It starts be describing an application built in some Node.JS framework called express.js by simply listing the contents of each of the files of that app with little explanation how they fit together. I wish it ramped me up correctly so that I advance to the other topics it addresses and which I find relevant to the subject of Microservices. I sadly switched to a .Net Core based book because of how it ensured that my transition from one chapter to the next is smooth. I will not recommend it unless you are proficient in the Express.js framework.
Displaying 1 - 10 of 10 reviews