Amazon has released AWS App Mesh, a service mesh that allows developers to standardise how microservices communicate, implement rules for communications between microservices, and capture metrics, logs, and traces directly into AWS services and third-party tools. App Mesh is effectively an AWS-specific hosted control plane for Envoy, an open source service mesh data plane proxy. App Mesh can currently be used with Amazon Elastic Container Service (ECS), Amazon Elastic Container Service for Kubernetes (EKS), and Kubernetes on EC2.
AWS App Mesh provides APIs (exposed via a CLI and SDK) that allow the specification of fine-grained traffic routing between applications based on service versions, for example, allowing a canary release or A/B deployment. App Mesh can also enforce access controls, quotas, and limits on service clients. Leveraging functionality provided by Envoy, traffic can also be shadowed to alternate environments for further troubleshooting, and faults can be injected for running chaos experiments. However, some of this functionality is scheduled for the GA release but is not currently implemented within App Mesh.
For deployment of App Mesh on ECS an Envoy proxy container image must be added to the associated task definition. Wth Kubernetes an Envoy proxy image must be added to the Kubernetes PodSpec. The Envoy "sidecar" containers enable App Mesh to intercept and manage all communication from the associated service, and export metrics, logs, and traces to the endpoints specified in the Envoy bootstrap configuration provided.
AWS App Mesh is made up of the following components:
- Service mesh: An instance of a "service mesh" (in AWS parlance) is a logical boundary for network traffic between the services that reside within it.
- Virtual nodes: A virtual node acts as a logical pointer to a particular "task group", such as an ECS service or a Kubernetes deployment.
- Envoy proxy and router manager: The Envoy proxy and its router manager container images configure the microservice task group to use the App Mesh service mesh traffic rules that have been configured for virtual routers and virtual nodes.
- Virtual routers: The virtual router handles traffic for one or more service names within a service mesh.
- Routes: A route is associated with a virtual router, and it directs traffic that matches a service name prefix to one or more virtual nodes.
App Mesh is currently targeting the use case of service-to-service "east-west" traffic control and observation. Although "use App Mesh for ingress routing" is listed as on the post-GA feature roadmap, the App Mesh documentation currently recommends using AWS Elastic Load Balancing to handle all "north-south" internet traffic and traffic from clients that are not within the organisation's trust boundary. Outside of the App Mesh ecosystem, other implementations offering ingress support based on Envoy are progressing, and this includes open source implementations such as Datawire's Ambassador, Solo's Gloo, and Istio Gateway.
AWS state that they have invested into building a service mesh that includes a control plane and API that follows the "AWS best practices". Currently App Mesh distributes an Envoy build of version 1.8.0 with an extensions for SigV4 that to ensure Envoy is authenticated properly with AWS authentication system (and this change to planned to be contributed upstream to Envoy). Specifically, App Mesh is designed to pluggable and will support bringing custom Envoy images and Istio Mixers in the future; has a design that allows AWS to add support for other computer services in the future; and is implemented as a multi-tenant control plane to be scalable, robust, cost-effective, and efficient.
Community reaction to the announcement has been mixed. Several people, including Shriram Rajagopalan, staff engineer at VMware and Istio contributor, noted that some source material in the examples appeared to be taken, without acknowledgement, from the Istio project. This was quickly addressed. Others, like Christian Posta, noted that App Mesh was, "in true AWS fashion, not open source". There is a post-GA feature currently documented in the App Mesh examples repository titled "Opensource App Mesh Envoy Management Service (EMS)", although this does not contain any information as to the scope of the open source release.
Several Twitter users, including industry luminary Kelsey Hightower, asked why AWS didn't contribute to the existing Istio project, and mused that with the "solid feature set and clean API, it must have been easier to start with Envoy, then work your way up, and ship once you had a minimal viable product." Arun Gupta, principal open source technologist at AWS, appeared to support this analysis, and stated that "Istio is too tightly coupled with #Kubernetes, we need the ability to scale workloads, not just containers but any workload across #AWS." Chris Aniszczyk, CTO/COO of the Cloud Native Computing Foundation, made the interesting point that "there is also the subtle point that Envoy is neutrally owned and governed where Istio currently is not".
Matt Klein, "plumber and loaf balancer" (software engineer) at Lyft, and creator of Envoy Proxy, shared a series of interesting positive thoughts via Twitter about the release of App Mesh. In regard to the primary goal of the Envoy project:
[the Envoy community] has never been shy about our goal, which is to create a feature rich, extensible, and configurable (using well typed and versioned APIs) data plane. It is NOT to create an opinionated end user experience.
He continued by suggesting that the "cloud native data plane" provided by Envoy, along with a scheduler such as Kubernetes, Nomad or Mesos, forms what is essentially "the new cloud native OS". Klein argued that this is a platform that can be "built upon, innovated upon, and monetized.":
[...] the base cloud native platform/OS is going to be completely open, and provided by all the major clouds and [P/C/F]aaS providers. The actual money and proprietary innovation is going to be the services on top: security/obs/auditing/workflow/UI/etc.
[...] And with all of the major cloud vendors, PaaS vendors, etc. converging on @EnvoyProxy as the default cloud native data plane, this means that we can now start building, and not have to worry about fragmentation. THIS IS SO POWERFUL.
Klein also acknowledged that both HashiCorp and Datadog announced that they are working on App Mesh integration as part of the AWS re:invent release announcement, further reinforcing his point about the focus of vendors aiming to provide additional higher-level value.
In summary, AWS App Mesh is available as a public preview in the North Virginia, Ohio, Oregon, and Ireland AWS Regions. There is no additional charge for using AWS App Mesh; customers pay only for the underlying AWS resources consumed by the App Mesh proxy that runs alongside service containers.
The GA release is planned in 2019. The full GA Roadmap and Post-GA Roadmap are available within the AWS APP Mesh Examples GitHub repository. Additional information on App Mesh can be on the Getting Started page.