Hello Ignacio! I'll try to address your questions, but some seem to need deeper architecture review etc, that is something we could do but probably as an commercial offering - if that's something you're interested please contact me / sales directly (made quite a few people very happy this way :-)).
> 1) Put everything on 1 single app (spray front end + backend) and deploy > many nodes or split into 2 separate apps? Even if separated I would like to > have multiple frontends hit by our load balancer for resilience. And having > 1 single app would be easier to maintain / deploy. > Splitting things up is usually a good idea :-) It also depends on your exact use case though, if it's a very simple app it may not be worth the effort etc. > 2) Assuming that I will have multiple nodes running the same application. > I plan to use a cluster aware router. In this scenario, would it be better > to use group or pool? The number of application nodes can go down or up any > time (manually or automatically) > Depends on your exact use case to be honest, we'd have to dive deeper. > 3) Crude basic design would be to have to spray router on front -> cluster > aware router A -> worker logic -> ? -> Database actors > 3a) Should that cluster aware router A be a singleton? Or can I run it on > all the nodes? > Try to avoid singletons of you don't need them. One case where you need singletons is when you need exact ordering of writes - you should use the Cluster Singleton or Cluster Sharding in order to make them fail-over if a node dies. > 3b) If it is a singleton and the node goes down, what will happen? > Use Cluster Sharding or Cluster Singleton - it will migrate the "singleton" to a non-failed node. http://doc.akka.io/docs/akka/2.3.6/contrib/cluster-sharding.html http://doc.akka.io/docs/akka/2.3.6/contrib/cluster-singleton.html > 3c) For the database access part, Should I also put a cluster aware router > on front and a fixed number of actors? or just per request would be ok? > I'd point to cluster sharding here, if you're able to design a nice shard key. Assuming that you actually expect load high enough to care :-) > Advanced stage questions > > 4) The migration process will be gradual, so old API applications will > need to communicate to updated versions running on akka. Of course I can > interconnect them using the http endpoint of spray (like they do now), but > the whole point of this is to avoid those internal http calls. Therefore, > is it possible to create an small actor that on those old apps that > connects to the cluster to make calls? > I think I'd actually use spray or akka-http for such endpoints. In case or larger version upgrades in the cluster it could be a bit fuzzy on compatibility (depends on exact versions between which you jump_. > 5) At some points this apps will be deployed in nodes on opposite sides of > the globe as well. What options are available to route based on some key or > just node latency? > You'd have to implement a custom topology-aware Router. It's not too hard to implement a router, see here: http://doc.akka.io/docs/akka/2.3.6/scala/routing.html#custom-router If we're talking about the cluster here, timeouts etc should be adjusted accordingly. But instead I'd propose to make the inter region talking go via api calls. > 6) We have the option to elastically increase/decrease the number of nodes > via some commands, would be possible to fire those commands based on the > sigar metrics routing? > Have a look at "subscribe to metrics events" http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html#subscribe-to-metrics-events Based on that you could implement something custom :-) I hope this helps! PS: Somehow Gmail decided to use Miku as your avatar, cool - I enjoy vocaloids as well. :-) -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe <http://typesafe.com> -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
