EnvoyCon North America 2021

Join us as we kick off EnvoyCon North America 2021!

Modern apps are increasingly relying on using external 3rd party services (such as Twilio for e.g) and shared cloud services (such as S3 for e.g.). External interactions are important not only for security but for the app's continuity and resiliency as well. The use of Envoy as an egress proxy for external interactions has been limited though, mostly as the external interactions are TLS protected and Envoy is not able to decrypt the external TLS sessions. This session demos a solution that enables Envoy as an egress proxy for external access. It builds upon a combined approach of deploying Envoy as a transparent egress sidecar proxy along with the SSLproxy (github.com/sonertari/SSLproxy). In this approach, SSLproxy acts as a transparent TLS interception proxy and Envoy provides traffic management & security on the decrypted traffic. We dive into the traffic stitching mechanism and a new Envoy listener filter that acts as the glue between Envoy and SSLproxy and extends Envoy for the integrated solution.

The Emissary-ingress (née Ambassador API Gateway) project got its start in 2017, with the stated goal of making it easy for developers to harness the power and flexibility of Envoy, in Kubernetes, without needing to be experts on either Envoy or Kubernetes. Realizing that goal has been quite a journey: to bring Envoy to non-experts, the Emissary-ingress team has needed to learn an enormous amount about how Envoy, from the basics of how it works and how to configure it to best effect, to how to build it, test it, extend it, and debug it. The experience has been by turns challenging, surprising, frustrating, delightful, and ultimately extremely rewarding: after four years, Emissary-ingress is a CNCF project running in thousands of installations around the world, bringing Envoy into production use for organizations that wouldn't otherwise be able to take advantage of it. Join Flynn from Ambassador Labs to dive further into the challenges we've seen, the many lessons we've learned along the way, and the things we think anyone working with Envoy should know.

Health checks are an essential part of distributed systems of today that allow one to operate services in a reliable manner. Without health checks, operating a large latency-sensitive system becomes impossible. However, as the composition of environments differ, it can become a real burden to support health checks. Additionally, as the system scales, users tend to face the dreaded N-square problem, and then hit a tipping point, and traditional solutions don't seem to work. In this talk, we will discuss the benefits of health checks in Envoy, some problems we have encountered at scale at Stripe, and options to mitigate such issues.

In the world of support engineering, one of the most valuable questions you can answer is "where is this problem coming from?" When it comes to debugging Envoy Proxy-based applications -- where the traffic can be coming in and out, backwards and sideways -- it can be particularly difficult to answer this question when you’re trying to figure out why a request is failing. This talk will provide a brief overview of how Envoy is structured, and then conduct a live walk through of the debug logs of a request. Attendees will learn how the information in these logs relate to Envoy's internal mechanics.

In the recent years of Envoy’s lifecycle, the service mesh landscape has matured drastically. With the industry growing and utilizing the xDS APIs, the products coming to market and the various solutions designed around the complexities of envoys discovery mechanisms, control plane bifurcation and disparity are more relevant than ever. Go Control Plane has become a targeted part of the Envoy ecosystem, and this talk will walk through what's planned in the pipeline, and what has been merged in this year.

If you’ve ever wondered what WebAssembly (Wasm) is and how it works with Envoy, this session is for you. At the heart of Envoy lies a variety of filters that provide features such as network routing, observability, and security. Did you know that you can also write your own filters to extend Envoy functionality? In this session, you will learn about Envoy extensibility and the details of extending Envoy with Wasm.

xDS is the way config is distributed to Envoy. Most of the ways the xDS API is implemented today (and in Istio) is through the state-of-the-world design. If one out of a thousand clusters changes and Envoy needs to know about the change, most control planes (including Istio) will send all of the thousand clusters to reflect the configuration change. On top of that, every configuration type is converged into one stream with Istio (ADS), which does not do the network any favors. This is the “quick and dirty” way, when logically, there should be no reason to send configuration when it hasn’t changed. This is what the delta xDS API aims to solve. Delta (or incremental) xDS is a variant of ADS/xDS, which has a different interface. If one configuration changes, that is the only configuration that will be sent. Istio is having quite a journey implementing delta xDS, sending only the “deltas” in configuration changes. Especially in a service mesh like Istio, which is the largest and most in-use mesh, there are quite a few caveats that need to be covered. This talk will be about the journey of Istio in implementing delta xDS, along with the expected benefits & apparent struggles that we had, along with guidance for future implementers of this amazing API.

Join us for closing remarks and a wrap-up of the day's content!