5 ms·

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

jacquesm 6y ago
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.
- dwohnitmok 6y ago
  > 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.
  - jacquesm 6y ago
    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.
    - dwohnitmok 6y ago
      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?
      - jacquesm 6y ago
        Yes. And you can simulate that perfectly using the co-routine mechanism.
brabel 6y ago
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_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... [2] https://medium.com/dartlang/dart-asynchronous-programming-isolates-and-event-loops-bffc3e296a6a https://medium.com/dartlang/dart-asynchronous-programming-is... [3] https://patterns.ponylang.io/data-sharing.html https://patterns.ponylang.io/data-sharing.html [4] https://doc.rust-lang.org/book/ch16-02-message-passing.html https://doc.rust-lang.org/book/ch16-02-message-passing.html
baldeagle 6y ago
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.
- dwohnitmok 6y ago
  > 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.

jacquesm 6y ago

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.

dwohnitmok 6y ago
> 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.
- jacquesm 6y ago
  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.
  - dwohnitmok 6y ago
    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?
    - jacquesm 6y ago
      Yes. And you can simulate that perfectly using the co-routine mechanism.

brabel 6y ago

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_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... [2] https://medium.com/dartlang/dart-asynchronous-programming-isolates-and-event-loops-bffc3e296a6a https://medium.com/dartlang/dart-asynchronous-programming-is... [3] https://patterns.ponylang.io/data-sharing.html https://patterns.ponylang.io/data-sharing.html [4] https://doc.rust-lang.org/book/ch16-02-message-passing.html https://doc.rust-lang.org/book/ch16-02-message-passing.html

baldeagle 6y ago

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.

dwohnitmok 6y ago
> 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.