サービス メッシュ マニア: Aspen Mesh または NGINX の選択
より大きなコンテナ エコシステムとともに、サービス メッシュは成熟に向けて前進し続けています。 ただし、まだ初期段階であり、サービス メッシュによるコンテナ内トラフィック管理の問題を解決するためにさまざまなアプローチが適用されています。
私たち（つまり企業としての私たち）は、この春のNGINXの正式な買収に至るまで、多くの質問に答えてきました。 そのうちのいくつかは、テクノロジーとソリューションの「重複」領域に焦点を当てていました。 結局のところ、NGINX と F5 はどちらもプロキシベースのアプリケーション配信ソリューションを提供しています。 NGINX と F5 はどちらもサービス メッシュを構築しています。 問題は、どちらが勝つかだ。
買収では往々にしてそういうことになるからです。
NGINX の担当者と私が何度も繰り返し述べてきたように、重複していると指摘されたテクノロジーは、私たちの見積もりでは、競合するものではなく、補完的なものだったのです。 当社のサービス メッシュ ソリューションでも同様です。
私たちのロジックは、アプリケーション配信に関する共通のビジョンから生まれています。 私たちは、コンテナとクラウド、マイクロサービス、そしてセキュリティ侵害の多発がアプリケーション配信のアーキテクチャとモデルに及ぼしている影響を認識しています。 同様に、「すべてのアプリケーションを配信するための 1 つのデータ パス」は存在しなくなり、「すべてのアプリケーション サービスを配信するための 1 つのアプリケーション配信モデル」も存在しなくなりました。 クラウドは複数のデータパスを導入します。 コンテナは新しいデータ パスを導入します。 どちらも、アプリケーション サービスの配置範囲を、ネットワーク ベースのプロキシ (ADC) から、クライアント、ネットワーク、サーバー、コンテナー、クラウドに至るまでのさまざまな場所に広げます。
「Bridging the Divide」シリーズのアーキテクチャに焦点を当てた投稿で述べたように、アプリケーション サービスをどこでどのように提供するかの選択は、多くの要因によって決まります。 これは、ベンダー実装や「エンタープライズ対 FOSS」の選択だけではありません。場所 (クラウドまたはオンプレミス)、運用モデル、さらには実装の容易さと必要な機能の比率も考慮した選択です。 配信パスの幅を考慮すると、アプリケーション サービスを挿入するための複数のオプションが提供されます。
このため、当社は F5 と NGINX を組み合わせたポートフォリオを競合するものではなく、補完的なものとして考えています。 アプリケーション配信の市場全体が、単一の場所への配置をめぐって競争するのではなく、複数の場所への配置をめぐって競争するようになったためです。
サービス メッシュは、コンテナ環境の拡張、セキュリティの確保、可視性を実現するように設計されています。 まだ初期段階にあり、急速に進化している技術であるため、複数のモデルが登場しています。 1 つはサイドカー プロキシの使用に基づいており ( Envoy は主要なCNCFプロジェクトおよび業界標準のサイドカー プロキシとして登場しました)、もう 1 つはNGINX Plusのようなアプリごとのプロキシを活用します。
コンテナに関しては、顧客がインフラストラクチャの選択について非常に強い意見を持っているため、現在は両方をサポートする予定です。 Istioと Envoy を好む人もいれば、すべてを NGINX で標準化している人もいます。
コンテナ環境で運用および管理する必要があるコンポーネントの数は非常に多いため、サービス メッシュを選択する際には、既存の技術の専門知識が重要な要素となります。 インフラストラクチャに NGINX を標準化している組織は、NGINX プロキシや NGINX ユニットから NGINX コントローラーまで、すべての NGINX ソフトウェアで構成される NGINX サービス メッシュ ソリューションに自然に惹かれる可能性が高くなります。 NGINX とそのオープンソース エコシステムにおける既存の運用上の専門知識により、導入時の摩擦や遅延が軽減されます。
他の組織も、Istio や Envoy などの代替オープンソース ソリューションについて同様の見解を持っています。 Aspen Mesh はEnvoy を活用し、Istio 上に実装するため、基盤となるテクノロジーに既に投資している組織にはより自然に適合します。 これは、テスト済み、強化済み、パッケージ化済み、検証済みの Istio ディストリビューションです。 Aspen Mesh は、Aspen Mesh ダッシュボードによるよりシンプルなユーザー エクスペリエンス、ユーザーがビジネス目標を指定、測定、適用できるようにするポリシー フレームワーク、 Istio VetやTraffic Claim Enforcerなどのツールなど、Istio 上にいくつかの機能を追加します。 Aspen Mesh は、NGINX と同様に、F5 BIG-IP と適切に統合されます。
NGINX と Aspen Mesh はどちらも、Kubernetes クラスターの管理と視覚化を提供します。 Aspen Mesh と NGINX はどちらも、オンプレミス オプションとしてソリューションを提供しています。 どちらも、 Replex の State of Kubernetes レポートで 37% の組織が指摘した最大の生産上の課題である可視性の問題に対処するために重要なトレース機能とメトリックを提供します。
サービス メッシュに対してサイドカー プロキシ ベースのアプローチを好む組織は、Aspen Mesh を好むでしょう。 アプリごとのプロキシベースのサービス メッシュがニーズに最適であると考える組織は、NGINX を好むでしょう。
選択はさまざまな要因によって決まりますが、私たちはこの新たな領域が、さまざまなニーズと要件の組み合わせに対応する選択肢を継続的にサポートするほど重要であると考えています。