2020年のコンテナを理解する: クラウドネイティブの次の目的地を見つける

2020年は特別な年になる運命にあります。それはもやの中で始まり、驚きの中で終わり、将来をさらに混乱させるものとなった。では、2020 年のコンテナとクラウド ネイティブはどうなるのでしょうか?どのように始まったか覚えていますか?どこへ行くのでしょうか？

1. Kubernetes: エンタープライズ インフラストラクチャの標準抽象化

2020 年には、プラットフォーム チームが独自のインフラストラクチャとして Kubernetes を採用することの合理性に疑問を抱く人は誰もいないでしょう。実際、2020 年の Kubernetes プロジェクトは、プラットフォーム チームが「すべて」を構築できるプラットフォーム レベルの抽象化レイヤーをクラウド コンピューティング インフラストラクチャに導入するという最も重要なミッションの完了に非常に近づいています。

今日のクラウド ネイティブ コミュニティでは、Kubernetes プロジェクトが「プラットフォームのためのプラットフォーム」として位置付けられ、その価値が広く認識され始めていることがすでにわかります。ますます多くのプラットフォーム チームが、PaaS、サーバーレス、AI プラットフォーム、データベース PaaS など、Kubernetes をベースにしたさまざまな上位レベルのプラットフォームを構築しています。最終状態指向の宣言型 API とその背後にある高性能なコントローラーは、「インフラストラクチャ レイヤーの抽象化の構築」という難しい技術的問題に対して、複雑さと使いやすさのバランスをとったソリューションを提供します。これに基づいて、Kubernetes プロジェクトは巨大な統合エコシステムを持ち、この「エンタープライズ インフラストラクチャの標準的な抽象化」が徐々に業界で認められる事実になりました。

さらに重要なのは、Kubernetes の真の成功は、抽象化そのものではなく、抽象化を構築する方法に実際に賭けている点にあります。ほとんどの場合、企業が Kubernetes をベースに上位層プラットフォームを構築する際には、補足としてさまざまな他の抽象化を導入したり、Kubernetes に組み込まれている抽象化の一部を置き換えたり隠したりします。Alibaba のオープンソース CloneSet、Tencent の GameStatefulSet プラクティス、その他の拡張ワークロードは、この傾向の最も良い例です。

Kubernetesエコシステムの機能が最下層からアプリケーション層まで徐々に向上するにつれ、2020年にはより多くの大規模インターネット端末企業がクラウドネイティブ層に加わり始めました。 Mesos エコシステムの元々のベンチマークである Apple が KubeCon 2020 North America の絶対的な主役となり、金融大手の MasterCard が OAM、Kubernetes、Crossplane プロジェクトに基づくクロスクラウドおよびクロスランタイムのアプリケーション配信プラットフォームを構築する社内実装事例を共有したのを目にしました。特に注目すべきは、基盤となる基本技術に関して「保守的」な印象を与えていたこれらの大手非クラウド企業が、2020年に仮想クラスターや標準アプリケーションモデル技術など、多くの新興技術の実装と検討を開始したことです。クラウドネイティブの波がテクノロジー業界全体に与えた影響は計り知れません。

さらに、Kubernetes の大きな人気と、それに基づいて出現した上位レベルのエコシステムが、Android の開発パスとますます収束していることを観察することは難しくありません。 Android は、携帯電話、テレビ、さらには自動車などのさまざまなハードウェア デバイスを統一された方法で抽象化および統合し、統一された開発インターフェース セットをプログラマーに公開して、プログラマーがこの統一された抽象化セットを使用してこれらのインフラストラクチャ機能にアクセスしたり利用したりできるようにします。この位置付けは Kubernetes と非常に似ています。ここでの唯一の違いは、Android サービスのプログラマーは APP 開発者であるのに対し、Kubernetes サービスの「プログラマー」はプラットフォームビルダーであるということです。この文脈では、「Kubernetes が Docker を放棄」などのニュースは簡単に理解できます。Android 自体は、携帯電話のバッテリーのブランドに焦点を当てる必要はありません。

この道は、Google がより得意とする「戦略」である可能性もあります。つまり、全力で「オペレーティング システム」を無料で宣伝し、商業的価値を得るための本当の方法は、オペレーティング システム自体ではなく、オペレーティング システムの上位層の生態学的価値を「収穫」することです。結局のところ、ユーザーは Android を購入するためにお金を使うことはありません。そのため、Google Cloud は現在、Anthos などの Kubernetes ハイブリッド クラウド ベースを通じて、世界中のあらゆるデータ センターに Google Cloud サービスを提供することに全力を注いでいます。

2. クラウドコンピューティングの「3層アーキテクチャ」が崩壊しつつある

長い間、業界におけるクラウド コンピューティングの理解は、「SaaS + PaaS + IaaS」という古典的な 3 層アーキテクチャ モデルを中心に展開されてきました。しかし、2020 年にはクラウド ネイティブ テクノロジーが大きな人気を博し、このモデルは課題に直面しているようです。

今日のクラウドネイティブ テクノロジーは、Docker とコンテナーの革新的な技術革命から生まれ、従来の PaaS (Cloud Foundry など) の長年にわたる人気の恩恵を受けています。最終的に、開発者とプラットフォームビルダーの両方の注目により、Kubernetes エコシステムをキャリアとして実装されました。

2020 年、クラウドネイティブ技術が徐々に成熟するにつれ、ユーザー指向のアプリケーション管理プラットフォームの形態は、Cloud Foundry/Heroku をベースとした従来の PaaS 形式 (つまり、エンタープライズレベルの PaaS) から、Shipa や Kalm などの軽量なアプリ サービスへと徐々に移行し始めました。ただし、軽量 App Services は、本質的には Kubernetes ベースの Heroku エクスペリエンスのレプリカです。優れた開発者エクスペリエンスを提供する一方で、従来の PaaS の「クローズド」および「非スケーラブル」な特性も継承しています。これは、クラウドネイティブ テクノロジー スタックに基づいて独自の「PaaS」を「DIY」したいと考えている多くの大企業の能力を超えているようです。

実際、クラウドネイティブ技術の導入が進むにつれ、ますます多くのプラットフォームビルダーにとって、「PaaS」自体の「解釈権」はもはや特定のプロバイダーに属するものではなく、プラットフォームビルダーのビジネスシナリオとエンドユーザーの実際のニーズに依存するようになっています。また、「SaaS」についても、クラウドネイティブがもたらしたコンテナ化されたソフトウェアパッケージングおよび配信システムとKubernetesベースが、クラウドソフトウェアの配布および運用方法にも大きな変化をもたらしました。したがって、PaaS であれ SaaS であれ、本質的には「クラウド ネイティブ」技術の波によって急速に「平坦化」されつつあります。このような状況では、クラウド コンピューティング システムの従来の「水平」分割は、実際には一貫性を保つことが困難になっています。典型的な例としては、現在 Kubernetes を PaaS とも IaaS とも呼べないということです。これは、インフラストラクチャ機能アクセス層とプラットフォーム層の独自の抽象化です。プラットフォームビルダーとして、それに基づいて頭の中で任意の上位層プラットフォームを構築することができます。この上位層プラットフォームを PaaS、サーバーレス、FaaS、あるいは SaaS と呼ぶかどうかは、抽象化の度合いと、それが依存する垂直機能の違いにすぎません。ここでは、「誰が誰の上に構築するか」というような区分はありません。

3. 次世代クラウドネイティブプラットフォーム構築システムの台頭

Kubernetes の成功により、企業のコスト センターでこれまで忘れられていた重要な役割である「プラットフォーム ビルダー」が大きく実現可能になりました。実際、Kubernetes が Docker エコシステムに取って代わり、今日のクラウド コンピューティング プラットフォームの主役になれたのは、このグループが最終決定を下したからにほかなりません。そうでなければ、Docker が到達するユーザーベースの規模と開発者エコシステムにおけるその受け入れを考えると、Kubernetes が勝つ可能性はほとんどありません。この点は見落とされがちです。実際、エンタープライズレベルのプラットフォームを実装するプロセスでは、プラットフォームのエンドユーザー（ビジネスの研究開発や運用保守など）が「お客様であり神様」であるにもかかわらず、このプロセスで重要な役割を果たし、最終的な意思決定権を持つのは、多くの場合、プラットフォームチームとビジネスの背後にいる上司です。

しかし同時に、Kubernetes 上のプラットフォーム構築エコシステムは、現在でも高度に集中化されています。典型的な観察結果では、現在、Kubernetes をベースにした完全な上位層プラットフォームを体系的に構築できるチームは、実際には第 1 層および第 2 層の大手インターネット企業に集中しており、そのプラクティスは「参考用」であることが多く、再現できることはほとんどありません。さらに、クラウド ネイティブの大きな人気によって、プラットフォーム ビルダーが PaaS やその他の上位レベルのプラットフォームを簡単に構築できるようになるわけではないようです。これは、実は、先ほど述べたクラウドネイティブ時代における「PaaS エコシステム」の停滞をさらに説明しています。Kubernetes をベースにした上位レベルのプラットフォーム (PaaS を含む) の構築は、2020 年でも依然として大企業やハイテク チームの専売特許です。

このプラットフォームによって構築された高度に集中化されたエコシステムは、クラウド ネイティブが構築することを望んでいる「包括的な」未来とは明らかに矛盾しています。もちろん、技術開発がビジョンに追いついていないため、クラウド ネイティブ コミュニティは止まることはありません。

実際、プラットフォーム ビルダーが Kubernetes をベースにさらに上位層プラットフォームを構築しようとする根本的な動機は、次の 2 つの要求から生まれます。

• より高い抽象化の次元: たとえば、ユーザーは「コンテナ」や「ポッド」ではなく、「アプリケーション」や「カナリア リリース」の概念を使用して操作したいと考えています。
• より高いスケーラビリティ: たとえば、ユーザーが望むアプリケーションのグレースケール リリース戦略は、Kubernetes のデフォルトの Pod リニア ローリング アップグレードではなく、「デュアル デプロイメント + Istio」のカナリア リリースに基づいています。これらの機能強化または拡張機能は通常、CRD + コントローラー プラグインの形式で Kubernetes に実装されます。

したがって、Kubernetes をベースとした上位層プラットフォームの構築は、現時点では無秩序で不規則に思えるかもしれませんが、本質的には「抽象化 + プラグイン機能の管理」という 2 つの中核的な要求に重点が置かれることになります。別の例を挙げると、現在誰もが Kubernetes 用に構築しているさまざまなダッシュボードは、実際には「抽象化」を実装する方法です。これらのダッシュボードは基本的に、Kubernetes API オブジェクトに基づいてユーザーが入力できる一連のフィールドを公開し、「ユーザーの使用意識を簡素化し、ユーザー エクスペリエンスを向上させる」という目的を達成します。これはもちろん、すべての「抽象化」の基本的な目標です。

クラウド ネイティブ コミュニティは、「抽象化 + プラグイン機能管理」という 2 つの要求に対する継続的な実践と思考に基づいて、プラットフォーム チームが上位レベルのプラットフォームを構築できるようにすることに重点を置いた KubeVela などのオープン ソース プロジェクトを 2020 年に誕生させました。このプロジェクトの位置付けは、クラウド ネイティブ エコシステム全体の中で非常にユニークです。垂直的な機能ではなく、Kubernetes に基づいて上位層プラットフォームを構築するための「ツール」のセットのようなものです。

• テンプレートベースの抽象化メカニズム、およびこの生成機能に基づいてドキュメントと OpenAPI スキーマを使用するための自動化されたプロセス (これにより、プラットフォーム チームがダッシュボードや Appfile を迅速に構築できるようになります)。
• OAM モデルに基づくプラグイン機能の登録、管理、および検出メカニズムを使用すると、プラグイン機能をモジュール式かつ自動的に管理できるほか、プラグイン機能間の競合を早期に警告することもできます。

偶然にも、Alibaba Cloud が KubeVela プロジェクトをオープンソース化した直後、クラウドコンピューティングのリーダーである AWS も、Re:Invent 2020 で AWS Proton 商用製品の正式リリースを発表しました。そのコンセプトは KubeVela プロジェクトと非常に似ていますが、プラットフォーム構築の基盤が AWS クラウドプラットフォームに置き換えられ、抽象テンプレートの定義に AWS 独自の Cloud Formation が使用されている点が異なります (KubeVela は現在、Google のオープンソース CUELang テンプレート言語をサポートしています)。

クラウド ネイティブと Kubernetes プロジェクトによってインフラストラクチャ層の抽象化がほぼ統一され、標準化された後、プラットフォーム チームがその上にさらに上位層プラットフォームを迅速かつ容易に、再現可能に構築できるようにする方法が、業界が積極的に検討し始めている重要な道筋になりつつあることが予測されます。繰り返しになりますが、従来のクラウド コンピューティングの「3 層アーキテクチャ」では、これらの製品に適した場所を見つけるのは困難です。 KubeVela にしろ AWS Proton にしろ、これらは PaaS でも IaaS でもなく、Kubernetes の競合でもありません。これらは、クラウド ネイティブのコンテキストで徐々に台頭しつつある新世代のプラットフォーム構築システムの初期の形態です。

4. クラウドネイティブの次のステップを探る

2020 年、クラウド ネイティブは、クラウド コンピューティング エコシステム全体で最も急速に成長しているメインスレッドであると言えます。そして、この開発の勢いを受けて、クラウド ネイティブは新年に次の開発領域について考え始めました。実際、さまざまなメーカーやチームがさまざまな分野で積極的に活動し、探求しているのを見ることができました。

ローカル開発とテスト

開発者が Kubernetes をローカルで開発およびテストできるようにすることが話題になり始めており、この分野ではニューヨークの Tilt プロジェクトがリーダーの 1 つです。 Alibaba Cloud と Tencent Cloud にも、KT Connet や Nocalhost など、このトピックに関するさまざまな次元のソリューションがあります。

クラウドネイティブ「ミドルウェア」の技術的変化

Sidecar モデルは、ミドルウェア分野の機能を次世代アプリケーション インフラストラクチャである Kubernetes に急速に浸透させています。すでに急成長を遂げている Istio によるトラフィック管理分野の破壊的変化に加えて、Microsoft は Open Service Mesh をオープンソース化することでこれに応えました。同時に、Microsoft の OAM の姉妹プロジェクトである Dapr は、「サービス検出とバインディング」の面で Kubernetes とミドルウェア間のギャップを直接的に縮めており、古いプロジェクトである Dubbo も次世代のクラウドネイティブ ミドルウェアの技術的な青写真を発表しました。もちろん、これらすべての背後にあるユーザーの動機は非常に明確です。クラウド ネイティブ時代のミドルウェアは、言語やプラットフォームに依存しないものでなければなりません。

「エッジ」とKubernetesディストリビューション

Kubernetes の「Android 化」のトレンドは、世界中のあらゆるデータ センターに Kubernetes を展開するという「野心」と切り離せないものであり、もちろんこれには「エッジ」デバイスも含まれます。ファーウェイの主力製品であるKubeEdgeに加え、アリババクラウドのOpenYurtプロジェクトも2020年にCNCFサンドボックスインキュベーションに参加し、テンセントクラウドはそれに続くものとしてSuperEdgeを提案した。同時に、AWS は 2020 年に EKS サービスの背後にある Kubernetes ディストリビューションである EKS-D を大規模にオープンソース化しました。これはもちろん、Google Cloud の Anthos と Microsoft Cloud の Arc レイアウトに対する強力な対応を意味します。クラウドベンダーが「Kubernetesを隅々まで展開する」ことに固執することで、Kubernetesの「Android化」が予想以上に早く進み、ISVやサービスインテグレーター側の「大惨事」も必然的に起こると予測できます。

クラウドネイティブアプリケーション管理とGitOps

クラウドネイティブなアプリケーションの管理と配信は、「新しい Android」である Kubernetes の重要な価値の焦点になりつつあります。この分野では、Alibaba Cloud と Microsoft の OAM + OpenKruise の組み合わせがすでに成果を上げています。同時に、コミュニティでは、プラットフォーム ビルダーをさらに支援する KubeVela などのオープン ソース フレームワークも登場しています。開発者ツール分野のリーダーであるHashicorpも、Waypointなどのクロスプラットフォーム開発者インターフェースツールをタイムリーにリリースしています。 Kubernetes 上のアプリケーション層テクノロジーが急速に進化するにつれ、アプリケーション構成管理センターとしての Git に基づいてアプリケーションを配信するというコンセプト (GitOps) が、従来の CI/CD の CD リンクに急速に取って代わり、Kubernetes 上でのアプリケーション配布の唯一の選択肢になりつつあります。 2020年末、CNCFアプリケーション配信ドメイングループはGitOpsワーキンググループの結成を正式に発表しました。これにより、GitOpsは徐々にクラウドネイティブCDのデファクトスタンダードへと押し上げられると思われます。 Kubernetes の Android 化は止められないため、新年にはこの分野でさらなる破壊的変化と革新が起こることを期待しています。

5. 2020年：クラウドネイティブの「正確な定義」はない

「クラウド ネイティブ」とは具体的に何でしょうか?コンテナとKubernetesですか?仮想マシンはクラウドネイティブですか? …

こうした「自己分析的な質問」は、クラウド ネイティブの概念に不慣れな多くの企業やチームによって常に引き起こされる混乱の原因となってきました。実際、「クラウド コンピューティング テクノロジーを活用してコストを削減し、ユーザーの効率を高める」ための一連のベスト プラクティスと方法論として、クラウド ネイティブという用語は、誕生、成長、そして今日の大きな人気を得て以来、継続的な自己進化と革新の過程にあります。 「明確な定義がない」というこの永続的な活力こそが、「クラウド ネイティブ」がクラウド コンピューティング エコシステムにとって非常に魅力的である理由です。

2020年、クラウドネイティブコミュニティ全体のさまざまな分野での積極的な探求と実験は、KubernetesやService Meshなどの成熟した実装プロジェクトに取って代わり、徐々にクラウドネイティブエコシステムの独自のメインテーマになりつつあります。これは実際には理解するのが難しくありません。クラウド ネイティブは今日まで発展を続け、「ソフトウェアはクラウド上で生まれ、成長する」というビジョンにますます近づいています。しかし、既存のクラウド ネイティブ テクノロジ シャーシはインフラストラクチャの抽象化と管理に重点を置きすぎていて、エンド ユーザー エクスペリエンスやテクノロジによってもたらされる多くの問題を無視しているという事実も明らかになりました。これらの問題は、クラウドネイティブコミュニティ全体の絶え間ない思考、蓄積、再革新を通じて補完および修正する必要があり、クラウドネイティブの技術的価値が徐々に「浮上」し、エンドユーザーに直接的な価値と物理的な体験を生み出すことができます。そうして初めて、クラウド ネイティブ テクノロジーは徐々に「民主化」され、シンプルで使いやすいクラウド ネイティブ プラットフォームの構築は、もはや大企業が「腕前を誇示する」ための独占領域ではなくなります。