It's fine to have dependencies, the point is two services that need to be deployed at the same time are not independent microservices.

▲

wowohwow 9 hours ago | parent [-]

Yes, the user I'm replying to is suggesting that taking on a dependency of a shared software repository makes the service no longer a microservice.

That is fundamentally incorrect. As presented in my other post you can correctly use the shared repository as a dependency and refer to a stable version vs a dynamic version which is where the problem is presented.

▲

jameshart 8 hours ago | parent | next [-]

The problem with having a shared library which multiple microservices depend on isn’t on the microservice side.

As long as the microservice owners are free to choose what dependencies to take and when to bump dependency versions, it’s fine - and microservice owners who take dependencies like that know that they are obliged to take security patch releases and need to plan for that. External library dependencies work like that and are absolutely fine for microservices to take.

The problem comes when you have a team in the company that owns a shared library, and where that team needs, in order to get their code into production, to prevail upon the various microservices that consume their code to bump versions and redeploy.

That is the path to a distributed monolith situation and one you want to avoid.

	▲	wowohwow 8 hours ago \| parent [-]
		Yes we are in agreement. A dependency on an external software repository does not make a microservice no longer a microservice. It's the deployment configuration around said dependency that matters.

▲

8 hours ago | parent | prev [-]

[deleted]