Search code examples
microservicesreusabilitydecoupling

Should Microservices be reusable?

Should Microsercices be reusable? With reusable I do NOT mean sharing Domain specific Models.

I mean should a microservice created for one application be reuseable in another application? Is it sufficient if they are reusable within an application?

What is the best way to decouple microservices. From my point of view as soon a microservices calls another microservice it is tightly coupled, means it can not easily (without modifications) be extracted and put into another microservice application that does not have the same service it refers to/from.

To decouple them, in my opinion, there are following ways:

  1. microservice A needs to talk to the other microservice B with a
    standard contract eg. a specfic protocol.
  2. another Microservice C acts as a gateway and asks microservice B for the data and passes it as input to microservice A.

A concrete example for nr. 2 would be:

Coupled:

client -> API GateWay -> UserProfileService -> Authorization Service

Decoupled:

Client -> API Gateway -> Authorization Service -> API Gateway -> UserProfileService

Am I right assuming that this all boils down to the goal of the microservice? There is no wrong and right?

Are there any other strategies i'm missing to decouple a microservice?

Solution

  • I think the responses you're likely to get will represent opinions more than answers, but I'll go ahead and give mine!

    The literature for microservices has long said, "decouple, decouple, decouple", but frankly I don't find this to be reality. When someone has created a useful API that would empower the functions of your own (auth, payments, and obviously databases come to mind), is it wrong to suggest that those need to be run alongside yours? Most people don't go through complicated, logic-filled gateways in order to make payments via Stripe or send text messages via Twilio, so why should privately hosted APIs be any different?

    It is great to design your own service to be a reusable, easily consumable/deployable component. That shouldn't mean it can't have dependencies, but rather that we should be mindful of the bloat those dependencies introduce. This mindfulness is something devs should practice whenever they introduce dependencies, regardless of whether they are app packages or dependent services/APIs.

    **disclosure: I build and run a framework/platform, Architect.io, to help cloud-native teams collaborate and build upon each others services. I've seen first-hand how company's like Facebook use similar tactics to enable service re-use and consumption, and wanted to build a microservices dependency resolver for the general public.