How to manage dependencies for microservices?

Question

We are in the process of slowly splitting out a monolithic application to smaller services and one of the debates we are having is how to manage dependencies. The challenge we have is that service A has a dependency on B. A pulls its dependencies from the release Nexus repo.

The problem is B is built and the dependency for A goes into the release-candidates nexus until the build is approved for production. This means new features on B are not immediately available to A. We are discussing if the current approach is the best approach or should B be promoted to the release nexus repo at an earlier stage e.g. after the automated tests have passed with the risk defects being found in B by exploratory testing impacting A.

Answer 1

It's hard to give an exact answer without further knowledge of the architecture of the system. However, I'd suggest building and releasing the artifact that more or less contains the interface of service B first.

The interface should not have any logic in it that needs testing. It also shouldn't have any dependencies to other artifacts of your system yet to be released. So, it should be easy to change the interface and to release a new version of it.

After the interface has been released, the next version of the client can be developed and built against the already released version of the service interface. There's no need to have the service implementation released yet. Actually, even the service itself could be developed only after releasing the interface. Since there are no direct dependencies between the services themselves, promoting services A and B can be done in any order or at the same time, after exploratory testing or so.

This is dependency inversion principle applied to packaging and configuration level. The service A does not directly depend on the implementation of service B. They both depend on the interface of the service B.

Answer 2

You can keep a monolithic app-level branch strategy, release and delivery approach, with all microservices side-by-side but acting as a whole. This would pretty much eliminate the dependency management, backward compatibility requirements and potentially exploding number of integration tests driven by version combinations.

Unless having independent release/delivery stories for each microservice was one of the reasons for which you're splitting the monolith, of course. Personally I consider ability to do that more of a disadvantage, see also https://softwareengineering.stackexchange.com/a/341938/187812