2021年のクラウドネイティブトレンドの予測

[編集者注] この記事の著者は、クラウド ネイティブ エンジニアとしての利点を活かして、クラウド ネイティブ IDE、エッジサイド Kubernetes、クラウド ネイティブ + Wasm、FinOps の台頭、クラウド ネイティブでの Rust の登場、GitOps + CD/PD の大幅な増加、サービス カタログ 2.0: クラウド ネイティブ開発者ダッシュボード、クロスクラウド、主流の eBPF など、2021 年以降のクラウド ネイティブ開発のトレンドに関する見解を共有します。

2021年1月の最初の数週間は、反乱からCOVID-19まで、かなり忙しかったので、皆さんが素晴らしいホリデーシーズンを過ごされたことを願っています。クラウド ネイティブ分野では、CNCF が最近、昨年達成したすべての作業を網羅した年次レポートを発表しました。機会があれば、皆さんにこのレポートをご覧になることをお勧めします。パンデミックを考慮すると、今年はかなり生産的な一年だったと言えます。

[[379818]]

私の仕事の一環として、私は一緒に仕事をしている企業や開発者に対して独自の視点を持っているので、2021 年以降のクラウド ネイティブのトレンドについての考えを共有したいと思いました。

クラウドネイティブIDE

Eclipse Foundation で開発者ツールの開発にかなりの時間を費やしてきた者として、私は最新の技術の進歩に非常に興奮しています。将来の開発ライフサイクル (コード、ビルド、デバッグ) は、ローカルの Emacs や VSCode のセットアップではなく、主にクラウド上で行われるようになります。最終的には、各プル リクエストに対して完全な開発環境がセットアップされ、事前構成されて独自のデプロイメントに接続されるため、ニーズに合わせて開発およびデバッグできるようになります。このテクノロジーの具体的な例は、GitHub Codespaces と GitPod を通じて実現されます。 GitHub の Codespaces はまだベータ版ですが、Prometheus と同様に GitPod を使用して体験することができます。 1 分ほどで、エディターとプレビュー環境を備えた完全にライブの開発環境が完成します。この開発環境 (ワークスペース) はコードで記述されており、他のコード成果物と同様にチーム内の他の開発者と共有できます。

最後に、今後 1 年間でクラウド ネイティブ IDE 分野で驚くべきイノベーションが見られることを期待しています。特に、GitHub Codespaces がベータ版に移行し、より広く利用できるようになると、開発者がこの新しいコンセプトを体験して気に入るようになるでしょう。

エッジにおけるKubernetes

Kubernetes は大規模なデータセンターでの使用から生まれましたが、Linux が新しい環境で進化してきたのと同じように、Kubernetes も進化し続けるでしょう。 Linux の場合、エンド ユーザーはカーネルを拡張して、モバイル展開、組み込み展開など、さまざまな新しい展開シナリオをサポートしています。私は、Kubernetes も同様の進化を遂げると確信しています。すでに、通信事業者 (およびスタートアップ企業) が VNF をクラウド ネイティブ ネットワーク機能 (CNF) に変換し、k3s、KubeEdge、k0s、LFEdge、Eclipse ioFog などのオープン ソース プロジェクトを通じて、エッジ プラットフォームとして Kubernetes を検討しています。通信事業者とエッジ向けのハイパースケール クラウド サポートを推進する力と、クラウド ネイティブ ソフトウェアを再利用し、すでに大規模なエコシステム上に構築する能力が組み合わさることで、Kubernetes は今後数年間でエッジ コンピューティングの主要なプラットフォームとしての地位を固めるでしょう。

クラウドネイティブ + Wasm

Web Assembly (Wasm) はまだ新しい技術ですが、特に WASI が成熟し、Kubernetes が前述のようにエッジ オーケストレーターとしてより多く使用されるようになると、クラウド ネイティブ エコシステムで成長するユーティリティおよびワークロードになると予想されます。 1 つの使用例は、Envoy がフィルターと LuaJIT で行っているような拡張メカニズムをサポートすることです。 Lua を直接扱う代わりに、複数のプログラミング言語をサポートする、より小さく最適化されたランタイムを使用できます。 Envoy プロジェクトは現在 Wasm を採用する過程にあり、スクリプト言語が一般的な拡張メカニズムであり、将来的には Wasm に完全に置き換えられるあらゆる環境で同様のパターンが採用されると予想しています。

Kubernetes の分野では、Microsoft の Krustlet のように、Kubernetes で wasi ベースのランタイムをサポートする方法を検討しているプロジェクトがあります。 Kubernetes は CRD やその他のメカニズムを通じて拡張され、VM (KubeVirt) などのさまざまな種類のワークロードを実行できるため、これは驚くべきことではありません。

また、Wasm を初めて使用する場合は、Linux Foundation の新しい入門コースと優れたドキュメントをお勧めします。

FinOps (CFM) の台頭

コロナウイルスの流行により、クラウドネイティブへの移行が加速しました。少なくとも半数の企業が、この危機の間にクラウド コンピューティング計画を加速させており、回答者の約 60% が、COVID-19 パンデミックによりクラウドの使用量が以前の計画を上回ると回答しています (2020 年のクラウドの現状レポート)。さらに、クラウド財務管理 (FinOps) は多くの企業にとって大きな懸念事項となっており、過去 6 か月間にクラウド ネイティブの取り組みを進めている企業と行った話し合いの半分で取り上げられました。クラウド プロバイダーは、顧客のコストが削減されるため、クラウド財務管理を簡素化することに消極的であると主張することもできますが、私の意見では、クラウド財務管理に関する本当の問題は、オープン ソースのイノベーションと標準化の欠如です (各企業がクラウド コスト管理をそれぞれ異なる方法で実行しています)。 CNCF 環境では、FinOps を容易にしようとするオープン ソース プロジェクトはそれほど多くありません。 KubeCost プロジェクトはありますが、まだかなり初期段階にあります。

さらに、Linux Foundation は最近、この分野での革新を支援するために「FinOps Foundation」を立ち上げており、この分野での優れた入門資料もいくつか用意しています。今後数年間で、FinOps 分野でさらに多くのオープンソース プロジェクトと仕様が登場すると予想しています。

クラウド上のRustの増加

Rust はまだ若いプログラミング言語です。特に Redmonk のプログラミング言語ランキングを例に挙げると、そのことがわかります。しかし、microVM Firecracker などの興味深いインフラストラクチャ プロジェクトで Rust を活用した CNCF プロジェクトがすでにいくつか登場しているため、今後 1 年間でより多くのクラウド ネイティブ プロジェクトで Rust が見られるようになると私は感じています。現在、CNCF プロジェクトの大部分は Golang で書かれていますが、Rust コミュニティが成熟するにつれて、数年後には Rust ベースのプロジェクトが Go ベースのプロジェクトに匹敵するものになると期待しています。

GitOps + CD/PDが大幅に増加

GitOps は、アプリケーションの展開、管理、監視を統合するための一連のベスト プラクティスを提供する、クラウド ネイティブ テクノロジーの運用モデルです (元々は Weaveworks の Alexis Richardson によって考案されました)。 GitOps の最も重要な側面は、Git でバージョン管理された望ましいシステム状態を宣言的に記述することです。これにより、基本的に、複雑なシステム変更セットを正しく適用し、検証することができます (Git やその他のツールによって有効化される優れた監査ログを介して)。実用的な観点から見ると、GitOps は開発者のエクスペリエンスを向上させ、Argo、GitLab、Flux などのプロジェクトの成長に伴い、今年は GitOps ツールが企業にさらに普及すると予想されます。 GitLab のデータを見ると、GitOps はまだほとんどの企業が検討していない新興のプラクティスであることがわかりますが、より多くの企業が大規模にクラウドネイティブ ソフトウェアを導入し始めると、GitOps も自然に追随すると思います。この分野についてさらに詳しく知りたい場合は、CNCF 内で新しく結成された GitOps ワーキング グループを確認することをお勧めします。

サービスカタログ 2.0: クラウドネイティブ開発者ダッシュボード

サービス カタログの概念は新しいものではなく、ITIL 時代に育った私たち年配者にとっては、CMDB (あの恐ろしいもの) のようなものを覚えているかもしれません。しかし、マイクロサービスとクラウドネイティブ開発の台頭により、サービスを文書化し、さまざまなリアルタイム サービス メタデータをインデックス化する機能は、開発者の自動化を推進する上で重要になっています。これには、サービス カタログを使用して所有権を理解したり、インシデント管理を処理したり、SLO を管理したりすることが含まれます。

将来的には、サービス カタログだけでなく、さまざまな自動化機能を通じてダッシュボードを 1 か所で拡張できる機能も提供する開発者ダッシュボードへのトレンドが見られるでしょう。最も古典的なオープンソースの例は Lyft の Backstage と Clutch ですが、比較的最新のオンプレミス クラウド展開を行っている企業であれば、プラットフォーム インフラストラクチャ チームが同様のものを構築しようとしている傾向があります。オープンソース開発者ダッシュボードが大規模なプラグイン エコシステムで成熟するにつれて、あらゆるプラットフォーム エンジニアリング チームによるダッシュボードの採用が加速するでしょう。

クロスクラウドがより現実的に

Kubernetes とクラウドネイティブの動きにより、クラウドネイティブおよびマルチクラウドのアプローチが本番環境で可能であることが証明されており、データでは「企業の 93% が Microsoft Azure、Amazon Web Services、Google Cloud などの複数のベンダーを使用する戦略を採用している」ことが明確に示されています (2020 年のクラウドの現状レポート)。クラウド市場が年々成熟するにつれて、Kubernetes によってプログラム可能なクロスクラウド管理サービスが実現することが期待されています。このアプローチの具体的な例は、Kubernetes API の拡張性を活用してクロスクラウド ワークロード管理をサポートするオープンソースのクロスクラウド コントロール プレーンを提供する Crossplane プロジェクトに体現されています (「GitLab がクロスクラウド コントロール プレーンを展開してマルチクラウド展開を提供する」を参照)。

主流のeBPF

eBPF を使用すると、カーネル コードを変更したりモジュールをロードしたりせずに、Linux カーネルでプログラムを実行できます。これはサンドボックス拡張メカニズムと考えることができます。 eBPF を使用すると、新世代のソフトウェアで Linux カーネルの動作を拡張し、ネットワーク、監視、セキュリティの向上など、さまざまなことをサポートできるようになります。歴史的に、eBPF の欠点は、それを活用するには最新のカーネル バージョンが必要であり、長い間、多くの企業にとって現実的な選択肢ではなかったことです。しかし、状況は変化しており、RHEL の新しいバージョンでもようやく eBPF がサポートされるようになったため、より多くのプロジェクトがその恩恵を受けるようになるでしょう。 Sysdig の最新のコンテナ レポートを見ると、最近 Falco の使用が増加していることがわかります。このレポートは Sysdig に少し偏っているかもしれませんが、実稼働環境での使用状況に反映されています。今後も eBPF ベースのプロジェクトにご注目ください。