Hacker News Reader

Comment by dwohnitmok | Hacker News Reader

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

View on HN

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

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.

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