4 ms·

I think an important thing to keep in mind when discussing monoliths or Microservices is that you can build modular code without needing multiple binaries, proc

I think an important thing to keep in mind when discussing monoliths or Microservices is that you can build modular code without needing multiple binaries, processes, or server instances. If you follow best practices when creating a monolith, creating well-defined modules with clear input and output boundaries, then it should be relatively easy to split those modules into separate programs and create ways for those modules to communicate, if it later becomes necessary to move towards a micro-services architecture.

KyeRussell 4y ago
I think a (but not the only) central conceit of a microservices architecture is that most development teams cannot be trusted to maintain proper separation of concerns, and enforcing at a technical level the inability to call Any Old Function is a big part of what you’re buying into.
- eeperson 4y ago
  This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? In theory the extra work of making an API call would give you smaller bowls of spaghetti. However, once you add some abstraction to making these calls it seems like developers are empowered to make the same mess. Except now it is slower and harder to debug.
  - simplotek 4y ago
    > This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint.
    - eeperson 4y ago
      > It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. I'm not sure I follow this. Doesn't this just mean that it is harder to make changes? Why would it be harder to make bad changes and not harder to make good changes? > Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint. I'm not sure I follow this either. Why would multiple services make teams great at complying with an architecture constraint?
    - thunky 4y ago
      > Walls make great neighbors I think you're trying to solve a communication problem with a technical solution, which is a recipe for trouble. If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. Especially once you inevitably realize that you put the walls in the wrong place and functionality has to move across borders, which is now a major pain because you've intentionally made it hard to change.
      - zabhi 4y ago
        > If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. But it actually does, and there is a lot of data to prove it. When you have a big project and a bunch of teams, the first thing you build is boundaries / walls. Then you get to defining interfaces between interdependent services. And this frees them up to get hacking on their modules in parallel - without stepping on each others' toes. Communication would have definitely helped, but it is way easier for smaller teams to own and operate their services and try to get a big organization plough through a big mess. That said, microservices are just one way to solve a problem, and not always the right way. But there is always a place where you would look at the problem, the organization that is tasked to solve it, and it would fit just right in.
      - yehosef 4y ago
        been there, done that.
- janef0421 4y ago
  Most compiled languages will allow a project to be split into multiple modules, and an `internal` access modifier can then be used to limit the use of an element to that module.
jjtheblunt 4y ago
But what defines "best practices", in this case?
- hnzix 4y ago
  Law of Demeter, constraining responsibility in functions while avoiding tortellini code, clear variable names etc.

KyeRussell 4y ago

I think a (but not the only) central conceit of a microservices architecture is that most development teams cannot be trusted to maintain proper separation of concerns, and enforcing at a technical level the inability to call Any Old Function is a big part of what you’re buying into.

eeperson 4y ago
This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? In theory the extra work of making an API call would give you smaller bowls of spaghetti. However, once you add some abstraction to making these calls it seems like developers are empowered to make the same mess. Except now it is slower and harder to debug.
- simplotek 4y ago
  > This always seemed strange to me. If your team can't be trusted not to make spaghetti in a monolith, what stops them from making distributed spaghetti in microservices? It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint.
  - eeperson 4y ago
    > It's far harder to update multiple services to handle requests they should not handle, let alone update a deployment to allow those requests to happen. I'm not sure I follow this. Doesn't this just mean that it is harder to make changes? Why would it be harder to make bad changes and not harder to make good changes? > Walls make great neighbors, just like multiple services make teams great at complying with an architecture constraint. I'm not sure I follow this either. Why would multiple services make teams great at complying with an architecture constraint?
  - thunky 4y ago
    > Walls make great neighbors I think you're trying to solve a communication problem with a technical solution, which is a recipe for trouble. If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. Especially once you inevitably realize that you put the walls in the wrong place and functionality has to move across borders, which is now a major pain because you've intentionally made it hard to change.
    - zabhi 4y ago
      > If multiple teams working on interdependent components can't communicate well enough to keep from stepping on each other's toes, imposing technical barriers probably isn't going to make things better. But it actually does, and there is a lot of data to prove it. When you have a big project and a bunch of teams, the first thing you build is boundaries / walls. Then you get to defining interfaces between interdependent services. And this frees them up to get hacking on their modules in parallel - without stepping on each others' toes. Communication would have definitely helped, but it is way easier for smaller teams to own and operate their services and try to get a big organization plough through a big mess. That said, microservices are just one way to solve a problem, and not always the right way. But there is always a place where you would look at the problem, the organization that is tasked to solve it, and it would fit just right in.
    - yehosef 4y ago
      been there, done that.
janef0421 4y ago
Most compiled languages will allow a project to be split into multiple modules, and an `internal` access modifier can then be used to limit the use of an element to that module.

jjtheblunt 4y ago

But what defines "best practices", in this case?

hnzix 4y ago
Law of Demeter, constraining responsibility in functions while avoiding tortellini code, clear variable names etc.