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