5 ms·

I found this to be surprisingly interesting and novel - usually I expect to see really low quality content when it's a post about microservices, whether for or

I found this to be surprisingly interesting and novel - usually I expect to see really low quality content when it's a post about microservices, whether for or against the idea. This boils it down to isolation, which I myself have written about in a similar vein[0]. > at this point security people simply don't believe that any of the following (each one the very best technology available at the time) is totally safe To be fair, we don't think anything is totally safe :) that's the point. Actually a lot of those things listed are why Chrome is so secure. I think this is a bit pessimistic about process isolation, which is actually quite powerful, but I get the point - there's no gap like an air gap. I prefer to think of monoliths and microservices as being completely unrelated ideas - they aren't on a spectrum of "big to small", they're just two totally different ways of approaching software development. I might put "monoliths" closer to SOA, in that they both describe a very basic approach to a problem, whereas Microservices is not "small services" it's about bounded contexts, patterns, organizations, etc. Anyways, I appreciated this post. [0] https://www.graplsecurity.com/post/architecting-for-performance-and-security-at-the-same-time https://www.graplsecurity.com/post/architecting-for-performa...

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

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.

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