Microservices communication in C#

[Arun Nair]

Hi,

 I am just beginning to delve into microservices using C#. I have some fundamental questions:

   1. Is a peer to peer communication between microservices better (using libraries like ZeroMQ or NetMQ) or via a Bus?

   2. Are there are tools available for service discovery in the Microsoft world?

   3. If  a peer to peer communication is adapted and an operation involves 5 different microservices, and one of them fails, how does one trace the fault?

   4. Since microservice are supposed to be small do you usually use separate repository classes to access data?

   5. If a microservice A cannot afford to make a async call to microservice B, does this mean both those pieces of functionality belong in a sing microservice?

 I understand that some of the answers to these depends on the problem domain, but am looking for some general guidance.

Thanks,

Arun

[Christian Posta]

I'm not a C# guy, but some of these questions aren't tied to technology, so I'll try to respond best I can :)

On Mon, Jul 6, 2015 at 1:34 AM, Arun Nair <arun...@gmail.com> wrote:

Hi,

 I am just beginning to delve into microservices using C#. I have some fundamental questions:

   1. Is a peer to peer communication between microservices better (using libraries like ZeroMQ or NetMQ) or via a Bus?

The prevailing thoughts around microservices are to prefer "choreography" over "orchestration" but in my opinion, that's no hard and fast rule. ie, using a distributed bus (nservicebus?) most certainly fits a "microservices" architecture. But you may find tradeoffs in practice of how much smarts the bus has vs how often you need to change the service in isolation without affecting other components (bus components, etc). 

   2. Are there are tools available for service discovery in the Microsoft world?

   3. If  a peer to peer communication is adapted and an operation involves 5 different microservices, and one of them fails, how does one trace the fault?

Ideally, some kind of service logging or centralized logging tools can help with this. And you can even instrument some more fine grained tracking, and only do "tracer" style logging, ie instead of having super fine grained logging on every single call, you could sample certain "n" number of calls... twitter uses something called zipkin i think to do this https://github.com/twitter/zipkin 

 

   4. Since microservice are supposed to be small do you usually use separate repository classes to access data?

I think that's a misconception that microservices are supposed to be "small". They should be as small as is needed to completely encapsulate a service's domain objects and "bounded contexts" .... you want to be able to be highly cohesive within the service (and autonomous to the point you can change things within the service..even through it away in favor of a completely different implementation if needed.. that that's a bit of an extreme in practice)... 

 

   5. If a microservice A cannot afford to make a async call to microservice B, does this mean both those pieces of functionality belong in a sing microservice?

If a service cannot afford to make a call over the network whether sync/async, you should think hard about whether to distribute the components. Distribution by itself doesn't make your services any less coupled (in fact it usually causes more overhead/complexity/etc than you think the benefits you're getting). Colocate pieces that should be colocated... but in your specific question, "it depends" :) maybe provide more context/detail?

 

 I understand that some of the answers to these depends on the problem domain, but am looking for some general guidance.

Thanks,

Arun

--
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/42670d39-f4e1-475e-ba84-e06a9566b5f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christian Posta

twitter: @christianposta

http://www.christianposta.com/blog

http://fabric8.io

[Arun Nair]

The problem domain is casino gaming, where the each game play posted from the casino floor has to have a sub-second response so that the score on the slot is updated in almost real time.  In this span of time all previous game plays have to be scanned to determine whether the current game play has hit a jackpot.  The no. of players playing simultaneously could be over 5000, with each player sending up to 5 to 6 game plays  to the server. (All optimizations including caching have been implemented)

I am thinking that with these kind of response time, I am apprehensive of using a bus, as this would add further delay to processing of messages from the casino floor. This is what is driving me towards considering a peer-to-peer approach rather than a bus. The driving force behind migrating to microservices is ease of maintenance, as the code has grown to more than a million lines,  I expect all the microservices deployed on the same server. We currently use a clustered setup with a load balancer.

-Arun