The Envoy Proxy Finds a Home at the CNCF, Amazon Web Services
Though gaining the most attention for being wingman to the Istio service mesh, companies are building products focused on security, observability, UI management and more based on the Envoy proxy.
The most recent is AWS App Mesh, a managed control plane for the proxy, which Amazon introduced as a preview earlier this month at re:Invent. It’s a service mesh that allows you to easily monitor and control communications across microservices applications running on Amazon ECS, EKS, and Kubernetes on ECS.
Envoy is a service mesh substrate that provides common utilities such as service discovery, load balancing, circuit breaking, logging and tracing to heterogeneous application architectures. It can be used as a service proxy to route requests between services or as an edge proxy to handle external traffic.
It’s the third project to graduate from the Cloud Native Computing Foundation incubator after Kubernetes and Prometheus.
An L4 (TCP) proxy with an extensible filter chain mechanism, it can be used for a variety of use cases, including transparent TLS proxying, MongoDB sniffing, Redis proxying and complex HTTP-based filtering and routing. It supports HTTP/2 and gRPC for both incoming and outgoing connections.
In June, HashiCorp released native integration with Kubernetes and Envoy. Now services inside and outside Kubernetes can now be automatically configured to securely connect via a built-in or Envoy proxy.
Meanwhile, Twistlock has been touting the security capabilities of the Istio-Envoy pairing.
Polyglot Environments
Ride-share service Lyft created Envoy in 2015 when it was transitioning from a monolithic architecture to microservices written in Python, according to Matt Klein, the project’s lead maintainer
“We were seeing many of the technical and human scaling issues with microservices — observability, trying to understand what was going on and general networking problems,” he said.
“Networking in a highly dynamic environment is quite complicated. Most companies were dealing with this by building libraries like Finagle in Java or Hystrix from Netflix. Obviously, that means you have to use a Java-based architecture. Companies that were polyglot, using many different languages, didn’t have that as a capability. You’re left with building a library in a bunch of different languages or going through and building a single proxy.”
Envoy is the third project to graduate from the CNCF incubation program, following Kubernetes and Prometheus.
Envoy is written in C++, main for performance reasons, but it can form meshes between components written in languages such as Go, Java, PHP and Python.
Envoy was built from the ground up for dynamic configuration and deployments that were always changing, Klein said. It was focused on advanced load balancing and focused on things other proxies had only in a paid version. Other proxies typically use a static configuration file that had to be manually deployed and reloaded. Envoy was built to have a centralized configuration system that could send configuration out to all the proxies and do that in a consistent way, he said.
“That really eases operations for this type of system because it allows a decoupling of the data plane or the proxy from the control plane or configuration-management system,” he explained.
Platform-agnostic
Envoy runs alongside the application and abstracts the network by providing common features in a platform-agnostic manner, Christian Posta, chief architect of cloud applications at Red Hat, explained in a guest post for The New Stack.
Running all the service traffic through an Envoy mesh provides consistent observability and tune overall performance and add features in a single place. In addition, he points out, service proxies like Envoy can help push the responsibility for things like resilience, service discovery, routing and metrics collection, down a layer below the application.
Posta has written a series of blog posts on using Envoy for circuit breaking; retries and timeouts; and distributed tracing.
“When building the open source Ambassador API Gateway, we chose Envoy Proxy over HAProxy and NGINX because of its feature set and forward-thinking vision,” said Richard Li, Datawire CEO and co-founder. “In addition, because Envoy was built at Lyft, there is no commercial pressure for a proprietary version of Envoy. Because of this, the Envoy community is outstanding — they focus only on the right features with the best code.”
He wrote more about the company’s selection process in this blog post.
Going forward, the project will be what the community drives forward, Klein said, but he has some ideas about Quic networking protocol, Kafka support, increased scalability and bringing Envoy to mobile and IoT devices.
The Cloud Native Computing Foundation and TwistLock are sponsors of The New Stack.
Feature Image: “Highway Patrol, ATC Japan 1960” by lord enfield. Licensed under CC BY-SA 2.0.
