3 ms·

Teams are highly coupled by their dependence on a common framework: they can't choose their own tools, and you are at high risk of having to coordinate with ano

Teams are highly coupled by their dependence on a common framework: they can't choose their own tools, and you are at high risk of having to coordinate with another team (the framework team) to release a new feature, all of which are things microservices are supposed to eliminate. Therefore, it's an antipattern.

quantumhobbit 10y ago
I've seen this happen where you develop a micro service and everything is working fine but the framework team makes a breaking change and doesn't tell you. Now your micro service is broken and it is somehow your fault because only your team is responsible for the micro service.
- yeukhon 10y ago
  Yes, dependency management is never fun. I think the current approach we have in all languages fail short because we all depend on a text file declaring dependencies. We need to be able track the dependencies and versions. As part of the build process before merging code into a release branch or master branch, it's probably worth reading the flat file, parse the content, and check with a service (backed by a database). -> depends A -> B B -> C C -> nothing D -> A If A has changed, then on merging A, we should run D with new A. If C changed, then A, B, C, D are need to be tested. A flag or a tag for "non-backward compatible" should be added so on merging we can notify the developers (both producer of the library and consumer of the library) aware of breaking changes in their review queue. If breaking changes keep popping up, time for the tech leads and team managers of both sides to meet and understand how to avoid breaking changes so often. I don't know, someone working with large tech stack should comment on their experience. But we can't just use a text file and an email hoping someone would follow up or realize.
  - z3t4 10y ago
    in my experience its always worth doing extra work to avoid circular dependencies and couplings.

quantumhobbit 10y ago

I've seen this happen where you develop a micro service and everything is working fine but the framework team makes a breaking change and doesn't tell you. Now your micro service is broken and it is somehow your fault because only your team is responsible for the micro service.

yeukhon 10y ago
Yes, dependency management is never fun. I think the current approach we have in all languages fail short because we all depend on a text file declaring dependencies. We need to be able track the dependencies and versions. As part of the build process before merging code into a release branch or master branch, it's probably worth reading the flat file, parse the content, and check with a service (backed by a database). -> depends A -> B B -> C C -> nothing D -> A If A has changed, then on merging A, we should run D with new A. If C changed, then A, B, C, D are need to be tested. A flag or a tag for "non-backward compatible" should be added so on merging we can notify the developers (both producer of the library and consumer of the library) aware of breaking changes in their review queue. If breaking changes keep popping up, time for the tech leads and team managers of both sides to meet and understand how to avoid breaking changes so often. I don't know, someone working with large tech stack should comment on their experience. But we can't just use a text file and an email hoping someone would follow up or realize.
- z3t4 10y ago
  in my experience its always worth doing extra work to avoid circular dependencies and couplings.