🎥 Link to the video
When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020
📚 Cited books
I have actually only heard you complain of people using microservices when they shouldn't have done. - Martin Fowler
People often tend to focus on the tech tool (the output), not the thing the tech tool let's you do (the outcome).
Going microservices should be a conscious choice that you have made because of some outcomes you are looking for, because of some benefits that such architecture can give you.
Good to ask: What is the benefit is going to give to you?
Example of benefits:
- More options to scale up the applications
- Independent deployability
- Limit the "Blast Radius" failures
When adopting microservices you always buy options. This means that all the advantanges you get comes with a cost!
Why?
- Microservices are not an ON/OFF switch
- Microservices are distributed systems, and they are hard
If you ever consider to try out microservices, don't spend months on deciding which platform to use. Just go with one and see what happens.
- Zero-downtime independent deployability.
- Isolate the data and its processing (example: GDPR).
- Enable an high-degree of organizational autonomy (distribute responsabilities into teams and reduce the amount of coordination needed between teams).
One of the major pitfalls of adopting microservices is ending up with a distributed monolith: when the deployment of a service is dependant on another. "I need to deploy this service before you can deploy your service."
- Create a deployment mechanism (don't bundle deployment of different services together)
- Look for recurring patterns (look for services that changes together)
- Information hiding (expose API, not data)
- Easier to limit the impact of each release
- Time to release
- Reduce the scope of the change (one team one codebase vs multiple teams one codebase)
We already have team and responsibilities boundaries within a monolith architecture, using modules, but they are often violated. Breaking modules into services makes it hard to violate.
- Data is hard.
- A lot of complexity of breaking complex systems lies in the data.
- After extracting a microservice you need to understand what part of the old database will be used.
- There has to be a willingness to change as an organization if you want to make the most out of using microservices.
- Microservices will very rarely save you money. They might help you make more money.
- Going microservices it doesn't have to be overnight.
- Rather than tech, it's more about how much degree of responsibilities and freedom we want each team to have. What kind of organization we want to be?