You can also introduce bottlenecks this way.  The most obvious of which is now you&#x27;ve introduced a socket boundary and very likely at least one network roundtrip for a piece of functionality that used to be local.<p>That said, one of the reasons I like using Erlang for building services is the structural primitive of the OTP Application.  It makes it pretty easy to build something self-contained that exposes a function API but can be deployed local to your other processes on the same VM or be trivially moved out to a dedicated machine&#x2F;cluster as a remote service with almost no change to the programming model for interacting with it.<p>Deciding where a piece of functionality should live is almost purely a question of how much latency you&#x27;re willing to tolerate.  Though to be fair, this is because the OTP Application construct gives an incentive to not build a true monolith from the outset, despite the fact that everything that makes up your whole system might be in one big release tarball.