Comment by elevation | Hacker News Reader

Comment by elevation | Hacker News Reader

Parent Full thread

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.

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.

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

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

What you are saying is outright ridiculous.

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

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

Reply on news.ycombinator.com