3 ms·

I think the thing people normally miss about microservices is that the goal of microservices is usually to solve organization and people problems and not techno

I think the thing people normally miss about microservices is that the goal of microservices is usually to solve organization and people problems and not technological ones. There's some tech benefits like allowing services to scale independently, but the biggest benefit is clear ownership boundaries and preventing code from becoming overly coupled where it doesn't need to be. If you're a team small team working on a single product you probably don't need microservices since you likely don't have the type of organizational problems that microservices solve. Microservices are likely premature optimization and you're paying the price to solve problems you don't yet have.

koliber 3y ago
Yep. There are situations where microservices genuinely add net value. In discussions like this one, people make valid points for microservices and for monoliths. Often, words like “large” and “many” are used without providing a sense of scale. Hers is a heuristic. It’s not a hard rule. There are likely good counter examples. It does sketch a boundary for the for/against equation for microservices. Would love to hear feedback about whether “100” is that number or a different heuristic would be more accurate. Engineering departments with fewer than 100 engineers should favor monoliths and seriously question efforts to embrace microservices. Above that, there’s an increasing chance the microservices could provide value, but teams should stick to a monolith as long as possible.