Scan barcode
rodhilton's review against another edition
4.0
I've been seeing lots of talk about Microservices, and it's something I have virtually no experience with. Since my coworkers have mentioned hearing lots of hubbub about Microservices, I decided to run a little book club for my team. So here is not only my review, but the reviews of my teammates, based on their feedback when discussing chapters every week.
I really enjoyed Building Microservices, I think it either already is, or soon will be, considered the bible of Microservice architecture. When I first got the book I was worried it was going to be impractical, or come off as an advocacy book - "here's why you should do microservices". My favorite NoSQL book is Martin Fowler's, largely because he introduces the book by saying you should use a relational database most of the time. It's a realistic attitude, one in line with my "choose boring technology" mantra, and it makes an author come across as a realist who builds software and not a young fanboy of the latest-and-greatest resume builder. Sam Newman surprised me by offering a similar tone in this book. He essentially says, don't build Microservices. Build monoliths, and then if the need arises, split it into microservices. Never start with microservices as the goal, and don't build greenfield microservice projects. It's a surefire way to get the domain wrong, and be forced to eventually merge everything into a monolith just to re-split it across correct bounded contexts. I felt like this advice was very practical, it lent a lot of weight to the book in my eyes.
The book is organized very well. There are a few chapters introducing Microservices and underscoring the value of utilizing a microservice-based architecture. These chapters never come off as fanboyish advocacy though, it seems like a real presentation of reasons why you might want to migrate toward microservices. After that things start getting a bit more technical, Newman discusses how microservices can and should talk to each other, how to go about splitting an already-existing monolithic codebase, how to deploy microservices, testing, monitoring, and security.
Every week my book club would meet, the refrain I kept hearing was "when are we going to get to the meat of the book?" Every chapter felt, to the group, like it was just getting warmed up, but never getting concrete enough. I think a lot of them were expecting more technical information, or even code. But a lot of the sections basically just wind up saying "make sure you get this or that right, it can be tough!" without a lot in the way of helping the reader get things right. Many of my coworkers said they wished the book was MORE opinionated, giving more concrete advice rather than just warnings to be careful when making particular decisions.
A few particular areas where I felt like the book could have gone into more detail is with regard to how to handle common stuff (for example, if monitoring or caching is part of every microservice you build, should it be in a common library? Who owns it? How does it get updated?) and how to structure a team so that microservices are consistent in terms of interface design and standards (is it a committee? Is it one person from each team?). These are things I think are easy to get wrong - I'd have liked a bit more guidance.
By far the best chapter of the book is the second-to-last chapter. Microservices at Scale gets into the nitty-gritty of a microservice architecture at a technical level that most of the other chapters don't quite. Discussions of patterns, circuit breakers, bulkheads, and so forth litter the (very long) chapter. It name-drops real projects and open source tools that can be used for microservices - I made more notes in this chapter than in any other in the book.
Overall the book is well-written and engaging. It's never too dry like O'Reilly books can often be, I really enjoyed it and learned a lot. I'm not sure if we're going to adopt microservices at work, but the book definitely helped me understand microservice architectures at a level where I can make informed decisions regarding their usage, and I feel like I'd be hitting the ground running if I decided to move forward in building them. I think the book is probably worth a read for most engineers in a position where they make software architecture decisions.
I really enjoyed Building Microservices, I think it either already is, or soon will be, considered the bible of Microservice architecture. When I first got the book I was worried it was going to be impractical, or come off as an advocacy book - "here's why you should do microservices". My favorite NoSQL book is Martin Fowler's, largely because he introduces the book by saying you should use a relational database most of the time. It's a realistic attitude, one in line with my "choose boring technology" mantra, and it makes an author come across as a realist who builds software and not a young fanboy of the latest-and-greatest resume builder. Sam Newman surprised me by offering a similar tone in this book. He essentially says, don't build Microservices. Build monoliths, and then if the need arises, split it into microservices. Never start with microservices as the goal, and don't build greenfield microservice projects. It's a surefire way to get the domain wrong, and be forced to eventually merge everything into a monolith just to re-split it across correct bounded contexts. I felt like this advice was very practical, it lent a lot of weight to the book in my eyes.
The book is organized very well. There are a few chapters introducing Microservices and underscoring the value of utilizing a microservice-based architecture. These chapters never come off as fanboyish advocacy though, it seems like a real presentation of reasons why you might want to migrate toward microservices. After that things start getting a bit more technical, Newman discusses how microservices can and should talk to each other, how to go about splitting an already-existing monolithic codebase, how to deploy microservices, testing, monitoring, and security.
Every week my book club would meet, the refrain I kept hearing was "when are we going to get to the meat of the book?" Every chapter felt, to the group, like it was just getting warmed up, but never getting concrete enough. I think a lot of them were expecting more technical information, or even code. But a lot of the sections basically just wind up saying "make sure you get this or that right, it can be tough!" without a lot in the way of helping the reader get things right. Many of my coworkers said they wished the book was MORE opinionated, giving more concrete advice rather than just warnings to be careful when making particular decisions.
A few particular areas where I felt like the book could have gone into more detail is with regard to how to handle common stuff (for example, if monitoring or caching is part of every microservice you build, should it be in a common library? Who owns it? How does it get updated?) and how to structure a team so that microservices are consistent in terms of interface design and standards (is it a committee? Is it one person from each team?). These are things I think are easy to get wrong - I'd have liked a bit more guidance.
By far the best chapter of the book is the second-to-last chapter. Microservices at Scale gets into the nitty-gritty of a microservice architecture at a technical level that most of the other chapters don't quite. Discussions of patterns, circuit breakers, bulkheads, and so forth litter the (very long) chapter. It name-drops real projects and open source tools that can be used for microservices - I made more notes in this chapter than in any other in the book.
Overall the book is well-written and engaging. It's never too dry like O'Reilly books can often be, I really enjoyed it and learned a lot. I'm not sure if we're going to adopt microservices at work, but the book definitely helped me understand microservice architectures at a level where I can make informed decisions regarding their usage, and I feel like I'd be hitting the ground running if I decided to move forward in building them. I think the book is probably worth a read for most engineers in a position where they make software architecture decisions.
naleagdeco's review against another edition
5.0
This has been my most enjoyable software design read since Release It! a few years ago (and I'm sad I waited so long to read it.)
I'm currently 1/3rd (I imagine) through the process of moving our software from a monolithic service into a microservice and more importantly one with multitenant customer integrations. I've been following the topics on this book through a variety of blog posts, other books (which expand on particular details of sections in his book) and conference videos.
In retrospect I wish I had started by reading this book so that I'd have a clear starting reference all in one place vs. seeing all those things fit together in a guided introduction.
Sam Newman is a very good technical writer, all of his text is clear, never too detailed and never too absract. His text is no-nonsense and that works well given this book's relatively short length for its wide scope.
The book starts with describing microservices and their supposed benefits. It then discusses important planning consideratinos (not just technical, business ones too!) before starting down this path, before going into strategies for starting to split one's monolithic service. The bulk of the book then becomes about particular considerations and possibly high-level approaches to a variety of software design aspects in a microservice context.
Those second and third chapters, about planning an architecture and about how to approach converting one's existing service, are increedibly useful to me. They aren't complete solutions, but they are approaches and considerations with enough guiderails that someone can start thinking about this for their particular situation.
Almost every other chapter provided at least one gleam of insight that I'll have to think about more at length, alongside the surveys of common microservice patterns for any particular aspect of running a software service.
If you are starting down the path of considering a microservice implementation, or are a developer inexperienced with how microservice architecture works, I highly recommend this book to see overall design philosophies and a lot of considerations about where one software's should be before beginning and also possible areas to start.
I'm currently 1/3rd (I imagine) through the process of moving our software from a monolithic service into a microservice and more importantly one with multitenant customer integrations. I've been following the topics on this book through a variety of blog posts, other books (which expand on particular details of sections in his book) and conference videos.
In retrospect I wish I had started by reading this book so that I'd have a clear starting reference all in one place vs. seeing all those things fit together in a guided introduction.
Sam Newman is a very good technical writer, all of his text is clear, never too detailed and never too absract. His text is no-nonsense and that works well given this book's relatively short length for its wide scope.
The book starts with describing microservices and their supposed benefits. It then discusses important planning consideratinos (not just technical, business ones too!) before starting down this path, before going into strategies for starting to split one's monolithic service. The bulk of the book then becomes about particular considerations and possibly high-level approaches to a variety of software design aspects in a microservice context.
Those second and third chapters, about planning an architecture and about how to approach converting one's existing service, are increedibly useful to me. They aren't complete solutions, but they are approaches and considerations with enough guiderails that someone can start thinking about this for their particular situation.
Almost every other chapter provided at least one gleam of insight that I'll have to think about more at length, alongside the surveys of common microservice patterns for any particular aspect of running a software service.
If you are starting down the path of considering a microservice implementation, or are a developer inexperienced with how microservice architecture works, I highly recommend this book to see overall design philosophies and a lot of considerations about where one software's should be before beginning and also possible areas to start.
tbueno's review against another edition
4.0
Nice overview of best practices when building microservices. Don't expect any hands on here, Sam Newman focuses on concepts using examples from the industry, but without much details about technologies or code samples.
At some point the book felt more suitable for VPs or CTOs instead of developers looking for guidance. nevertheless I still think it is a nice reference about the topic.
At some point the book felt more suitable for VPs or CTOs instead of developers looking for guidance. nevertheless I still think it is a nice reference about the topic.
danielwestheide's review against another edition
3.0
If you are new to micro services, or service-oriented architectures in general, this books provides a good overview of all the things you need to take into account, which trade-offs have to be made etc. That said, it can't serve as more than a starting point – every single chapter deserves a book of its own.
car0's review against another edition
adventurous
challenging
informative
reflective
relaxing
medium-paced
2.5
books_are_nice_and_enjoyable's review
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.”