Microservices Architecture with AKKA Cluster

[Maatary Okouya]

Hi,

given that Longom is not working to Scala anytime soon. I wonder if someone could share with some good content on how build a good microservice architecture with AKKA including Recommendation, best practices, things to avoid and so on. 

Or if someone as experiences and want to share it here that would be grate. 

For instance what are the layer involves from database up to the REST Layer and so on. 

[Akka Team]

Hi Maatary,

I think if you want to go with a pure Akka solution then akka-http is the way to go. Otherwise, there is nothing really specific to Akka based microservices, so all the generic advice for services apply here without modification.

Probably akka-cluster and persistence needs a mention. Clusters should not span across microservices if possible, instead they should be contacted via controlled APIs (e.g. REST). The client should not be aware that there is a cluster underneath the API. As for persistence, the usual rule applies here, don't share databases between microservices, only expose data through controlled APIs. Streaming HTTP is a great help here as you can stream out large datasets relatively painlessly.

-Endre

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Akka Team

Lightbend - Reactive apps on the JVM

Twitter: @akkateam

[Maatary Okouya]

Thanks for your input. However i am not sure to understand what you mean with 

"Clusters should not span across microservices if possible, instead they should be contacted via controlled APIs (e.g. REST)"

If one use clustering, then one should have one cluster per microservices ? The same cluster should not be used for multiple micro-services ? Does that also means that each microservice should be fully self contained, running on its on instance of akka-http i.e. http server ?

[Akka Team]

Yes this is correct. 

Having multiple microservices in one cluster will force each of those microservices to use the same tech stack and hinder separate deployment of fixes and upgrades to just one of them. There are of course, as always with architectural questions, no right and wrong, just advantages and disadvantages, and there may be reasons in a specific use case to go against what most people do, you just have to be aware of what you gain and what it costs you.

--

Johan

[Dagny T]

Hi Mataary!

I'm actually looking into this very same thing myself!  Thanks so much for starting this thread; and I've posted some followup comments on general Service Design points that hopefully the Akka Team will comment on shortly!

I've found these relevant Activator Templates; and am working through munging them together to create a coherent code reference for myself:

1) http://www.lightbend.com/activator/template/akka-http-websocket-reactive-streams

2) http://www.lightbend.com/activator/template/akka-sample-twitter-streaming

If you'd like to collaborate on standing up a fully coherent prototype; please go ahead and ping me!

Cheers!

Dagny T

[Dagny T]

Hi Maatary,

Just an update that I had got from the Akka Team on my original stab at an implementation for this using those (apparently outdated) Activator Templates:

"The tweet publisher is the glue from the eventStream to Akka Streams. As you say, there are other ways of doing this. For example passing a Source.queue to the TweetActor and let it publish into that instead of eventStream -> ActorPublisher. In general I think you should avoid the ActorPublisher and ActorSubscriber if you can, and if you can't then a custom GraphStage may anyways be a better solution as the APIs look today."

So, I went ahead to create an experimental GraphDSL that does a fan out/then merge within a local module (i.e. no cross-network HTTP and Websocket calls); and will just proceed with adding the cross-network connectivity based on that API.  This is with my general assumption that this DSL encapsulates underyling implicit Actors -- thus making ActorPublisher and ActorSubscriber creation unnecessary.

Just wanted to make sure that you got this latest information from the Akka Team as well; so as not to waste your time!

Cheers!

D

 

On Friday, July 15, 2016 at 9:03:05 AM UTC-7, Maatary Okouya wrote:

[Dagny T]

Typo on my last comment; meant to say I 'used' the existing Akka Graph DSL.  (Definitely didn't write my own!)

On Friday, July 15, 2016 at 9:03:05 AM UTC-7, Maatary Okouya wrote:

[Maatary Okouya]

Thank you very much for this detailed input.

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---

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

[Maatary Okouya]

BTW, 

yup would love to collaborate on this issue. Although right now i barely have the time. In a near future yes. Will definitely get back to you on that.