> as if achieving that were only possible through herculean effort
I encourage you to reread my comments, I'm not suggesting anywhere that high-performance requires exceptional effort.
In fact, I'm actively admitting that for applications where high-performance is required, IPCs/RPCs are not an option.
> just isn't worth it for most applications
Performance is valuable, but it's one dimension of value.
My premise is that, given the maturity of RPC frameworks and network tooling in 2020, most already-networked applications can afford to trade the performance hit of additional hops on the backend.
Whether what you get in exchange for that performance hit is valuable?
That is mostly a function of the quality of your eng platform.
> a local message-send is also a helluva lot easier [on the programmer?] than any kind of IPC
This strongly depends on your engineering org, although it seems like this is the point that's hardest to imagine for some people.
If you're on a team that depends on the availability of data maintained by N other teams,
(given the maturity of RPC Frameworks and network tooling in 2020, again)
It is much easier to apply SLOs and SLAs to an interface that's gated by an RPC service.
> spend significant extra effort in coding, deployment and monitoring
The extra effort here is made completely negligible by the existence of a decent platform team.
FWIW, I wouldn't be able to imagine it if I haven't experienced it myself.
> benefits have to be pretty amazing to be worth it
I still think you're overestimating some of the costs (see above). FWIW, I've worked in an RPC-oriented environment for years now, and reliability has never been a concern. Our platform team is pretty good, but we are not a Google-esque company (200 engineers, including eng managers)
The performance trade-off has been demonstrably worthwhile, because we've used it to purchase a degree of team independence that would not have been otherwise possible.
>In fact, I'm actively admitting that for applications where high-performance is required, IPCs/RPCs are not an option.
But you're framing it as "...for applications where high-performance is required", as if taking the performance, expressiveness and reliability hits should obviously be the default, unless you have very special circumstances.
My point is, and continues to be, that it's the other way around: you should go for simplicity, reliability and performance unless you have, and can demonstrate you have, very special requirements.
I encourage you to reread my comments, I'm not suggesting anywhere that high-performance requires exceptional effort.
In fact, I'm actively admitting that for applications where high-performance is required, IPCs/RPCs are not an option.
> just isn't worth it for most applications
Performance is valuable, but it's one dimension of value.
My premise is that, given the maturity of RPC frameworks and network tooling in 2020, most already-networked applications can afford to trade the performance hit of additional hops on the backend.
Whether what you get in exchange for that performance hit is valuable?
That is mostly a function of the quality of your eng platform.
> a local message-send is also a helluva lot easier [on the programmer?] than any kind of IPC
This strongly depends on your engineering org, although it seems like this is the point that's hardest to imagine for some people.
If you're on a team that depends on the availability of data maintained by N other teams,
(given the maturity of RPC Frameworks and network tooling in 2020, again)
It is much easier to apply SLOs and SLAs to an interface that's gated by an RPC service.
> spend significant extra effort in coding, deployment and monitoring
The extra effort here is made completely negligible by the existence of a decent platform team.
FWIW, I wouldn't be able to imagine it if I haven't experienced it myself.
> benefits have to be pretty amazing to be worth it
I still think you're overestimating some of the costs (see above). FWIW, I've worked in an RPC-oriented environment for years now, and reliability has never been a concern. Our platform team is pretty good, but we are not a Google-esque company (200 engineers, including eng managers)
The performance trade-off has been demonstrably worthwhile, because we've used it to purchase a degree of team independence that would not have been otherwise possible.