Scan barcode
mattj256's review
5.0
A high-level overview of the advantages (and disadvantages) of microservices, with a lot of high-level information about how to handle various aspects of system architecture.
As someone who is new to microservices, I thought this book was great. I'm mostly looking for high-level information, not code samples. (If you're looking for step-by-step instructions of how to build things, this is not the book for you.)
The most interesting parts of the book were the occasional real-world examples. The author describes something that broke in production, why it broke, and what steps were taken to make the system more resilient going forward. Definitely recommended if you're looking for a high-level overview.
As someone who is new to microservices, I thought this book was great. I'm mostly looking for high-level information, not code samples. (If you're looking for step-by-step instructions of how to build things, this is not the book for you.)
The most interesting parts of the book were the occasional real-world examples. The author describes something that broke in production, why it broke, and what steps were taken to make the system more resilient going forward. Definitely recommended if you're looking for a high-level overview.
albcorp's review against another edition
5.0
This is a book that perfectly fulfills the role that it set for itself. Throughout, the writing was clear and direct, and had just the right level of informality to make it easier to read. It did not attempt to tell me everything about the subject, and as a result I feel confident that I have gained a very useful overview. The final chapter summary was particularly helpful in this respect. I wish every book had one as good as this #
afuerstenau's review against another edition
5.0
Very interesting, not so long read about different aspects regarding micro services. Spiced up with stories, models and code. Definitely worth reading for me.
lucapette's review against another edition
2.0
It felt more like a series of blog posts (sometimes, paragraphs seemed very disconnected from each other)
joaodiasconde's review against another edition
3.0
This book covers many topics related to microservices and distributed systems overall. As such, and given it is a relatively short book, it does not discuss in depth any of them but certainly gives enough detail for a junior to grasp core concepts. In short, it is a great introductory book to this architectural style and brings our attention to common pitfalls.
arkron's review against another edition
2.0
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.
jordi's review against another edition
4.0
Buen resumen de todo lo que tienes que saber sobre microservices
pero por el tamaño del libro, no puede entrar en detalles en ninguno de los aspectos.
Lo peor es que aunque referencia muchos otros trabajos, no hay un indice de estas referencias.
Asi que hice el mio propio
https://medium.com/@trusmis/references-for-the-building-microservices-book-d146c8a7142c#.zc5yfaqyy
pero por el tamaño del libro, no puede entrar en detalles en ninguno de los aspectos.
Lo peor es que aunque referencia muchos otros trabajos, no hay un indice de estas referencias.
Asi que hice el mio propio
https://medium.com/@trusmis/references-for-the-building-microservices-book-d146c8a7142c#.zc5yfaqyy
hundred's review against another edition
4.0
I work on microservices for a living and I found this book to be very valuable. Mainly because it makes you evaluate and inspect aspects of microservices which one might take for granted or assume to be standard based on work experience.
Newman starts the book out with a description of microservices and, surprisingly, a discussion of what it means to be an "architect" (or perhaps more appropriately - "town planner") for a microservices architecture. I found this particular section to be super helpful at this particular point in my career, as it focuses on communicating the rationale for a technical direction to a team and putting in place resources to help *people* move towards an architecture which is good for the business.
After the first two chapters, we dive into technical details and things to consider for a microservices architecture: Modelling, Integration (Rest vs RPC, Synchronous vs Asych communication), splitting up the Monolith, Monitoring, etc. All of this is covered at a high level, but if you're working in a microservices architecture already it forces you to think about these aspects and how they actually work at your company. At my place of employment, a lot of this stuff is abstracted away behind our tooling, so it's helpful to think about how I'd do it at a startup.
Some of the ideas I found most useful:
- High cohesion, Loose coupling - building services to be loosely coupled means that they interact with each other through technology-agnostic interfaces which allow each service to be deployed independently. When an architecture has high cohesion, you only need to go to one place when a behaviour needs to change. i.e. If I need to change the properties of a user, I should only need to go to the user service to do that.
- The concept of Orchestration vs Choreography - I'm not sure I love these analogies, but Newman presents Orchestration as a service which accepts requests, runs them through central business logic and then tells a number of dumb services exactly what to do, and Choreography as being event driven, with smart services taking action on events. When a user is created, for example, an event may be emitted which is consumed by the registration and search service, which each have business logic to do their own thing. Newman strongly prefers Choreography.
- Incremental change - Making changes incrementally as opposed to trying to execute big bang migrations makes a lot of sense to me. There's less risk of your project not delivering any value, and it allows you to get things wrong as you execute the migration without upsetting a very large project.
- Splitting the Monolith using bounded contexts - start by breaking your monolith into clear modules which have their own responsibilities, then migrate those modules to their own service. Constructing these service boundaries is hard, so this may change.
- Constructing practices from principles which are derived from business goals is a good way to think about making sure that your engineering habits are grounded in some business value. I liked this whole chapter on Evolutionary Architects.
Some things to note:
- The book is a little dated (2015), so doesn't cover some newer trends like Container Orchestration, Infrastructure as code, or Observability. Docker, for example, is a "I hope people start using this" mention in this book.
- Maybe a subset of the above, some of the technologies which were highlighted in this book feel faddish (or maybe the author has an affiliation) such as HATEOS, Fitnesse, some XML libraries which are pitched.
- I found that some of this advice doesn't seem to apply very well to very large scale organizations. Using raw REST over and HTTPClient vs an RPC framework may be good advice for a startup but becomes difficult when you have hundreds of microservices and need an easy onramp for new developers. Consider whether the advice applies well to your domain.
- The BIG question "Do you even need to use microservices?!" Comes at the END of the book! This should be the first thing that he discusses but is only brought up very briefly in the first chapter.
Overall, an amazing introduction to microservices, with a broad set of topics which has helped me to think more critically about the services I help build.
Newman starts the book out with a description of microservices and, surprisingly, a discussion of what it means to be an "architect" (or perhaps more appropriately - "town planner") for a microservices architecture. I found this particular section to be super helpful at this particular point in my career, as it focuses on communicating the rationale for a technical direction to a team and putting in place resources to help *people* move towards an architecture which is good for the business.
After the first two chapters, we dive into technical details and things to consider for a microservices architecture: Modelling, Integration (Rest vs RPC, Synchronous vs Asych communication), splitting up the Monolith, Monitoring, etc. All of this is covered at a high level, but if you're working in a microservices architecture already it forces you to think about these aspects and how they actually work at your company. At my place of employment, a lot of this stuff is abstracted away behind our tooling, so it's helpful to think about how I'd do it at a startup.
Some of the ideas I found most useful:
- High cohesion, Loose coupling - building services to be loosely coupled means that they interact with each other through technology-agnostic interfaces which allow each service to be deployed independently. When an architecture has high cohesion, you only need to go to one place when a behaviour needs to change. i.e. If I need to change the properties of a user, I should only need to go to the user service to do that.
- The concept of Orchestration vs Choreography - I'm not sure I love these analogies, but Newman presents Orchestration as a service which accepts requests, runs them through central business logic and then tells a number of dumb services exactly what to do, and Choreography as being event driven, with smart services taking action on events. When a user is created, for example, an event may be emitted which is consumed by the registration and search service, which each have business logic to do their own thing. Newman strongly prefers Choreography.
- Incremental change - Making changes incrementally as opposed to trying to execute big bang migrations makes a lot of sense to me. There's less risk of your project not delivering any value, and it allows you to get things wrong as you execute the migration without upsetting a very large project.
- Splitting the Monolith using bounded contexts - start by breaking your monolith into clear modules which have their own responsibilities, then migrate those modules to their own service. Constructing these service boundaries is hard, so this may change.
- Constructing practices from principles which are derived from business goals is a good way to think about making sure that your engineering habits are grounded in some business value. I liked this whole chapter on Evolutionary Architects.
Some things to note:
- The book is a little dated (2015), so doesn't cover some newer trends like Container Orchestration, Infrastructure as code, or Observability. Docker, for example, is a "I hope people start using this" mention in this book.
- Maybe a subset of the above, some of the technologies which were highlighted in this book feel faddish (or maybe the author has an affiliation) such as HATEOS, Fitnesse, some XML libraries which are pitched.
- I found that some of this advice doesn't seem to apply very well to very large scale organizations. Using raw REST over and HTTPClient vs an RPC framework may be good advice for a startup but becomes difficult when you have hundreds of microservices and need an easy onramp for new developers. Consider whether the advice applies well to your domain.
- The BIG question "Do you even need to use microservices?!" Comes at the END of the book! This should be the first thing that he discusses but is only brought up very briefly in the first chapter.
Overall, an amazing introduction to microservices, with a broad set of topics which has helped me to think more critically about the services I help build.