Separation of concerns between code and service layout (2010)(josephkirwin.com)
josephkirwin.com
Separation of concerns between code and service layout (2010)
https://www.josephkirwin.com/2020/10/04/separation-of-concerns-between-code-and-service-layout/
4 comments
(author of this blog post..)
I was aware of CORBA, but have never worked with it. I should have added a link out to it, I might do that.
I think most ideas do have necessary conditions to succeed, and perhaps network latency (especially in single VPC) has improved a lot since those days.
The original motivations weren't just network based. The scenario where I wanted to use CAP_LINUX_IMMUTABLE to create append-only log files via EXT4 attr was a good example of where being able to decorate a function to say that it runs in a separate container potentially seemed like a reusable concept.
> trying to abstract away the differences can be a bad scene
Agree, generally I'm against "magic" behavior in code. That's why I quite like the protobuf philosophy of being able to see the generated code at compile time, as opposed to some runtime magic.
What I'm suggesting is just to abstract some of that boilerplate code, but it could still go badly if used without consideration.
I was aware of CORBA, but have never worked with it. I should have added a link out to it, I might do that.
I think most ideas do have necessary conditions to succeed, and perhaps network latency (especially in single VPC) has improved a lot since those days.
The original motivations weren't just network based. The scenario where I wanted to use CAP_LINUX_IMMUTABLE to create append-only log files via EXT4 attr was a good example of where being able to decorate a function to say that it runs in a separate container potentially seemed like a reusable concept.
> trying to abstract away the differences can be a bad scene
Agree, generally I'm against "magic" behavior in code. That's why I quite like the protobuf philosophy of being able to see the generated code at compile time, as opposed to some runtime magic.
What I'm suggesting is just to abstract some of that boilerplate code, but it could still go badly if used without consideration.
Makes sense, thanks for the clarification! Do you think it's a good idea to have a "passthru" option at all?
The Erlang VM lets you move actors from your local computer to a different cluster transparently for the caller.
The author seems to be thinking it can be transparent at the method call site, but it’s not really the case: when executed locally, pure functions are guaranteed to return (unless hardware limitations), while remote execution necessarily brings the network issues with it; pure functions could now fail for network reasons, but only when running elsewhere.
Erlang works around this by forcing you to think of calls to actors as messages and to deal with all the network issues that come with it: works both locally and non locally.
The author seems to be thinking it can be transparent at the method call site, but it’s not really the case: when executed locally, pure functions are guaranteed to return (unless hardware limitations), while remote execution necessarily brings the network issues with it; pure functions could now fail for network reasons, but only when running elsewhere.
Erlang works around this by forcing you to think of calls to actors as messages and to deal with all the network issues that come with it: works both locally and non locally.
why is this marked (2010)? I think it's from 2020-10-04!
Hmm, I actually don't know why that was added, or how I can remove that. Maybe it was added because I was talking adjacent to CORBA :P
[deleted]
A previous journey down this road: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...