Are microservices allowed to call each other?

[Christoph Grotz]

Hi,

at the moment we have an interessting discussion running, and I wanted to get some input.

Are microservices allowed to call each other, or does this break the self-containment of the service?

Regards,

Christoph

[John S. Ryan]

mu.

[Chris Richardson]

Short answer: Yes.

--
You received this message because you are subscribed to the Google Groups "microservices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microservice...@googlegroups.com.
To post to this group, send email to micros...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/7aa035c7-f14b-4a53-8167-23b19a8091f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christoph Grotz]

Two people, two opinions.

During discussions, we weren't sure. Some of my colleagues sided with the opinion that microservices calling each other would mean breaking self containment.

On the otherhand, IMHO a self-contained services are allowed to work with other services like DB services or external services (services that are outside of the systems context). 

Am I missing something?

[Chris Richardson]

Hi,

Not sure I would use the term 'self containment'.

Roughly speaking microservices are all about modularity

It's perfectly fine for a module to depend upon other modules.

One concern is how inter-service communication patterns impact latency since it involves remoting.

To pick an extreme example, let's suppose a service handles a request by making 50 sequential calls to other services.

That's likely to result in an unacceptably  high response time.

On the other hand, if a service made 50 parallel calls to other services (e.g. scatter/gather style communication) that's likely to have a low response time.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/8b9a85e2-359f-4443-80ae-c2f00be13b36%40googlegroups.com.

[Patto Cheng]

I got the same trouble, let's say there is a product requirement that is querying member's assets, including account balance, fund balance, and coupon. And we have account service, fund service and coupon service, should I aggregate fund and coupon query in account service and supply the aggregate query interface in account service ?  Or a gateway pattern is better ?

[Christoph Grotz]

We decided due to performance, that microservices shouldn't call each other in a synchronous fashion. Also the amount of interdepdency that took place while they called each other was horribly.

We decided to use a gateway pattern and are very happy with it. Though we also enrich data in an asynchronous update in certain cases, mostly to reduce the amount of requests for the clients.

[Javier Alvarez Samayoa]

The way we were able to manage this is with an 'Orchestration Layer' pattern.

Your 'web apps' can call a Orchestration microservice that does nothing but present an tailored api for the web app. This Orchestration layer is in charge of calling multiple microservices, according to the need of the app.

[John S. Ryan]

Makes absolute sense, Javier.  It's the larger scale version of the "Use Case" in Bob Martin's Clean Architecture.

Is "Orchestration Layer" a synonym for API Gateway? or are you pointing at something different than that?

--
You received this message because you are subscribed to a topic in the Google Groups "microservices" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microservices/Ra84t2Xmyj4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microservice...@googlegroups.com.

To post to this group, send email to micros...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/6f700c96-98f9-438b-8a75-7018d5dce777%40googlegroups.com.

[Javier Alvarez]

For 'me', the API Gateway is just a 'proxy'. Hide the real url's of the other services and give me one unique root url from where to call then.

GET /v1/foo  -> Gateway [  /v1/foo == internal.foo.server/v1 ] -> Foo

GET /v1/bar  -> Gateway [  /v1/bar == internal.bar.server/v1 ] -> Bar

The orchestration layer can merge or transform the responses of multiple internal services (business logic stuff)

GET /v1/foo                    -> OL [  GET internal.foo/v1/foo + POST internal.bar/v1/bar .... ]

                     object.json <-

Each call to the internal microservices should be asynchronous, manage dependency downtime, and all that good stuff.

Javier Alvarez Samayoa (@JManGt)
Free culture advocate and Ruby on Rails Developer
@jmangt | Skype: jas373 | Cel +502 50177932

[David Kuster]

I'm glad this thread has gotten picked up again. I'd meant to post this link a while back and then life happened.

Dan Woods has a presentation where he details the whole "are microservices allowed to call each other" thing.

https://www.youtube.com/watch?v=yk_VlKUDKMA

To me the short version is, you can pick. The situation where they don't call each other he calls a "platform architecture", whereas having them call he other he refers to as a "distributed service layer". My opinion is not having them call each other feels much cleaner and easier to stand up because you don't have those inter-service dependencies. In my (semi-vague) ideal architecture they don't talk to each other directly but loosely communicate via something like Kafka and pub/sub. Whether that works in practice is not something I've had the opportunity to directly try yet.

What I also envision happening is starting out with a notion of this awesomely clean separation and no services call each other, yeah! And then, oops, we forgot about this, and damn, they came up with that requirement, and well, we have this deadline so we could just take a shortcut (but only this one time) and before you know it they all call each other and your platform architecture has become a distributed service layer. :)

A further theory is that the "backends for frontends" (BFF) pattern Sam Newman talks about in his book would help mitigate the devolution. That may be pretty similar to the Orchestration Layer mentioned previously. Further, in my mind the API gateway is more than just a proxy - I would consider that to be the same thing as the orchestration/BFF layer. But I'm not the expert on that by any means.

[Patto Cheng]

However, as a matter of fact, there are many cases you do not need merge or transform the request or response, it is just a 'proxy'.  In this case, every time when I add an interface into a backend microservice, I have to add it into the orchestration layer doing nothing but proxying, it sucks.

Another problem comes out in this pattern, as we integrating more and more interfaces into the orchestration layer or api gateway, this level will become the new monolithic application, at this time should we divide it again?

[Kasun Indrasiri]

As per the Microservices architecture, there's nothing prevent us from inter-microservices calls. Here are some of the commonly used techniques wrt microservices integration. 

- Microservices can call each other via a Gateway. (but they should't call microservices directly) 

- Orchestration logic may reside on another microservice. 

- In some cases, people use the Gateway as the orcestration layer as a virtual microservice. However when it comes to scaling, independent deployment that approach violates the microservices architectural principles. 

I tried to elaborate more on some of the things related to the same concepts in my blog [1]. 

[1] http://kasunpanorama.blogspot.com/2016/02/microservices-enterprise-integration.html

[Bruno Freitas]

Hi Chris,

How about security in microservices inter-communication? I think that the security of the API Gateway (in my case OAuth 2.0) is not applicable. I'm thinking in JWT for that.