Hacker News Reader

Comment by anankaie | Hacker News Reader

Ideally, What I want is the ability to decide later whether a particular call should be local, or RPC, and I should not have to care about any of it until I need to start scaling. I should also not need to specify locally what is going on - my reference infrastructure should handle turning the call into a jump-call or a net-call. Ideally, the fiber system that simulates multithreading for me should have an extensibility point that allows my RPC infrastructure to hook into it and "do the right thing" by treating RPC calls as the equivalent of cross-proc co-routines, especially if my OS lets me transparently share memory between two processes: In a way that would let me share pointers and modules across them.

Someday I will find a way to untangle this wishlist enough to turn into a design.

View on HN

> What I want is the ability to decide later whether a particular call should be local, or RPC

Using hindsight, most of the systems that pretend that the network part of invoking RPCs is "easy" and "simple" and "local" end up being very complex, slow and error prone themselves.

See DCOM, DCE, CORBA and EJBs RMI.

You need instead a efficient RPC protocol that doesn't hide the fact it is a RPC protocol - like Cap'n Proto (it's "time-traveling RPC" feature is very interesting).

IMO the real problem with microservices comes from dealing with distributed state - going from one data store with usually strong consistency guarantees - to many distributed stores that have no way of ensuring they are in sync is the hard part.

RPC vs local calls is trivial in comparison and you can get that level of transparency out of the box with functional programming - it's just data in data out.

Ideally yes. But there are two major differences between a local and a remote call:

1) A remote call – inherently – fail. However, some local calls never fail. Either because they are designed to never fail or because you have done the required checks before executing the call. A remote call can fail because the network is unreliable and there is no way around that (?).

2) A remote call – inherently – can be very slow. Again because of the unpredictable network. A local call may be slow as well but usually either because everything is slow or because it just takes a while.

So if you have a call that may or may not be local you still have to treat it like a remote call. Right?

I think having a certain set of calls that may or may not be executed locally is not that bad. Usually it will just be a handful of methods/functions that should get this "function x(executeLocally = false|true)" treatment - which is prob. an acceptable tradeoff.

The cool part about "some local call never fails" is that because of scale out, out-of-order multi-threaded execution, is that even "local calls" (for some definitions of local) can fail as your preconditions get invalidated in other threads, unless you're employing mutexes/barriers.

Those modern computers are a network mesh of small D/G/CPUs, and it's coming back to bite us sometimes.

CORBA made rpc calls opaque, which was nice in theory, but there are faults that need to be handled only for remote calls. It’s a lot of extra code to handle those faults that you don’t need for local functions.

DCOM and CORBA are the two tarpit nightmares that you want to do everything you can never to have anything to do with.

I think dcom does this

Reply on news.ycombinator.com