AKKA MicroServices Communication

[Maatary Okouya]

Hi, 

as of now what is that people usually do when exposing microservices: 

1 - Do you communicate via REST (which can easily be turn somewhat async). 

2 - Do you rather use Binary communication ? 

The point is if microservices allow full blown interoperability by encapsulating how the the microservice is done, using akka/scala/java, Python, Java with other framework, and so on, how one reconcile that with AKKA binary communication between actors. I wonder what is the practical vision around micro-services. 

Even if it is not J2EE containers, it seems like in practices, one will stick to AKKA infrastructure to support and run all the microservices.  However if one as a set of microservices to be build by another team that works in another languages, then we have a problem. How to ensure communication between those services ?

I find the API GateWay approach to be a hassle that add complexity, but i may be wrong. 

3 - Finally what is the best way to expose an actor or a set of actor behind a rooter, as one microservice to the outside world, using Json Rest. So far i would use AKKA-HTTP where i would define all my endpoint, to the microservices, and then use actors on the back, that actually do the work. However in this configuration, i have a hard time to reconcile the idea of bounded context and so on. It seems to amount to the API GateWay. I don't see how to expose multiple independent Microservices, with their own interface to the world, without using one central interface (webserver) like akka http. 

3.1 - Shall i deploy multiple instance of Akka HTTP independently, if i want to have fully independent microservices ?  I think it would be great to precise what it is important to isolate. The service code, the server, http endpoint definition, and so son. 

4 - Is Akka HTTP compatible with AKKA Clustering ?

[Michael Bondar]

Here are how we do it on our project.

Approach to service oriented architecture is a bit different when it comes to clustering, therefore term "service" is not really applicable here. I believe it's better to stick to "node" which are usually expose actors to other nodes and can communicate with message passing (let's call it internal communication). There is no point to bring http interface to internal communication (since in could be done with standard message passing).

If you need to expose your node to "services" (like apps written in different language) you might bring an additional interface like HTTP or some kind of queue (we are using activemq to keep the flow asynchronous).

середа, 20 липня 2016 р. 18:13:23 UTC+3 користувач Maatary Okouya написав:

[Maatary Okouya]

Approach to service oriented architecture is a bit different when it comes to clustering, therefore term "service" is not really applicable here. 

Could you please explain that further ?