Scan barcode
A review by rodhilton
Building Microservices: Designing Fine-Grained Systems by Sam Newman
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.