How to share jar layers between diffrent microservices?

Question

I'm currently working on a project with some spring-boot based microservices. Currently every microservice has it's own layered jar with the default spring boot layer configuration. This already reduces the number of different layers across minor version changes of the same microservice. But the many different microservices add up when needing to push container images to a customer.

However a lot of microservices share large parts of their dependencies. For example all use spring core and spring boot features. Most of them use spring-data-jpa. Some of them make use of a message broker, solr for search or spring-integration. And then there are features that are unique to only one microservice like there is one that needs to generate pdfs or another needs to send emails.

Am I somehow able to share common layers between different microservices? Like there is a layer containing spring-core and spring-boot and their transitive dependencies. And then there is a layer containing spring-data-jpa and it's transitive dependencies excluding those from the spring-core and spring-boot layer. And so on ..

Answer 1

In case there is a need to make deliverables smaller one can try the following:

• do not package the SpringBoot application into a fat jar, but instead keep the libs with all the dependencies in some common folder.
• when building the application for container image one most probably has to set the lib type as provided so that it's not being packaged into the final assembly (that will make local development complicated IMHO).
• every microservice will have the cp option passed to the JVM as an argument that will reference that folder.
• if building with docker the copying of the libs folder should be defined as a separate step, or even make a base image that will include all of the libs in a specific folder (to be further referenced by the JVM)

Things to consider:

• All of those steps will complicate the container image-building phase.
• Typically, the space saved will not compensate for the effort and complexity of the support needed.