Thomas Graf は、 等価と呼ばれる人気のあるオープン ソース (およびクラウド ネイティブ) ネットワーキング テクノロジの作成者です。 繊毛. Cilium は、カーネル レベルの Linux テクノロジの上に構築されています。 eGMP.
このインタビューで、Graf は、成長するクラウドネイティブ ネットワーキング エコシステムで Cilium と eBPF が果たす役割と、Kubernetes の採用と進化に関するより広範なトレンドについて説明します。 彼は、大企業内で誰が Kubernetes を使用および購入しているのか、クラウド ネイティブ インフラストラクチャを改善する必要があるのか、標準化への欲求がイノベーションをどのように推進しているのかについて説明しています。
将来: eBPF と Cilium について、コンピューティングとネットワーキングのコンテキストで、一般的に、そして具体的には クラウド ネイティブ エコシステム?
トーマス・グラフ: 全体として、eBPF は技術であり、非常に低レベルです。 これはカーネル開発者向けに設計されたもので、私のバックグラウンドはカーネル開発です。 eBPF はカーネルにとって、オペレーティング システムにとっては、ブラウザにとっての JavaScript と同じものです。 JavaScript がブラウザーをプログラム可能にするのと同じように、オペレーティング システムをプログラム可能にします。 以前は、特定の Web サイトを実際に使用するには、ブラウザーのバージョンをアップグレードする必要がありました。 そして JavaScript が登場し、突然アプリケーション チームと開発者が大規模なアプリケーションを構築できるようになり、最も人気のあるワープロ アプリケーションがブラウザ内アプリケーションに取って代わられるまでになりました。 それが大きなイノベーションの波を引き起こしました。
オペレーティング システム レベルではありますが、eBPF でも同じことが起こっています。これは、カーネルまたはオペレーティング システム レベルで突然、すべてを確認し、すべてを制御できるようになるためです。これは、セキュリティにとって非常に重要です。カーネルを変更する必要はありません。ソースコード。 基本的にプログラムをカーネルにロードして、その機能を拡張し、新しい機能をもたらすことができます。 これはまた、大規模なイノベーションの波を解き放ちました。 Facebook、Google、Netflix などのハイパースケーラーは、独自のカーネル チームとともに、これを独自に直接使用しています。
Cilium がもたらしたのは、低レベルの eBPF テクノロジを使用して、特にクラウド ネイティブの波に対して、ソフトウェア インフラストラクチャの新しい波を本質的に提供することです。 これは、Software-Defined Networking のようなものであり、VMware NSX となった Nicira が仮想化業界にもたらしたものと考えてください。 クラウド プロバイダーまたはパブリック クラウド インフラストラクチャとオンプレミス インフラストラクチャが混在するクラウド ネイティブでも同じことを行っています。 また、ネットワーク、セキュリティ、可観測性のユースケースをインフラストラクチャ レイヤーで解決しています。
そして、リリースされたばかりの Cilium Service Mesh は、これらの機能の進化版ですか?
現在起こっていることは、約 XNUMX 年前から、XNUMX つの空間が衝突しているということです。 Cilium がこれまで行ってきたことは、ネットワーキング、仮想化ネットワーキング、そしてクラウド ネイティブ ネットワーキングに焦点を当ててきましたが、それでもネットワーキングです。 しかし、その後、トップダウンで、Twitter と Google のアプリケーション チームが取り組みました。 サービスメッシュ もの — 最初にアプリケーションで、次にサイドカー ベースのモデル、プロキシ ベースのモデルで、これはプロジェクトのようなものです イスティオ 配達。 そして今、これらの XNUMX つのレイヤーが近づいています。 従来型の企業がクラウド ネイティブの世界に参入しつつあり、エンタープライズ ネットワーキングの要件がありますが、アプリケーション チームもサービス メッシュを必要としています。.
Gartner はこの新しいレイヤーを「サービス接続」と呼んでいますが、この用語が流行るかどうかはわかりませんが、基本的には、エンタープライズ ネットワーキング部分と、アプリケーション チームから提供されるサービス メッシュ部分を含むレイヤーです。 それが顧客の要求であるため、Cilium 自体に機能を追加しました。 したがって、基本的に、Cilium は企業ネットワーク側から上向きになり、サービス メッシュは下向きになり、ネットワーク側のより多くの部分に入ります。
サービス メッシュ
ウィキペディアによると: サービス メッシュは、プロキシを使用して、サービスまたはマイクロサービス間のサービス間通信を促進するための専用インフラストラクチャ レイヤーです。 専用の通信レイヤーは、通信に可観測性を提供する、安全な接続を提供する、失敗した要求の再試行とバックオフを自動化するなど、多くの利点を提供できます。
Kubernetes スタックのネットワーキングとサービス メッシュ レベルにこれほど注目されているのはなぜですか?
複数のクラウドで実行し、アプリケーションをコンテナーに分割する必要があるため、接続レイヤーが中心になっています。 かつてはおそらくプロセス間通信やミドルウェアだったものがネットワークになっているため、ネットワークはアプリケーションが互いに通信し、データが流れるために絶対に不可欠になりつつあります。
特にクラウドネイティブでは マルチクラウドは絶対に不可欠になりつつあります. すべてのクラウド プロバイダーには独自のネットワーク レイヤーがありますが、もちろん、独自のクラウドに合わせて調整されています。 オンプレミスのサービスはありますが、真のマルチクラウドではありません。 Cilium と eBPF は、マルチクラウドにとらわれないレイヤーを提供します。 オンプレミスでも、パブリック クラウドとまったく同じように動作します。 いくつかのパブリック クラウド プロバイダーは、管理対象の Kubernetes 製品の内部で Cilium を使用しており、通信事業者はオンプレミスの 5G インフラストラクチャに Cilium を使用しています。 両方の言語を話し、これらの世界をつなぐことです。
クラウド プロバイダーが顧客を閉じ込める最も簡単な方法の XNUMX つは、その接続レイヤーを所有することだからです。 戦略的なインフラストラクチャの観点から、仮想化レイヤーが重要だったように、今では接続とネットワーク レイヤーが絶対的な重要性を持っていると思います。
[将来の] イノベーションの源はオープンソースであり、その需要を牽引する顧客とユーザーは、ハイパースケーラーよりも XNUMX レベル下の企業、つまり依然として非常に破壊的な大企業です。
現時点で Kubernetes はかなり広く受け入れられ、採用されていますが、一部のサークルではまだやり過ぎだという話があります。 Kubernetes とクラウド ネイティブ エコシステム全体は誰のためのものだと思いますか?
これは、最新のアプリケーション チーム向けです。 最新のアプリケーション チームを惹きつけ、市場投入までの時間を短縮するには、クラウド ネイティブ インフラストラクチャを提供する必要があるという認識が芽生えたと思います。 ラムダのようなサーバーレスで、プロトタイピング (初期、プレ MVP、さらにはコンセプトの証明や内部販売まで) をよく目にします。 次に Kubernetes で、アプリ チームがインフラストラクチャを直接所有できるためです。 そして、本番環境に移行すると、エンタープライズのオンプレミス Kubernetes ディストリビューションに移行します。 しかし、これは実際にはインフラストラクチャ全体の比較的小さな部分であり、おそらく XNUMX 桁または XNUMX 桁台前半の割合です。
しかし、それは明らかに新しい標準になるでしょう。 仮想化の採用が最初は非常に遅く、やり過ぎだと人々が言ったのと同じように、時間が経つにつれて、もちろん、ほとんどのものを置き換え始めました.ここでも同じことが見られます. または、現代言語と同じように。 人々は、Java はやり過ぎだと言いましたが、おそらく今でも多くのアプリケーションにとってそうです。しかし、Java 以外のアプリケーション開発を行うことが非常に困難になった時期がありました。それは、アプリケーション開発者の大多数が Java で記述できるためです。最新のアプリケーション チームに当てはまります。彼らは、より機敏に開発し、製品を迅速に市場に投入するために、Kubernetes が周りにあることを期待しています。
インフラストラクチャ側では、少しやり過ぎかもしれませんが、代替手段がアプリケーションをサーバーレスからオンプレミスに書き直すことである場合、それは大規模な作業です。 Kubernetes はその中間であり、非常に魅力的です。
Kubernetes には、より優れた開発者エクスペリエンスが必要であるという考えについてはどうでしょうか?
元の OpenShift を見ると、Kubernetes にリベースする前は、これでした。 アプリケーション チームとの距離がさらに近くなり、アプリケーション開発者のエクスペリエンスがさらに向上しました。 Git にプッシュすると、自動的にデプロイされます。 Heroku もこれを試しましたが、SaaS ベースです。
Kubernetes は一歩後退し、次のように述べています。 アプリケーションに合わせて調整するだけではいけません。」 これは妥協点です。アプリケーション チームにとって十分な魅力を備えている必要がありますが、特定の環境の外でそのアプリを実行し、アプリケーション開発者以外の人が管理できるようにする必要があります。
Docker と Kubernetes の間の最大のステップは、Docker がすべて開発者の経験であったということです。 その部分は解決しましたが、パブリック クラウド エコシステムの部分は解決していません。
どうやってここまでたどり着いたの？ これは、サービスとしてのプラットフォーム (PaaS) とアプリケーション コンテナーからの自然な進化でしたか?
それは Docker イメージと Docker のパッケージ化の側面でした。 古い学校は、仮想マシンにデプロイする方法であり、その周りにはあらゆる種類の自動化がありました. そして、Facebook が Tupperware で行っていたことがありました。これは非常にカスタムメイドで、非常に大規模なものでした。 その後、Docker が登場し、基本的にこのコンテナー イメージが提供され、誰もがそれをミニチュア VM のように扱うことができるようになりました。 アプリを配布できるようになり、600MB の仮想イメージではなく、10MB のコンテナーになりました。 しかし、同じように扱うことができます。必要なものはすべて揃っています。
これにより、アプリケーションをミニ VM のように扱うことができる Kubernetes のようなオーケストレーターを導入する能力が解き放たれましたが、さらに一歩進んで実際にそれらをマイクロサービスとして扱うこともできました。 両方を行うことができます。
Docker と Kubernetes の間の最大のステップは、Docker がすべて開発者の経験であったということです。 その部分は解決しましたが、パブリック クラウド エコシステムの部分は解決していません。 クラウド プロバイダーとの緊密な統合は行われていませんでしたし、必ずしも必要でもありませんでした。 それを解決したのがKubernetesです。
企業内で誰が Kubernetes を実行していると思いますか? 個々のアプリケーション チームですか?
クラウド ネイティブで起こった興味深い変化があります。それは、「プラットフォーム チーム」の台頭です。 彼らはアプリケーション エンジニアではありません。 彼らはネットワーク運用の知識が少しあり、セキュリティの知識もかなりあります。 彼らは SRE の知識があり、クラウドの自動化の方法を知っています。 アプリケーション チームにプラットフォームを提供し、それらのアプリケーション チームを顧客として扱っています。
プラットフォーム チームは、最新のアプリ チームを満足させる次世代インフラストラクチャを提供する任務を負っているため、Kubernetes と関連テクノロジーを購入します。
サーバーレス、特に非常に迅速なアプリケーション開発の余地は確実にあると思います。 しかし、エンタープライズでは、クラウド ネイティブは仮想化の上にある新しいレイヤーと見なされています。
それはまったく新しいバイヤーですか、それともまったく新しいチームですか? それとも、プラットフォーム チームは、Google や Facebook のような場所に存在し、現在主流になっているようなものですか?
ほとんどが新しいチームです。 彼らはある程度、Google や Facebook の SRE チームに似ていると思います。 ただし、アプリケーション チームは、おそらく企業でのアプリの展開の多くを所有しています。これは、企業では、Google や Facebook のようにソフトウェア エンジニアと SRE を明確に区別していないためです。 この進化は、あなたが仮想化チームを持っていた方法と非常に似ていると言えます。その後、多くのネットワーク運用がネットワークから移行された、または進化または進歩しました。 ハードウェア ネットワークについて 仮想化. たとえば、これらのチームは VMware NSX の運用を開始しました。 ここでも同じことが起こっています。
ただし、必ずしも新しい予算ではありません。 たとえば、クラウドへの支出が増加し、ネットワーク ハードウェアへの支出が減少するにつれて、予算がセキュリティとネットワーキングからこのプラットフォーム チームにシフトしています。 多くの場合、セキュリティ チームやネットワーク運用チームと協力して賛同を得ていますが、実際にはかなりの予算を所有しています。
どのように見えますか クラウドネイティブコンピューティング基盤 進化し、Kubernetes は常にその中心にあるのでしょうか?それとも、クラウド ネイティブ化の動き全体の中心にあるのでしょうか?
Kubernetes は CNCF の発端であり、最初の XNUMX 年間は Kubernetes とパブリック クラウドがすべてでした。 約 XNUMX 年前から私たちが見てきたことは、もはや Kubernetes だけではなく、実際にはクラウド ネイティブに関するものになっているということです。 原則. これは実際には、必ずしもクラウドではなく、プライベート クラウドでさえないことを意味します。 多くの場合、従来のエンタープライズ ネットワーキング、退屈なオンプレミス インフラストラクチャ、ベアメタル サーバーなどでさえありますが、クラウド ネイティブの原則が組み込まれています。
新しい標準は現在ハイブリッドであり、複数のパブリック クラウド プロバイダーとオンプレミス インフラストラクチャが含まれています。 企業は、同じアプリケーション開発者の俊敏性を提供したり、最新のクラウド ネイティブ ツールで可観測性を提供したり、最新のクラウド ネイティブ ツールでセキュリティを実現したりしたいと考えています。既存のインフラストラクチャ。
古い世界に接続し、MPLS、VLAN、sFlow、および NetFlow と通信するという非常に強い需要が見られます。これは、既存のエンタープライズ要件のセット全体です。 それらのどれも消えていません。
それから約 XNUMX 年が経過しましたが、クラウド ネイティブ空間は一時的な流行ではないようです。 進化し続ける余地はどれくらいありますか？
「ああ、Kubernetes はおそらく短命であり、サーバーレスが次のレイヤーになるだろう」というような時期が確かにありました。 または、「Kubernetes は OpenStack に似ています。 とか、「消えて実装明細になる」とか。 そして、それは起こっていません。
サーバーレス、特に非常に迅速なアプリケーション開発の余地は確実にあると思います。 しかし、企業では、クラウド ネイティブを仮想化の上にある新しいレイヤーと見なしており、仮想化と同様の有効期間があると考えています。 これは、クラウド ネイティブへの移行のまさに始まりにいることを意味します。
インフラストラクチャ レベルでまだ解決しなければならない大きな問題は何ですか?
企業は、望むと望まざるとにかかわらず、マルチクラウド戦略が突然必要になる状況に陥っています。 オンプレミスのインフラストラクチャも備えているため、その上にハイブリッド クラウド戦略が必要になっています。 また、特定のパブリック クラウドに縛られることなく、このインフラストラクチャ全体でセキュリティやその他の機能を普遍的に実行する方法を理解する必要があります。
したがって、これが次の大きな課題です。VMware のように、マルチクラウドとクラウド ネイティブの不可知論者になるのは誰でしょうか? クラウド ネイティブの VMware になるのは誰ですか?
最新のアプリケーション チームを惹きつけ、市場投入までの時間を短縮するには、クラウド ネイティブ インフラストラクチャを提供する必要があるという認識が芽生えたと思います。
また、クラウド ネイティブの採用は、アーリー アダプターであった現代の Web 企業にとって比較的簡単だったかもしれませんが、あなたの観点からの課題は、この現代の世界と既存のエンタープライズ ツールおよびシステムとの間のギャップを埋める新しいテクノロジーを構築することですか?
難しいのは、最新のアプリ チームがインフラストラクチャ レイヤーを自分たちと同じくらい速く進化させることに慣れていることです。 そしてこれにより、インフラストラクチャ レイヤーがさらにプログラム可能になり、調整可能になりました。 そのため、クラウド ネットワーキング レイヤーの上にネットワーキング レイヤーとセキュリティ レイヤーが実際に表示されます。 しかし、現在は企業が参入してきており、依然として古い世界に接続し、MPLS、VLAN、sFlow、および NetFlow と通信するという非常に強い需要が見られます。これは、既存の一連の企業要件全体です。 コンプライアンス ルールはすべて同じままです。 と 現代の SaaS 企業の一部でさえ、規模が大きくなり、コンプライアンスを重視するにつれて、これらの課題に直面しています。 などがあります。
テクノロジーの観点からは、新しいクラウド ネイティブの世界を既存のエンタープライズ要件に接続する方法についてです。 これらの問題の多くは、パブリック クラウド プロバイダーによって隠蔽されていたためです。 パブリック クラウド プロバイダーはコンプライアンスの問題を解決しましたが、オープン ソース化も公開もしていませんでした。 彼らはそれを自分たちで解決しました。 これはクラウドの価値の一部です。 企業は、パブリック クラウド サービスに縛られたくない場合は、それを再構築して購入する必要があります。
クラウド ネイティブ イノベーションの次の波はどこから来ると思いますか? それはまだ Google のような会社から来ているのでしょうか、それとも新しいタイプの会社が主導権を握っているのでしょうか?
とても興味深いです。 それはおそらく Google や Facebook から来たものではないと思います。 イノベーションの源はオープンソースであり、需要を牽引する顧客とユーザーは、ハイパースケーラーよりも XNUMX レベル下の企業になります。Adobe、Shopify、GitHub のように、まだ大きな破壊力を持っている大企業です。 しかし、金融サービス、保険会社、通信会社など、テクノロジーによって破壊されるリスクにさらされている企業も同様です。 これらの企業はすべて、反復可能な開発およびインフラストラクチャ モデルを使用してインフラストラクチャを標準化することに共通の関心を持っています。
26年2022月XNUMX日に投稿
テクノロジー、イノベーション、そして未来。
ご登録いただきありがとうございます。
受信トレイでウェルカムノートを確認してください。
「投稿」（記事、ポッドキャスト、ビデオ、ソーシャルメディアを含む）で表現された見解は、そこに引用された個人の見解であり、必ずしもAH Capital Management、LLC（「a16z」）またはその関連会社の見解ではありません。 ここに含まれる特定の情報は、a16zが管理するファンドのポートフォリオ企業を含むサードパーティの情報源から入手したものです。 a16zは、信頼できると思われる情報源から取得したものですが、そのような情報を独自に検証しておらず、情報の永続的な正確性や特定の状況に対するその適切性について表明していません。
このコンテンツは情報提供のみを目的として提供されており、法律、ビジネス、投資、または税務に関するアドバイスとして信頼されるべきではありません。 これらの問題については、ご自身のアドバイザーにご相談ください。 証券またはデジタル資産への言及は、説明のみを目的としたものであり、投資の推奨または投資顧問サービスの提供を構成するものではありません。 さらに、このコンテンツは、投資家または将来の投資家による使用を目的としたものではなく、a16zが管理するファンドへの投資を決定する際にいかなる状況においても信頼されない場合があります。 （a16zファンドへの投資の申し出は、私募覚書、サブスクリプション契約、およびそのようなファンドの他の関連文書によってのみ行われ、その全体を読む必要があります。）言及、参照、または記載されているのは、a16zが管理する車両へのすべての投資を代表するものではなく、投資が有益である、または将来行われる他の投資が同様の特性または結果をもたらすという保証はありません。 アンドリーセンホロウィッツが管理するファンドが行った投資のリスト（発行者がa16zに公開を許可していない投資、および公開されているデジタル資産への未発表の投資を除く）は、次のURLで入手できます。 https://a16z.com/investments/.
内部に提供されているチャートおよびグラフは、情報提供のみを目的としており、投資決定を行う際に依存すべきではありません。 過去のパフォーマンスは将来の結果を示すものではありません。 コンテンツは、示されている日付の時点でのみ話します。 これらの資料に記載されている予測、見積もり、予測、目標、見通し、および/または意見は、予告なしに変更される場合があり、他の人が表明する意見と異なる場合や、反対する場合があります。 参照してください https://a16z.com/disclosures 追加の重要な情報。
