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