4 ms·

I find microservices can help in just keep everything small and focused. I know you can do this with a monolith. But having a process boundary really enforces i

• Oras 10y ago
  until you mix it with other legacy part of the system then it will be pain in the neck
• crdoconnor 10y ago
  I find that the boundary creates operational headaches. A function call won't time out, deliver a 502 error, have authentication/authorization issues, require load balancing, etc. etc. A REST API will. Plus, once you've debugged a problem that involves crossing 5 microservice boundaries you'll start to wonder if it was all worth it. Monolith is also a wrong (and somewhat derogatory) word to describe a non-microservice architecture. There's nothing monolithic about loosely coupled code running on the same machine. I really think that microservices are a hack to deal with conway's law in large corporations. Operationally it's inefficient but it fixes a nexus of technical and political problems when the correct boundary is picked.
  • misha67 10y ago
    Well said. "Monolith" is a pejorative that prejudices any discussion of said code.
  • UK-AL 10y ago
    Except most applications are monolith. Monolith code can still be loosely coupled. However it is harder.
    • crdoconnor 10y ago
      No, not at all. The only difference I noticed with respect to rube goldberg (what you call "microservices") systems and coupling is that tight coupling between components of rube goldberg systems was much more painful: particularly debugging across multiple service boundaries.