> Why would I want to replace straighforward function calls with network calls in my monolith?
I agree that there's nothing inherently virtuous with replacing a functioning local call with a remote procedure call. But if you decide to break your monolith up for any one of the reasons people tend to follow service-oriented architecture, then Differential reduces the friction.
The problem though is that you're taking the known failure mode interpretation of microservices (what we call a distributed monolith) and making it "easier" by adding significantly more complexity. As many of the other comments here have said, this has been done before. You are repeating the mistakes of DCOM and gussying it up with a modern-looking marketing page.
You demonstrate a lack of understanding of idempotence on your marketing page, which is enough to dismiss your service outright. With all due respect, I'm sure you've put a ton of work into this, and you may even manage to sell it to some teams, but this has been tried and failed so many times in software development's history. It won't be any different now. This is very likely to cause long term harm to any team that adopts it.
For anyone considering it, please make sure you actually understand idempotence and autonomy. Look into event sourcing. Study the fallacies of distributed computing. Check out the work of Udi Dahan and Scott Bellware. Run, do not walk from anything purporting to do the things that this does.
Thanks for the time and effort you put into writing this comment.
> As many of the other comments here have said, this has been done before. You are repeating the mistakes of DCOM and gussying it up with a modern-looking marketing page.
Respectfully disagree, it's not really comparable to DCOM and CORBA. It contains a control plane which is stateful [1]. CORBA does have an ORB [2], which is close, but the specification does not allow for durability.
I do apologise for having a modern looking marketing page.
> You demonstrate a lack of understanding of idempotence on your marketing page, which is enough to dismiss your service outright.
I think we discussed this elsewhere in the thread where I gave you the implementation details that prove the claims of the marketing page.
> With all due respect, I'm sure you've put a ton of work into this, and you may even manage to sell it to some teams, but this has been tried and failed so many times in software development's history. It won't be any different now. This is very likely to cause long term harm to any team that adopts it.
It's actually open-source [4] and self-hostable, so teams don't have to "buy" it. I admire you confidence about this failing, and you might be right. But the reason why this has been tried before in the software development history tells me that the proper abstraction is somewhere out there. If everyone resorted to not trying something that failed before from a new perspective, we probably wouldn't be very successful as a species. Everything is a remix, after all.
> For anyone considering it, please make sure you actually understand idempotence and autonomy. Look into event sourcing. Study the fallacies of distributed computing. Check out the work of Udi Dahan and Scott Bellware. Run, do not walk from anything purporting to do the things that this does.
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.
This would likely require a longer, higher bandwidth conversation than we could or should do in a comment thread. If you're interested, you can join me in the Eventide Slack [4], but I will warn you there's already some discussion about this offering (though, nothing I haven't said here). But, I'm here, so... :)
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).
I do disagree with some of your opinions, but I find them interesting and valuable. I've definitely changed my mind about things before, so you might be right on all of these counts - but our experiences might differ enough to have different opinions.
> Here's a hint at the fundamental disconnect. Services shouldn't talk to other services. Period. Not if that can be avoided.
I agree in principle, but I've not been able to see this followed in a large sprawling engineering organisation.
I will definitely join the slack once I have some distance from this. To be honest, I didn't expect this to be posted on HN at this point in the project - and HN can be somewhat merciless :)
Thanks again for engaging with me. You've inspired me to do some changes - especially in how I position the value prop and I learned a lot from reading your references. Much appreciated :)
I too appreciate your engagement. I understand that HN can be merciless, and I do try to be direct, which can sometimes be felt as merciless or harsh. I'm trying to give my unadulterated perspective because I care about the outcomes for the industry as a whole.
And yes, I can imagine it was quite a shock to get this much unexpected feedback all at once. You handled it well, from what I've seen.
> I agree in principle, but I've not been able to see this followed in a large sprawling engineering organisation.
Ours isn't large and sprawling (only around 15 devs) but we managed to build and maintain ~100 back end services and ~20 front end web applications and we're only speeding up as we go. It's possible, but it takes effort and it requires doing things that go against "best practices". [1] It also requires significant cultural and managerial work (see Lean, Steven Spear's work, etc.).
Good luck in your product and learning journey. Hopefully we can connect again down the road. Cheers.
> Why would I want to replace straighforward function calls with network calls in my monolith?
I agree that there's nothing inherently virtuous with replacing a functioning local call with a remote procedure call. But if you decide to break your monolith up for any one of the reasons people tend to follow service-oriented architecture, then Differential reduces the friction.
Here are our thoughts on this: https://docs.differential.dev/advanced/soa/
> "Centralization" and "reliability" don't sound like words that often come together. What if the control plane goes down? Unless they have a cluster?
Yes, there's a cluster.