Envoy Proxyの過去，現在，未来を探求する第１回のEnvoyConが，KubeConとCloudNativeConとともに米国シアトルで開催された。初日で注目すべき話題は次のようなものだ – Envoyの成功は短期間で立ち上がった(非商業的な)コミュニティと，パフォーマンスや拡張性，詳細に定義された管理APIといった技術的品質の重視によるものである。Envoyコードベースには，LyftやGoogle，Appleといった企業から多くのエンジニアが貢献している。Squareは，オンプレミスとパブリッククラウドの両方で，120を越えるサービスにわたって2,000を越えるEnvoyインスタンスを実運用環境にデプロイした。
Lyftの"配管工兼ロードバランサ"(ソフトウェアエンジニア)でEnvoy Proxyの作者であるMatt Klein氏による，Envoy開発に関する公演で初日は始まった。Lyftチームは2015年に社内プロジェクトとしてプロキシを開発した。モノリシックなアプリケーションからサービスベースのシステムに移行するにあたって，バックエンドデータストアのロードバランシングとサービスディスカバリに関する彼らの要件をすべて満足するプロキシが，当時は他になかったためだ。プロジェクトは当初，"Lyft Proxy"と呼ばれる予定であったが，"もっとクールな"名称を希望するエンジニアリングチームの要望で，"プロキシ"の同義語を探さざるを得なくなった，という経緯がある。
Envoyは2016年半ばにオープンソースとしてリリースされた後，短い期間でコミュニティに幅広く採用され，Cloud Native Computing Foundation(CNCF)によって"インキュベーションプロジェクト"としてホストされることになった。Kubernetesと並んで，EnvoyはCNCFから"卒業"した唯一のプロジェクトである。これはEnvoyの成熟度，コントリビュータの幅広さ，採用の広範囲さを示すものだ。IstioやAmbassador，Glooといったコントロールプレーンを提供するプロジェクトと合わせて，Envoyは間違いなく，現代的なサービスメッシュやエッジゲートウェイのための"ユニバーサルデータプレーンAPI"になっている。さらに，Envoyプロジェクトは元々C++で記述されていたが，Ant Financialチームが，Envoy APIのGoベースの実装であるSOFAMeshを開発している。
Klein氏は自身の見解として，Envoyの成功の大きな理由は"コミュニティ"であり，その理解と貢献とサポートにある，と述べている。さらに氏は，Envoyが業界で急速に普及したのには，他に理由があることも示唆している。それはすなわち，プレミアム(有償)"バージョンが存在しないことであり，プロジェクト内の決定が"テクノロジ・ファースト"を基本としていることであり，Envoyをベースとした"差別化された成功"(コントロールプレーンの実装など)を可能にするエコシステムが構築されていることだ。技術的な観点からは，Envoyはパフォーマンス，信頼性，現代的なコードベース，拡張性，クラス最高の可観測性，明確に定義された構成APIを提供している，と氏は考えている。
GoogleのスタッフソフトウェアエンジニアであるHarvey Tuch氏が続いて講演し，Envoyに対するコントリビューションの状況について説明した。コード提供およびプルリクエストにおける最大のコントリビュータは，Lyft，Google，Turbine Labs，Tetrate，Alibaba，IBM，Solo，Datawire，Appleである。過去２年間で，Envoyのコードベースは20,000行から100,000行以上に拡大したが，管理性向上のため，2018年に，"code"と"extensions"の２つに分離する作業が行われている。
StripeのソフトウェアエンジニアのIsaac Diamond氏が，バックエンドサーバに実装可能なEnvoy管理用の"xDS" APIの概要を説明した。このAPIは、例えばクラスタディスカバリサービス(CDS)、ルートディスカバリサービス(RDS)、エンドポイントディスカバリサービス(EDS)、リスナディスカバリサービス(LDS)などをカバーする。これらのAPIはいずれも結果整合的であり、相互に交信することはない。サービスのA/Bデプロイメントを行うような高度なオペレーションの多くは、トラフィックの欠落を防止するために、オペレーションの順序性を要求する可能性があるため、アグリゲートディスカバリサービス(ADS)サービスがしばしば利用される。ADS APIは、他のすべてのAPIに対して、単一の管理サーバから単一のgRPC双方向ストリームを介したマーシャリングを可能にするため、オペレーションの決定論的な順序付けを実現できる。
続いて、SquareのソフトウェアエンジニアであるMichael Puncel氏とSnow Pettersen氏が登壇し、SquareにおけるEnvoyの運用状況について報告した。Squareのエンジニアリングチームがモノリシックなアプリケーションからサービスベースのシステムに移行する上で、Envoyは、同社が展開する独自のサービスメッシュを実装するための中核部分を担っている。移行の理由となったのは、クライアント/サーバライブラリの簡素化、ロードバランシングに関する責務分散、アプリケーションからのインフラストラクチャの抽象化などだ。Squareのアプリケーションはおもに自社サーバ上で動作しており、一部がパブリッククラウドで運用されている状態だ。同社のサービスでは"Kubernetes風"のデプロイメントシステムを採用しており，ネットワーク名前空間は持たないが，すべてのアプリケーション間通信にmTLS(mutual TLS)を必須としたマルチテナントホスト上で動作するアプリケーションをオーケストレーションしている。
Squareチームが実装したEnvoyコントロールプレーンは，(一般的に使用されるgo-conrol-planeではなく)オープンソースのjava-control-plane上に構築されており，IDアクセス管理(IAM)とサービスディスカバリに独自のキャッシングを使用している。
Puncel，Pettersen両氏は，自らのチームが仮想IP(VIP)によるサービスディスカバリとルーティングソリューションから，Envoyを使用したサービスメッシュに移行した方法について，詳細に説明した。現在はレガシシステムと同等の機能を実装しており，オンプレミスとパブリッククラウドを使用した120サービスにわたって，2,000のEnvoyインスタンスを展開している。Envoyとインタラクションを持つコントロールプレーンのエンジニアリングに多くの考慮とリソースを投入してきた氏らは，エンジニアにメリットを理解させ，トレーニングを提供し，メッシュの展開をコーディネートするという面から，"サービスメッシュを展開する上で最も難しいのはマイグレーションだ"と警告している。
今後は，Envoyへのマイグレーションの完成，Kubernetesへのサービスオーケストレーションの移行，セキュリティ管理のためのSPIFFEインテグレーションの追加，現在のエッジ/フォワードプロキシのリプレースなどを計画している。
Alibaba GroupのデベロッパアドボケートであるAndy Shi氏が次に登壇しAlibabaがJavaベースのRPCマイクロサービスの自動スケーリングにEnvoyを使用している方法について説明した。氏は，AlibabaがオープンソースとしてリリースしているJava RPCフレームワークであるApache Dubbo – 中国では非常にポピュラーである – と，リアクティブなストリームセマンティクスを提供するアプリケーションプロコトルのRSocketを紹介し，これらテクノロジとEnvoy，そしてKubernetes Horizontal Pod Autoscalerのインテグレーションについて解説した。 DobboとRSocketから独自のメトリクスを取得してPrometheusに送るために，いくつかのEnvoy用のフィルタを開発し，ユーザトラフィック・パターンやサービスインタラクションに基づいた自動スケーリングの判断に利用している。この領域の開発は現在も進行中で，Shi氏は開発者に対して，自動スケーリングのような運用上の知見とタスク自動化をサポートするため，可観測性を優先するように提言した。
講演で使用されたスライド資料はEnvoyConスケジュールのページで公開されている。また，プレゼンテーションの多くは，CNCFのYouTubeチャネルで見ることができる。