4 ms·

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You ac

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optimal hardware. Number of failure modes increases, but you get to be more fault tolerant. There's no blanket answer here. If you need the benefits, you pay the costs. I think a lot of these microservice v.s. monolith arguments come from poor application of one pattern or the other, or using inadequate tooling to make your life easier, or mostly - if your software system is 10 years old and you haven't been refactoring and re-architecting as you go, it sucks to work on no matter the initial architecture.

marcosdumay 3y ago
From the developer POV, the difference is on the interface. And while we have all kinds of tools to help us keeping a monolith in sync and correct, the few tools we have to help with IPC can not do static evaluations and are absolutely not interactive. From the ops POV, "deploy is more complex" is a large understatement. Each package is one thing that must be managed, with its own specific quirks and issues.
hu3 3y ago
> Probably just the interface - function calls become RPC. Network calls introduce new failure modes and challenges which require more plumbing. Can I retry this RPC call safely? How about exponential backoff? Is my API load-balancer doing its thing correctly? We'll need to monitor it. How about tracing between microservices? Now we need OpenTelemetry or something like that. How harder is it to debug with breakpoints in a microservice architecture? How can I undo a database transaction between 2 microservices? Suddenly your simple function call just became a lot more problematic.
- wnolens 3y ago
  My first Q was re: monolith on one host to many services on one host. And yes, when going off-host, you'll have these issues. One should not employ network hops unnecessarily. Engineering is hard. Doesn't make it not worth doing.
  - charcircuit 3y ago
    Even on one host processes can crash at different times.
elevation 3y ago
Monolith->microservice is not a trivial change no matter how well-factored it is to begin with -- though being poorly architected could certainly make the transition more difficult! > Probably just the interface - function calls become RPC. This sounds simple, but once "function calls become RPC" then your client app also needs to handle: * DNS server unreachable * DNS server reachable but RPC hostname won't resolve * RPC host resolves but not reachable * RPC host reachable but refuses connection * RPC host accepts connection but rejects client authentication * RPC host presents untrusted TLS cert * RPC accepts authentication but this client has exceeded the rate limit * RPC accepts authentication but says 301 moved permanently * RPC host accepts request but it will be x seconds before result is ready * RPC host times out Even for a well-factored app, handling these execution paths robustly probably means rearchitecting to allow you to asynchronously queue and rate limit requests, cache results, handle failure with logarithmic back-off retry, and operate with configurable client credentials, trust store, and resource URLs (so you can honor 301 Moved Permanently) and log all the failures. You'll also need additional RPC functions and parameters to provide data that had previously been in context for local function calls. Then the monolith's UI may now need to communicate network delays and failures to the user that were impossible before network segmentation could split the app itself. Refactoring into microservices will require significant effort even for the most well built monolith.
- ReflectedImage 3y ago
  Microservices not being able to talk to each other the network basically never comes up. What you are saying is outright ridiculous.
- Aerbil313 3y ago
  Honestly we just need better tooling. Where is my micro-service-fleet creator, which handles built-in all these failure modes of RPC calls?
- wnolens 3y ago
  I was offering that simplification to compare monolith single host to multi-service single host. No network hops. But yes, you proceed to explain (some of) the complexities of RPC over the network. Security concerns make this even worse. I could go on.. Engineering is hard
crabbone 3y ago
When discussing microservices, the proponents almost always forget the key aspect of this concept, the micro part. The part that makes this stand out (everyone already heard about services, there's no convincing necessary here, if you feel like you need a service, you just make one, and don't fret about it). So, whenever someone advocates for this concept, they "forget" to factor in the fragmentation caused by requiring that services be very small. To make this more concrete: if you have a monolith + microservice, you don't have microservices, because the later implies everything is split into tiny services, no monoliths. Most of the arguments in favor of microservices fall apart as soon as you realize that it has to be micro. And once you back out of the "micro" requirement, you realize that nothing new or nothing deep is being offered.
yCombLinks 3y ago
You lose atomic transactions. Every business action is orders of magnitudes more more complex because of that.
- buster 3y ago
  Absolutely true, but also: Usually, your business transactions happen in a business context, which happens to be in a microservice. It can be a sign of bad design if you happen to have a lot of those transactional problems. You will have distributed transactions with a distributed microservice setup, but most transactions will still be be contained within a single microservice (and thus be atomic and not distributed).

marcosdumay 3y ago

From the developer POV, the difference is on the interface. And while we have all kinds of tools to help us keeping a monolith in sync and correct, the few tools we have to help with IPC can not do static evaluations and are absolutely not interactive. From the ops POV, "deploy is more complex" is a large understatement. Each package is one thing that must be managed, with its own specific quirks and issues.

hu3 3y ago

> Probably just the interface - function calls become RPC. Network calls introduce new failure modes and challenges which require more plumbing. Can I retry this RPC call safely? How about exponential backoff? Is my API load-balancer doing its thing correctly? We'll need to monitor it. How about tracing between microservices? Now we need OpenTelemetry or something like that. How harder is it to debug with breakpoints in a microservice architecture? How can I undo a database transaction between 2 microservices? Suddenly your simple function call just became a lot more problematic.

wnolens 3y ago
My first Q was re: monolith on one host to many services on one host. And yes, when going off-host, you'll have these issues. One should not employ network hops unnecessarily. Engineering is hard. Doesn't make it not worth doing.
- charcircuit 3y ago
  Even on one host processes can crash at different times.

elevation 3y ago

Monolith->microservice is not a trivial change no matter how well-factored it is to begin with -- though being poorly architected could certainly make the transition more difficult! > Probably just the interface - function calls become RPC. This sounds simple, but once "function calls become RPC" then your client app also needs to handle: * DNS server unreachable * DNS server reachable but RPC hostname won't resolve * RPC host resolves but not reachable * RPC host reachable but refuses connection * RPC host accepts connection but rejects client authentication * RPC host presents untrusted TLS cert * RPC accepts authentication but this client has exceeded the rate limit * RPC accepts authentication but says 301 moved permanently * RPC host accepts request but it will be x seconds before result is ready * RPC host times out Even for a well-factored app, handling these execution paths robustly probably means rearchitecting to allow you to asynchronously queue and rate limit requests, cache results, handle failure with logarithmic back-off retry, and operate with configurable client credentials, trust store, and resource URLs (so you can honor 301 Moved Permanently) and log all the failures. You'll also need additional RPC functions and parameters to provide data that had previously been in context for local function calls. Then the monolith's UI may now need to communicate network delays and failures to the user that were impossible before network segmentation could split the app itself. Refactoring into microservices will require significant effort even for the most well built monolith.

ReflectedImage 3y ago
Microservices not being able to talk to each other the network basically never comes up. What you are saying is outright ridiculous.
Aerbil313 3y ago
Honestly we just need better tooling. Where is my micro-service-fleet creator, which handles built-in all these failure modes of RPC calls?
wnolens 3y ago
I was offering that simplification to compare monolith single host to multi-service single host. No network hops. But yes, you proceed to explain (some of) the complexities of RPC over the network. Security concerns make this even worse. I could go on.. Engineering is hard

crabbone 3y ago

When discussing microservices, the proponents almost always forget the key aspect of this concept, the micro part. The part that makes this stand out (everyone already heard about services, there's no convincing necessary here, if you feel like you need a service, you just make one, and don't fret about it). So, whenever someone advocates for this concept, they "forget" to factor in the fragmentation caused by requiring that services be very small. To make this more concrete: if you have a monolith + microservice, you don't have microservices, because the later implies everything is split into tiny services, no monoliths. Most of the arguments in favor of microservices fall apart as soon as you realize that it has to be micro. And once you back out of the "micro" requirement, you realize that nothing new or nothing deep is being offered.

yCombLinks 3y ago

You lose atomic transactions. Every business action is orders of magnitudes more more complex because of that.

buster 3y ago
Absolutely true, but also: Usually, your business transactions happen in a business context, which happens to be in a microservice. It can be a sign of bad design if you happen to have a lot of those transactional problems. You will have distributed transactions with a distributed microservice setup, but most transactions will still be be contained within a single microservice (and thus be atomic and not distributed).