Service discovery.

Service discovery allows you to specify dependencies between two or more services, without hardcoding their addresses and ports. Let's say we have two services:

  • scores-backend which provides REST API on port 80 inside the container (exposed to 32868 outside the container)
  • scores-frontend which displays data provided by scores-backend API.
$ armada list
Name Address ID Status Tags armada ae148a2d3a1a passing - scores-backend e93f803bbea8 passing ['env:dev'] scores-frontend 7f50c2d2f285 passing ['env:dev']

Without service discovery.

In this case, our scores-frontend service would have to know on which address and port can it find scores-backend. We can hardcode it, but this is not a good practice. What happens when a backend service port changes? You can always run this service on the same port, but what happens if this port is used by another service? You'd have to change your configuration. As number of services grow, you have to remember which service runs on which port, as well as keep it well documented.

With service discovery.

Armada offers solution to this problem. In our scores-frontend code, we can simply add one entry to our supervisor configuration.

[program:require_scores_backend] directory=/opt/microservice/src/local_magellan command=python 2000 scores-backend finds an armada service with scores-backend name and 'dev' env, then maps it's address to localhost:2000 inside the container. From now on, we can deploy scores-backend on any ship within armada cluster and always use localhost:2000 for API requests.


  • If we run our frontend with dev/legacy/john env, will first try to find service with matching dev/legacy/john env. Should it fail, it will try to find a service with dev/legacy env and eventually with dev env. Note that it will not match a service without specified env.

Load balancing.

  • If there are two ore more scores-backend services with matching envs, require_service will automatically balance load between them.