Service Discovery is a key concept of the microservices architecture which enables different microservices within the ecosystem to discover and communicate with each other.
Broadly, there are two approaches through which this can happen.
- Server Side Service Discovery
- Client Side Service Discovery
Regardless of the approach, the core functionality that is expected from the service discovery component is that it maintains a registry of address and service name combinations and shares that information when needed. The component will have to store multiple addresses against a service name in case the service is running multiple instances as part of its workload.
Let's take an example where there are two services created inside a single ECS cluster. We will call one resource-server and the other client for simplicity's sake. As their name suggests, the containers running inside the client service will need to be able to discover and connect to a single container under resource-server to call an API, let's say.
Server Side Service Discovery
In this mode, the service discovery component owns up the following responsibilities
- Maintaining a registry of service name <-> container IP address mappings.
- Acting as a proxy. Accept connections from
clientand proxy them to one of theresource-servercontainers to enable load-balancing.
In AWS ECS, this component is typically an Elastic Load Balancer. While creating the service, ECS takes in configuration to create and set up load balancer registration.
Once set up, ECS will take care of keeping the target group of the load balancer up to date with the IP addresses of each container spawned by the service. The load balancer in this case acts as a registry containing the endpoints available against each service and owns up the responsibility of routing as well. Hence the name, Server Side Service Discovery.
We will not go into the details about how to set up such a component in this article as we will concentrate on Client Side Service Discovery more.
Client-Side Service Discovery
In the case of client-side service discovery, the component acts as a registry of the endpoints and provides the list to the client when the client requests them. So, in contrast to a load balancer setup, the service discovery component in this scenario does not take the responsibility of proxying the requests. The client will find out which endpoints are associated with a service it wants to call and decides the endpoint to make the call against.
The process is quite simple and can be summarised as shown below.
There are open-source tools that provide this functionality such as Netflix's Eureka. In AWS ECS however, the required functionality can be achieved using Route 53 as the registry.
Setting up ECS service to use Service Discovery
Before we setup service discovery, there are some considerations that can be found here. If the setup doesn't seem to be working, cross check the AWS environment with these considerations to ensure everything is as it is supposed to be.
While creating a new service within an ECS cluster, select the Enable service discovery integration option under the network configuration section to open up the panel to configure Service Discovery.
Namespace - Leave the selection to the default to create a new hosted domain within Route 53. If a namespace is already created, choose the same.
Namespace name - Name of your namespace if it is being created for the first time.
Configure service discovery service - Choose Create new service discovery service per each service in the ecosystem.
Service discovery name - Name of your service. Clients will use this name to resolve the endpoints.
These are the main configuration options to be filled in. Leave the rest of the options to their defaults or select the optimal ones based on your knowledge and move ahead and create the service.
Repeat the same procedure for each service that is created.
Verifying if DNS records are being added to Route 53.
Navigate to Route 53 page in AWS Console to notice that there is a new hosted zone created (if you chose to create a new one through ECS during your first service creation. Otherwise you would have had it already)
Click on the hosted zone named local to see that the Records page contains entries related to the services created in ECS.
You can go to the Task details page in ECS to cross-verify the IP address registered in the DNS record against a service.
Verifying if DNS resolution is working
Let's SSH into the container running under the client service and try to dig the name resource-server.local and verify if the container is receiving a response from the name server (Route 53)
Likewise, when we have multiple containers running under a single service, the name server will return multiple addresses.
It is then down to the client to decide which IP address to use to make the call. For example, if we use curl to make an HTTP call with the verbose flag, we can notice that each call is using a different IP address.
Why use Client Side Service Discovery over Server Side?
One major benefit of using Client Side Service Discovery is the removal of the extra hop when calling an endpoint to communicate. This reduces latency under time crucial conditions.
Secondly, it removes the dependency on the load balancer to scale. In the context of AWS, though application load balancer can scale indefinitely as it is a managed service, under particular scenarios like flash traffic, ELB requirespre-warming. Avoiding the usage of ELB in such cases removes this complication.