Earlier quoted context omitted.
If one part of the application needs to be changed frequently and/or is used by other applications, then it makes sense to separate it as a microservice. However, for other parts, I think it might be better to stay as a monolith since when you have a network in your calls, things get messier. Networks are unreliable even if it is your local area network. In my career I saw some unrelated network equipment was sending…
Not sure if rate of change truly matters. In my opinion, microservices make most sense when dealing with multiple team. It's much easier to update core services when everyone depends on it through the network, rather than requiring people to redeploy their stuff. If you're a single team operation, it's not really a problem if all your stuff runs in a single process. It may even benefit you in terms of performance and…
On the other hand, I agree with your point of multiple teams. I tried to mean same thing with "used by other applications"