Is it possible to simply update dependencies across multiple microservices?

Question

Spring

Using shared libraries in microservices is bad practice. But each microservice in any case has dependencies on frameworks and libraries. For example, Spring Boot, Kafka Java Client, etc.

If the system consists of 30 Spring Boot-based microservices using Gradle or Maven as the build tool and distributed as Docker images, is there an easy way to update the Spring Boot version in all microservices? Updating all microservices one by one takes a lot of effort. And the more microservices in the system, the more effort is required.

The reason for updating may be a dependency vulnerability.
For example, Spring Boot 2.2.0.RELEASE depends on Tomcat 9.0.27 which has the CVE-2020-1938 vulnerability(Vulnerability is taken simply as an example). The vulnerability has been fixed in Tomcat 9.0.31, so upgrading to Spring Boot 2.2.4.RELEASE resolves the issue.

There is an option to declare Spring Boot version in build.gradle as 2.2.+ . But this introduces uncertainty about the versions used, and someone still has to rebuild all the microservices.

If the vulnerability is critical, there is no time to wait for a new version of Spring Boot with a fix, and Tomcat must be explicitly updated in build.gradle . Or even replace with Undertow, which also requires changes to build.gradle .

Using standalone Tomcat instead of embedded doesn't help much either, since microservices are distributed as Docker images, not as WAR files that are deployed in a Servlet container.

In Java EE, security updates were, in theory , very simple. You update an application server (like WildFly) or install a security patch, and if the application only uses the Java EE API, no further changes are required. Is there a similar concept of simple dependency updates for microservices (at least in theory)?

Answer 1

Welcome to the real world. In fact, this problem is not new at all. Yes, dependencies are convenient, but painful, which is why testing is necessary, and some organizations even use security testing of third-party components.
It is worth starting to treat your problem in order to implement CI / CD and receive reports on successful builds. Add testing later. After that, you will understand that it is necessary to fix dependencies in projects quite hard, fork third-party libraries, version your code in the repository. Even the API will have to be versioned over time and learn how to write contracts, documentation) A lot of additional work, but at the same time, this is all - the only thing that keeps projects coming out of the sandbox afloat

Answer 2

As a matter of fact, dependency isolation is one of the reasons for packaging applications in an image.
If this bothers you, then you simply should not use docker.