Shared library vs Microservice? [closed]

Question

I have two micro services(ms) ms1 and ms2. In both of the ms there is duplicate reusable code(like hashing/security related/orm/etc). Just FYI this usable code can sometimes maintain some state as well in DB (if it matters by any chance)

There are two ways, I can proceed

1. Either extract the reuable code as separate library and include in both ms
2. Create separate ms for this reusable code and expose it as rest end points

If I take approach 2, advantage is I just have to redeploy the ms3 in case of any change. If take approach 1, I need to redploy both ms. At the same time approach 2 will require separate maintenance/resources/monitoring.

Which one is more ideal approach in terms of system design considering hardware resource is not a challenge. I just mentioned two microservicebut in some cases there are more than two ms having duplicate code.

I am not sure what is the criteria which can help me to decide whether to go towards shared library or micro service ?

Update :-

I have got some clarity from below blogs but still have question. Will think and post anew question if required.

https://blog.staticvoid.co.nz/2017/library_vs_microservice/

https://dzone.com/articles/dilemma-on-utility-module-making-a-jar-or-separate-2

Answer 1

Microservices are only one of architectural styles. In some cases it is better, in some it is worse than other styles. If you don't use microservices it not mean that your architecture is not good.

If you still want to have microservices, then none of these approaches (shared library vs. library as a new "microservice") is good.

I'd suggest to consider following.

1. Microservice approach does not mean, that each end point should be encapsulated into a separate microservice. It is normal, that one microservice provides several different end points. If this is your case, then put your two services into a sinbgle microservice and make them reachable via two different end points. Then it is fine that both of them share some classes.

2. Microservices should normally have independent persistence layer. If there is a strong dependency on the common persistence layer, check, what was the reason to split them into different microservices. Do they really work with different business domains? Can these service be developed and deployed independently on each other? If not, then may be there is no reason to put them into different microservices and it could be better to put them into a single microservice. Then it would be fine if they share some classes.

3. A good microservice should be provide functionality for some domain. If you put shared code to a separate microservice, then it may be that your shared "microservice" does not provide any functionality for a domain, but is just a wrapper for utilities. That would be not a microservice.

4. If you have strong reason to separate your services into two different microservices, then duplicate the code. Each microservice should be independent on the others. It should be possible to replace database and to replace any classes of one microservice without affecting the other one. One normal way to make them independable is duplicate the classes that you (currently) consider as shared. If the services are really independent with the time this duplicated code will change and will be different in each microservice. If you have to change this code in both services simultaneously, then it means that your split is not correct and that what you have are not microservices.