books_are_nice_and_enjoyable's review against another edition
4.5
In the introduction section, Newman wrote in the section about 'Why I wrote the book' that:
"Microservices have become, for many, the default architectural choice. This is something that I think is hard to justify, and I wanted a chance to share why. This book isn’t pro microservices, nor is it anti microservices. I just want to make sure that I’ve properly explored the context in which these ideas work well and shared the problems they can cause."
He succeeded, in my view.
The book's coverage of ownership models and organizational structures (chp. 15) in particular included some very important points that motivated me to read the book Team Topologies right after this one, and later to share some of the learnings from that book with management who would otherwise likely not have been aware of these (important!) dimensions and factors. But I also shared multiple other insights from this book with members of my team, it's really just a very decent book.
"Microservices have become, for many, the default architectural choice. This is something that I think is hard to justify, and I wanted a chance to share why. This book isn’t pro microservices, nor is it anti microservices. I just want to make sure that I’ve properly explored the context in which these ideas work well and shared the problems they can cause."
He succeeded, in my view.
The book's coverage of ownership models and organizational structures (chp. 15) in particular included some very important points that motivated me to read the book Team Topologies right after this one, and later to share some of the learnings from that book with management who would otherwise likely not have been aware of these (important!) dimensions and factors. But I also shared multiple other insights from this book with members of my team, it's really just a very decent book.
elenab_elless's review against another edition
4.0
A book that is more about ideas behind microservices and fine grained systems than technology specifics.
The key principles for microservice architectures:
- You want services that are loosely coupled and highly cohesive - so find boundaries that help ensure that related behaviour is in one place and that communicate with other boundaries as loosely as possible.
- Avoid database integration
- Understand the trade-offs of REST and RPC, but strongly consider REST as a good starting point for request/response integration.
- Prefer choreography over orchestration.
- Avoid breaking changes and the need to version by understanding Postel's Law and using tolerant readers.
- Think of user interfaces as compositional layers.
- Focus on maintaining the ability to release one service independently from another - you need one CI build per microservice.
- If possible, move to a single-service per host/container.
- Automate everything.
- Optimize for fast feedback, and separate types of tests accordingly
- Avoid the need for end-to-end tests whenever possible by using consumer-driven contracts.
- Use consumer-driven contacts to provide focus points for conversation between teams.
- Understand the trade-off between putting more effort into testing and detecting issues faster in production (optimizing MTBF vs MTTR)
- It is preferable that teams aligned along bounded contexts
- An essential part of building a resilient system is the ability to safely degrade functionality
- Prepare for the sorts of failure that can happen with distributed architectures. Handle failure by using timeouts, circuit breakers, bulkheads and isolation
- Consider using blue/green or canary release techniques to separate deployment from release
- Use semantic monitoring to see if your system is behaving correctly, by injecting synthetic transactions into your system to simulate real-user behavior.
- Aggregate your logs, and aggregate your stats, so that when you see a problem you can drill down to the source.
I liked the cautionary tales and examples, as well as the idea of embracing the concept of evolutionary architecture, where your system bends and flexes and changes over time as you learn new things.
Change is inevitable. Embrace it.
Also, funny side remark:
The main thing I noticed, though, was that the hard drives were attached by velcro. I asked one of the Googlers why that was. “Oh,” he said, “the hard drives fail so much we don’t want them screwed in. We just rip them out, throw them in the bin, and velcro in a new one.”
The key principles for microservice architectures:
- You want services that are loosely coupled and highly cohesive - so find boundaries that help ensure that related behaviour is in one place and that communicate with other boundaries as loosely as possible.
- Avoid database integration
- Understand the trade-offs of REST and RPC, but strongly consider REST as a good starting point for request/response integration.
- Prefer choreography over orchestration.
- Avoid breaking changes and the need to version by understanding Postel's Law and using tolerant readers.
- Think of user interfaces as compositional layers.
- Focus on maintaining the ability to release one service independently from another - you need one CI build per microservice.
- If possible, move to a single-service per host/container.
- Automate everything.
- Optimize for fast feedback, and separate types of tests accordingly
- Avoid the need for end-to-end tests whenever possible by using consumer-driven contracts.
- Use consumer-driven contacts to provide focus points for conversation between teams.
- Understand the trade-off between putting more effort into testing and detecting issues faster in production (optimizing MTBF vs MTTR)
- It is preferable that teams aligned along bounded contexts
- An essential part of building a resilient system is the ability to safely degrade functionality
- Prepare for the sorts of failure that can happen with distributed architectures. Handle failure by using timeouts, circuit breakers, bulkheads and isolation
- Consider using blue/green or canary release techniques to separate deployment from release
- Use semantic monitoring to see if your system is behaving correctly, by injecting synthetic transactions into your system to simulate real-user behavior.
- Aggregate your logs, and aggregate your stats, so that when you see a problem you can drill down to the source.
I liked the cautionary tales and examples, as well as the idea of embracing the concept of evolutionary architecture, where your system bends and flexes and changes over time as you learn new things.
Change is inevitable. Embrace it.
Also, funny side remark:
The main thing I noticed, though, was that the hard drives were attached by velcro. I asked one of the Googlers why that was. “Oh,” he said, “the hard drives fail so much we don’t want them screwed in. We just rip them out, throw them in the bin, and velcro in a new one.”
mattj256's review against another edition
5.0
A high-level overview of the advantages (and disadvantages) of microservices, with a lot of high-level information about how to handle various aspects of system architecture.
As someone who is new to microservices, I thought this book was great. I'm mostly looking for high-level information, not code samples. (If you're looking for step-by-step instructions of how to build things, this is not the book for you.)
The most interesting parts of the book were the occasional real-world examples. The author describes something that broke in production, why it broke, and what steps were taken to make the system more resilient going forward. Definitely recommended if you're looking for a high-level overview.
As someone who is new to microservices, I thought this book was great. I'm mostly looking for high-level information, not code samples. (If you're looking for step-by-step instructions of how to build things, this is not the book for you.)
The most interesting parts of the book were the occasional real-world examples. The author describes something that broke in production, why it broke, and what steps were taken to make the system more resilient going forward. Definitely recommended if you're looking for a high-level overview.
albcorp's review against another edition
5.0
This is a book that perfectly fulfills the role that it set for itself. Throughout, the writing was clear and direct, and had just the right level of informality to make it easier to read. It did not attempt to tell me everything about the subject, and as a result I feel confident that I have gained a very useful overview. The final chapter summary was particularly helpful in this respect. I wish every book had one as good as this #
afuerstenau's review against another edition
5.0
Very interesting, not so long read about different aspects regarding micro services. Spiced up with stories, models and code. Definitely worth reading for me.
lucapette's review against another edition
2.0
It felt more like a series of blog posts (sometimes, paragraphs seemed very disconnected from each other)