3 ms·
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
by 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 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.