3 ms·

Team size isn’t the only factor in breaking a monolith into services. In my experience it's been an effective strategy for removing bottlenecks in your applicat

• im_down_w_otp 11y ago
  You can also introduce bottlenecks this way. The most obvious of which is now you've introduced a socket boundary and very likely at least one network roundtrip for a piece of functionality that used to be local. 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/cluster as a remote service with almost no change to the programming model for interacting with it. Deciding where a piece of functionality should live is almost purely a question of how much latency you'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.