Why shared libraries between microservices are bad?

Question

Sam Newman states in his book Building Microservices

The evils of too much coupling between services are far worse than the problems caused b

Answer 1

The evils of too much coupling between services are far worse than the problems caused by code duplication

The author is very unspecific when he uses the generic word "coupling". I would agree with certain types of coupling being a strict no-no (like sharing databases or using internal interfaces). However the use of common libraries is not one of those. For example if you develop two micro services using golang you already have a shared dependency (towards golang's basic libraries). The same applies to libraries that you develop yourself for sharing purpose. Just pay attention to the following points:

• Treat libraries that are shared like you would dependencies to 3rd party entities.
• Make sure each component / library / service has a distinct business purpose.
• Version them correctly and leave the decision which version of the library to use to the corresponding micro service teams.
• Set up responsibilities for development and testing of shared libraries separately from the micro services teams.

Don't forget - The microservices architectural style is not so much focusing on code organization or internal design patterns, but on the larger organizational and process relevant aspects to allow scaling application architectures, organizations and deployments. See this answer for an overview.