"When should I use microservices?" When you need to. There is a long history of applications being implemented poorly and then switching their design in order

"When should I use microservices?" When you need to. There is a long history of applications being implemented poorly and then switching their design in order to fix the implementation. Stop that! Shitty legacy codebases are a fact of life, but just changing the design without considering why it needs to be that way won't result in anything more than a new shitty implementation. At a previous employer, there was a mandate given down that all new services had to be 100% API-driven. Of course, very few people followed this. But even if they had, this would not have resulted in every single team's tools performing better or more reliably. Some head honcho probably just wanted the potential for all of the benefits of services with APIs, but completely ignored the fact that there's cases where you just don't need an API, or that it would be effectively meaningless to its function. You can design monolithic now, and split out micro-services later, or vice versa. The former allows you to work faster and get shit done now. The latter gives you the idea that in the future you can tie together new services with a minimum of effort, but not a promise. Add to that that it's the equivalent of wrapping every system call in a shellack of IPC calls and you get into some really kludgy stuff. And heaven forbid you ever need to call one of those services 10,000 times more than you used to and suddenly wonder why there's a big bottleneck in your system that didn't exist when the function was monolithic.