Scan barcode
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.
fingolfintek's review against another edition
3.0
I first picked this one up back in 2016, made it halfway through or thereabouts and then life happened - I was fairly busy at work for a couple of months and the book completely slipped my mind... Until now - 2020 the year I had time.
I honestly don't know what to think - the writing was above average for a technical book: the sentences were natural, the style simple yet not simplistic, explanations short and to the point, advice sound, no space was lost on waffle and even the humour was good! Unfortunately, that's not all you need to write a good technical book.
Each chapter and consequently the book as a whole is comprised of a collection of high-level principles, usually illustrated by using a made-up online music store as an example. The great thing about being a book that deals exclusively with principles and ways of thinking is that what you preach has a decent chance to stay relevant for a long time - as is the case here, where even five years later everything stated still holds.
However, it is worth mentioning that even in 2016 or for that matter in 2015, when it was originally published, the book was hardly a revelation - all of the principles presented here have more or less been known for years, have been tried, tested, and shouted from the battlements by Netflix, Spotify, Amazon and all the other big names who owed their business successes, at least in part, to the massive adoption of microservices.
Reading this in 2020, one can also see a glaring hole where serverless should be - granted, it was still very new and riddled with growing pains in 2015 but it showed tremendous promise, and I wish the author at least mentioned it in passing.
So, to sum it all up - even in today's landscape the book is a decent collection of sound advice... that more or less everyone already knows and has known for years.
I honestly don't know what to think - the writing was above average for a technical book: the sentences were natural, the style simple yet not simplistic, explanations short and to the point, advice sound, no space was lost on waffle and even the humour was good! Unfortunately, that's not all you need to write a good technical book.
Each chapter and consequently the book as a whole is comprised of a collection of high-level principles, usually illustrated by using a made-up online music store as an example. The great thing about being a book that deals exclusively with principles and ways of thinking is that what you preach has a decent chance to stay relevant for a long time - as is the case here, where even five years later everything stated still holds.
However, it is worth mentioning that even in 2016 or for that matter in 2015, when it was originally published, the book was hardly a revelation - all of the principles presented here have more or less been known for years, have been tried, tested, and shouted from the battlements by Netflix, Spotify, Amazon and all the other big names who owed their business successes, at least in part, to the massive adoption of microservices.
Reading this in 2020, one can also see a glaring hole where serverless should be - granted, it was still very new and riddled with growing pains in 2015 but it showed tremendous promise, and I wish the author at least mentioned it in passing.
So, to sum it all up - even in today's landscape the book is a decent collection of sound advice... that more or less everyone already knows and has known for years.
henryarmitage's review against another edition
4.0
This is a fairly easy read that doesn't get into a lot of code or technical details. Besides microservices, covers a lot of the tools and techniques an architect should consider when designing a modern application.
spyralnode's review against another edition
5.0
The essential book on microservices. For a technical subject, this is very readable, and does an excellent job at combining approachability in style with precise and well-explained concepts.
Sam Newman is objective in his proposal and identifies both cases when these techniques work and cases where they don’t, and invited the reader to think about potential outcomes from design choices, such as through the CAP theorem. He also discusses the role of the architect and Conway’s law and organisational politics, making this a very complete read.
For me what was especially valuable was how he goes through his train of thought, justifying and criticising step by step what will happen and how this could be improved upon, for example on redundancy strategies and scaling.
Sam Newman is objective in his proposal and identifies both cases when these techniques work and cases where they don’t, and invited the reader to think about potential outcomes from design choices, such as through the CAP theorem. He also discusses the role of the architect and Conway’s law and organisational politics, making this a very complete read.
For me what was especially valuable was how he goes through his train of thought, justifying and criticising step by step what will happen and how this could be improved upon, for example on redundancy strategies and scaling.