When to extract or introduce a service

In my mind, there are a small number of legitimate reasons to split out a new back-end service in an existing architecture. Here they are:

1. The new functionality would be easier to build using a different tech stack
2. The scaling requirements of the new functionality are different than the current system
3. The new functionality requires different access controls than the rest of the system
4. A different deployment method or frequency would be better for the new functionality.

Or, stated in pain points:

1. I can’t build this in the language we’re using
2. This thing won’t be performant enough if I add it to our current system
3. No way in heck am I giving our current system unfettered access to X
4. I have to deploy 137 times a day and our current CI workflow takes an hour

There are a lot of hard things about building distributed systems. These problems include: eventual consistency, serialization overhead, network latency, segmentation tolerance, distributed consensus, service discovery, schema synchronization, ordered changes, inter-service authentication, service-to-service encryption, request loops, event loops, event ordering, lions, tigers, bears, sharknados, and most terrifyingly XML if you do it wrong. New services should not be split out lightly – often the pain of solving all the issues of distributed systems is worse than the pain of working in a crufty old codebase. Introduce network boundaries only with great thought and consideration.