米国シアトルで開催された最初のEnvoyConで，eBayのエンジニアリングチームが講演し，同社のネットワークの"エッジ"において，既存のハードウェアベースのロードバランサの置き換えとしてEnvoyを運用していることを報告した。そこから得たおもな教訓は，現実的なシナリオの範囲におけるパフォーマンス特性の検証にはテストが不可欠であること，新旧エッジシステムの移行は組織および技術の両面から注意深くコントロールする必要があること，そして，"プログラム可能なエッジ"には多くのメリットとともに，いくつかの課題も存在するということだ。
テクニカルスタッフメンバとしてeBayに従事するソフトウェア技術者のBala Madhavan，Qui Yu両氏による講演は，eBayは米国内にデータセンタを所有しているが，レイテンシを低減し，ユーザによりよいパフォーマンスを提供するため、世界中でPoP(Points of Presence)を運用している，という説明から始まった。各PoPではKubernetesクラスタを用いた"ソフトウェア主体のインフラストラクチャ"を使用しており，各クラスタのエッジで動作する"南北"ゲートウェイが，外部との入出力トラフィックをすべて管理する役割を担っている。
eBayエッジチームは，各Kubernetesクラスタ内の複数のコンテナでEnvoyを運用しており，レディネス(Readyness)とライブネス(Liveness)をプローブすることで，コンテナが期待通り動作していること，動的なリカバリプロセスが完全に動作していることを確認している。レイヤ７ルーティングとデプロイメントコントロールは，独自開発したKubernetes Custom Resource Definitions(CRDs)によって管理されており，カスタム機能仕様にはIngressアノテーションを使用している。同社では独自のディスカバリサービスを実装して，ルーティングディスカバリサービス(RDS)，リスナディスカバリサービス(LDS)，エンドポイントディスカバリサービス(EDS)，クラスタディスカバリサービス(CDS)といった，一連のEnvoy管理xDS APIの処理を実行すると同時に，それぞれがデプロイメントとルーティングを担っている。
ハードウェアベースのロードバランサ実装からEnvoyを利用したエッジソリューションへの移行は，段階的に行われている。移行の第1ステップでは，既存のものと新たなEnvoyソリューションの機能的ギャップの認識と実装が行われる。この作業では，eBayチームがEnvoyオープンソースプロジェクトのアップストリームに提供済の関連コードが使用されている。プロプライエタリな認証管理システムとの統合には別のサポートが提供されており，データプレーンにもいくつかのカスタマイゼーションが実施されている(こちらはまだアップストリームには提供されていない)。これらがコネクションのプリフェッチを処理し，独自要件に基づいて特定のルートへのリクエストをドロップないしリセットし，適切なエラー処理を行うための"デフォルトアップストリームクラスタ"を提供している。明記されていない"SSLおよびTCP最適化"として，Googleの新しい新しいTCPフロー管理アルゴリズムであるBBRもサポートされている。
Madhavan，Yu両氏は応答時間のグラフを公開して，Envoyを採用した新たな実装が，現時点では旧来のハードウェアロードバランサよりもパフォーマンス的に優れていることを示してみせた。Envoy HTTPフィルタとして動的オブジェクトキャッシングをサポートするキャッシング層 -- 外部キャッシュストアと，複数のキャッシュストア上のキャッシュデータのシャードにEnvoyのRingHashロードバランサを使用している -- の追加により，TTFB(time-to-first-byte)が1桁改善されている。
可観測性に関しては，各PoP内にPrometheusを運用しており，視覚化には中央のGrafanaを使用している。警告処理はAlertmanagerと外部チェックを使用して実装し，静的および動的なしきい値による異常検出を行っている。エッジのスタック全体はKubernetes内に，デプロイメントの"Single Source of Truth"として機能するHelm Chart経由でインストールされる。
おもな教訓をまとめるならば、最も重視すべきなのはテストの必要性だ。ハードウェアとソフトウェアにまたがった評価が重要であると同時に、エンドユーザがパフォーマンス低下に見舞われないことを保証するためには、リアルユーザ・モニタリング(RUM)が不可欠である。DCおよびPoPのフェイルオーバのテストに加えて、カオス試験も実施する必要がある。"スムーズなワークロードマイグレーション"のための教訓としては、クロスファンクショナルな(チームによる)計画と確認作業が望ましいことエッジソリューション間のトラフィック移行をコントロール下で実行すると同時に、運用関連のメトリクスを詳細に監視すること、などが挙げられる。
一方で課題として挙げられるのは、新システムが動作するPoP数が増加した場合の運用のスケーリング、PoP間の設定の差異の検出、クラスタ管理のためのツーリングサポートの提供、といったものだ。API駆動のEnvoyプロキシによる"プログラム可能なエッジ"の実装には多くのメリットがあるが、課題もいくつか浮かび上がっている。例を挙げるならば、コントロールプレーンの"開発か購入か"の決定、既存の(レガシ)コンポーネントとの統合、メトリクスや関連するパフォーマンスデータへの対応方法、ハードウェアを専門とする運用チームがソフトウェアベースのソリューションをデバッグおよびトラブル対応しなければならないこと、などである。
"Running Envoy as an Edge Proxy"で使用されたPDFスライドはEnvoyConのスケジュールのページで、プレゼンテーションの記録はCNCFのYouTubeチャネルで、それぞれ公開されている。