Already 20 years ago in my company we established a Java framework for building logical modules with clear service boudaries between them. There were clear and clean APIs that prevented access across those borders. Also the UI was decomposed in that way. I still think it was a great solution and many years ahead of its time. But one thing remained back then: We always talked about the possibility to deploy these modules as physically independent services. But we never did. We stayed at deploying it as a "modulith". We probably had been able to hide the serialization and network stuff from the developer (still just calling Java interfaces), but there would have been no magical stuff that hides the complexities of distributed computing - all the errors and special situations that would arise sooner or later. And still today I see no other chance to explicitely address it. You may abstract away which serialization and bus system you use - but there is enough other stuff that remains.
Hi Derek, Wouldn't MS Orleans be a better answer to the pains of Microservices than Service Weaver? You played around a bit a few years ago. Considering that the Orleans now has more features than 5 years ago, would you consider it as a good framework for enterprise applications or do you still prefer decoupled architecture with queue and service bus?
Hi Derek. I've been watching your videos for about 2 years now. Thanks a lot, I appreciate it. What I would like you to talk about is reliable messaging accross modules in a modular monolith. In a modular monolith the inter-module communication is usually based on direct method calls which introduces coupling. In Spring environment we have application events, but they are not reliable. Yes, I could use a message broker like RabbitMQ, but it sounds a little bit odd to use a message broker in a modular monolith. Maybe I could use a DB for a message broker-like communication? What's your opinion?
> ...but it sounds a little bit odd to use a message broker Having a message broker with reliable queues or topics means that the message consumer can be restarted gracefully without losing messages. This has value even in a monolithic context. The new Spring Modulith approaches this by providing a persistent storage layer for Spring application events which can be backed by a JDBC store, as an example.
It would be interesting to see a comparison between this approach and the API Gateway + Serverless (Lambda Function). In this approach you can also develop as a monolith but then every endpoint runs separately on its own compute.
To be fair, it's a little hand wavy to just say "you need less coupling." In practice, decoupling services is expensive both in development and design cost and actual infrastructure cost, because it often requires data duplication in independent databases. Furthermore, message based architectures are orders of magnitude more difficult to build and maintain as opposed to traditional request response architectures. Lastly, decoupling is almost always less efficient. One big advantage of service weaver is how easy it is to change how the system is deployed, which can be used to colocate remote calls that are otherwise causing latency in the system. I could go on, but in summary I just think people act like decoupling is a zero cost no brainer, when in fact it comes with many tradeoffs (like every engineering decision ever).
It's not "you need less coupling", it's "you need to realize the degree of coupling and how you're coupling". If you have no coupling there are no interactions. It's not about "no coupling", it's about managing it. You can't manage it unless you're paying attention to it. Adding messaging doesn't magically remove coupling either, it's just removing the temporal aspect. RPC has it's place, but that place isn't everywhere in all context is I guess where I'm going with this, and I don't think a framework hiding it helps.
The topic made me think deeper. Lets try to add some abstraction here. Suppose you are starting small cofee shop business. At first you are the only employee and you do all the work. Let it be cashier, barman and cleaner. And you are good at first. After some time, and growth you need for some reason to scale the barman role but not the other two. You just hire additional persons and delegate barman role to them. Now you have 3 employees, one is working as a cashier and cleaner and two others are barman. What happened here? The business roles didnt change. The coupling didnt change. The communication pattern changed because the cashier and the barman persons now need to communicate some how about the orders. Previously all the communication was done in same physical boundary. Lets go deeper. What does actually service represents? For me it is as simple as this: the service represent a business role. The functions for the role are defined by the business. And the only thing we want from a service is do the job well. Same for the business role. And what does process represents here? The process is just a physical subject that performs (executes) the role. So it doesn't matter is the subject that performs a role a human or a process. The business just ask to perform it well. Now let's combine these thoughts. As a business i want some flexibility when it comes to assigning roles to subjects. In a typical business i just assign the role to new person and that is it. And the coupling doest change because the process didn't change. The communication protocol did. Same goes for services that were once communicating in one physical boundary and now are communicating between physical boundaries. And here the final question, why should we limit our flexibility to change the role assignments on the go just because the subjects are no longer humans? For me the solution presented makes perfect sense without asking additional questions about coupling. It is just about efficiency.
As an addition. Try to think what would a business do, when the demand goes down, and it no longer needs so many barman people. Will the physical boundaries change? Will it be as easy to combine all services back?
We build modular monoliths and deploy it via serverless route by route. Its easy in Node or Python, but its of course not .NET (this probably has more complexity)
You'll always have to code to the lowest common denominator, i.e. RPC. So why not always use RPC (via HTTP) in the first place? This technology seems to solve a problem I've never had at the cost of huge complexity increase.
I have experience with this approach on high scale (10 000+ physical servers, 4 regions, etc) & high load @ Java. We had multiple systems developed with multiple modules under one roof. In the main business logic project, whose roots come from old J2EE concepts, we even had situations when you really may have some sub-events been routed to special servers who has some extra access, or other capabilities. These "events" development were bulky and painful at times, but worth the sacrifice. System I was responsible, been one repo to 3 deployed systems. Each system was a kind of distributed database layer with business logic tangled in - performance gains were enormous. Unifying all 3 layers has been beneficial because like 60% of tasks required changes in at least two layers. Test tooling has been made to facilitate precise business logic tests, unit tests and black-box like API tests. How it's like to work like this on the distance? We had really tight hiring standards, but sometimes they leaked and this caused severe pain. So if you go this "boundles" path, check that your team is top-notch
Learn more about Software Architecture & Design by subscribing to my newsletter.
🚀mailchi.mp/63c7a0b3ff38/codeopinion
Already 20 years ago in my company we established a Java framework for building logical modules with clear service boudaries between them. There were clear and clean APIs that prevented access across those borders. Also the UI was decomposed in that way. I still think it was a great solution and many years ahead of its time. But one thing remained back then: We always talked about the possibility to deploy these modules as physically independent services. But we never did. We stayed at deploying it as a "modulith". We probably had been able to hide the serialization and network stuff from the developer (still just calling Java interfaces), but there would have been no magical stuff that hides the complexities of distributed computing - all the errors and special situations that would arise sooner or later. And still today I see no other chance to explicitely address it. You may abstract away which serialization and bus system you use - but there is enough other stuff that remains.
Architecture can’t trump design
You led out your concerns well! Thanks for the content!
Btw. you have the perfect pace when speaking! I had to turn the playback speed normal!
Sometimes I feel like I'm going a bit fast, so good to know it's not.
Hi Derek, Wouldn't MS Orleans be a better answer to the pains of Microservices than Service Weaver? You played around a bit a few years ago. Considering that the Orleans now has more features than 5 years ago, would you consider it as a good framework for enterprise applications or do you still prefer decoupled architecture with queue and service bus?
Hi Derek. I've been watching your videos for about 2 years now.
Thanks a lot, I appreciate it.
What I would like you to talk about is reliable messaging accross modules in a modular monolith.
In a modular monolith the inter-module communication is usually based on direct method calls which introduces coupling.
In Spring environment we have application events, but they are not reliable.
Yes, I could use a message broker like RabbitMQ, but it sounds a little bit odd to use a message broker in a modular monolith.
Maybe I could use a DB for a message broker-like communication? What's your opinion?
> ...but it sounds a little bit odd to use a message broker
Having a message broker with reliable queues or topics means that the message consumer can be restarted gracefully without losing messages. This has value even in a monolithic context. The new Spring Modulith approaches this by providing a persistent storage layer for Spring application events which can be backed by a JDBC store, as an example.
@@transientwaveform1475 I never heard about Sping Modulith before. Thanks a lot, I appreciate
It would be interesting to see a comparison between this approach and the API Gateway + Serverless (Lambda Function). In this approach you can also develop as a monolith but then every endpoint runs separately on its own compute.
To be fair, it's a little hand wavy to just say "you need less coupling." In practice, decoupling services is expensive both in development and design cost and actual infrastructure cost, because it often requires data duplication in independent databases. Furthermore, message based architectures are orders of magnitude more difficult to build and maintain as opposed to traditional request response architectures. Lastly, decoupling is almost always less efficient. One big advantage of service weaver is how easy it is to change how the system is deployed, which can be used to colocate remote calls that are otherwise causing latency in the system. I could go on, but in summary I just think people act like decoupling is a zero cost no brainer, when in fact it comes with many tradeoffs (like every engineering decision ever).
It's not "you need less coupling", it's "you need to realize the degree of coupling and how you're coupling". If you have no coupling there are no interactions. It's not about "no coupling", it's about managing it. You can't manage it unless you're paying attention to it. Adding messaging doesn't magically remove coupling either, it's just removing the temporal aspect. RPC has it's place, but that place isn't everywhere in all context is I guess where I'm going with this, and I don't think a framework hiding it helps.
The topic made me think deeper. Lets try to add some abstraction here.
Suppose you are starting small cofee shop business. At first you are the only employee and you do all the work. Let it be cashier, barman and cleaner. And you are good at first. After some time, and growth you need for some reason to scale the barman role but not the other two. You just hire additional persons and delegate barman role to them.
Now you have 3 employees, one is working as a cashier and cleaner and two others are barman.
What happened here? The business roles didnt change. The coupling didnt change. The communication pattern changed because the cashier and the barman persons now need to communicate some how about the orders. Previously all the communication was done in same physical boundary.
Lets go deeper. What does actually service represents? For me it is as simple as this: the service represent a business role. The functions for the role are defined by the business. And the only thing we want from a service is do the job well. Same for the business role. And what does process represents here? The process is just a physical subject that performs (executes) the role. So it doesn't matter is the subject that performs a role a human or a process. The business just ask to perform it well.
Now let's combine these thoughts. As a business i want some flexibility when it comes to assigning roles to subjects. In a typical business i just assign the role to new person and that is it. And the coupling doest change because the process didn't change. The communication protocol did. Same goes for services that were once communicating in one physical boundary and now are communicating between physical boundaries.
And here the final question, why should we limit our flexibility to change the role assignments on the go just because the subjects are no longer humans? For me the solution presented makes perfect sense without asking additional questions about coupling. It is just about efficiency.
As an addition. Try to think what would a business do, when the demand goes down, and it no longer needs so many barman people. Will the physical boundaries change? Will it be as easy to combine all services back?
@@infinitum6964 why would you need a physical boundary change? You just scale down the amount of barman.
One should keep in mind that not all businesses care about flexibility so much and should ⚖ pros and cons when selecting the approach.
We build modular monoliths and deploy it via serverless route by route. Its easy in Node or Python, but its of course not .NET (this probably has more complexity)
it's remind me of ms orleans project
and the new .NET Aspire too
@@thiagocustodio8177 .NET fingers-crossed/hope-and-pray =) hahaha
Service weaver is discontinued as of Dec 2024
Wow didn't know that, thanks for the info. Just read that on their site.
You'll always have to code to the lowest common denominator, i.e. RPC. So why not always use RPC (via HTTP) in the first place? This technology seems to solve a problem I've never had at the cost of huge complexity increase.
Interesting 👍
I have experience with this approach on high scale (10 000+ physical servers, 4 regions, etc) & high load @ Java. We had multiple systems developed with multiple modules under one roof. In the main business logic project, whose roots come from old J2EE concepts, we even had situations when you really may have some sub-events been routed to special servers who has some extra access, or other capabilities. These "events" development were bulky and painful at times, but worth the sacrifice.
System I was responsible, been one repo to 3 deployed systems. Each system was a kind of distributed database layer with business logic tangled in - performance gains were enormous. Unifying all 3 layers has been beneficial because like 60% of tasks required changes in at least two layers. Test tooling has been made to facilitate precise business logic tests, unit tests and black-box like API tests.
How it's like to work like this on the distance? We had really tight hiring standards, but sometimes they leaked and this caused severe pain. So if you go this "boundles" path, check that your team is top-notch
Can you share the company?
@@Circe-wz3kg ok.ru - we had many publications about our approach, but all in russian language.
TLDR ; 10 mins of my life got wasted.