My take: 1. "I have this application, but I need to process batch jobs / run heavy workflows / do ML etc..." -- definitely split into multiple services. 2. "I

My take: 1. "I have this application, but I need to process batch jobs / run heavy workflows / do ML etc..." -- definitely split into multiple services. 2. "I have this application, but this one feature I want to add is implemented really well as a library/app that's not easy to integrate" -- same spirit as 1 -- also a good candidate for SOA 3. "I have an application for end users, and various internal tools that differ in their quality/security/privacy requirements" -- probably a good reason to build those separately (but not a necessity) 4. "I have an application and it doesn't scale well with my growth" -- this is one of the most common reason behind implementing microservice architecture, but I think it requires a lot more thought than just 'yup, let's obviously do horizontally scalable microservices' 5' "Our monolith is slow to compile, run and test" -- careful with this one: it's probably easier in the majority of cases to fix your tests, builds, and runtime speeds, than start splitting up your (probably already very complex) application into services 6. "Our org is split into multiple functional groups and we want to move independently" -- not a good reason for SOA/microservices: you're increasing eng complexity and reducing org collaboration and risking a lot of work overlap. 7. "Microservices have been successful in [Big Company]" -- not a good reason. The benefits/trade-offs are usually fairly unique to each organization and require careful "inward" thinking instead of following trends 8. "One microservice per business function is a good pattern and we're going to mandate it" -- terrible idea. Top-down eng culture mandates prevent better solutions from even being considered. Don't do this at your company.