
By Sam Newman
Favorite quotes and key takeaways from this book.
“As Ben Christensen from Netflix puts it, when we think about the bigger picture, “it needs to be a cohesive system made of many small parts with autonomous lifecycles but all coming together.” So we need to find the balance between optimizing for autonomy of the individual microservice without losing sight of the bigger picture. Defining clear attributes that each service should have is one way of being clear as to where that balance sits.”
Key takeaway
The end service is a sum of its parts, but you still need to make each individual part great for the entire thing to be great
“We want related behavior to sit together, and unrelated behavior to sit elsewhere. Why? Well, if we want to change behavior, we want to be able to change it in one place, and release that change as soon as possible. If we have to change that behavior in lots of different places, we’ll have to release lots of different services (perhaps at the same time) to deliver that change.”
Key takeaway
Abstraction is key to coding
“Make sure you know what you’re getting: keep your middleware dumb, and keep the smarts in the endpoints.”
Key takeaway
Middleware is a commodity. Focus on value at the endpoints
“Build if it is unique to what you do, and can be considered a strategic asset; buy if your use of the tool isn’t that special.”
Key takeaway
Wardley mapping. Don’t build custom commodities...
“The answer here is pretty straightforward: monitor the small things, and use aggregation to see the bigger picture.”
Key takeaway
Focus on the inputs and the rest will take care of itself
“This led famously to its two-pizza teams, where no team should be so big that it could not be fed with two pizzas. This driver for small teams owning the whole lifecycle of their services is a major reason why Amazon developed Amazon Web Services. It needed to create the tooling to allow its teams to be self-sufficient.”
Key takeaway
Smaller teams can outduel bigger ones
“As we’ve discussed before, we aim to ensure our services are decomposed such that the pace of change inside a service is much higher than the pace of change between services.”
Key takeaway
Things broken into small pieces can be optimized and modified much easier and quicker than a big thing
“But let’s again consider what microservices are: services modeled after a business domain, not a technical one. And if our team that owns any given service is similarly aligned along the business domain, it is much more likely that the team will be able to retain a customer focus, and see more of the feature development through, because it has a holistic understanding and ownership of all the technology associated with a service.”
Key takeaway
Be audience focused instead of technically / functionally focused
“By decomposing our systems into finer-grained microservices, we’re hoping to expose lots of seams in the form of APIs that people can use to do many, hopefully wonderful, things. If you get your discovery right, we know where things are. But how do we know what those things do, or how to use them? One option is obviously to have documentation about the APIs.”
Key takeaway
Microservices are like APIs and allow lots of small teams to connect
“Experience has shown us that interfaces structured around business-bounded contexts are more stable than those structured around technical concepts. By modeling the domain in which our system operates, not only do we attempt to form more stable interfaces, but we also ensure that we are better able to reflect changes in business processes easily. Use bounded contexts to define potential domain boundaries.”
Key takeaway
Organize around a business objective, not a technical/functional objective
“Learn to embrace the concept of evolutionary architecture, where your system bends and flexes and changes over time as you learn new things. Think not of big-bang rewrites, but instead of a series of changes made to your system over time to keep it supple.”
Key takeaway
Focus on the little things, they add up!