Using AWS App Mesh
AWS App Mesh is a managed version of Service Mesh that AWS provide. App Mesh is designed to be used purely for traffic management of services running in AWS.
What is Service Mesh?
A service mesh is a dedicated infrastructure layer that controls service-to-service communication over a network. It provides a method in which separate parts of an application can communicate with each other. Service meshes appear commonly in concert with cloud-based applications, containers and microservices.
Proxy and Control Plane
The proxy sits between all service and manages and observes all traffic. The control plane translates intent to proxy config, and distributes the proxy config to the proxy servers
What are the alternatives
Istio is one of the most popular in this group of technologies. Istio is not limited to just traffic management, it focuses on other features such as security and observability.
How is AppMesh used?
AWS AppMesh can be used with Fargate / ECS / EKS and EC2.
In order for your app to communicate with AppMesh, you need to sideload a proxy inside your pod. There are various technology choices which can be used with this proxy
- HTTP access logging
- Cloudwatch logging
- Cloudwatch metrics
- Other envoy tracing drivers
- Load balancing
- Weighted targets
- Service discovery (DNS and cloud map)
- Path based routing
App Mesh Constructs
- Virtual Services
A Virtual Service is a representation in App Mesh of an actual service. When your application makes a call to a different microservice, this is what it will call out to.
- Virtual Nodes
A Virtual Node represents the combination of a deployment and a service. A Virtual Node requires a DNS endpoint mapping it to a deployment. The name of the Virtual Node also needs to match an environment variable in the Envoy proxy so that it can identify itself. There are several other things that you manage in the Virtual Node, such as which services it can reach.
- Virtual Router and Routes
The Virtual Router and Routes create the connections between the Virtual Services and Virtual Nodes. You attach one or more Virtual Routers to your Virtual Service and then configure the routes to point at one or more Virtual Nodes.
Comparisons with Istio
|Runs in a sidecar||Runs from within your container|
|Path based routing||Can route based on anything within the request|
|On or off access to a service within the mesh||Allows RBAC and ACL controls per service method within a service|
|Active health checks||Active health checks|
|Some recovery features||More advanced recovery features|
|Integrates with existing AWS services easily||Full logging and monitoring with dashboards|
|No support for TLS||TLS supported|
Why would we want this?
By using AppMesh, we can offload communication management logic from application code and libraries into configurable infrastructure, because this decouples from the application, it means that it is no longer thr responsibility of a developer to maintain and patch when newer versions of the sdks are made available.
Reduce troubleshooting time required by having end-to-end visibility into service-level logs, metrics and traces across your application.
Manage all service to service traffic using one set of APIs regardless of how the services are implemented.
Minimises the inconcistencies between services and how they interact with each other, as you can roll out changes to all without requiring deployments of individual applications.
Written on November 7, 2019.