3 ms·

I'm curious about the trope "microservices are more closely coupled than a monolith" - in my experience this is because the microservice architecture is very ba

by sgt101 5y ago

I'm curious about the trope "microservices are more closely coupled than a monolith" - in my experience this is because the microservice architecture is very badly thought out. There are many ways to refactor it and produce a decoupled and robust system. So - is this me deluding myself or is it the case of an architectural style being traduced because of poor implementation?

roblaszczak 5y ago
You are right - I'm using it as as shorthand. It's referring to the "typical" monolith architecture perception. I'm actually a big fan of modular, properly implemented monoliths. In the first blog article I was even showing that it can be actually an implementation detail if an application is monolith or microservice: https://threedots.tech/post/microservices-or-monolith-its-detail/ https://threedots.tech/post/microservices-or-monolith-its-de...
deleted 5y ago
[deleted]
radiospiel 5y ago
I think microservices should eb considered a organizational and "deploymental" (is that a word) implementation detail, really. If the data you are dealing with does not allow for easy segretation then microservices are quite expensive to maintain, so, yea: bad architecture, not so much bad implementation.
ebiester 5y ago
It's a common microservice antipattern. When people go "yay microservices" but have no experience designing one, don't bring in people with that experience, and don't get lucky, they end up in the antipattern. It isn't inherent to microservices, but it is common enough that many people will work on a distributed monolith.
z3t4 5y ago
The article lightly taps on the issue... > It’s a key for achieving proper services separation. If you need to touch half of the system to implement and test new functionality, your separation is wrong.
jmull 5y ago
They aren't inherently more coupled than a monolith. But they aren't significantly less coupled either. The advantage to micro services is that you can develop, test and deploy/release them independent of other components in the system. But there are plenty of other kinds of dependencies that can exist between components and if you don't don't manage them somehow, your system will drift toward a "ball of mud" where everything is dependent on everything else and any change is cross-cutting and difficult. That's true whether you have micro services or not.
dasil003 5y ago
I think it’s more that if you have a bad or unstable interface between services it’s way worse than if it’s an internal interface within a single service. Successful SOA requires extremely good judgement and foresight in order to get the tradeoffs right. Even the word microservices coupled with “code craftsman” consultants peddling just-so rules of thumb about how big services “should be” without any specific domain context has lead a generation of engineers down a path of hard lessons about understanding your use case before blindly reaching for a pattern.
ddek 5y ago
The level of coupling doesn't depend on the deployment architecture at all. It is entirely a function of how much modules know of each others API's. If I have a monolith where each operation synchronously delegates to other modules within the same process, then this system may be tightly coupled. However, even if it is, API calls are fast and predictable. If I rewrite the same monolith into microservices, where the same API calls are replaced with HTTP requests to the other services, my system is still tightly coupled. Each API call now incurs xx ms of latency and risk of transient failure. I could deploy each module independently, but doing so would cause other modules to fail. Arghh! Arguably the degree of coupling hasn't changed here, but the implications are that much more severe. Loosely coupled microservices usually use some highly available message queue or streaming system so services can operate independently. You can still be tightly coupled in this architecture though. If you issue a message, then immediately wait for a response message, you're in pretty much exactly the same situation as above. Actually loosely coupled services usually issue and consume messages separately. In this case, if one service goes down a backlog builds, but the other service can still push messages on to it. Some loosely coupled microservice architectures (Starling Bank comes to mind) do use synchronous HTTP messaging. Sometimes you want the services themselves to ensure delivery of messages.
- foobarian 5y ago
  Over time, the level of coupling absolutely does depend on the deployment architecture. The problem with a monolith is that developers tend to follow paths of least resistance and can easily introduce cross-codebase dependencies by autocompleting or C&P, resulting in a degree of coupling that is very hard to undo, and slows down all sorts of future projects (fixing bugs in shared modules, upgrading stuff, etc.). With separately versioned and deployed services, a developer can't overwrite some global variable because they are in a rush and it's the quick and dirty solution. They may need to ask the owning team for an OK to introduce a new endpoint, run the design by them, code review, etc. This tends to lead to better designs. Overall it can still lead to complicated system but I think the extra guardrails are a net benefit.
  - username90 5y ago

by sgt101 5y ago

roblaszczak 5y ago

You are right - I'm using it as as shorthand. It's referring to the "typical" monolith architecture perception. I'm actually a big fan of modular, properly implemented monoliths. In the first blog article I was even showing that it can be actually an implementation detail if an application is monolith or microservice: https://threedots.tech/post/microservices-or-monolith-its-detail/ https://threedots.tech/post/microservices-or-monolith-its-de...

deleted 5y ago

[deleted]

radiospiel 5y ago

I think microservices should eb considered a organizational and "deploymental" (is that a word) implementation detail, really. If the data you are dealing with does not allow for easy segretation then microservices are quite expensive to maintain, so, yea: bad architecture, not so much bad implementation.

ebiester 5y ago

It's a common microservice antipattern. When people go "yay microservices" but have no experience designing one, don't bring in people with that experience, and don't get lucky, they end up in the antipattern. It isn't inherent to microservices, but it is common enough that many people will work on a distributed monolith.

z3t4 5y ago

The article lightly taps on the issue... > It’s a key for achieving proper services separation. If you need to touch half of the system to implement and test new functionality, your separation is wrong.

jmull 5y ago

They aren't inherently more coupled than a monolith. But they aren't significantly less coupled either. The advantage to micro services is that you can develop, test and deploy/release them independent of other components in the system. But there are plenty of other kinds of dependencies that can exist between components and if you don't don't manage them somehow, your system will drift toward a "ball of mud" where everything is dependent on everything else and any change is cross-cutting and difficult. That's true whether you have micro services or not.

dasil003 5y ago

I think it’s more that if you have a bad or unstable interface between services it’s way worse than if it’s an internal interface within a single service. Successful SOA requires extremely good judgement and foresight in order to get the tradeoffs right. Even the word microservices coupled with “code craftsman” consultants peddling just-so rules of thumb about how big services “should be” without any specific domain context has lead a generation of engineers down a path of hard lessons about understanding your use case before blindly reaching for a pattern.

ddek 5y ago

The level of coupling doesn't depend on the deployment architecture at all. It is entirely a function of how much modules know of each others API's. If I have a monolith where each operation synchronously delegates to other modules within the same process, then this system may be tightly coupled. However, even if it is, API calls are fast and predictable. If I rewrite the same monolith into microservices, where the same API calls are replaced with HTTP requests to the other services, my system is still tightly coupled. Each API call now incurs xx ms of latency and risk of transient failure. I could deploy each module independently, but doing so would cause other modules to fail. Arghh! Arguably the degree of coupling hasn't changed here, but the implications are that much more severe. Loosely coupled microservices usually use some highly available message queue or streaming system so services can operate independently. You can still be tightly coupled in this architecture though. If you issue a message, then immediately wait for a response message, you're in pretty much exactly the same situation as above. Actually loosely coupled services usually issue and consume messages separately. In this case, if one service goes down a backlog builds, but the other service can still push messages on to it. Some loosely coupled microservice architectures (Starling Bank comes to mind) do use synchronous HTTP messaging. Sometimes you want the services themselves to ensure delivery of messages.

foobarian 5y ago
Over time, the level of coupling absolutely does depend on the deployment architecture. The problem with a monolith is that developers tend to follow paths of least resistance and can easily introduce cross-codebase dependencies by autocompleting or C&P, resulting in a degree of coupling that is very hard to undo, and slows down all sorts of future projects (fixing bugs in shared modules, upgrading stuff, etc.). With separately versioned and deployed services, a developer can't overwrite some global variable because they are in a rush and it's the quick and dirty solution. They may need to ask the owning team for an OK to introduce a new endpoint, run the design by them, code review, etc. This tends to lead to better designs. Overall it can still lead to complicated system but I think the extra guardrails are a net benefit.
- username90 5y ago