Comment by jacquesm | Hacker News Reader

Comment by jacquesm | Hacker News Reader

Parent Full thread

There is a subtle link between monoliths and microservices: co-routines. You can emulate a service oriented architecture inside a monolithically linked application. That way if you ever do decide you need to break for further isolation and/or to be able to parallelize the execution for more performance it down you at least can limit that to cutting on the dotted lines.

I personally like microservices a lot because they allow you to do one more thing (a variation on the isolation theme, sure), to limit the scope of what you, the programmer have to deal with at any given time. Your specifications, tests and mental activity all focus on a much smaller chunk of code, which is much easier to deal with.

I don't think I've ever built a bug-free monolith, but I'm fairly sure I've been able to repeatedly produce bug-free (or nearly bug free, you can never be 100% sure) microservices. And that to me is the bigger advantage, the scope limitation from the programmers perspective.

I find the most common outcome of adopting microservices is a buggy system made of bug-free microservices, via misunderstood specifications or surprising interactions.

Yes. Also something I see in messaging oriented architectures, often seen with microservices for async communication, since synchronous calls usually make the whole as reliable as its least reliable element.

Message orientation, in isolation for each message handler, is wonderful, easy to test, decoupled etc. But the overall flow is harder to understand and coupling at the business level still exists. You still need to remove stock from inventory after a sale even if the two parts don't communicate directly. Messages are COMEFROM.

The other thing is reliability. Monoliths can usually rely on the ambient availability of resources - a synchronous in-process call will have a CPU available because that's how in-process calls work - but services across the network might not have resources to respond for some time. It cuts the other way too, though; when the monolith is down, everything is down. There's tradeoffs everywhere.

Every bit of complexity that you add has a price tag, before adding it you need to look at that tag and decide whether or not the price is worth it in this particular case. More often than not the answer is 'no' but people will go ahead and do it anyway.

Yes, what will typically happen is that people go overboard, and instead of 5 or so big functional blocks they explode the monolith into 50 (I've seen 200!) microservices and then end up with a huge overhead in terms of IPC and complexity in the IPC protocol that is worse than it ever was before. Bonus points if all it does is synchronous calls between services leading to a deadlocks and other hard to debug issues.

Good software architecture is hard.

Coroutines can have shared memory though and the lack of shared memory is perhaps one of the defining features of microservices.

Yes, it is an in-between step, which is why I used it as an illustration. You get roughly the same architecture but without the process isolation. In fact: co-routines will share some memory, whether you like it or not, they are in the same executable.

> You get roughly the same architecture but without the process isolation.

I think that's only true for very specific kinds of architecture which are only tangentially related to coroutines: stateless data transformations or actor-inspired architectures. Things like shared atomic data structures or mutexes translate pretty poorly to microservice architectures (they're doable, but really painful, bug-prone, and you give up a ton of performance).

EDIT: Hmmmm... on reflection, I suppose if you think of the actual stateful set of yield and continuation operations of coroutines they are one particular possible microservice architecture, but it strikes me as a bit messy? Although I guess you can retrofit the usual set of other concurrency operators on top.

It's a hack for sure, you are essentially creating a new little operating system within one binary. But it is an architecture that works remarkably well for quite a few applications: message switches, games and so on. And it even works on architectures where you only get one thread of execution.

Ah I see, you perhaps mean a slightly more general concept of coroutines than I was thinking about? Closer to something that fits a thread-like interface on top of actual threads regardless of whether it's being done through direct yields or intermediated by some sort of scheduler?

Basically the crucial point being getting concurrency without the need for actual parallelism?

Yes. And you can simulate that perfectly using the co-routine mechanism.

You can have same-process memory isolation in any programming environment that support isolates/actors, like JavaScript (via web workers[1]), Dart[2], Pony[3], and if done carefully, Rust[4] (probably many others too but I am not familiar with others that I can remember now).

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

[2] https://medium.com/dartlang/dart-asynchronous-programming-is...

[3] https://patterns.ponylang.io/data-sharing.html

[4] https://doc.rust-lang.org/book/ch16-02-message-passing.html

But Redis....

Seriously, I've seen a monolith broken up into a microservice using Redis as shared memory. Didn't know it was an anti-pattern.

> Didn't know it was an anti-pattern.

You really just have to be clear whether you are building a distributed monolith vs a set of microservices. In the former case, you are optimizing entirely for performance and scalability concerns. It just so happens if you have things that require scaling of the underlying hardware, our current state-of-the-art tooling handles scaling hardware resources (number of cores and memory) better when you have separate services rather than bundling it all in a single program.

However, you get none of the operational/human-level process changes of microservices. Teams are still coupled to the changes in the shared state. Anything that changes the shared state cannot be deployed independently. In fact from a process perspective things are probably even harder to coordinate now since the coupling is still there, but not explicitly expressed in code anymore. And from a site reliability perspective, you still have a single point of failure: the shared memory. Any mitigation strategies you use for that you could've used for a monolith as well.

Reply on news.ycombinator.com