What do you think?
Rate this book
Monolith to Microservices: Sustaining Productivity While Detangling the System
How do you detangle a monolithic system and migrate it to a microservices architecture? How do you do it while maintaining business-as-usual? As a companion to Sam Newman's extremely popular Building Microservices, this new book details a proven method for transitioning an existing monolithic system to a microservice architecture.
With many illustrative examples, insightful migration patterns, and a bevy of practical advice to transition your monolith enterprise into a microservice operation, this practical guide covers multiple scenarios and strategies for a successful migration, from initial planning all the way through application and database decomposition. You'll learn several tried and tested patterns and techniques that you can use as you migrate your existing architecture.
*Ideal for organizations looking to transition to microservices, rather than rebuild
*Helps companies determine whether to migrate, when to migrate, and where to begin
*Addresses communication, integration, and the migration of legacy systems
*Discusses multiple migration patterns and where they apply
*Provides database migration examples, along with synchronization strategies
*Explores application decomposition, including several architectural refactoring patterns
*Delves into details of database decomposition, including the impact of breaking referential and transactional integrity, new failure modes, and more
With many illustrative examples, insightful migration patterns, and a bevy of practical advice to transition your monolith enterprise into a microservice operation, this practical guide covers multiple scenarios and strategies for a successful migration, from initial planning all the way through application and database decomposition. You'll learn several tried and tested patterns and techniques that you can use as you migrate your existing architecture.
*Ideal for organizations looking to transition to microservices, rather than rebuild
*Helps companies determine whether to migrate, when to migrate, and where to begin
*Addresses communication, integration, and the migration of legacy systems
*Discusses multiple migration patterns and where they apply
*Provides database migration examples, along with synchronization strategies
*Explores application decomposition, including several architectural refactoring patterns
*Delves into details of database decomposition, including the impact of breaking referential and transactional integrity, new failure modes, and more
255 pages, Paperback
Published September 4, 2019
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 78 reviews
November 26, 2019
Sam Newman did it again. He has written a very good book on microservices.
The one which is technology-agnostic & in the same time - very practical.
What I like most is that Sam doesn't try to avoid answering uncomfortable questions - e.g. what to do when we have queries spanning across separate storages. Another positive fact is that we're not getting 100th description of what is CQRS & Eventsourcing.
What else? There's no zealotry, no expressed preferences regarding any particular tools (except Sam's love towards FaaS ;>), examples presented are good enough (not really deeply into the details, but on a sufficient level).
What did I miss? Some more explicit statements regarding data redundancy (pragmatism over normalization), helpful conventions (append-only approach & immutability of selected data - this was partially covered in the chapter about deletes).
Strongly recommended. Short, but a very decent book.
P.S. The version I've got was sponsored by nginx (2019.10) - it may differ slightly from the version which will be mass-printed.
The one which is technology-agnostic & in the same time - very practical.
What I like most is that Sam doesn't try to avoid answering uncomfortable questions - e.g. what to do when we have queries spanning across separate storages. Another positive fact is that we're not getting 100th description of what is CQRS & Eventsourcing.
What else? There's no zealotry, no expressed preferences regarding any particular tools (except Sam's love towards FaaS ;>), examples presented are good enough (not really deeply into the details, but on a sufficient level).
What did I miss? Some more explicit statements regarding data redundancy (pragmatism over normalization), helpful conventions (append-only approach & immutability of selected data - this was partially covered in the chapter about deletes).
Strongly recommended. Short, but a very decent book.
P.S. The version I've got was sponsored by nginx (2019.10) - it may differ slightly from the version which will be mass-printed.
January 27, 2020
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.
June 12, 2020
What I liked a most in the book is that is short and dense. It have everything in proper amount of length, giving a good overview of the problems, and provide some of possible solution to them with a bit of “what I would do”.
Really good book.
Really good book.
June 26, 2020
Practical advice on how to move to Microservices. It also discusses the reasons you would want to migrate your app to a Microservices architectural style and even gives alternatives that might help you achieve the same goal without migrating. I liked the realistic examples, trade-off analysis.
I enjoyed Chapter 4, on Decomposing the Database the most, because I think that's probably the hardest part when migrating to Microservices (and the one that gets the least amount of coverage in many resources). The patterns cover problems we've all seen in the wild and the solutions are pragmatic and useful.
I enjoyed Chapter 4, on Decomposing the Database the most, because I think that's probably the hardest part when migrating to Microservices (and the one that gets the least amount of coverage in many resources). The patterns cover problems we've all seen in the wild and the solutions are pragmatic and useful.
February 1, 2022
I confess that the title made me think of a very boring and strictly tactical book. However the book starts with a strategic view of microservices, specifying the benefits and drawbacks of the approach regarding large escale engineering and startups as well.
Later on, SN covers some very useful patterns when it comes to design microservices from unstructured monolithic architectures.
Furthermore, it covers precisely the challenges of tackling databases when decoupling your monolithic architecture.
Finally, I really appreciated the sobered and mature view of SN considering the impacts os scaling your microservices architecture on large scale software engineering taking into account the cognitive load that some organizations might face if they are too much permissive.
This is an essential book for architects and software engineers that wish to improve their knowledge on possible challenges and solutions dealing with microservices. In my point of view this book is paramount for technological leaders - CTOs, Chief Architects and so on - that are facing a technological growth and intend to employ some evolutionary software architecture strategy.
Later on, SN covers some very useful patterns when it comes to design microservices from unstructured monolithic architectures.
Furthermore, it covers precisely the challenges of tackling databases when decoupling your monolithic architecture.
Finally, I really appreciated the sobered and mature view of SN considering the impacts os scaling your microservices architecture on large scale software engineering taking into account the cognitive load that some organizations might face if they are too much permissive.
This is an essential book for architects and software engineers that wish to improve their knowledge on possible challenges and solutions dealing with microservices. In my point of view this book is paramount for technological leaders - CTOs, Chief Architects and so on - that are facing a technological growth and intend to employ some evolutionary software architecture strategy.
April 5, 2020
One word: BORING
The book is basically 2~3 chapters and bunch of filler chapters.
If you have some experience or got your hands dirty already with microservices, then probably the majority of the book is known to you, the material you read and watch online on daily basis covers the majority of the book.
If you don't have any experience with microservices AND you've been living in a cave to avoid online material about microservices then it might be a good book for you.
The book is basically 2~3 chapters and bunch of filler chapters.
If you have some experience or got your hands dirty already with microservices, then probably the majority of the book is known to you, the material you read and watch online on daily basis covers the majority of the book.
If you don't have any experience with microservices AND you've been living in a cave to avoid online material about microservices then it might be a good book for you.
July 16, 2021
A great book presenting patterns for transforming a monolithic system into a microservice architecture. The Sam Newman’s exposition is clear (but dense!), very pragmatic and grounded in reality, reflecting real-life experience in countless projects. It gives me a lot of confidence that a good chunk of the initial chapters is spent giving you reasons not to choose microservices: all the pros and cons are evaluated, and alternatives are proposed. This type of architecture is not for everybody, especially not for startups.
If after all the warnings you’re still convinced that microservices are the way to go, the author proceeds by defining basic concepts and outlining the general plan for a successful migration. DDD is presented as an invaluable tool for identifying service boundaries, and several other aspects are also explored: cultural changes, team satisfaction, ownership, etc. because technical matters are not the only subject that needs to be considered.
The core of the book is in chapters 3 and 4, which present a catalog of high-level patterns for splitting a monolith both from the service’s perspective and from the database’s perspective. The solutions to common problems are explained at different levels of detail: some involve fiddling with networking and infrastructure, others modifying service code via refactoring, and others propose changes in the database or its tables – but never going into actual implementation details.
Several of the patterns felt familiar; I’ve probably applied them in some capacity without knowing they existed (but I wish I knew them before!) I was very satisfied with the patterns and the methodology, it encourages incremental, evolutionary changes in architecture while offering multiple alternatives; sometimes the author shows his preference for one over the other but he’s emphatic that all depends on the context of each problem. For a an example of the plethora of options available for each situation, take a look at the discussion of how to split reference data in a database.
A couple of the patterns present somewhat surprising solutions, I really liked this out-of-the-box thinking, away from dogmatisms and from the tyranny of batch processing and monolithic databases, making a good case for event-based microservice architectures.
The final chapter deals with practical considerations and tips when the number of services starts to grow, and when to expect the problems to pop up. Interesting stuff to have in mind. Also in this chapter and in the whole book in general, the author recommends open source tools for different needs, I’ll list the most useful for my own future reference: change data capture systems, service meshes, GitHub Scientist, FlywayDB, SchemaSpy, ELK, Jaeger, pact.io.
A final word of advice: bear in mind that this book is not a standalone reference. To gain a good understanding of the details of implementing a microservice architecture, one needs to also read “Building Microservices” by the same author, which I intend to do – the perfect companion for this volume. Needless to say, I highly recommend this book to any architect considering jumping into the microservice bandwagon, but doing so in a responsible way.
If after all the warnings you’re still convinced that microservices are the way to go, the author proceeds by defining basic concepts and outlining the general plan for a successful migration. DDD is presented as an invaluable tool for identifying service boundaries, and several other aspects are also explored: cultural changes, team satisfaction, ownership, etc. because technical matters are not the only subject that needs to be considered.
The core of the book is in chapters 3 and 4, which present a catalog of high-level patterns for splitting a monolith both from the service’s perspective and from the database’s perspective. The solutions to common problems are explained at different levels of detail: some involve fiddling with networking and infrastructure, others modifying service code via refactoring, and others propose changes in the database or its tables – but never going into actual implementation details.
Several of the patterns felt familiar; I’ve probably applied them in some capacity without knowing they existed (but I wish I knew them before!) I was very satisfied with the patterns and the methodology, it encourages incremental, evolutionary changes in architecture while offering multiple alternatives; sometimes the author shows his preference for one over the other but he’s emphatic that all depends on the context of each problem. For a an example of the plethora of options available for each situation, take a look at the discussion of how to split reference data in a database.
A couple of the patterns present somewhat surprising solutions, I really liked this out-of-the-box thinking, away from dogmatisms and from the tyranny of batch processing and monolithic databases, making a good case for event-based microservice architectures.
The final chapter deals with practical considerations and tips when the number of services starts to grow, and when to expect the problems to pop up. Interesting stuff to have in mind. Also in this chapter and in the whole book in general, the author recommends open source tools for different needs, I’ll list the most useful for my own future reference: change data capture systems, service meshes, GitHub Scientist, FlywayDB, SchemaSpy, ELK, Jaeger, pact.io.
A final word of advice: bear in mind that this book is not a standalone reference. To gain a good understanding of the details of implementing a microservice architecture, one needs to also read “Building Microservices” by the same author, which I intend to do – the perfect companion for this volume. Needless to say, I highly recommend this book to any architect considering jumping into the microservice bandwagon, but doing so in a responsible way.
November 29, 2020
A nice book with lots of recepies, patterns and best practices for breaking monoliths into microservices. Not too detailed into tech stuff, but still good anough.
May 10, 2020
I went through many of mentioned problems in hard way. Anyway, it was a good opportunity to stop and think. I like that this book does not push microservices for everything. Architectonic hints described in the book could be handy for any modular system.
I got a free copy via nginx
I got a free copy via nginx
Read
October 14, 2022I'm depressed now
Read
January 22, 2020A great thing about this book is that it covers a lot of the non-technical prerequisites that need to be considered within an organization, before even bothering to attempt to migrate to a microservices architecture. Basic questions about “why” an organization would even want to do that are not-so common sense, but essential. Without knowing why your organization wants to make such a move most likely condemns the “IT department” to merely creating the legacy systems of tomorrow.
There is also coverage of methods to help advocate for such prerequisite organizational change, which is probably not something your average software developer is familiar with, so a very valuable read indeed.
The patterns for migrating from monoliths to microservices in Chapter 3 include some that are just useful pattens in any system migration or modification context, but the coverage is clear and reminded me of the times when I’d employed similar techniques myself. As is the case with design patterns, having a common vocabulary for them is a valuable aspect.
Chapter four covers decomposition of your classic relational database schemas into more microservices friendly granularity, without glossing over the trade-offs to be understood.
The last chapter overviews some types of issues that one might experience during an incremental journey to more and more microservices and perhaps a growing organization (if you are lucky to be part of a successful one!)
I read the Building Microservices book first, but found this one useful for its focus on migrating from a monolith / shared database nightmare to microservices. I’ll certainly take care to pull this back up when I’m facing some kind of migration issue, for inspiration or ideas I might forget in the meantime.
That said, if you can properly modularize your system(s) then you might be better to not even think about microservices, a point made in both this book and the earlier one.
I read the 1st edition - there’s several editing / typo problems throughout (mostly chapters 3 and 4 I think), but not so bad the content can’t be understood.
There is also coverage of methods to help advocate for such prerequisite organizational change, which is probably not something your average software developer is familiar with, so a very valuable read indeed.
The patterns for migrating from monoliths to microservices in Chapter 3 include some that are just useful pattens in any system migration or modification context, but the coverage is clear and reminded me of the times when I’d employed similar techniques myself. As is the case with design patterns, having a common vocabulary for them is a valuable aspect.
Chapter four covers decomposition of your classic relational database schemas into more microservices friendly granularity, without glossing over the trade-offs to be understood.
The last chapter overviews some types of issues that one might experience during an incremental journey to more and more microservices and perhaps a growing organization (if you are lucky to be part of a successful one!)
I read the Building Microservices book first, but found this one useful for its focus on migrating from a monolith / shared database nightmare to microservices. I’ll certainly take care to pull this back up when I’m facing some kind of migration issue, for inspiration or ideas I might forget in the meantime.
That said, if you can properly modularize your system(s) then you might be better to not even think about microservices, a point made in both this book and the earlier one.
I read the 1st edition - there’s several editing / typo problems throughout (mostly chapters 3 and 4 I think), but not so bad the content can’t be understood.
September 11, 2020
The book approaches the problem of migrating an existing monolithic architecture to a microservice architecture.
The book considers technical as well as non-technical issues involved in the migration.
The technical part of the book (Chapters 3 and 4) is still very high level. No programming language is used and no code examples are given.
Potential problems and possible solutions are clearly illustrated with pros and cons.
The first chapter introduces the monolithic design, its defining characteristics, its inherent limitations and how microservices can improve that.
Chapter 2 highlights the importance of careful planning before embarking on a migration process.
It suggests the need to consider implications in terms of team organization, skills, and costs.
The author also points out that migration to microservices is not a must and in some situations a monolithic design might actually be a better solution.
Chapter 3 discusses several patterns that can be used to incrementally migrate selected functionalities into a microservice.
It explores possible alternative solutions to common problems and describes positive and negative aspects of each.
Chapter 4 focuses on how a database that backs a monolith affects and is affected by the migration of some functionality to a microservice.
Splits and non splits solutions are considered together with repercussions on data access and transactions.
Chapter 5 is a sort of troubleshooting summary where potential migration problems are reviewed with solutions.
"Building Microservices" is another other book from the author that partly overlaps with this one but discusses microservices from a more general point of view.
"Monolith to Microservices" focuses more on the problem of migrating an existing monolithic system to one based on microservices.
In the book you will read several times "if you want to know more about this read my other book Building Microservices".
I found this very annoying.
The book considers technical as well as non-technical issues involved in the migration.
The technical part of the book (Chapters 3 and 4) is still very high level. No programming language is used and no code examples are given.
Potential problems and possible solutions are clearly illustrated with pros and cons.
The first chapter introduces the monolithic design, its defining characteristics, its inherent limitations and how microservices can improve that.
Chapter 2 highlights the importance of careful planning before embarking on a migration process.
It suggests the need to consider implications in terms of team organization, skills, and costs.
The author also points out that migration to microservices is not a must and in some situations a monolithic design might actually be a better solution.
Chapter 3 discusses several patterns that can be used to incrementally migrate selected functionalities into a microservice.
It explores possible alternative solutions to common problems and describes positive and negative aspects of each.
Chapter 4 focuses on how a database that backs a monolith affects and is affected by the migration of some functionality to a microservice.
Splits and non splits solutions are considered together with repercussions on data access and transactions.
Chapter 5 is a sort of troubleshooting summary where potential migration problems are reviewed with solutions.
"Building Microservices" is another other book from the author that partly overlaps with this one but discusses microservices from a more general point of view.
"Monolith to Microservices" focuses more on the problem of migrating an existing monolithic system to one based on microservices.
In the book you will read several times "if you want to know more about this read my other book Building Microservices".
I found this very annoying.
March 29, 2021
This book has some good advice on how to manage an application or database migration in small steps.
The first and last chapters are just an introduction to microservices and their problems. Nothing new especially for those who have already read "Building Microservices".
The second chapter helps us to plan the migration including the soft skills required. But more interesting than that, it shows us that depend on the problems we are trying to solve there are some easier and cheaper alternatives to microservices that do necessarily involve code. For example, changing the organizational structure or the infrastructure.
The third and forth chapters talk about the patterns. This should be the most important part of the book but I didn't like how the patterns were organized. Comparing to other "patterns" books like "Design Patterns" and "Enterprise Integration Patterns", this book is much more disorganized. One of the most valuable thing about the patterns is that when you read about one of them, you can also have a good overview about other related ones. Here, the patterns are sometimes compared only in one way. For example, if patterns A and B are related and B is presented last, the chapter that talks about B will compare it to A but not necessary the other way around. That way, you can only see the relationship among them if you read them in order.
Besides that, some patterns seems not to be very useful. The most important ones are listed and explained in this talk was made just before this book release:
https://www.youtube.com/watch?v=9I9Gd...
I think it is something between 3 and 4 stars. I will rate as 4 because it is not easy to find material about it.
The first and last chapters are just an introduction to microservices and their problems. Nothing new especially for those who have already read "Building Microservices".
The second chapter helps us to plan the migration including the soft skills required. But more interesting than that, it shows us that depend on the problems we are trying to solve there are some easier and cheaper alternatives to microservices that do necessarily involve code. For example, changing the organizational structure or the infrastructure.
The third and forth chapters talk about the patterns. This should be the most important part of the book but I didn't like how the patterns were organized. Comparing to other "patterns" books like "Design Patterns" and "Enterprise Integration Patterns", this book is much more disorganized. One of the most valuable thing about the patterns is that when you read about one of them, you can also have a good overview about other related ones. Here, the patterns are sometimes compared only in one way. For example, if patterns A and B are related and B is presented last, the chapter that talks about B will compare it to A but not necessary the other way around. That way, you can only see the relationship among them if you read them in order.
Besides that, some patterns seems not to be very useful. The most important ones are listed and explained in this talk was made just before this book release:
https://www.youtube.com/watch?v=9I9Gd...
I think it is something between 3 and 4 stars. I will rate as 4 because it is not easy to find material about it.
March 14, 2023
This book is gold. I wish I had read it when I was struggling to break down a legacy monolith into microservices. A lot of the problems I faced were actually covered in this book, and even if I couldn't have avoided them, I would have been better prepared for them. The book isn't just about microservices, but it also covers how to break down your codebase and persistence layer to make them more modular. It even helps you to consider whether you need to do this in the first place and the cost of doing it.
I think it would be great if this book had a second edition with more practical examples. For instance, most people are aware that to decouple and migrate part of your database to a new microservice, you need to copy the data and start using it. However, it's actually more challenging to do than we realize, especially if you want to achieve zero downtime. Simple backup and restore, along with some synchronization strategy, may not be enough. It can be a real challenge to avoid a maintenance window while ensuring that the data is consistent between both databases (consider using write-ahead log for synchronization and MD5 checksum hash function for testing).
I'm currently reading Software Architecture: The Hard Parts, and I think these two books complement each other pretty well.
I think it would be great if this book had a second edition with more practical examples. For instance, most people are aware that to decouple and migrate part of your database to a new microservice, you need to copy the data and start using it. However, it's actually more challenging to do than we realize, especially if you want to achieve zero downtime. Simple backup and restore, along with some synchronization strategy, may not be enough. It can be a real challenge to avoid a maintenance window while ensuring that the data is consistent between both databases (consider using write-ahead log for synchronization and MD5 checksum hash function for testing).
I'm currently reading Software Architecture: The Hard Parts, and I think these two books complement each other pretty well.
December 25, 2019
A well-written book on the different problems that you are likely to encounter when migrating from a monolith to a distributed systems microservices architecture. The book is neatly divided into different parts that cover different technical and non0technical aspects of making the move such as figuring out if microservices architecture is the right path for you (Chapter 1), getting the right team and team structure in place and also management buy-ins (Chapter 2), breaking down code and migrating using different patterns to reduce coupling (Chapter 3), migrating and breaking down datastore and database schemas and patterns to do this (Chapter 4), The likely problems that you will encounter when undergoing the migration (Chapter 5).
I like the fact that the book looks at the migration path holistically liberally talking about different kinds of tools, techniques and further reading references. I have done such migrations in the past in my career but I learnt a lot in this book (even if it was the name for the patterns I implemented). The version that I read was sponsored by Ngnix so it might be slightly different from the commercial book.
I like the fact that the book looks at the migration path holistically liberally talking about different kinds of tools, techniques and further reading references. I have done such migrations in the past in my career but I learnt a lot in this book (even if it was the name for the patterns I implemented). The version that I read was sponsored by Ngnix so it might be slightly different from the commercial book.
March 3, 2021
It's so hard to write a good book about software architecture. I think you have two options: digging deeply into the technical details or trying to be technologicaly agnostic and relying only on "abstractions". This book is of the latter type - word "Docker" is used only once and word "Kubernetess" is used less than five times :) And this is a really good book.
What I liked:
- Simplicity. All the patterns short and well explained. Moreover, we always have a context of usage - it's easier to put it in the "real-life" scenario.
- Pragmatism. I like the idea of slider instead of button for description of making changes. Nothing is for free and we should always look at architecture migration in this way.
What I didn't like:
- The shallowness of some topics. For example, the phrase "extract your services based on bounded contexts" is in self a topic for multiple books. However, I understand that exploring such problems in this book would increase the number of pages dramatically :) I accept it.
What I liked:
- Simplicity. All the patterns short and well explained. Moreover, we always have a context of usage - it's easier to put it in the "real-life" scenario.
- Pragmatism. I like the idea of slider instead of button for description of making changes. Nothing is for free and we should always look at architecture migration in this way.
What I didn't like:
- The shallowness of some topics. For example, the phrase "extract your services based on bounded contexts" is in self a topic for multiple books. However, I understand that exploring such problems in this book would increase the number of pages dramatically :) I accept it.
October 28, 2020
Another great microservices book from Sam Newman. I felt this is a sequel to his earlier book, Building Microservices. Sam updated some concepts from recent microservices evolution such as choreographed vs orchestrated Sagas, added infrastructure evolution such as Kubernetes. I loved the depth he covered the monolith database refactoring and the simple but elegant solutions he proposed using schemas and views in existing database engine for refactoring. I'm a fan of Sam's pragmatic approach when introducing new concepts that works very well for startups and big corporations. He also delved in to details about the organizational aspects of microservices and the distributed systems concerns that microservices might bring. If you liked reading his earlier book Building Microservices, then this is a highly recommended sequel helping in implementing that.
April 7, 2021
This book seems to be a step 1 if an organization is flirting with the idea of moving from a monolith to microservices. I like the fact the author is honest about evaluating your needs before allowing yourself to be swept by the herd. Since I am a part of an organization which has already made the decision to switch to using microservices (and rightly so!!), it's interesting to know that some issues are quite widespread regardless of which organization you work for and actually see them in front of myself. The author has identified those issues and has given solutions which are actually being implemented by my team (eg: Strangler Fig, Shims).
But at some point, one might realize that the author has written things that are quite obvious and seemed repetitive (parity with legacy functionality, end-to-end integration testing, breaking changes). It kind of became a drag in the 5th chapter.
But at some point, one might realize that the author has written things that are quite obvious and seemed repetitive (parity with legacy functionality, end-to-end integration testing, breaking changes). It kind of became a drag in the 5th chapter.
March 17, 2023
Really great book.
It does not concentrate on any specific technological stack, but gives very good advice on what to be aware of when moving to microservices, what problems they could solve, and decide whether such migration is the right step for you.
Sam is not "preachy" about microservices, and honestly states possible problems, and cases where migration won't help you.
While it's impossible to give advice that will work for 100% of people, author does provide a wide selection of options for migrations, with considerations for each one, so that one can compare their situation with "hypothetical" one, and adapt decision for their case.
If you have a monolith currently, or thinking about migration, or you're already part of microservice company, but want to know more about challenges of microservice architecture - this will be a great read.
It does not concentrate on any specific technological stack, but gives very good advice on what to be aware of when moving to microservices, what problems they could solve, and decide whether such migration is the right step for you.
Sam is not "preachy" about microservices, and honestly states possible problems, and cases where migration won't help you.
While it's impossible to give advice that will work for 100% of people, author does provide a wide selection of options for migrations, with considerations for each one, so that one can compare their situation with "hypothetical" one, and adapt decision for their case.
If you have a monolith currently, or thinking about migration, or you're already part of microservice company, but want to know more about challenges of microservice architecture - this will be a great read.
August 18, 2020
Pure excellence - must read
It is an amazing book. It covers everything from start to end. If you want to travel the road of Microservices.
It’s structured in a way that fits the mental model of monolith developers but to evaluate Microservices architecture. It’s going to serve a glossary of what to do & what not to do when doing Microservices.
Starts with simple 3 questions, during the journey you would feel yeah it feels very real. But without single line of code. You will get answers along the way, from people problems, team ownership, tackling database, importance of DDD and suggestions on tool one has to learn along the way.
Thanks Sam Newman for writing such an amazing book.
It is an amazing book. It covers everything from start to end. If you want to travel the road of Microservices.
It’s structured in a way that fits the mental model of monolith developers but to evaluate Microservices architecture. It’s going to serve a glossary of what to do & what not to do when doing Microservices.
Starts with simple 3 questions, during the journey you would feel yeah it feels very real. But without single line of code. You will get answers along the way, from people problems, team ownership, tackling database, importance of DDD and suggestions on tool one has to learn along the way.
Thanks Sam Newman for writing such an amazing book.
September 8, 2020
A very well written book, which shows in every page the experience of the author on the topic. It really puts into perspective the huge task of moving to microservices from a monolith, the most common pitfalls, and provides possible solutions to them.
The book is mostly useful as a reference for your journey of moving to microservices, it is not an absolute proven guide of not failing, but more a collection of very well organized experiences that will help you avoid most common problems and kind of guide your decision making.
It is good that the author emphasizes at the start that microservices is not for every situation, and spends some time explaining how you can figure this out for your current situation before you start.
The book is mostly useful as a reference for your journey of moving to microservices, it is not an absolute proven guide of not failing, but more a collection of very well organized experiences that will help you avoid most common problems and kind of guide your decision making.
It is good that the author emphasizes at the start that microservices is not for every situation, and spends some time explaining how you can figure this out for your current situation before you start.
August 25, 2021
I think this book gives a great overview on how to start a successful Monolith to Microservices transition. The part that I liked the most is that the Technical Project Management techniques described in this book can be applied to any large technical undertaking.
Another thing that I really appreciated is that book talks about how Microservices can't be a silver bullet and end coal by themselves and how to identify what problem they can solve if any.
However, to actually lead the process of splitting the monolith before reading this book I felt the reader needs to have a good understanding of Domain-Driven Design. The book covers it very briefly.
Another thing that I really appreciated is that book talks about how Microservices can't be a silver bullet and end coal by themselves and how to identify what problem they can solve if any.
However, to actually lead the process of splitting the monolith before reading this book I felt the reader needs to have a good understanding of Domain-Driven Design. The book covers it very briefly.
August 26, 2021
This book was illuminating to me in terms of laying out a process for getting from a to z. I'm currently in the middle of such a transition in my work as a software engineer and I learned a lot about the why and the how of to do so. I enjoyed the lack of real code examples instead the book focuses on describing concepts through simple diagrams. The work of breaking apart monoliths is not obvious and there are a lot of pitfalls one can find themselves in if you don't have the experiences. I now have a lot more clarity on what the right approaches are in a wide variety of situations. The book is also quite short and readable which made it easy to digest.
November 6, 2021
Definitely a book every software engineer must read! Newman shows how complex is the job of restructuring a monolithic application in a microservice one, where you can fail and how much. Correctly the author put the doubt into your mind if it is the correct choice for you to follow the microservice approach or not, or if you are ready for that. There are so many challenges that the team and his organisation must be well aligned with that challenge! Never do the transformation all together, but design and follow an iterative and evolving path. Complex software will become even more complex with the transformation, and only a strong discipline and good organization will make you successful!
January 23, 2022
Book covers various patterns that teams can use in transforming monoliths to microservices. It lists out and has high level details on what could be possible path of migrations in different conditions. Sam has also given his personal preferences after every pattern. For a team that has started to ask whether to migrate to Microservices and if yes, then what could be general guidance, this is a good work. It won't take long to read it end to end. Key takeaway would be - list of patterns and pros and cons of each one of those. You can then start your in-depth analysis of your systems by keeping all of this information at the forefront. It can make your decision making exercise more objective.
November 9, 2020
Why Sam Newman wrote this book? (IMO)
Because as Martin Fowler wrote, "You must be THIS tall to use microservices".
When should I move to microservice architecture?
What are the pros and cons of microservice architecture?
Which module of my system should I move as first?
What is the process of refactoring to microservices?
What are the best practices for refactoring to microservices?
What new problems will occur after moving to microservice architecture?
This book will help you grow to "THIS" tall by answering those and other questions.
Because as Martin Fowler wrote, "You must be THIS tall to use microservices".
When should I move to microservice architecture?
What are the pros and cons of microservice architecture?
Which module of my system should I move as first?
What is the process of refactoring to microservices?
What are the best practices for refactoring to microservices?
What new problems will occur after moving to microservice architecture?
This book will help you grow to "THIS" tall by answering those and other questions.
March 24, 2021
Honestly in the past years I have read a lot of titles about microservices architecture but this one turned out to be actually useful for me and my job. For the last two years I was desperately trying to get rid of monolithic structured applications and this book gave me the best approaches to do that! It is fairly simple but really practical and useful! Congrats to Newman! Although there were many thing I already knew, there were also some observations and simple advices that can definitely change your workflow whenever you are facing such issues.
January 8, 2022
This book was great! A really approachable book on how to practically transition from a monolithic architecture to a microservice based one.
It doesn't advocate for it, and in particular he makes sure to point out that microservices might NOT be right for you.
I will say that it may be helpful to read his other book (Building Microservices) first, because there were a few points where he didn't go as deep and directs you to the relevant sections of the prior work. On the whole though, that's a pretty minor issue.
It doesn't advocate for it, and in particular he makes sure to point out that microservices might NOT be right for you.
I will say that it may be helpful to read his other book (Building Microservices) first, because there were a few points where he didn't go as deep and directs you to the relevant sections of the prior work. On the whole though, that's a pretty minor issue.
December 31, 2019
This a review for the first chapter of the book... I like the written approach/style of the book. It initiates from core concepts of coupling and cohesion which are the core principle and linked well with microservices decompositions and common scenarios.
Thoughts for an extension for the book:
I thought this chapter one is a good link to the requirements phase. The requirements being decomposed in the same way as a pre-design phase to then prepare for microservices design.
Thoughts for an extension for the book:
I thought this chapter one is a good link to the requirements phase. The requirements being decomposed in the same way as a pre-design phase to then prepare for microservices design.
May 18, 2020
Good overview - pretty basic if you’ve had Microservices experience before
The first 4 chapters go over patterns of migrating from monolith to Microservices, the pros and cons of Microservices, and other such things. If you’ve done any work with Microservices, much of this will be familiar.
I found chapter 5 to be the most interesting chapter. It discusses the growing pains you’re likely to run into, and gives some good advice on how to address those pains.
The first 4 chapters go over patterns of migrating from monolith to Microservices, the pros and cons of Microservices, and other such things. If you’ve done any work with Microservices, much of this will be familiar.
I found chapter 5 to be the most interesting chapter. It discusses the growing pains you’re likely to run into, and gives some good advice on how to address those pains.
Displaying 1 - 30 of 78 reviews