Shared libraries in microservice [duplicate]

Question

So I have read shared libraries in micorsevrice ae bad, becuase they dont allow complete autonomy of the service to evolve.

And example:

Service A and Service B both talk to Service C to view some data.

I can create the domain objects in each service and copy the code from Service C.

OR

I can share a shared library between the services.

Now i know if i need to chnage the shared library il have to deploy the 3 services again.

BUT

If i duplicate code and I find a bug in the original code, I still need to deploy all 3 services as the code is copied so there still is a ripple affect.

So why is sharing so bad, in my example?

Answer 1

You are almost always going to have some common components between different services.

• For Example: most services will communicate via TCP and often HTTP. Do you need to find a different library to handle TCP or HTTP communication for each service? NO

• In your example, it sounds as though the shared library would just be a common way for Service A and Service B to communicate with Service C. This is very similar to having common code for handling a communication protocol

• Decoupling services is desirable for many reasons and should be strived for if at all possible. But when it is impractical then it is up to the developer(s) to decide on a course of action. As other people have pointed out, you may want to consider redesigning your system so that these common dependencies are removed. But as I don't know the context and this has already been pretty well explained by others - I will leave that at that and focus on the rest of the question

• If you need to share code between services, and the services are written in the same language then I would do it with one library. Yes you will have to deploy the library to all servers for any changes. But at least the changes will only happen in one place.

• Personally, I don't see any benefit at all in breaking this into different libraries. It's confusing - You'll have to remember your different implementations. If both break, you have two fixes to make. If something changes you have two places to make the change.

• How decoupled would two implementations really be anyways? they are both doing the same thing, both depend on the same data and both are likely to be designed by the same person with the same understanding of the problem. If there are bugs in one then there will probably be similar bugs in the other.