Lagom ServiceLocator using deterministic hostnames


I am working to deploy a simple Lagom System of Microservices into an externally hosted cloud. Each microservice will be its own DockerImage. Each microservice is declared to the hosting service, and is given a deterministic “hostname” (app.service.project) which is resolve-able only from within the deployed cloud. These names remain the same across otherwise-distinct “environments”.

Now, when using runAll goals, a ServiceLocator and ServiceGateway are started. I have seen docs which would enable me to disable these.

My question is how I map hostnames to services such that one Lagom microservice may resolve and invoke another Lagom microservice in the same project. For example, do I need to use a specific ServiceLocator which resolves via DNS?

At this stage the services we are deploying are the well-known Hello-Impl and Stream-Impl, so feel free to answer in those terms.

My project name is “example”, I may ascribe the service name “lagom” to each microservice, so Hello would be rsolvable as hello.lagom.example, and Stream as stream.lagom.example.

Kind regards, Robin.

After further reading I think we should be

  • using lagom-scaladsl-akka-discovery-service-locator (is there a javadsl alternative),
  • providing a class ExampleApplicationLoader extends LagomApplicationLoader in every microservice module,
  • configuring this approximately as:
   service-name-mappings {
     hello {
       lookup = hello.lagom.example
       scheme = http

Am I on the right track? Any simplistic (HelloWorld-style) examples out there?

Much obliged, Robin.


Check Production overview and Lagom kubernetes setup considerations

Hope this helps.


We are not using Kubernetes. I’m sure I have read that documentation already, but will happily do so again if it might be relevant to the non-K8s case.


Lagom officially supports kubernates and all examples regarding production deployment are focused on that.
But of course other types of “deployments” can be configured.
You have to take in mind two things that are relevant for this topic (stated in referenced documentation):

  1. “services need to locate the addresses of other services to communicate with them. This requires you to configure an implementation of a ServiceLocator that Lagom uses to look up the addresses of services by their names”

  2. “ Lagom services that require an Akka Cluster (which includes any that use the Lagom Persistence or Publish-Subscribe APIs) must have a strategy for forming a cluster or joining an existing cluster on startup”

#1 is obvious and #2 is one of the lagom’s biggest competitive features

#1 is locating of other services and #2 is locating other instances of the same service to form a cluster

Both can be configured with static or dynamic locating/discovery.

Configuration depends on targeted deployment environment and what that environment supports.

  1. for static you configure (in each service application.conf):
    a) other services endpoints (#1 - Using static values for services )
    b) service instance endpoints (#2 - Akka - Joining to Seed Nodes)

  2. for dynamic you can use:
    a) other services endpoints discovery (#1) Akka Discovery Service Locator that uses Akka’s Service Discovery for underlying implementation
    b) service instance locating (#2) Akka Cluster Bootstrap that also uses Akka’s Service Discovery.

With Akka’s Service Discovery you can use different discovery methods (kubernetes api, Consul, Marathon, AWS, DNS SRV).
You need to check if any of this fit your deployment environment.

Microservices always come in numbers so static option will become challenging very soon and I suggest you check what dynamic options will fit.

Hope this helps.