What do you think?
Rate this book
Building Microservices: Designing Fine-Grained Systems
Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic applications to smaller, self-contained microservices. But developing these systems brings its own set of headaches. With lots of examples and practical advice, this book takes a holistic view of the topics that system architects and administrators must consider when building, managing, and evolving microservice architectures.
Microservice technologies are moving quickly. Author Sam Newman provides you with a firm grounding in the concepts while diving into current solutions for modeling, integrating, testing, deploying, and monitoring your own autonomous services. You'll follow a fictional company throughout the book to learn how building a microservice architecture affects a single domain.
Discover how microservices allow you to align your system design with your organization's goals
Learn options for integrating a service with the rest of your system
Take an incremental approach when splitting monolithic codebases
Deploy individual microservices through continuous integration
Examine the complexities of testing and monitoring distributed services
Manage security with user-to-service and service-to-service models
Understand the challenges of scaling microservice architectures
Microservice technologies are moving quickly. Author Sam Newman provides you with a firm grounding in the concepts while diving into current solutions for modeling, integrating, testing, deploying, and monitoring your own autonomous services. You'll follow a fictional company throughout the book to learn how building a microservice architecture affects a single domain.
Discover how microservices allow you to align your system design with your organization's goals
Learn options for integrating a service with the rest of your system
Take an incremental approach when splitting monolithic codebases
Deploy individual microservices through continuous integration
Examine the complexities of testing and monitoring distributed services
Manage security with user-to-service and service-to-service models
Understand the challenges of scaling microservice architectures
473 pages, Paperback
First published December 25, 2014
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 427 reviews
October 29, 2015
Microservices are a relatively new trend in computer science, coined around 2012. This conceptual book touches lots of aspects surrounding those little sisters of Service-oriented architectures (SOA): Starting from the basics, it covers topics like integration, splitting monoliths, deployment, testing, monitoring, security, system design and the role of architects, and scaling services.
The Good
Newman takes a holistic approach, analyzes the topic from lots of angles. It isn't a dry read but the author introduces a couple of real-life experiences leading to an enjoyable read. I found a couple of gems embedded in the text that I didn't know about, like references to Nagios, Hexagonal Architectures or Holistic Software Development, which I plan to read about later on.
The book is quite short with only 300 pages and will take only a couple of evenings to dig through. Each chapter ends with a nice summary.
The Bad
Given its size and the broad range of topics, it doesn't come as a surprise that each topic doesn't get a lot of screentime, leading to a very shallow discussion. This comes in handy, if you only want to get hints what could be thought about. In the end, the coverage isn't very helpful.
It is an egocentric text, stemming from thoughts of the author alone, it doesn't introduce community's knowledge or give any hints to further readings in this specific area. No references to articles, blogs, books covering more details with respect to Microservices.
The Ugly
The book is mainly about anything else but Microservices, roughly 20% are specific to the book's main topic. There are lots of chapters which don't or nearly don't talk about them at all. For example, there is a philosophical chapter about the role of architects without touching the topic at all. Other chapters are a nice read on computer science topics or service oriented architectures but don't cover specifics of Microservices.
Although there are lots of hidden gems and references, the book doesn't contain a list of literature or a definition of terms. An overview book should give references to deeper analysis, but you won't find any here.
Architects who know their stuff, who haven't missed the last 15 years of SOA, should read the wikipedia article rather than this book. I don't recommend the book at all.
The Good
Newman takes a holistic approach, analyzes the topic from lots of angles. It isn't a dry read but the author introduces a couple of real-life experiences leading to an enjoyable read. I found a couple of gems embedded in the text that I didn't know about, like references to Nagios, Hexagonal Architectures or Holistic Software Development, which I plan to read about later on.
The book is quite short with only 300 pages and will take only a couple of evenings to dig through. Each chapter ends with a nice summary.
The Bad
Given its size and the broad range of topics, it doesn't come as a surprise that each topic doesn't get a lot of screentime, leading to a very shallow discussion. This comes in handy, if you only want to get hints what could be thought about. In the end, the coverage isn't very helpful.
It is an egocentric text, stemming from thoughts of the author alone, it doesn't introduce community's knowledge or give any hints to further readings in this specific area. No references to articles, blogs, books covering more details with respect to Microservices.
The Ugly
The book is mainly about anything else but Microservices, roughly 20% are specific to the book's main topic. There are lots of chapters which don't or nearly don't talk about them at all. For example, there is a philosophical chapter about the role of architects without touching the topic at all. Other chapters are a nice read on computer science topics or service oriented architectures but don't cover specifics of Microservices.
Although there are lots of hidden gems and references, the book doesn't contain a list of literature or a definition of terms. An overview book should give references to deeper analysis, but you won't find any here.
Architects who know their stuff, who haven't missed the last 15 years of SOA, should read the wikipedia article rather than this book. I don't recommend the book at all.
May 9, 2016
Mixed feelings about this book. I had high expectations before starting reading it but after reading some chapters I've started feeling bored with so much shallow information about a lot of 'tooling stuff'.
The book is a big overview of a series of concepts and advices (and tooling!) you should care about in an environment of distributed systems such as integration, deployment, monitoring, security, scaling and the like. There's nothing practical in its content, which have disappointed me a lot (for a book named "Building" Microservices).
I don't recommend it if you're a beginner programmer or you have little knowledge about networking, cloud, monitoring and other 'operations' concepts and tooling. For programmers or architects working with this kind of environment, it may be useful as a guide for reviewing/improving the architecture.
If there's a true good thing to say about the book, it's the fact that it may help to show that playing with microservices (one of those 'buzzwords' in the last years) is definitely not a simple thing to do. There's a lot of practices that must be running for this type of architecture work.
For all of that, I think the most appropriate name for this book should be "Managing an environment of distributed systems" or something like that.
The book is a big overview of a series of concepts and advices (and tooling!) you should care about in an environment of distributed systems such as integration, deployment, monitoring, security, scaling and the like. There's nothing practical in its content, which have disappointed me a lot (for a book named "Building" Microservices).
I don't recommend it if you're a beginner programmer or you have little knowledge about networking, cloud, monitoring and other 'operations' concepts and tooling. For programmers or architects working with this kind of environment, it may be useful as a guide for reviewing/improving the architecture.
If there's a true good thing to say about the book, it's the fact that it may help to show that playing with microservices (one of those 'buzzwords' in the last years) is definitely not a simple thing to do. There's a lot of practices that must be running for this type of architecture work.
For all of that, I think the most appropriate name for this book should be "Managing an environment of distributed systems" or something like that.
May 15, 2020
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.”
February 21, 2015
One of the best software architecture-related books I've read recently.
Suitable for software architects of ANY level - youngsters can learn a lot & more experienced ones can validate their own experience against author's statements & opinions. What I loved most about this book is that it's not "PowerPoint Architecture" (theory & model) book - it has been written by a practitioner, for practitioners & it's 100% based on practical experience. For me (& I consider myself a battle hardened architect) it was extremely refreshing to read.
Pros:
* clear, straightforward messages in the content (illustrated with decent cases)
* simple, logic structuring
* pragmatic approach to microservices (this topic got a lot of sneer & hate over the internet)
* goes through all the aspects - not just functional decomposition, but deployment, maintainability & many more
* sort of a one-stop-shop in terms of healthy architecture basic rules
Cons:
* somewhere in the middle (Testing, Monitoring, Security chapters) book "looses its identity a bit" -> it gets too general (in describing general rules & patterns) & it kinda forgets about microservices as the focal point; to be honest it was a bit irritating, but fortunately the final part ("... at scale") is very good
* chapters 3-5 (related to service composition) are fine, but in some places they lack a bit of depth -> for instance I was missing descriptions of scenarios with multiple tiers of low- & high-level services.
Anyway, this book is HIGHLY recommended.
Suitable for software architects of ANY level - youngsters can learn a lot & more experienced ones can validate their own experience against author's statements & opinions. What I loved most about this book is that it's not "PowerPoint Architecture" (theory & model) book - it has been written by a practitioner, for practitioners & it's 100% based on practical experience. For me (& I consider myself a battle hardened architect) it was extremely refreshing to read.
Pros:
* clear, straightforward messages in the content (illustrated with decent cases)
* simple, logic structuring
* pragmatic approach to microservices (this topic got a lot of sneer & hate over the internet)
* goes through all the aspects - not just functional decomposition, but deployment, maintainability & many more
* sort of a one-stop-shop in terms of healthy architecture basic rules
Cons:
* somewhere in the middle (Testing, Monitoring, Security chapters) book "looses its identity a bit" -> it gets too general (in describing general rules & patterns) & it kinda forgets about microservices as the focal point; to be honest it was a bit irritating, but fortunately the final part ("... at scale") is very good
* chapters 3-5 (related to service composition) are fine, but in some places they lack a bit of depth -> for instance I was missing descriptions of scenarios with multiple tiers of low- & high-level services.
Anyway, this book is HIGHLY recommended.
December 27, 2014
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.
December 10, 2016
If you're new to microservices, this book is a decent intro, covering most of the major topics you need to be aware of. It only covers the topics at a surface level (to be fair, it would've been a very long book if it went in-depth on each one), which is just enough to show you what questions you should be asking. Of course, you'll have to seek elsewhere to find those answers, but at least now you'll know what to look for.
However, the biggest weakness of the book is that it makes microservices seem like a good idea for just about everyone. Obviously, the author has a vested interest in this perception, since he wants to sell more books, but the reality is that microservices are NOT a good choice for many use cases. They make perfect sense at the scale of a company like Google or Facebook, but most companies do not face that kind of scale, and, even more importantly, most companies do not have the resources of a Google or Facebook to invest in making microservices usable.
Running microservices requires a massive investment in terms of orchestration, configuration management, automated deployment, build tooling, monitoring, alerting, feature toggles, service discovery, service APIs, I/O management, and versioning. Breaking up a monolith or any sort of large rewrite is also a MAJOR undertaking—and a major risk for a company. The author doesn't hide these drawbacks, but in my opinion, he massively understates them. Microservices are not for everyone (just like NoSQL and distributed systems aren't for everyone!), and it's a disservice to the industry to tell people otherwise.
However, the biggest weakness of the book is that it makes microservices seem like a good idea for just about everyone. Obviously, the author has a vested interest in this perception, since he wants to sell more books, but the reality is that microservices are NOT a good choice for many use cases. They make perfect sense at the scale of a company like Google or Facebook, but most companies do not face that kind of scale, and, even more importantly, most companies do not have the resources of a Google or Facebook to invest in making microservices usable.
Running microservices requires a massive investment in terms of orchestration, configuration management, automated deployment, build tooling, monitoring, alerting, feature toggles, service discovery, service APIs, I/O management, and versioning. Breaking up a monolith or any sort of large rewrite is also a MAJOR undertaking—and a major risk for a company. The author doesn't hide these drawbacks, but in my opinion, he massively understates them. Microservices are not for everyone (just like NoSQL and distributed systems aren't for everyone!), and it's a disservice to the industry to tell people otherwise.
January 1, 2021
Microservices nedir, bu mimariyi/yaklaşımı uygulamak ne zaman iyi olabilir ne zaman olmayabilir, hangi noktalara dikkat etmeli, hangi ihtiyaç için hangi "tool"lar mevcut, nerelerde başımız ağrıyabilir vs gibi genel bir yol izliyor kitap. Başlangıç için iyi, ayrıntılı bilgi için yeterli değil ancak kitabın vaadi de bu değil sanıyorum. Eric Evans'ın Domain-Driven Design kitabına çokça gönderme var. Öncesinde okumak faydalı olacaktır.
June 6, 2022
I have rated this book so low because most of the concepts (>85%) were already known to me.
Most books that the author mentions i have already read , and this one brought little to no value to me. Some kind of summary across multiple domains without feeling like it doubles down and provides authentic content in any of them.
I would put it more as an index type of book , something for people that want to get accustomed to the terminology and get a wider view of the problem at hand , but i think its a far fetch to call it as the title reads "Building".
Most books that the author mentions i have already read , and this one brought little to no value to me. Some kind of summary across multiple domains without feeling like it doubles down and provides authentic content in any of them.
I would put it more as an index type of book , something for people that want to get accustomed to the terminology and get a wider view of the problem at hand , but i think its a far fetch to call it as the title reads "Building".
This entire review has been hidden because of spoilers.
August 22, 2016
The Pragmatic Programmer of the microservices age. So many lessons learned the hard way are documented here. A quick and information packed read.
November 3, 2015
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.
June 8, 2020
At first, If I were the author, I called this book something like "Microservices concepts" or like "Choosing whether to migrate to microservices or not.".
This book is not practical, but covers lots of microservice concepts, at least in the outlines. It gives us useful knowledge about different aspects of microservices and defines the concepts, so it is worth reading.
I also enjoyed the perception and thoughts of Sam Newman about software architecture and disciplines that I think this type of thinking comes from the Thought Works ( Martin Fowler ). After reading the book, you can talk hours and hours about these kinds of stuff in a general way :D
---
اول از همه به نظرم این کتاب باید یه چیزی مثل « کانسپتهای ماکروسرویس » یا « انتخاب کردن رفتن به سمت مایکروسرویس » نامگذاری میشد، چون پرکتیکال نیست و اون قسمت « بیلدینگ » رو خیلی بهش توجهی نکرده.
از طرفی بخش خوبی از ایدههای مایکروسرویس رو از نظر سرفصلی پوشش داده که خب همین یه درک خوبی از قضیه بهمون میده و از این نظر حقیقتا کتاب ارزش خوندن داره.
من از مدل فکر کردن و درک و فهم سمنیومن از معماری نرمافزار و فرآیندهای نرمافزاری خوشم اومد که خب به نظرم میاد این مدل فکری از مارتین فولر نشات میگیره. به هر حال کتاب کتاب خوبیه و با خوندنش کلی چیز جدید به به صورت سطحی یاد گرفتین که میتونین در موردش ساعتها صحبت کنین :دی
This book is not practical, but covers lots of microservice concepts, at least in the outlines. It gives us useful knowledge about different aspects of microservices and defines the concepts, so it is worth reading.
I also enjoyed the perception and thoughts of Sam Newman about software architecture and disciplines that I think this type of thinking comes from the Thought Works ( Martin Fowler ). After reading the book, you can talk hours and hours about these kinds of stuff in a general way :D
---
اول از همه به نظرم این کتاب باید یه چیزی مثل « کانسپتهای ماکروسرویس » یا « انتخاب کردن رفتن به سمت مایکروسرویس » نامگذاری میشد، چون پرکتیکال نیست و اون قسمت « بیلدینگ » رو خیلی بهش توجهی نکرده.
از طرفی بخش خوبی از ایدههای مایکروسرویس رو از نظر سرفصلی پوشش داده که خب همین یه درک خوبی از قضیه بهمون میده و از این نظر حقیقتا کتاب ارزش خوندن داره.
من از مدل فکر کردن و درک و فهم سمنیومن از معماری نرمافزار و فرآیندهای نرمافزاری خوشم اومد که خب به نظرم میاد این مدل فکری از مارتین فولر نشات میگیره. به هر حال کتاب کتاب خوبیه و با خوندنش کلی چیز جدید به به صورت سطحی یاد گرفتین که میتونین در موردش ساعتها صحبت کنین :دی
February 24, 2020
A good introduction to the microservices World for the automatization defenders
March 7, 2017
Microservices is still very young and this book does a fair job in covering all the aspects of the intricacies that involve in adopting to it. I was expecting something different before I picked this book, however, most of the concepts elicited here are some of the known concepts to me as an Architect. It still has a lot gold mines spread around the entire book. I would not say this is a must-read for a Software Architect, but the learnings of the book will definitely add value to your thinking process in designing fault-tolerant and large scale systems. In any case, getting hands on and having a first person point of view is vital to really digest the things the Author talks about.
March 3, 2020
The guidance contained in Building Microservices is valid but the execution feels sloppy and rushed.
There are more than the forgivable number of grammar, punctuation, and even spelling errors in this book. Anecdotes are not well-adapted for the chapter topics. Diagrams are not consistent and are rarely meaningful.
As an example of the overall feel of this book, at the end Newman attempts to distill his offering into a set of key principles. However, the distillation is lost in the fact that said principles aren't even all, well, principles. "Decentralize all the things" makes some sense in this context, but "Culture of Automation" is a trait of successful microservice engineers, not a principle. Another one, "Highly observable," is an attribute of well-designed systems, not a principle at all. The scattered nature of this example makes it difficult to glean what are some of the most practical lessons in architecting and operating distributed systems that Newman assuredly has learned himself.
Maybe the editor should be blamed, but I can't help but feel that Newman's valuable insight is overshadowed here by a disappointing lack of finesse.
There are more than the forgivable number of grammar, punctuation, and even spelling errors in this book. Anecdotes are not well-adapted for the chapter topics. Diagrams are not consistent and are rarely meaningful.
As an example of the overall feel of this book, at the end Newman attempts to distill his offering into a set of key principles. However, the distillation is lost in the fact that said principles aren't even all, well, principles. "Decentralize all the things" makes some sense in this context, but "Culture of Automation" is a trait of successful microservice engineers, not a principle. Another one, "Highly observable," is an attribute of well-designed systems, not a principle at all. The scattered nature of this example makes it difficult to glean what are some of the most practical lessons in architecting and operating distributed systems that Newman assuredly has learned himself.
Maybe the editor should be blamed, but I can't help but feel that Newman's valuable insight is overshadowed here by a disappointing lack of finesse.
September 29, 2022
I remember reading parts of the first edition and finding it light but the second edition is a serious rewrite with more meat on the initial skeleton and even significant reorg of the bones. Overall it’s is a great overview and holistic analysis of microservices with possible pros and cons in all phases of the SDLC. The title could be misleading as despite numerous development and delivery technologies are highlighted, the focus is still high level architecture so not a good fit for developers looking for a cookbook with recipes. Newman provides good case studies though to discuss his ideas with great references for further reading, and also fun notes on onion architecture, datensparsamkeit, confused deputies, Schrödinger backups, chaos monkeys or gorillas and postmortems…
April 25, 2016
Книга не является строгим руководством к действию, она, скорее, представляет собой набор эмпирически выведенных принципов, на основе которых могут строиться микросервисы.
В книге красной нитью проходит идея о том, что в построении микросервиса ключевым понятием является "ограниченный контекст". Автор убедителен, неоднократные ссылки на труд Эрика Эванса лично меня вдохновляют на прочтение "Domain Driven Design".
В книге красной нитью проходит идея о том, что в построении микросервиса ключевым понятием является "ограниченный контекст". Автор убедителен, неоднократные ссылки на труд Эрика Эванса лично меня вдохновляют на прочтение "Domain Driven Design".
March 25, 2015
The book does a good job exposing the ideas and good practices behind a migration to (micro)services. if you've been doing it for a while it's a good way to checklist what you've done. If you're jumping on the wagon it has a nice overview about the practices and the tools that are out there to help you. I feel that the chapter about Scaling gives a good summary of the whole book.
March 19, 2021
Great book!
I actually read the updated edition - diving more into the technologies that gained some ground throughout last 5 years (docker, kubernetes etc.). This book gives a high-level overview of all the things you need to take into account when thinking about microservice architecture, which for me, as a "newbie" in the topic was perfect.
I actually read the updated edition - diving more into the technologies that gained some ground throughout last 5 years (docker, kubernetes etc.). This book gives a high-level overview of all the things you need to take into account when thinking about microservice architecture, which for me, as a "newbie" in the topic was perfect.
January 26, 2018
I think this book is going to be useful for any engineer onboarding the world of microservices. It gives a broad and complete overview of all stages of the process: from design to deployment and testing.
On the other hand, from my perspective, for more experienced engineers already familiar with similar systems this book would rather look like a reiteration of all the difficulties and problems one might face while working with microservices. In many cases, the author agrees with the complexity of certain problems (e.g. database scaling/sharding, 2 phase commit, etc) but does not dive into details of how to approach these problems in real world. However, this is probably intentional, as many of these problems go far beyond a single book.
In short: highly recommended to everybody dealing with the concepts of microservices for the first time ever.
On the other hand, from my perspective, for more experienced engineers already familiar with similar systems this book would rather look like a reiteration of all the difficulties and problems one might face while working with microservices. In many cases, the author agrees with the complexity of certain problems (e.g. database scaling/sharding, 2 phase commit, etc) but does not dive into details of how to approach these problems in real world. However, this is probably intentional, as many of these problems go far beyond a single book.
In short: highly recommended to everybody dealing with the concepts of microservices for the first time ever.
September 13, 2017
If you have to read just one book about microservices, choose this. Quick&easy to read but very complete; it summarizes related subjects (not only the technical ones). A book to read from beginning to end, but also one to consult. It mentions a lot of technologies, but never without the corresponding concept/topic so it'll hardly get outdated. In the end, you just feel confident to develop this way.
October 18, 2019
I have used this book twice, when we split the monolith into smaller apps, and when we built micro services from scratch, it was very useful and handy to give a directions to build the microservices. This book will not give a strict direction how-must-do but rather what-to-think-about to understand what challenges might come and possible solutions to handle it. All other depends on your own experience and sense of architecture therefore there is one chapter about who is an architect. I would recommend this book to read if you are going to build micro services and discuss it in your development group otherwise it will too theoretical and obvious.
August 26, 2018
This book shows a lot of aspects to consider before using microservices.
It is hard to rate it because it is the first book I read about the topic. I really liked some parts, but I feel that the author did not put the same effort in other ones. There is not a consistent narrative among the topics. Some of them are focused on the concepts with detailed explanation. And some of them are more focused on tools.
It is hard to rate it because it is the first book I read about the topic. I really liked some parts, but I feel that the author did not put the same effort in other ones. There is not a consistent narrative among the topics. Some of them are focused on the concepts with detailed explanation. And some of them are more focused on tools.
December 18, 2021
4/5 Stars: An in depth run through Building Microservices
Calling upon his extensive experience in working with microservice architectures, Sam Newman shares his insights about the ins and outs of every aspect you will encounter when building your own microservices.
I approached this book as a personal brush up on the topic, and to get back in touch with a broader perspective about developing software today. What I got out of this book was a rapid deep dive into conceptual theory, communication systems, error handling, enabling to evolve and so much more.
So do I know now how to build a Microservice?
No. This is not a cookbook that tells you how to write a microservice. In fact, this book feels more like a chess guide about strategy and tactics. If using microservices in your production was a game, then the tools, frameworks and programming languages make up a constantly increasing pool of pieces and the board is as big as you get to scale it. In this game, you have to keep the balances between complexity and advantages, risks and revenues, while always aiming to come out on top of the bargain. I know now how to look at my system(s) and decide in my own tech-stack if microservices are the right fit for its purpose.
Do I get advice on how to approach implementing microservices in my system(s)?
Yes. From cutting microservices out of your existing monolith, over communication and transaction techniques all the way across testing and deployment to security and scaling, Newman touches virtually every aspect of microservice implementation. Most issues will be demonstrated on illustrative examples from MusicCo, a fictional company accompanying us throughout the whole book, or with anecdotes from his real life experience on working for different clients and companies. On the downside, there are extremely many variations of technologies, strategic goals and organizational structures to be considered. Therefore, some corner cases get only brushed at very briefly. Under that light, the book seems short, but provides references for further reading.
Newman gives you perspective of the whole and guiding principles to work with.
In every chapter you will come out with a better understanding of the context and one or two default options to start with in your specific situation. The very first principle is "independent deployment", closely followed by "if it ain't broken, don't fix it". So on one side, you get practical criteria to recognize a microservice when you see one, but more importantly when something went wrong and what you got into production is not at all what you thought you designed. On the other side, he provides many calls to caution, to help you avoid critical traps along the way and keep things manageable and cost-efficient.
Who should read this book?
I really think the right question would be what this or that role in a software organization will get out of this book. Developers looking for a step by step guide to build their own microservice will be very disappointed. But developers working in a team that decided to go microservices will need to understand the ideas behind the new architecture, tools and technologies and what outcome they are to be used for.
Architects will get a better understanding of their role, and how building microservices is about mapping individual systems and keep them out of each others way. Operators will get advice how to do things themselves or how to automate everything with proper tooling, which is extremely important if you want to keep doing microservices for longer than just a couple of months. Tech-lead and senior developers will come out with a better understanding of all the new complexity and traps they will face eventually, but also with a vision of freedom, independence and potential that is near impossible to gain outside a microservice architecture.
But the important message that should hit everybody is that the people of an organization make microservice possible or impossible. The technology you chose is almost irrelevant if it doesn't suit the people you are working with. No matter what technology you use, a monolithic organization won't build anything but monolithic systems.
I'm new to microservices, but my start-up company wants to use them. What's in for me?
After reading Newman's book, I came to understand microservices less like "a software" and more like one of many ways to put your systems together. Observe that I am using the plural. If you create a single system - which is most often the sensible way to start in a new business - then you are incapable of having a microservice architecture. That said, Newman has you covered. He will give you all the advice needed to prepare your team and your system to evolve into a microsercive later on, but once and only once this step becomes necessary.
Will I get advice how to start developing and deploying multiple distributed but interacting systems from scratch?
You don't want to do that. Building Microservices will tell you why. A microservice architecture comes with a host of headaches, shocks and nightmares, not to mention an increased cost for everything and organizational strains. In Newman's own words:
What looks like a wonderland really is a horror trip for everybody involved. You need the revenue to cover the costs and pains for building microservices, and it really should be the last thing you consider under any circumstance. That said, Building Microservices is always trying to introduce you to the easiest options first, before carefully guiding you as safely as possible into the process of adopting microservices.
So why is everybody so hyped about microservices?
Because the software industry is always changing, and it changes fast. More and more industries migrate into the virtual landscape, erect their business portals in the cloud, with customers following close behind. Web is by far the quickest way to spent and gain money, so you want to reach as many people as possible. Companies come up with good ideas all the time, only to end up developing something completely different from what they originally intended, because the customers want it so. And let's face it, we need our customers to know what we can sell them in quality and in bulk.
So our business changes. The technology changes. The people we work with grow, organizations are restructured, changing who we are. Preparing your system for all the unknown eventualities to come is key for survival. Microservices are highly adaptable, highly flexible, highly resilient. They give you exactly what you need to survive under these conditions, but for them to really give you all these benefits, you have to be very careful about implementing them into your production.
Guiding you towards the right decisions is the ambition behind Building Microservices. It turned out a great book, and I would recommend it to anyone in the field who wants to get a better understanding of the whole picture.
Calling upon his extensive experience in working with microservice architectures, Sam Newman shares his insights about the ins and outs of every aspect you will encounter when building your own microservices.
I approached this book as a personal brush up on the topic, and to get back in touch with a broader perspective about developing software today. What I got out of this book was a rapid deep dive into conceptual theory, communication systems, error handling, enabling to evolve and so much more.
So do I know now how to build a Microservice?
No. This is not a cookbook that tells you how to write a microservice. In fact, this book feels more like a chess guide about strategy and tactics. If using microservices in your production was a game, then the tools, frameworks and programming languages make up a constantly increasing pool of pieces and the board is as big as you get to scale it. In this game, you have to keep the balances between complexity and advantages, risks and revenues, while always aiming to come out on top of the bargain. I know now how to look at my system(s) and decide in my own tech-stack if microservices are the right fit for its purpose.
Do I get advice on how to approach implementing microservices in my system(s)?
Yes. From cutting microservices out of your existing monolith, over communication and transaction techniques all the way across testing and deployment to security and scaling, Newman touches virtually every aspect of microservice implementation. Most issues will be demonstrated on illustrative examples from MusicCo, a fictional company accompanying us throughout the whole book, or with anecdotes from his real life experience on working for different clients and companies. On the downside, there are extremely many variations of technologies, strategic goals and organizational structures to be considered. Therefore, some corner cases get only brushed at very briefly. Under that light, the book seems short, but provides references for further reading.
Newman gives you perspective of the whole and guiding principles to work with.
In every chapter you will come out with a better understanding of the context and one or two default options to start with in your specific situation. The very first principle is "independent deployment", closely followed by "if it ain't broken, don't fix it". So on one side, you get practical criteria to recognize a microservice when you see one, but more importantly when something went wrong and what you got into production is not at all what you thought you designed. On the other side, he provides many calls to caution, to help you avoid critical traps along the way and keep things manageable and cost-efficient.
Who should read this book?
"Just remember that without people on board, any change you might want to make could be doomed from the start."
I really think the right question would be what this or that role in a software organization will get out of this book. Developers looking for a step by step guide to build their own microservice will be very disappointed. But developers working in a team that decided to go microservices will need to understand the ideas behind the new architecture, tools and technologies and what outcome they are to be used for.
"No matter how it looks at first, it's always a people problem." - Garry Weinberg
Architects will get a better understanding of their role, and how building microservices is about mapping individual systems and keep them out of each others way. Operators will get advice how to do things themselves or how to automate everything with proper tooling, which is extremely important if you want to keep doing microservices for longer than just a couple of months. Tech-lead and senior developers will come out with a better understanding of all the new complexity and traps they will face eventually, but also with a vision of freedom, independence and potential that is near impossible to gain outside a microservice architecture.
But the important message that should hit everybody is that the people of an organization make microservice possible or impossible. The technology you chose is almost irrelevant if it doesn't suit the people you are working with. No matter what technology you use, a monolithic organization won't build anything but monolithic systems.
"Any organization that designs a system [...] will inevitably produce a design whose structure is a copy of the organization's communication structure." - Conway's Law
I'm new to microservices, but my start-up company wants to use them. What's in for me?
After reading Newman's book, I came to understand microservices less like "a software" and more like one of many ways to put your systems together. Observe that I am using the plural. If you create a single system - which is most often the sensible way to start in a new business - then you are incapable of having a microservice architecture. That said, Newman has you covered. He will give you all the advice needed to prepare your team and your system to evolve into a microsercive later on, but once and only once this step becomes necessary.
Will I get advice how to start developing and deploying multiple distributed but interacting systems from scratch?
You don't want to do that. Building Microservices will tell you why. A microservice architecture comes with a host of headaches, shocks and nightmares, not to mention an increased cost for everything and organizational strains. In Newman's own words:
"It seems a lot of people adopting microservices are doing so because everyone else is doing it, rather than microservices being right for them."
"Microservice architectures give you more options, and more decisions to make."
What looks like a wonderland really is a horror trip for everybody involved. You need the revenue to cover the costs and pains for building microservices, and it really should be the last thing you consider under any circumstance. That said, Building Microservices is always trying to introduce you to the easiest options first, before carefully guiding you as safely as possible into the process of adopting microservices.
"Think not in big-bang rewrites, but instead of a series of changes made to your system over time to keep it supple."
So why is everybody so hyped about microservices?
Because the software industry is always changing, and it changes fast. More and more industries migrate into the virtual landscape, erect their business portals in the cloud, with customers following close behind. Web is by far the quickest way to spent and gain money, so you want to reach as many people as possible. Companies come up with good ideas all the time, only to end up developing something completely different from what they originally intended, because the customers want it so. And let's face it, we need our customers to know what we can sell them in quality and in bulk.
"Change is inevitable. Embrace it."
So our business changes. The technology changes. The people we work with grow, organizations are restructured, changing who we are. Preparing your system for all the unknown eventualities to come is key for survival. Microservices are highly adaptable, highly flexible, highly resilient. They give you exactly what you need to survive under these conditions, but for them to really give you all these benefits, you have to be very careful about implementing them into your production.
Guiding you towards the right decisions is the ambition behind Building Microservices. It turned out a great book, and I would recommend it to anyone in the field who wants to get a better understanding of the whole picture.
September 15, 2019
The book is a useful and practical guide on how to build and maintain a microservice architecture. Although it doesn't go much deep in the specifics, it covers all aspects of such architecture and you can find many valuable takeaways. Some of the topics discussed are: when microservice architecture should/shouldn't be used, splitting monolith applications, designing, deploying, testing, monitoring, and scaling microservices.
September 5, 2015
I worked with Sam a few years ago and I was curious to see what he'd been up to.
Microservices are all the rage, right now. At work, I've been struggling with a monolith of my own. We cannot upgrade the technology stack because the task is just too big. Had we had a microservice-based approach, we would have had small pieces that we could have upgraded one at a time over time.
The most important characteristic of microservices is to minimize coupling between them, so that the lifecycle of one is not tied to the lifecycle of any others. With an independent lifecycle, a microservice is free to evolve at its own pace. Finding the right boundaries between microservices is therefore critical. And the choice of integration technology can influence the options for implementing a microservice too.
The book gives a whirlwind tour of the a wide array of techniques and technologies that can help you manage a simple service but become crucial when dealing with a large number of cooperating microservices. Some examples, in no particular order:
HATEOAS
Docker
customer-driven contracts
Graphite
ELK (Elasticsearch, Logstash, Kibana)
collectd
Strangler pattern when replacing legacy systems
immutable servers
correlation IDs
Netflix's Simian Army
circuit breakers and bulkheads to contain failures
distributed transactions
data pumps for aggregating data in data warehouses
RPC vs. event-based
Some of the anecdotes reminded me of experiences I've had a Google, some of them great and some of them less so. Overall, the book gives broad coverage of all the things you must keep in mind if you want to start using microservices. It does not provide in depth coverage of any one topic, so you have to look elsewhere for direct implementation advice. The book does give you a number of places to start looking and the big picture view so you can see how the pieces fit together.
Microservices are all the rage, right now. At work, I've been struggling with a monolith of my own. We cannot upgrade the technology stack because the task is just too big. Had we had a microservice-based approach, we would have had small pieces that we could have upgraded one at a time over time.
The most important characteristic of microservices is to minimize coupling between them, so that the lifecycle of one is not tied to the lifecycle of any others. With an independent lifecycle, a microservice is free to evolve at its own pace. Finding the right boundaries between microservices is therefore critical. And the choice of integration technology can influence the options for implementing a microservice too.
The book gives a whirlwind tour of the a wide array of techniques and technologies that can help you manage a simple service but become crucial when dealing with a large number of cooperating microservices. Some examples, in no particular order:
HATEOAS
Docker
customer-driven contracts
Graphite
ELK (Elasticsearch, Logstash, Kibana)
collectd
Strangler pattern when replacing legacy systems
immutable servers
correlation IDs
Netflix's Simian Army
circuit breakers and bulkheads to contain failures
distributed transactions
data pumps for aggregating data in data warehouses
RPC vs. event-based
Some of the anecdotes reminded me of experiences I've had a Google, some of them great and some of them less so. Overall, the book gives broad coverage of all the things you must keep in mind if you want to start using microservices. It does not provide in depth coverage of any one topic, so you have to look elsewhere for direct implementation advice. The book does give you a number of places to start looking and the big picture view so you can see how the pieces fit together.
August 19, 2018
Excelente livro de Sam Newman, que cobre todos os principais aspectos da arquitetura de microserviços, desde itens clássicos como bounded contexts e transações distribuídas até estratégia de como quebrar um sistema monolítico em microserviços. Todos os pontos abordados no livro são introdutórios, caso contrário o livro teria no mínimo 1000 páginas. Mas vale ressaltar que são introduções na medida certa, muitas vezes com referências externas para se aprofundar caso haja interesse. Valeu cada centavo gasto. Se você já é especialista no assunto, vale a pena pensar duas vezes antes de comprar.
August 15, 2016
I was somewhat skeptical about the book. Microservices are hype and seems that everyone nowadays has own advice on how to break the scary monolith. Still I found this book very good. Apart from the concrete "break the monolith" subject, it addresses many common architectural - and on my opinion - much more important questions - about good software design, art of decision making, coupling and cohesion, DDD and much more. Technical advices and sum up of different tooling are also quite useful.
September 30, 2018
Sam Newman's book tackles the challenge of sttling the reference text on microservices. First the architecture principles are hare, clearly stated and opiniated. Second it handles different aspect of the architecture such as tests, scaling or reaching here from legacy. The content is here and it's clearly and well written. Job done.
Ma note de lecture en Français ici
Ma note de lecture en Français ici
April 14, 2023
What bothered me was that its a book that isn‘t sure which purpose it fulfills. It‘s neither a book that you can read cover to cover, nor one where you look up things if you need them. So it‘s sometimes extremely high level system design, and sometimes a concrete problem thats being solved. Overall it was too high level for me, I would rather read something like „designing data intensive applications“ to really understand what’s going on.
March 19, 2017
"The need to change our systems to deal with scale isn't a sign of failure. It is a sign of success."
Displaying 1 - 30 of 427 reviews