Review of [YouTube video](https://www.youtube.com/watch?v=ZChGXfRDHKA) by [[Sam Newman]].
## Summary
- The "micro" part was a mistake when naming and size ultimately doesn't really matter.
- The ideal size has so many factors and is organisation-specific so not worth debating.
- The number of microservices in your solution is much more relevant. As you increase number of microservices, you increase the benefits but also increase the painpoints of managing them all.
## Detailed Notes
- Potential ways to measure a microservice's size:
- Lines of Code:
- not ideal
- different languages are more/less expressive
- different problem domains simply will require more code
- **Number of interfaces to other services**
- Minimise interfaces and keep rest encapsulated
- **Ultimately the concept of size is a bit of a red herring. ==If we had time over again, we would go back and remove the "micro" part of the name==**.
- Uses example of company called Gilt who slowly ramped up their use of microservices over time after starting with a [[Ruby on Rails]] ([[Monolithic architecture]]).
- **Main question to ask yourself is "How many services can you manage?"**
- "**The vast majority of pain, suffering and anguish is related to the interactions between them**. These things become worse, the more you have of them".
- Analogy: "**Think of adopting microservices as turning up a dial — as you turn dial up, you get more of the benefits of them and the opportunity to take advantage of them, but you also magnify all the pain of building them.**" Find your happy place on the dial and don't compare yourself to other orgs.
- Worry less about size, and more about what you're doing with them.
---
tags: #SoftwareArchitecture #ArticleReview #Video