soa - Microservice Architecture- cross-domain chattiness -

i have relatively new project employs microservice architecture. feel pretty size , granularity of individual services, exception or our security service.

i have 3 main services, let's foo-service, bar-service, , baz-service. these services never need communicate, 3 services regularly talk via http requests security-service. want stop variety of reasons- biggest each request individual services spawns request security service, can turn several hops once account load balancing, etc. i've been reading "software architecture patterns" mark richards, , recommends in these instances should share databases , violate dry: copy required functionality each service. still, uses example smaller "utility" classes, may not apply in instance.

the security service isn't big, copy each of other services. said, it's big enough don't feel great copying , pasting - 314 'relevant' lines of code according coveralls (java there's lot more actual code ;-). turn module each service brings in- services have shared dependency , has bit me in past. of course security code grow on time add authentication methods, aren't reinventing wheel when comes auth it's integrating other libraries , authentication services. is, don't imagine particular code base getting huge.

so question, should copy , paste code or build module every service brings in? thanks!

i want stop variety of reasons- biggest each request individual services spawns request security service, can turn several hops once account load balancing, etc.

pros of leaving separate service:
- changes security business logic affect security service , not need change client services.

pros of moving security logic client services:
- speed/performance.
- 1 less service manage might mean reduced operation costs.

speed (performance) might trump here, depending on requirements are, come increased development costs.

if move security logic own re-usable module can called within other services job @ encapsulating , following basic lose-coupling-tight-cohesion design. also, since might have defend decision years come, please have explanation future boss not fire when asks why cost update our security logic. have benchmarks readily available, people lie, numbers don't. once had 1 page benchmark results new db begged for. asked multiple times different people why went new db... send them 1 page , never heard further questions person.

this video might make feel better regard sto bucking trend: https://www.youtube.com/watch?v=stcrm572aes

it shows how , why netflix bucked trend , did not go rest architecture api's. architecture customer of requirements , cost, not other way around.

edit: big pro leaving service might have create multiple modules each language being supported. @ job our security services used client services across multiple languages.