4 ms·

This would be true in a monolith as well unless configured otherwise. Functions don’t just start talking to each other; you have to explicitly connect them via

This would be true in a monolith as well unless configured otherwise. Functions don’t just start talking to each other; you have to explicitly connect them via a function invocation. I’m not sure how an architecture would change that.

throwaway894345 5y ago
It’s pretty straightforward. In a monolith everything is in the same memory space, so the payment system credentials and routines are available to the whole monolith. In a microservice architecture, one service can’t access the memory or routines of other services.
- ironmagma 5y ago
  One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. Either way, you are just picking different contract enforcement mechanisms. The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible. And in that case, I really have to ask, who are your teammates that you trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war.
  - throwaway894345 5y ago
    > One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. You're mistaken. The operating system largely prevents cross-process memory access. Of course, CPU vulnerabilities can circumvent these protections, but even then your micro services can run on distinct machines while monoliths can't. > The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible Yeah, that's the idea. "defense in depth". > And in that case, I really have to ask, who are your teammates that you trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war. (1) not all attackers are internal (2) some attackers are internal and many very profitable organizations do restrict employee access to secrets (and in many cases this is required by compliance).
    - ironmagma 5y ago
      > The operating system largely prevents cross-process memory access. As do programming languages. Yes, a few languages like C allow you to do anything that's physically possible, but most popular languages including Python and JavaScript make leaking function-internal memory to the outside world either very inconvenient or impossible. As for memory being shared among processes, it's not only not impossible but quite common in performance-sensitive applications. https://man7.org/linux/man-pages/man7/shm_overview.7.html https://man7.org/linux/man-pages/man7/shm_overview.7.html > many very profitable organizations do restrict employee access to secrets For one, code is not secret. Secondly, when was this discussion scoped to profitable organizations? A very, very large chunk of HN readers work in startups. > in many cases this is required by compliance This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required." Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith.
      - throwaway894345 5y ago
        > Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith. I share your doubts that this is a good faith argument, in particular, you keep responding to arguments that I patently didn't make: > For one, code is not secret. I didn't claim code was secret, I claimed that we should secure secrets and prevent attackers from executing routines that they shouldn't have permissions to execute. > Secondly, when was this discussion scoped to profitable organizations? I didn't scope the conversation to profitable organizations, I mentioned that profitable organizations often secure their applications. I'm giving you an example and you bizarrely think I'm limiting the conversation only to that example. You do the same thing here as well (and suggest that I'm the one who isn't focused): > This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required." Again, I give "in some cases security is even required" and you take it as "we're no longer talking about other reasons for which security is beneficial". Honestly, the "monolith vs microservice" question is interesting, but it's not interesting to debate someone who is bent on responding to arguments I clearly didn't make. :) Whether you're being obtuse on purpose or by accident, this conversation has become dull, and I'm ducking out of it.

throwaway894345 5y ago

It’s pretty straightforward. In a monolith everything is in the same memory space, so the payment system credentials and routines are available to the whole monolith. In a microservice architecture, one service can’t access the memory or routines of other services.

ironmagma 5y ago
One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. Either way, you are just picking different contract enforcement mechanisms. The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible. And in that case, I really have to ask, who are your teammates that you trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war.
- throwaway894345 5y ago
  > One function cannot access the memory space of another function any less explicitly than one process can access the memory of another process. You're mistaken. The operating system largely prevents cross-process memory access. Of course, CPU vulnerabilities can circumvent these protections, but even then your micro services can run on distinct machines while monoliths can't. > The only way this would be helpful is if your whole goal is to make something (breaking the contract) as hard to do as possible Yeah, that's the idea. "defense in depth". > And in that case, I really have to ask, who are your teammates that you trust them so little as to literally enforce separation this way? No healthy organization should have to resort to this kind of civil war. (1) not all attackers are internal (2) some attackers are internal and many very profitable organizations do restrict employee access to secrets (and in many cases this is required by compliance).
  - ironmagma 5y ago
    > The operating system largely prevents cross-process memory access. As do programming languages. Yes, a few languages like C allow you to do anything that's physically possible, but most popular languages including Python and JavaScript make leaking function-internal memory to the outside world either very inconvenient or impossible. As for memory being shared among processes, it's not only not impossible but quite common in performance-sensitive applications. https://man7.org/linux/man-pages/man7/shm_overview.7.html https://man7.org/linux/man-pages/man7/shm_overview.7.html > many very profitable organizations do restrict employee access to secrets For one, code is not secret. Secondly, when was this discussion scoped to profitable organizations? A very, very large chunk of HN readers work in startups. > in many cases this is required by compliance This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required." Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith.
    - throwaway894345 5y ago
      > Let's stay focused. There are so many implicit assumptions you're taking as granted, I'm starting to doubt this is even an argument in good faith. I share your doubts that this is a good faith argument, in particular, you keep responding to arguments that I patently didn't make: > For one, code is not secret. I didn't claim code was secret, I claimed that we should secure secrets and prevent attackers from executing routines that they shouldn't have permissions to execute. > Secondly, when was this discussion scoped to profitable organizations? I didn't scope the conversation to profitable organizations, I mentioned that profitable organizations often secure their applications. I'm giving you an example and you bizarrely think I'm limiting the conversation only to that example. You do the same thing here as well (and suggest that I'm the one who isn't focused): > This argument weakens the entire stance, because it shifts the goalpost from "this thing is good" to "this thing is legally required." Again, I give "in some cases security is even required" and you take it as "we're no longer talking about other reasons for which security is beneficial". Honestly, the "monolith vs microservice" question is interesting, but it's not interesting to debate someone who is bent on responding to arguments I clearly didn't make. :) Whether you're being obtuse on purpose or by accident, this conversation has become dull, and I'm ducking out of it.