> The programming model enables a developer to write a
distributed application as a single program, where the code is
split into modular units called components (Section 3). This
is similar to splitting an application into microservices, except that microservices conflate logical and physical boundaries.
I definitely do see the merits to this. The fact that we always see logical separation of services resulting in split codebases did never sit right with me.
Trying to answer the question of - can you build your entire stack in a monolithic way, but split it to domain-driven services at the runtime?
That way, you get the developer experience of co-location, and runtime benefits of isolated workloads. The service definitions are malleable and can evolve as the complexity increases.
I actually don’t want the developer experience of co-location. There are millions of things that are totally irrelevant happening in my company’s (thousands of engineers) monolith. The noise in the commit log is considerable. Isolated repos are smaller, and reduce useless coupling.
I get that it's not a universally applicable solution. I guess at a certain point of scale your organisation would grow out of complete co-location.
But I don't think we have to go with the 100% co-location approach as well. A large monorepo could be organized into domain specific mini-monorepos with co-location benefits.
I think Google, Meta, Microsoft, Twitter, Uber [1] and the thousands of engineers that these companies (and many other companies) employ, would disagree with you.
Very interesting indeed. This reminds me of a (relatively) recent standard for distributed industrial process control.
For industrial process control, the IEC-61499 [1] standard introduces an architecture where the program and its function blocks are independent of where the components actually run.
I don't believe automatic distribution of the components to different devices is included. But, it allows setting up function blocks and their interconnections, and then distributing function blocks between devices. Inter-device communication is included in the standard.
Compared to standard PLC programming (IEC-61131), 61499 adds events to the function block diagram paradigm.
I don't think this standard os popular yet, but I've always wanted to give it a try.
If you can’t build a high performance monolith with clean modular components then you will make an even worse job building a micro-services system.
The worst pile of garbage software I have seen in my 30+ years career is a micro-services system. With 150+ services making it nearly impossible to figure out why the software blows up in production.
The easiest to maintain almost-never-a-bug-in-production software I have ever worked with is a massive but well-designed million+ line C++ monolith.
No architecture pattern or programming language will guarantee a well designed system. Only a good team of experienced developers, who truly understand how to design software well, will create great software.
It’s a people problem not an architecture pattern problem.
14 comments
[ 3.9 ms ] story [ 45.0 ms ] threadCall me boring but I'd rather "ssr-server" rather than something like "tango" any day of the week.
> The programming model enables a developer to write a distributed application as a single program, where the code is split into modular units called components (Section 3). This is similar to splitting an application into microservices, except that microservices conflate logical and physical boundaries.
I definitely do see the merits to this. The fact that we always see logical separation of services resulting in split codebases did never sit right with me.
We've been trying to solve the same problem, but albeit in a different way here: https://docs.differential.dev/getting-started/thinking/ (Disclaimer: I'm the founder - would love to collaborate)
Trying to answer the question of - can you build your entire stack in a monolithic way, but split it to domain-driven services at the runtime?
That way, you get the developer experience of co-location, and runtime benefits of isolated workloads. The service definitions are malleable and can evolve as the complexity increases.
But I don't think we have to go with the 100% co-location approach as well. A large monorepo could be organized into domain specific mini-monorepos with co-location benefits.
A mono-repo makes decisions for your teams.
[1] https://en.wikipedia.org/wiki/Monorepo
For industrial process control, the IEC-61499 [1] standard introduces an architecture where the program and its function blocks are independent of where the components actually run.
I don't believe automatic distribution of the components to different devices is included. But, it allows setting up function blocks and their interconnections, and then distributing function blocks between devices. Inter-device communication is included in the standard.
Compared to standard PLC programming (IEC-61131), 61499 adds events to the function block diagram paradigm.
I don't think this standard os popular yet, but I've always wanted to give it a try.
4diac is an open source implementation.
[1] https://en.m.wikipedia.org/wiki/IEC_61499
[2] https://www.eclipse.org/4diac/
Pretty huge caveat over the entire piece. If we all had nice modular code bases this while thing would be easy regardless of the deployment details.
Any additional details on what tech they used to achieve this automatic splitting?
The worst pile of garbage software I have seen in my 30+ years career is a micro-services system. With 150+ services making it nearly impossible to figure out why the software blows up in production.
The easiest to maintain almost-never-a-bug-in-production software I have ever worked with is a massive but well-designed million+ line C++ monolith.
No architecture pattern or programming language will guarantee a well designed system. Only a good team of experienced developers, who truly understand how to design software well, will create great software.
It’s a people problem not an architecture pattern problem.
There is no silver bullet.