Scan barcode
nheer's review
informative
inspiring
reflective
medium-paced
5.0
"Monolith to Microservices" is a highly insightful book that diligently tackles the complex process of transitioning an application from monolithic architecture to microservices. It bridges the gap between theory and practice, bringing valuable pragmatic recommendations to the table.
The book excels in delineating modern architectural patterns, providing an updated framework for individuals grappling with contemporary software development needs. Not only does it discuss the 'how-to' extensively, but it also lays emphasis on the 'why', offering readers the understanding to make informed decisions rather than blindly following best practices.
A key strength of this book lies in its balanced view. The author doesn't merely paint an idyllic picture of microservices but delves into potential pitfalls and challenges too. This clear-eyed perspective extends beyond pure technical implications, touching on organizational, cultural, and operational pitfalls that one might encounter during the transition.
This feature turns the book into more than just a technical guide; it becomes a holistic tool for organizations seeking to navigate the rough waters of infrastructure transformation. The author's articulate style blended with relatable examples and practical tips aids in transforming esoteric concepts into comprehensible knowledge.
In conclusion, "Monolith to Microservices" is a must-read for anyone involved in or looking to embark on the journey of transitioning from a monolithic architecture to microservices. It is woven with wisdom, cautionary tales, and helpful strategies that will guide you effectively through the complexity of such a transformation.
xii_emisario's review
informative
medium-paced
4.0
El mensaje del libro está justo al final: no adopte una arquitectura nueva solo por copiar a otros, entienda su contexto y busque soluciones a sus problemas.
rahwa's review
5.0
Informative and easy to understand, with lots of real life examples. Focused on strategies and practices rather than which tech stack to use. Also full of recommendations of other books to read for more information on a specific subject.
jasminenoack's review
informative
slow-paced
3.75
good content overall, when they start listing patterns they aren't different enough to justify being different patterns consistently
hundred's review
4.0
Overall I found this book to be an excellent, practical guide to approaching a monolith decomposition, though I have a few issues with it.
The Good:
- Newman starts by presenting all of the reasons why you might want to do microservices and how you could solve them WITHOUT doing microservices. This was the main complaint with "Building Microservices" which presents microservices without being too critical about when one would want to avoid microservices.
- There's a great section describing how one might help their organization to make a change to microservices. This section builds nicely on Newman's second chapter of "Building Microservices", "The Evolutionary Architect".
- There are some good decomposition patterns, notably: branch by abstraction and the strangler fig pattern.
- There is an EXCELLENT section on the growing pains one might encounter when they start adopting microservices. I found this section to be particularly useful because it's leveraging Newman's considerable experience as a consultant, in which he's seen lots of different companies adopt microservices and encounter problems.
- Newman focuses on core, long-lived aspects of migrations instead of on specific technologies (which will be outdated in a year), with just enough technology examples to help one connect concepts to real world examples.
The Not So Good:
- The actual decomposition recommendations almost entirely ignore the issues brought up in the "Growing Pains" chapter. One huge issue which microservices bring up is that network calls have a different guarantee than databases: they may fail, they aren't transactional, they may timeout, etc. This causes big problems with two proposals in the book:
- Dual write migrations - A migration strategy in which one writes to both systems using rest calls, migrates data, and then changes reads to the new source of truth. The big issue with this strategy is keeping both stores consistent since calls to either system can fail or timeout. In my experience, this is one of the hardest parts of migrations, and it's barely handled as written. I would have loved to see more examples of how companies handled this, from Newman's experience.
- Orchestrated Sagas - A similar issue arises in Orchestrated Sagas. There may be partial failures on any part of the way with both the inbound saga and the "compensating transaction". The book suggests using choreographed transactions where possible but doesn't bring up this danger of orchestrated transactions.
I'm wondering if it would have been better to restructure the book to first present the unique issues which microservice architectures encounter and then present decomposition techniques which lead to architectures which are resilient to these issues.
- The decomposition examples given are pretty straightforward. This is probably to make the points very clear, but it would have been great to have at least one example of a decomposition which was tricky or which wasn't worth decomposing at all. Newman mentions that such examples exist, but doesn't do any further examination.
Overall:
Overall, a very practical guide to migrating from a monolith to microservices, and (importantly) why you might not want to.
The Good:
- Newman starts by presenting all of the reasons why you might want to do microservices and how you could solve them WITHOUT doing microservices. This was the main complaint with "Building Microservices" which presents microservices without being too critical about when one would want to avoid microservices.
- There's a great section describing how one might help their organization to make a change to microservices. This section builds nicely on Newman's second chapter of "Building Microservices", "The Evolutionary Architect".
- There are some good decomposition patterns, notably: branch by abstraction and the strangler fig pattern.
- There is an EXCELLENT section on the growing pains one might encounter when they start adopting microservices. I found this section to be particularly useful because it's leveraging Newman's considerable experience as a consultant, in which he's seen lots of different companies adopt microservices and encounter problems.
- Newman focuses on core, long-lived aspects of migrations instead of on specific technologies (which will be outdated in a year), with just enough technology examples to help one connect concepts to real world examples.
The Not So Good:
- The actual decomposition recommendations almost entirely ignore the issues brought up in the "Growing Pains" chapter. One huge issue which microservices bring up is that network calls have a different guarantee than databases: they may fail, they aren't transactional, they may timeout, etc. This causes big problems with two proposals in the book:
- Dual write migrations - A migration strategy in which one writes to both systems using rest calls, migrates data, and then changes reads to the new source of truth. The big issue with this strategy is keeping both stores consistent since calls to either system can fail or timeout. In my experience, this is one of the hardest parts of migrations, and it's barely handled as written. I would have loved to see more examples of how companies handled this, from Newman's experience.
- Orchestrated Sagas - A similar issue arises in Orchestrated Sagas. There may be partial failures on any part of the way with both the inbound saga and the "compensating transaction". The book suggests using choreographed transactions where possible but doesn't bring up this danger of orchestrated transactions.
I'm wondering if it would have been better to restructure the book to first present the unique issues which microservice architectures encounter and then present decomposition techniques which lead to architectures which are resilient to these issues.
- The decomposition examples given are pretty straightforward. This is probably to make the points very clear, but it would have been great to have at least one example of a decomposition which was tricky or which wasn't worth decomposing at all. Newman mentions that such examples exist, but doesn't do any further examination.
Overall:
Overall, a very practical guide to migrating from a monolith to microservices, and (importantly) why you might not want to.
More...