Service Discovery - Microservices on AWS

The term "microservice architecture" is now commonly used to define the development of an application as a suite of small independent services that communicate with each other via some form of HTTP resource API.  

One of the primary challenges with microservices architectures is allowing services to discover and interact with each other, thus was born the concept of service discovery: a concept where a service makes itself discoverable so that another service can call it by name without knowing its physical location or server address. 

There are three main approaches to service discovery used in the development community today:

• Server-side service discovery
• Client-side service discovery
• Service mesh

The service-side approach is the simplest form of service discovery, each service sits behind a load balancer and client of the service use URI of the load balancer to invoke the service, it is the responsibility of the load balancer to maintain some sort of registry for storing information about different services.  An AWS Elastic Load Balancer (ELB) is an example of this approach.

In client-side mode, it is the client that must take care of balancing and maintain the service registry which knows the locations of all service instances.  One example of this approach is Netflix Eureka with Netflix Ribbon or Hashicorp Consul or etcd.

On the AWS side, there is also a dns-based service discovery: Amazon ECS now includes integrated service discovery that makes it easy for your containerized services to discover and connect with each other. Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system based on Amazon Route 53, AWS Lambda, and ECS Event Stream, or connect every service to a load balancer.

Amazon ECS creates and manages a registry of service names using the Route 53 Auto Naming API. Names are automatically mapped to a set of DNS records so that you can refer to a service by name in your code and write DNS queries to have the name resolve to the service’s endpoint at runtime. You can specify health check conditions in a service's task definition and Amazon ECS ensures that only healthy service endpoints are returned by a service lookup.

Another option is to leverage the capabilities of AWS Cloud Map. AWS Cloud Map extends the capabilities of the Auto Naming APIs by providing a service registry for resources, such as IPs, URLs, and ARNs, and offering an API-based service discovery mechanism with a faster change propagation and the ability to use attributes to narrow down the set of discovered resources. Existing Route 53 Auto Naming resources are upgraded automatically to AWS Cloud Map.

Finally we have the service mesh approach: service meshes are an additional layer for handling inter-service communication, which is responsible for monitoring and controlling traffic in microservice architectures. This allows tasks, like service discovery, to be completely handled by this layer.

Typically, a service mesh is split into a data plane and a control plane. The data plane consists of a set of intelligent proxies that are deployed with the application code as a special sidecar proxy that intercepts all network communication between microservices. The control plane is responsible for communicating with the proxies.

Service meshes are transparent, which means that application developers don’t have to be aware of this additional layer and don’t have to make changes to existing application code. AWS App Mesh is a service mesh that provides application-level networking to make it easy for your services to communicate with each other across multiple types of compute infrastructure. App Mesh standardizes how your services communicate, giving you end-to-end visibility and ensuring high availability for your applications.

You can use AWS App Mesh with existing or new microservices running on AWS Fargate, Amazon ECS, Amazon EKS, and self-managed Kubernetes on AWS. App Mesh can monitor and control communications for microservices running across clusters, orchestration systems, or VPCs as a single application without any code changes.