SOA Deployment unit composition from multiple services

In the ADSD course Udi Dahan presented an idea that service from SOA is a logical construct and not a physical one. That means, that service-parts can be deployed in arbitrary number of deployment units. This is a very powerful idea and it lets us be far more creative when designing services and drawing service boundaries.

The problem with this approach is that of 3rd party dependencies. See this picture:

How would you go around this issue of having 3rd party dependencies in different versions in different services, that you’d like to deploy in the same deployment unit?

Udi spoke of a script that is validating the packages in the release pipelines and I can imagine something similar working here as a protection too, but that doesn’t solve the problem of being coupled to one singe version if a library.

If we would want to enforce having dependencies without version clashes, that would quintessentially mean, that we’d have to update the whole (or at least a part of) distributed system at once. Is there an elegant solution for this?

Hi @bosko.stupar,

I’m not sure this a problem specifically related to SOA but a general challenge when working in larger systems with different components, teams, deployments and so on. I don’t think there is a simple solution to this but in general, making sure to use SemVer compliant dependencies will help a lot.

Following SemVer, what you can do to reduce the problem is to establish a wider agreement on the current major version of a common shared dependency. This could be done company-wide, or per service, or per deployment unit, whatever works. Once everyone uses the same major version, there should be little conflicts as SemVer should guarantee compatibility within than boundary. Arguably, this calls for some effort and coordination when upgrading major versions, but that in the nature of new major versions which by SemVer definition will most likely contain breaking changes.

1 Like