One of the big announcements at AWS re:Invent this week was the AWS App Mesh.
Before talking about it though, let’s look at what the heck a mesh is anyway…
What is a service mesh?
A service mesh is an infrastructure layer for microservice architectures. It handles communication concerns between services, making that communication more visible (or “observable”) and manageable. More specifically, it can handle things like service discovery, routing & load balancing, security (e.g., encryption, TLS, authentication, authorization) and provide error handling such as retries and circuit breaking.
Control plan vs Data plane
The capabilities mentioned above (service discovery, routing, encryption, authn/authz etc) are actions performed data (network packets) into and out of a microservice. As a result, they are sometimes referred to as the “data plane”.
How we control actions on the data is referred to as the “control plane”. The control plane is the policy and configuration for controlling the traffic.
The data plane is usually implemented a “side-car” proxy that runs alongside each microservice. The most popular one is Envoy Proxy (created by the folks at Lyft), and that is indeed what is used by AWS App Mesh. In the past, the dominant control plane was Istio, but now AWS App Mesh has moved into the space too.
Together, the data plane and the control plane are what we call the service mesh.
(I guess you could debate whether AWS App Mesh is a control plane that uses Envoy as its data plane, or whether App Mesh is simply a Service Mesh with the concomitant data and control plan. The latter – thinking of App Mesh as simply being a Service Mesh – seems to make more sense to me).
Why do we need a Service Mesh?
Although the term is new, the concepts of the data plane are not. Routing, encryption etc are integral to distributed computing. The concept of the control plane is new however, or at least the concept has never really been formalized or named before. Matt Klein (architect of Envoy) argues that it has usually been done manually using adhoc config and scripting tools. But the need has certainly been there; the ability to more easily control and observe traffic has been sorely lacking. I have certainly seen intermittent issues with microservices that you were difficult to explain, with developers shrugging their shoulders and asking “Network issues?”.
The advantages of handling these types of concerns in a service mesh using side-cars is that it frees the applications (and associated development teams) from having to deal with these issues in every app. In the past, such concerns were often dealt with using common code (e.g. libraries) in each app, but with the downsides of need to be language specific as well as having to be tied in with app releases.
The AWS App Mesh
The new AWS App mesh (currently available as a public preview) aims to make it “easy to monitor and control microservices running on AWS”. App Mesh can be used with ECS, EKS and Kubernetes running on EC2, and can be combined with existing AWS services such as CloudWatch and X-Ray.
As well as providing traffic observability, App Mesh also aims to help with deployments, allowing you to configure traffic routing via the use of a virtual router, allowing the roll out of new service versions using blue/green canary deployments.
There is no additional pricing for App Mesh, just for the computing resources you are using with ECS/EKS/EC2 etc.
What about Istio?
Istio has been the dominant service mesh option for some time, and there definitely seem to be many similarities between AWS App Mesh and Istio. Both are a service mesh. Both wrap Envoy as the data plane. Both aim to solve similar needs in terms of allowing you to monitor and control the flow of traffic between your microservices.
Istio however is open source, vendor agnostic, and has been around for much longer and hence is more mature. For example Istio security capabilities include transport (service-to-service) authentication via support for mTLS, and Origin (end-user) authentication via JWTs and integration with Auth0, Firebase Auth and Google Auth. It also supports service identities not just using AWS IAM, but also Kubernetes and GKE/GCE/GCP.
AWS App Mesh does provide integration with with IAM Policies, Roles, and Permissions, but I haven’t been able to find anything else in the docs about authentication support. Maybe I’ve just missed it though. Note that Istio provides its Mutual TLS authentication via Envoy, so presumably(?) App Mesh will be able to do the same.
So, App Mesh would seem to be lacking some of the features of Istio. However, given that AWS is the 800lb gorilla in the room, not just with massive engineering resources but widespread popularity in the engineering community, it seems likely it will become a dominate tool. Will it displace Istio? It will be interesting to watch…
References and further reading
- “Introducing AWS App Mesh” session video from re:Invent 2018
- Service mesh data plane vs. control plane (Matt Klein)
- AWS App Mesh (AWS)
- Introducing AWS App Mesh – service mesh for microservices on AWS (AWS)
- Getting Started with AWS App Mesh (AWS)
- Envoy Proxy
- Istio
| Published on Java Code Geeks with permission by Shaun Abram, partner at our JCG program. See the original article here: Service Mesh: Istio and AWS App Mesh Opinions expressed by Java Code Geeks contributors are their own. |
