Microservice Communication using AWS App Mesh

The Service Mesh

In a typical monolithic application, internal communication can be a trivial exercise. We can invoke another component of the application using a native call or using a simple request/response API. 

In a typical Microservice Architecture (MSA), we can directly invoke a microservice from another microservice as done in a Service Oriented Architecture (SOA) monolithic based design. However, when our application scales and we have a lot of microservices communicating with each other, it is hard to track requests and we have no visibility to the application.

As a solution, the Service Mesh Architecture was introduced in the industry. Service Mesh is an abstracted infrastructure layer that provides service to service communication. 

The Sidecar Pattern

Service Mesh routes requests between microservices using an Edge Proxy. Each microservice will have an Edge Proxy attached to them. Rather than communicating directly, incoming and outgoing communications between services will be handled via these Edge Proxies. 

Since the Edge Proxy has the visibility of all incoming and outgoing requests, it can handle monitoring, request tracing, logging and configuration without modifying the microservices application code. Therefore, microservices don’t have to worry about Non-Functional Requirements (NFRs). Basically, microservices are delegating the inter-service communication to the Edge Proxy. This method of segregating application functionalities to a separate process/container is explained as the sidecar pattern (see Figure 1).

There are few popular and well-established open-source Service Mesh offerings in the market, such as Istio and Linkerd

AWS App Mesh

AWS App Mesh [1] is the AWS implementation of the Service Mesh. This fully managed service can be used with Amazon Elastic Container Service (ECS), AWS Fargate, Elastic Kubernetes Service (EKS) or vanilla containers hosted in EC2. Currently, App Mesh doesn’t support AWS Lambda, but it’s in the App Mesh future roadmap [2].

In addition, App Mesh is integrated with AWS services like Cloud Map, Certificate Manager, CloudWatch, X-Ray and third party tools like Datadog,Alcide, HashiCorp, Sysdig, SignalFx, Spotinst, Tetrate, NeuVector, Weaveworks, Twistlock, Wavefront by VMware, and Aqua.

App mesh uses an Envoy proxy as it is a sidecar proxy. You need to include an Envoy proxy with your ECS task/Kubernetes pod or add it to the EC2 instance that the microservices container is running, if you are not using ECS or EKS. Also, you need to enable/configure service discovery to use App Mesh. If you are using ECS, you can easily enable service discovery in ECS create service wizard [3]. 

Key Components of the App Mesh Control Plane

There are two main components of a Service Mesh. 

  1. Data Pane – Consists of the Sidecar Proxy along with its Microservice
  2. Control Pane – NFR components

Just like in any other Service Mesh, the App Mesh Control Pane consists of the following key components (see Figure 2).

Service Mesh: This is the boundary of the App Mesh. All components of the mesh reside inside this.

Virtual Services: This is a virtual representation of your microservice. Each microservice should have a virtual service.

Virtual Nodes: This is the logical representation of a task group such as ECS service or Kubernetes deployment. You can directly attach a virtual node to a virtual service or you can attach it to a virtual route. Here you have to configure the service discovery config of the microservice, virtual service that the virtual node will communicate with, Transport Layer Security (TLS) configuration and HTTP access logs path. 

Virtual Routers: Handles traffic for one or more virtual services within your mesh. Using virtual routers, you can direct incoming requests to different virtual nodes. You need to define routes inside the virtual routers to configure traffic direction.

Routes: Associated with a virtual router, it directs traffic that matches a service name prefix to one or more virtual nodes. You can specify the weightage and the percentage of traffic that each virtual node should receive. This feature can be used for canary deployments.

App Mesh Features

  • Easy integration with Amazon ECS, Amazon EKS, AWS Fargate and Kubernetes running on EC2
  • Logging and monitoring using Amazon CloudWatch
  • End to end visibility of the application using Amazon X-Ray
  • Service-to-Service Authentication with Mutual TLS (mTLS)
  • Canary deployments using virtual routers and routes
  • Fully managed AWS service

App Mesh Pricing

Using App Mesh is free of charge. You are paying for the underlying infrastructure/resources that you use with the App Mesh.

Missing Features

App Mesh was introduced back in 2018 and it’s relatively new compared to Istio and Linkerd. Therefore, it lacks certain features and is not fully integrated with a few AWS services.

  • Limiting rates to protect services from traffic spikes is not available yet
  • There is no way to configure options for the circuit breaker
  • AWS Lambda integration
  • AWS API Gateway support

Conclusion


Although App Mesh is a relatively new service mesh, it offers seamless integration with most AWS services. it is a free managed service and is easy to configure. Since more and more developers are shifting towards microservice architecture, AWS is focusing on integrating the App Mesh with other AWS services like Lambda, API Gateway and bringing in features like rate limiting in the near future.

Shehan Ekanayake

Associate Technical Lead