5 ms·
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
by 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 agoOver 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 agoWith microservices the other team can easily accidentally ddos your server bringing down the system. Ensuring they don't do that require them to build their microservice properly. And if you can trust them to do that then you can trust them to be a good steward in a monolith. So I don't see how microservices are better, it just lets you easier ignore problems but those problems are still there. Also if you want to stop the other team from abusing your code then you can easily fix that. Most languages lets you deliver code in an interface that they can't easily break either, try that before microservices.