EnvoyCon North America 2021

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.

Envoy has a number of different load shedding mechanisms available out-of-the-box. Circuit breaking, rate limiting, admission control, adaptive concurrency-- how do they work? When should you use them? How can they fail spectacularly? Let's find out!

This one's a deep-dive into the different load shedding mechanisms available in Envoy. Come watch Tony gush about how each one is implemented, the queuing/scheduling concepts behind them, and how they can fail to protect us from noisy-neighbor problems. He'll conclude with some experimental results based on his previous work on FBThrift and how we (as a community) can apply those ideas to improve Envoy.

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.

Tinder adopted an Envoy based service mesh for their Kubernetes based infrastructure a few years ago. Our implementation is custom to Tinder's architecture but the lessons we picked up along the way are universal. Whether it's how we store and represent our routing configuration, building out a robust monitoring pipeline for all our Envoy metrics, utilizing Envoy's global rate limiting capabilities to protect our infrastructure, meshing our database and microservice requests, retry and timeout do’s and don’ts, and more, there is plenty of knowledge to share. We will explore our bespoke features like deadline propagation, multi-cluster Envoy metric monitoring, and how we implemented our own xDS control plane. From the early struggles of our service mesh migration, to cautionary tales and best practices, we're excited to walk through the process of building out an Envoy topology that powers Tinder's infrastructure worldwide.

Each day, Twitter responds to hundreds of billions of requests from users around the world. Today, Envoy is the point of entry for 100% of these requests. This hasn't always been the case. Not long ago, requests to Twitter passed through an ancient and highly bespoke edge proxy that was created internally and predated the open-source Envoy. In this talk, Ryland will describe how Twitter runs Envoy at the edge at scale, some of the unique benefits that Envoy provides in Twitter's edge architecture, and highlight features that Twitter has contributed to Envoy to support the edge use-case. He will outline how Twitter's edge architecture has evolved over time as the number of users and services has grown, what the next steps are for Twitter's edge, and the role Envoy will play in the future.

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.