Review of [YouTube video]( 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