When I say it's like DCOM/CORBA, I'm referring to the notion of RPC. Specifically, the notion that it's a good idea to perform synchronous remote calls as a matter of course. It significantly reduces autonomy. In my opinion, we should not be encouraging people to build distributed monoliths, even if we can make it look like a regular monolith.
Monolithism is the problem [1] [2], and distributing that monolith only solves technical issues, but not the productivity ones that typically matter more. Distributing them also creates technical issues in terms of latency and cascading failures.
The existence of a control plane doesn't impact my concern about this, but it does add an additional concern. See smart pipes vs. dumb pipes. [3]
> I do apologise for having a modern looking marketing page.
That's not necessary, I wasn't saying that was bad. It looks nice, but if it's marketing something that can be harmful, that would be the problem. Its aesthetics are a differentiating factor. I wasn't trying to say anything more about it than that.
> But the reason why this has been tried before in the software development history tells me that the proper abstraction is somewhere out there.
Maybe, or maybe we don't pay enough attention to our past learnings and the body of knowledge that came before us.
> Wise words, but I'd appreciate it if you could dive into the way things are [1] [3] a little bit, and let me know if you hold the same views.
I read these, and there's nothing that I would consider new, although it is somewhat surprising to read what effectively amounts to the goal being to add network hops and complexity to monolithic code in order to get scaling and other technical benefits.
> Monolithic codebases provide a great developer experience, but resulting monolithic services often do not.
I disagree [5]. They only appear to provide that to teams that don't yet have the skills necessary to do proper partitioning. I believe that teams, and developers in general, will be better served by learning how to do this. They will unlock long term continuity [6] in productivity that they couldn't have imagined.
> Instead of n services talking to n services...
Here's a hint at the fundamental disconnect. Services shouldn't talk to other services. Period. Not if that can be avoided. See: autonomy. This is where pub/sub comes in. When services have autonomy, developers have productivity, and products are more resilient (at the very least).
[1] https://github.com/aaronjensen/software-development/blob/mas...
[2] https://github.com/aaronjensen/software-development/blob/mas...
[3] https://twitter.com/sbellware/status/1760037861347258416
[4] https://eventide-project.org/
[5] https://github.com/aaronjensen/software-development/blob/mas...
[6] https://github.com/aaronjensen/software-development/blob/mas...