by emrah on 7/21/2022, 6:30:06 PM
The benefit of microservices is also its downfall. You need to maintain each one as a separate entity.
This is true whether you have "microservices" or "libraries packaged and released individually".
I think when you need to introduce a breaking change, if versioning is not sufficient, you could create a separate library and upgrade each service slowly to it while still maintaining both libraries until all services have moved to the new one. This is more semantics than anything else but might be useful.
I'm afraid there is no silverbullet. I'd love to hear more suggestions too.
by trcarney on 7/21/2022, 6:54:44 PM
you could set the shared code a submodule in git. you can set this up so the submodule points to a specific commit. this way any changes to the shared library won't break your other services. Or the company I work for uses artifactory to store shared libraries and we point our services to a specific version of the shared library. this way not all services need to be upgraded at once.
When we first started out on this endeavor we created a parent POM called common-service. This POM declares dependencies such as Hibernate, Spring Boot, and some homegrown common libraries (the most important being a JAR that handles service discovery, rather than each service having to implement service discovery on their own).
Now that we have 200 services running in production, it is a difficult to roll out new versions of common-service for a variety of reasons - some teams don't have the capacity, some teams prioritize business requirements over upgrades, etc.
How do you handle this in your organization? Do you have shared code across your microservices? Is it an anti-pattern to share code across microservices?
PS: We are going to start implementing Kubernetes. Kubernetes will require many changes to our common-service codebase so I figured I would see if anyone had any good ideas out there.
Thank you.