My english isn't good. so if you don't understand, please let me know.
I designed micro service architecture. Each service has same library which is team mate made.
(Theses libraries are already distributed maven system, and we used versioning.)
I wonder how to manage these common library dependency (version). Sometimes if library version changed, we have to check all of services and upgrade dependecies.
So someone said to me.
Try to make common library which has all library dependency, than other services use that common library.
But i don't like these idea. Is this best for micro service architecture?
How do I manage library dependencies used by the micro service architecture?
thank you!
The answer is simple: Packaging. There are multiple tools out there that help you package your libraries into some format that is reusable between your projects.
You can use npm in the javascript world
You can use nuget primarily in the .net world
You can use maven/artifactory primarily in the java world
The list goes on. The concept and the ideas are the same.
Bear in mind the following, though. One of the strengths of microservices, is that individual teams can work on their own microservice using any technology they like and any framework. Most companies drop this way of thinking though as they can't afford to have so many people knowing so many frameworks over time. It needs some thinking though, if the team is big enough and the domain is large enough to warrant microservices.
Second thing is why use common libraries at all? Apart from simple utilities, microservices are not even supposed to call the same databases. Check if you are sharing resources apart from external sdks that call the same apis and such.
If even after minimizing the dependencies you still need some package, then semantic versioning is the key. You must decide between the following
Backwards compatibility and impact.
In semantic versioning we are maintaining versions of the same software until we don't. By using x.y.z versions in your packages and maintaining branches at least four each major, you can support multiple consumers with minimal impact. Downside to this is that you must support multiple versions.
Update in x (major version), means breaking compatibility.
Update in y, means extending the library but maintaining compatibility.
Updated in a, means just bug fixing, plus performance improvements.