I'm sure there are many variants and definitions, but the company I'm at runs one.
The gist of it is that there's one codebase with multiple separate "modules". This codebase is packed and linked as a library and then we build different super slim hosts that load different parts of the monolith in production containers. Usually just different environment variables or config.
But locally, we can run the whole thing in one process. We're.using .NET so `dotnet run` brings up the whole app. Whereas we might run parts of the app in different console hosts in prod, locally they are hosted background services in-process.
From a debug perspective, this is super awesome since you can just launch and trace one codebase. If we broke it out into 3-4 separate services, we'd have to run 3 processes and 3 debuggers. 3 sets of configuration, 3 sets of CI/CD, 3 sets of testing. Terrible for productivity.
We have parts of the system connected to SQS for processing events and if we need more throughout, we simply start more instances of the container all running the same monolith.
I think GCP is probably one of the best platforms for building modular monoliths because of its tight orientation around HTTP push.
I implemented this in one of my past startup jobs. Basically a core banking system that implemented multiple roles of the system, including open banking. Depending on config, it would act as a bank, as an OB service provider, as an OB registry, as a merchant, etc. In addition, it was built in a way that instances, if allowed could talk to each other in 2 ways:
1. As part of the same entity, so you could scale your operation.
2. As part of an ecosystem, so you could for example create an entire open banking network or just a regular network with bank transfers and card payments using proper protocols such as ACH, ISO8583 and ISO2022 for example.
And there is a separate concept of a configurable application which can completely reshape its component graph according to some high level configuration flags (like database=prod|dummy), we call it "multi-modal applications".
I'm looking to break an old java monolith application in something like that: modular code base, single deployment artifact, multiple configurable use cases.
I've yet to find a good existing tool to compose the application at build time, other than using a godawful lot of maven profiles combinations
Often this is view as counter microservices pattern. Microservice architecture assumes each service has its own data storage and is logically independable from other services.
Monolith on the other hand is a single application with all of the logic in one place.
Distibuted monolith is a set of applications\services like in microservices pattern but they can share common data storage and depend on each other.
Data Storage and Compute should be separate orthogonal issues, it's not needed in this comparison.
Stateful vs Stateless.
Your monolith is a binary that gets distributed to hosts to perform some function. The binary has multiple entry points that can be envoked. Most calls are via internal library call.
Microserverices (also stateless) have a different artifacts for each component, services call other services via a private API (often grpc/httprc).
CharlieDigital|2 years ago
The gist of it is that there's one codebase with multiple separate "modules". This codebase is packed and linked as a library and then we build different super slim hosts that load different parts of the monolith in production containers. Usually just different environment variables or config.
But locally, we can run the whole thing in one process. We're.using .NET so `dotnet run` brings up the whole app. Whereas we might run parts of the app in different console hosts in prod, locally they are hosted background services in-process.
From a debug perspective, this is super awesome since you can just launch and trace one codebase. If we broke it out into 3-4 separate services, we'd have to run 3 processes and 3 debuggers. 3 sets of configuration, 3 sets of CI/CD, 3 sets of testing. Terrible for productivity.
We have parts of the system connected to SQS for processing events and if we need more throughout, we simply start more instances of the container all running the same monolith.
I think GCP is probably one of the best platforms for building modular monoliths because of its tight orientation around HTTP push.
figassis|2 years ago
1. As part of the same entity, so you could scale your operation.
2. As part of an ecosystem, so you could for example create an entire open banking network or just a regular network with bank transfers and card payments using proper protocols such as ACH, ISO8583 and ISO2022 for example.
pshirshov|2 years ago
And there is a separate concept of a configurable application which can completely reshape its component graph according to some high level configuration flags (like database=prod|dummy), we call it "multi-modal applications".
And we created the perfect tool for wiring them: https://izumi.7mind.io/distage/index.html
alserio|2 years ago
pmontra|2 years ago
konart|2 years ago
Monolith on the other hand is a single application with all of the logic in one place.
Distibuted monolith is a set of applications\services like in microservices pattern but they can share common data storage and depend on each other.
mlrtime|2 years ago
Stateful vs Stateless.
Your monolith is a binary that gets distributed to hosts to perform some function. The binary has multiple entry points that can be envoked. Most calls are via internal library call.
Microserverices (also stateless) have a different artifacts for each component, services call other services via a private API (often grpc/httprc).
unknown|2 years ago
[deleted]