Hacker News Reader

Comment by wnolens | Hacker News Reader

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.

View on HN

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.

Microservices not being able to talk to each other the network basically never comes up.

What you are saying is outright ridiculous.

Honestly we just need better tooling. Where is my micro-service-fleet creator, which handles built-in all these failure modes of RPC calls?

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

That is all true but most languages have semi-sane libraries with semi-sane defaults that handle most of that. Sure you need some config and tuning but it's not completely uncharted waters

This is why I saw microservices are "closer to the metal", i.e. they depend more on the physical characteristics of their environment than non-microservices.

A function call in a monolith can:

  * segfault
  * be called with the wrong number of parameters
  * call the wrong function
  * go through but never return
  * substitute itself with another function

All of which are very similar to the RPC situation. However we practically never see this because of the OS guarantees like memory safety, security, etc, plus there are standardized ways of handling when these problems do occur, notably try / catch patterns.

These issues can* be abstracted as well, but the advantage of scaling (being close to the metal) is the disadvantage as well (being very close to the hardware abstractions that let you scale).

E.g., there is no difference between running a microservice on a scaling computer than guarantees memory access across a cluster with interrupts, etc (some millions of cpus and terabytes of memory), and running it on a bunch of instances, except the hardware. The former is exotic and abstracts the hardware, the later does not and so all these "low level" errors surface with great frequency.

> 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.

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.

Even on one host processes can crash at different times.

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.

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.

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

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).

Reply on news.ycombinator.com