EnvoyCon 2020 is scheduled as a virtual event this week. InfoQ caught up with creator of Envoy, engineer at Lyft and self-described plumber, Matt Klein, regarding Envoy ahead of EnvoyCon 2020 on the rapid rise of both the technology and community.
Envoy, which was the third project to graduate from CNCF behind Kubernetes and Prometheus, was originally created at Lyft. It is a high performant edge/middle/service proxy well suited for cloud-native and service mesh applications.
Klein talks primarily about the challenges faced by developers moving to microservices architecture, and explores how Envoy abstracts the modern dynamic network and lets application developers focus on the business logic. Although Envoy is often referred to as an L4/L7 proxy, Kleint's advice for application developers is to focus on the application layer (L7).
He rounds out the interview by talking about the biggest strengths of Envoy, i.e. its community -- a diverse set of users and vendors.
InfoQ: One of the stated high-level goals for Envoy has been “the Network should be transparent to applications. When problems do occur it should be easy to determine the source of the problem.” Can you elaborate a bit more on this goal?
Matt Klein: When practitioners move to microservice architectures, they face many difficulties, chief among them networking and observability. It’s an incredibly difficult problem to make a microservice architecture look like a monolithic architecture from the perspective of the application developer (i.e., function calls between components “just work”).
Envoy was designed for the highly elastic “cloud native” architectures that are becoming increasingly common in modern deployments. Envoy’s feature set (service discovery, load balancing, eventually consistent configuration, best in class observability, advanced protocol support, etc.) is geared towards abstracting the modern dynamic network from application developers so they can focus on the business logic.
InfoQ: Can you provide some historical context as to why and how Envoy was born?
Klein: I have been working on distributed systems networking for over 10 years, across AWS, Twitter, and now Lyft. Prior to Lyft, I wrote the edge proxy used to serve all of Twitter’s traffic. Additionally, I observed how Twitter handled the thorny problem of service to service networking using a Finagle-based library approach on top of the JVM.
When I arrived at Lyft, I noticed that Lyft was facing all of the same problems as are commonly found when deploying a microservice architecture (per above primarily networking and observability). Additionally, Lyft had a “polyglot” architecture, making a library-based approach impractical.
Envoy was created to simultaneously solve Lyft’s edge networking and service to service networking problems using a unified solution. Operating a single proxy both at the edge as well as for internal networking greatly simplifies operational complexity.
InfoQ: You have not shied away from calling Envoy as a bus for SOA services. What exactly does this mean? And aren’t microservices and service mesh a revolution instead of a mere evolution of SOA?
Klein: I don’t think microservices and SOA are any different in practice. Cynically, “microservice” is a term created by consultants and vendors to help sell new offerings. If we assume that microservices and SOA are the same, we come back to the first question above, which is how to make their deployment less painful. This boils down to trying to make the network transparent to application developers. In this respect, Envoy acts as a “communications bus” that links together various services both at the edge and between the services.
InfoQ: As a developer or architect, do I need to worry about the L4/L7 networking layers and how load balancing is done? If so, can you provide a quick primer of how much should I care about L4/L7?
Klein: The trend in modern architectures is to focus on application-level concepts (e.g., application-level authn/authz, application-level load balancing, application-level observability, etc.). As such, I don’t think that most modern application developers have to have a substantial understanding of L4 (TCP/UDP) concepts (though it certainly can’t hurt!).
At L7, although Envoy abstracts a huge number of concepts, it typically can’t abstract everything. For example, HTTP retries, timeouts, etc. are often application-specific and will require some application developer input. My advice is for application developers to focus what time they have for learning networking concepts at L7.
InfoQ: Envoy is usually mentioned in the same breath as HAProxy, and NGINX. As a developer, if I have to choose a proxy today, why would I choose Envoy over the competition?
Klein: I tell people to pick the technology that works for them and to not focus on trends. HAProxy and NGINX have both been around for a long time and are great, stable projects. Envoy has become very popular for a few different reasons: its community-driven technology-first approach; consistent configuration engine (xDS) built for highly elastic cloud native deployments; stability; velocity; and focus on security.
I always tell people to focus on the problems they are trying to solve, and if Envoy is well-suited to tackling those problems it’s a great choice!
InfoQ: EnvoyCon 2020 is coming up this week. What’s your assessment of the Envoy community, the roadmap for Envoy in general, and especially areas that you need to focus both in terms of technology and the community?
Klein: I continue to be absolutely blown away by the growth of the Envoy community. Never in my wildest dreams would I have imagined the project would be where it is today, after only four years of being open source.
I’m often asked for “the roadmap.” The reality is that as a community-driven project, I only have a vague sense of what everyone is working on at any given time. Some of the big things I know about include QUIC/HTTP3, WASM, continued security investment, new xDS APIs for additional configuration options. But, there is so much going on that it’s hard to keep track.
In terms of areas of investment that would be nice: we always need a ton of help with documentation, examples, and general CI/release tooling. These are super high impact areas, but it can be difficult to find people willing to work on them as it typically is not directly related to writing features for their day job.
In summary, Klein talks about how Envoy has helped application developers implement solutions based around service mesh and microservices technologies by abstracting the complexities of the networking layers. He draws a parallel to Service Oriented Architecture (SOA) and how microservices architecture might indeed be a manifestation of SOA. Finally, he talks about the growth of the Envoy community and areas where they are particularly looking for help.
Documentation and Getting Started material is available at envoyproxy.io.