"Don't use tools aimed at Google levels of complexity" is a take that has become quite popular, but it's definitely lacking nuance. Tools are pretty multi-facet

"Don't use tools aimed at Google levels of complexity" is a take that has become quite popular, but it's definitely lacking nuance. Tools are pretty multi-faceted and rarely have a single selling point. For example, Kubernetes solves a whole boatload of general service orchestration problems in a unified way; perhaps it's true that you only ever need this at Google scale, but you can certainly benefit from it at almost any scale where it runs. (Which is a lot. k3s is pretty light.) Does that mean you should write microservices for your toy? Probably not. But the trade-off calculus for microservices is not scale. It is a lot of things. If you had an application that was extremely trivial to run as decoupled services, and the boundaries between them are not liable to change much, maybe you really should use microservices from zero, and benefit from better failure isolation among other things. But yes, probably not. Still, I think the idea that microservices are not really a great idea is a flimsy justification for Ruby on Rails in general. It's fair enough to say that if your language, framework and library choices are working for you and your product, you aren't beholden to justify them really. That said, that doesn't mean they couldn't be better with different decisions, and it's sincerely hard to determine that. Sometimes, I get the feeling that articles in this vein are just as much about convincing the authors that they made the right choice as it is convincing anyone else. But it's not really that important, since I don't really feel you actually need to convince much of anyone, if you like your decision.