米国シアトルで開催された第1回のEnvoyConで，Pinterest，Yelp，Grouponのエンジニアたちが，Envoy Proxyの現在のユースケースについて発表した。すべてに共通するメッセージは， 現代のネットワークにおいて"ユニバーサル [プロキシ] データプレーンAPI"を提供するというビジョンの成就に，Envoyが近づきつつあるということだ。大規模な商業組織では，エッジゲートウェイやサービスメッシュ，ハイブリッドネットワーキングブリッジなど，さまざまなユースケースのプロダクショントラフィック管理をEnvoyに任せている。
Pinterestのエンジニアリングチームは昨年，それまでの"境界ロードバランサ"モデルから，Envoyベースのエッジプロキシモデルへの移行を果たし，現在ではプロダクションエッジトラフィックのすべてがEnvoyを経由するようになっている。同社でトラフィックサイト信頼性エンジニア(SRE)を務めるDerek Argueta氏は，既存のインフラストラクチャがAWSパブリッククラウド内に展開されており，入力トラフィック管理を提供するためにレイヤ７のAWS Classic Elastic Load BalancerとVarnishキャッシュを使用していることを明らかにした。このソリューションの課題としては，ELBのスケーリングの問題，最適ではないTLSの切断，動的なアップストリーム処理に関するサポートの欠如(例えば，ルーティングを更新するには，新たなサービスとしてデプロイするか，あるいは古いインスタンスを廃止しなければならない)といったものが挙げられる。現在入手可能なネットワークプロキシの分析によってチームは，拡張APIや優れた可観測性，サービスメッシュ移行計画との整合性など，Envoyに移行する新たなモチベーションを見出したのだ。
移行作業の第一段階では，A/Bデプロイ，ボット検出，CDN要求署名など，既存スタックと同等の機能を提供する新たなエッジソリューションを開発することが重視された。Envoyの既定のサーキットブレーカがアグレッシブであることや，トラフィックの低下回避のためにコンテナのホットリスタートをオーケストレーションする必要性，HTTPに関わるさまざま"ニッチやミスマッチ"(Hyrumの法則に関わるもの)など，マイグレーション中にはいくつかの"問題(hiccups)"に直面した。その結果，エンジニアリングチームは，Envoyの問題をデバッグする能力を取得するために多大な投資を行うことになった。それまでエッジエンジニアリングチームの保持していたスキルは，ハードウェアベースのエンタープライズロードバランサのソリューションが中心であったため，これは大きな課題となった。
Argueta氏は，Envoyを使用した新たなエッジソリューションで，Pinterestが"ステージベース"のA/Bデプロイメントを行った方法の包括的な概要を説明してくれた。既存のデプロイメントシステムとの互換性の必要から，これは"カスタムソリューション"として実現されている。新たな機能のロールアウト中は，サービスの複数のバージョンがデプロイされ，ルーティングはホストのリストとIP，そしてZookeeperに追加されたステージデータによってコントロールされる。このデータは，エンドポイントディスカバリサービス(EDS) APIと通信するサイドカープロセスで構成される，独自のコントロールプランを介してエッジのEnvoyに転送される。
可観測性に関しては，SREや他のエンジニアが問題と，それに関連する根本原因を早期に識別できるよう，"高シグナルで低ノイズ"な情報を提供するという目標を掲げて，一連のグラフとダッシュボードの開発とイテレーションが実施された。エッジ上のEnvoyに対しては，リソース利用率の上昇，接続エラー，プロトコルエラーに関するアラートが設定されている。今後の作業としては，ThriftサポートとMemcached統合の提供，MySQLおよびApache Kafkaフィルタの追加，API認証のエッジEnvoyへの移動などが予定されている。
次のセッション，"How to DDOS yourself with Envoy (and other migration horrors)"では、YelpのソフトウェアエンジニアであるBen Plotnick氏と，テクニカルリーダのJohn Billings氏が登壇した。Billings氏の講演は、アプリケーション開発者が最も気にするのはバグフリーなコードを短期間で提供してユーザの問題を解決することであって、新たなRPCテクノロジの利用や通信タイムアウト値の設定には関心がない、という話題から始まった。そのため、2014年にYelpのインフラストラクチャエンジニアリングチームは、同社が"サービスメッシュ v1"と呼んでいるものを実装した。これは，アプリケーションからインフラストラクチャへのネットワーク通信を部分的に抽象化するもので、中心に配置された(そして手作業で設定された)HAProxyルーティングレイヤで実装されていて、旧式のサービス志向アーキテクチャ(SOA)のエンタープライズサービスパターン(ESB)にやや近いものだった。
有効ではあったが、手作業によるHAProxyの再ローディング(と関連するエンジニアの労力)とスケーリング上の問題から、インフラストラクチャチームは、AirBnbのSmartStackサービスディスカバリソリューションをベースとした"サービスメッシュ v2"を導入することにした。このソリューションもHAProxyを使用していたが、運用上のルーチン作業の多くがサイドカープロセスとして実装され、自動化された。これにより、人であるオペレータが構成を設定するのを待つ必要や、手作業に関わるスケーリングの問題は解決した。
このソリューションは数年にわたって問題なく運用されていたが、2018年に実施された、アプリケーション"開発者満足度"調査により、いくつかの領域で改善の余地のあることが明らかになった。具体的には、動的な要求ルーティングの実装を可能にすることや、ユーザトラフィックを実行する前に運用のカナリアテストを(運用エンジニアの時間を使わずに)実行することなどだ。関連する運用上のアセスメントが実施され、3つのソリューションが候補として検討された。エンジニアが習熟しているHAProxyを拡張してこの機能を実現する方法、Lyftの成功例に触発されたEnvoyへのスイッチ、もうひとつのポピュラーなサービスメッシュ実装であるLinkerdへのスイッチである。そして最終的に、SmartStackの提供する基盤アーキテクチャを用いて、Envoyを活用したサービスメッシュに移行するという決断が下された。
インフラストラクチャエンジニアリングチームが"meshd"という、Envoy用のシンプルなコントロールプレーンを(チームの使いなれた言語である)Pythonで実装し、コンフィギュレーションのロードにはフラットファイルが使用された。このアプローチの検証は，"インクリメンタルな開発"の原則に従って限定的な範囲のユースケースを特定し、meshdを使用したエンドツーエンドを実装することで行われた。次にPlotnick氏が登壇し、最大限の影響を(最小限の介入で)提供する"カットポイント"を認識したことから、開発チームが使用するためのシンクライアントライブラリを実装することになった状況について説明した。これらシンクライアントは、コンテキストの伝搬やx-envoy-*ヘッダの設定、データのマーシャリングなどを行う。クライアントライブラリは、既存のソリューションとEnvoyを使用した新たなソリューション間のルーティングを切り替える実験を可能にする機能フラグを実装するための，最も適した場所でもある。
Envoyを使用した新たなメッシュの開発中は，継続的インテグレーションと継続的デリバリの原則が広範に使用された。また，それまでのソリューションにあった手作業の検証は，自動化されたエンドツーエンドのテストに置き換えられた。
Envoyのような最新のテクノロジで作業するのは楽しいが，エンジニアリングの本当の目的はユーザの問題解決であることを忘れてはならない，何とならば，組織やチームが編成される理由はそこにあるからだ，ということを再確認して，氏らの講演は終了した。
続くセッションでは，GrouponのスタッフソフトウェアエンジニアであるTristan Blease氏とシニアソフトウェアエンジニアのMichael Chang氏が，"Bridging the gap between on-prem and cloud: a story about Envoy + a hybrid boundary"と題したプレゼンテーションを行った。Grouponでは現在，アプリケーションワークロードの大部分をオンプレミスで運用しているが，最終的にはKubernetes上にデプロイしたコンテナ化サービスとパブリッククラウドによるハイブリッドスタックを運用する計画である。
現行のスタックはエッジと内部トラフィックの処理にさまざまなテクノロジを使用しており，計画中のマイグレーションでは評価が必要な新たな要件が生まれている。具体的には，コンフィギュレーション時の手作業プロセスの回避，可観測性に関する"より強力なストーリ"の提供，サービス間通信におけるTLSとアクセス管理の実装などだ。エンジニアリングチームでは，自分たちの"理想的なアーキテクチャコンポーネント"の試験と評価を行ったが，そのひとつがEnvoyだった。
両氏は現行および計画中のシステムアーキテクチャの全体的な概要を説明し，オンプレミスとクラウド間でのトラフィックを確保する上での課題について論じた。Envoyインスタンスはエッジプロキシノードとしてデプロイされ，環境間のトラフィックをルーティングする責務を負う。Envoyの構成情報はおもにNoSQLデータベースに格納される。このデータベースは，少量の追加コードとともにコントロールプレーンとして動作し，ホスト，ルート，エンドポイントに関する情報を，関連するEnvoyマネージメントxDS APIに提供する。
講演で使用されたスライド資料はEnvoyConスケジュールのページで公開されている。また，プレゼンテーションの多くは，CNCFのYouTubeチャネルで見ることができる。