3 ms·
“You don’t need to introduce a network boundary as an excuse to write better code” Absolutely this! microservices is just decoupling by another name.... and y
by TickleSteve 10y ago
“You don’t need to introduce a network boundary as an excuse to write better code”
Absolutely this!
microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this.
Monolithic code can also be nicely decoupled too.
- dragonwriter 10y ago> microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this. If code is decoupled enough that it can be separated into independent processes communicating over a network, that creates additional freedom into how the components can be deployed to (real or virtual) hardware, which is itself a kind of decoupling. If you have processes communicating by local-only IPC methods or, even moreso, components operating within the same process, there is a form of tighter coupling than exists when the components are separate networked components.
- naasking 10y ago> If code is decoupled enough that it can be separated into independent processes communicating over a network, that creates additional freedom into how the components can be deployed to (real or virtual) hardware, which is itself a kind of decoupling. It also introduces additional failure modes.
- jimbokun 10y agoSounds like you are on the verge of investing Erlang!
- TickleSteve 10y agodisagree, coupling is a logical connection, and has nothing to do with calling-semantics. Whether a local function call or an RPC, its still the same level of coupling, this is just a difference in the (equivalent of) a link-layer in a network stack. Adding a network connection is a much more complicated calling-semantic than a function call, many more and different failure modes.