Kubernetes は自身の複雑さに圧倒されてしまうのでしょうか?

Kubernetes はアプリケーション開発者にとって複雑すぎるのでしょうか?

数週間前、私は KubeCon EU に出席し、講演を行いました。約 4,700 人が参加する大規模なイベントで、2014 年 11 月にパリで開催された OpenStack Summit を思い出しました。大勢の人が集まり、ベンダーも集まり、プログラマーたちがパーティーを開いていました... しかし、根本的な問題が分かりました。私が会った人のほとんどが、運用・保守担当者や SRE エンジニアだったのです。アプリケーション開発者はどこにいるのでしょうか?この複雑なインフラストラクチャは、本来これらの人々のために役立つはずではないでしょうか? Kubernetes コミュニティは本当にユーザーのニーズに注意を払っているのでしょうか?そこで私は思わずこう思いました。Kubernetes は複雑すぎるのだろうか?その複雑さが障害になっているのでしょうか?

このように考えるのは少しやりすぎのように思えるかもしれませんが、結局はそうはならないと思います。 OpenStack と比較すると、Kubernetes には独自の利点があります。まず、スケーラビリティが高く、数千台のサーバーがある環境で大規模なクラスター スケジューリングを実現できます。 2 つ目は、3 大クラウドベンダーがマネージド Kubernetes サービスの提供を開始したことです。 Kubernetes はわずか 4 年で、クラウド コンピューティングとインフラストラクチャの分野でほぼ事実上の標準になりました。しかし、Kubernetes の複雑さは依然としてすべての人にとって問題です。 OpenStack は 2014 年以降衰退しています。Kubernetes も OpenStack の足跡をたどるのでしょうか?

[[238474]]

ほとんどの開発者はGoogleのような規模の問題を抱えていない

Kubernetes は、Google のような規模の複雑さと問題に対処するために開始されました。私たちは、インフラストラクチャが自己修復可能で、水平方向にスケーラブルで、宣言的に構成可能であること（つまり、コードとしてのインフラストラクチャ）を望んでいます。しかし、実際のところ、大多数のアプリやアプリ開発者はこれらの問題に直面していません。ほとんどのアプリケーションは、プロジェクト規模とユーザー ベースの両方の点で中程度の規模であるか、市場製品調査の初期段階にあります。

通常、アプリケーションが大規模になるまで、このような複雑さを追加する必要はありません。この場合、トラフィック負荷を処理できる限り、単一のデータベース サーバーとアプリケーション サーバーの方が適している可能性があります。 99.5% の時間利用可能であり、完全な運用アラートがある場合は、ほとんどのアプリケーションとワークロードに適しています。分散システムの構築の複雑さと、それによって生じる市場投入までの時間の遅延により、得られる利益は価値を上回るものとなるでしょう。

まったく新しいアプリケーションにとって最大のリスクは、ターゲット製品または市場が見つからないことです。つまり、これらのアプリケーションは導入されたものの、一度も使用されなかったのです。誰もアプリケーションを使いたがらなかったため、最終的にコードは放棄されました。これは、ほとんどのアプリケーション コードが直面する可能性のある状況です。私のキャリアのほとんどは、コードと機能を繰り返し検討し、アプリケーションに適した機能セットを見つけることに費やされてきました。一度見つかれば、それを拡張することはできますが、それ以前の努力は、時期尚早な最適化に過ぎません。

Kubernetes の問題点は、プロジェクトの初期段階で認知負荷が高くなる点にあると思います。最初に考慮すべきことが非常に多いため、プロジェクトを開始して迅速に反復する上で障害となる可能性があります。プロジェクトの初期段階では、機能開発速度と反復速度が最も重要です。 Heroku は理想的な開発モデルだと思います。 Postgres を使用すると、あまり多くのことを考えなくても、データベースをホストし、新しいコードをデプロイし、Git プッシュを通じて外部にサービスを提供することができます。完璧に拡張できない可能性があり、コストがかかる可能性がありますが、アプリケーションが拡張されるまではこれらの問題についてまったく心配する必要はありません。

簡単に言えば、Kubernetes は単純なものを複雑にし、複雑な問題を解決できるようにします。 Kubernetes が本当に成功するには、プロジェクトの初期段階を簡素化し、アプリケーション開発者の認知負荷を軽減する必要があります。規模が大きくなるにつれてすべてが複雑で扱いにくくなるため、開発者がいつかは Kubernetes の複雑な部分を学び始めても問題ありません。しかし、成功する開発プラットフォームとして、これらの決定は必要がない限り開発者に委ねられるべきではありません。 Ruby on Rails の父、David Heinemeier Hansson (コードネーム DHH) は、RailsConf 2018 基調講演でこの状況を「JIT 学習」と呼びました。

Rails を例に挙げてみたいと思います。当時、Rails がなぜそれほど成功したのでしょうか?それは、Ruby（当時は日本発の新しいプログラミング言語でした）の人気や、Rails と Ruby が動的な Web ページの作成に優れていたからではなく、開発者の生産性を向上させることができたからです。 DHH は、15 分でブログを作成する方法を全員に示し、同じものを作成するのに数週間、あるいは数か月かかる Java および .NET 開発者の注目を集めました。開発者が Rails を選択するのは、これらのフレームワークとインフラストラクチャによってユーザーに機能をより早くリリースできるためです。

Rails は開発者向けのアプリケーション スケルトンを作成し、スキャフォールディングといくつかのプロジェクト コードを生成します。開発者は、アプリケーション コードをどのように編成するか、データベース モデルをどこに配置するか、どのアセット パイプラインを定義するか、データベースの移行をどのように実行するか、その他のタスクや決定を完了する方法など、プロジェクトの開始時に多くの決定を行う必要はありません。

Kubernetes もこのタイプのジェネレーターから恩恵を受けることができると思います。特定のリソース ジェネレーターはいくつか存在しますが、需要を満たすには到底足りません。さまざまな種類のアプリケーション用のテンプレートがあればさらに良いでしょう。リレーショナル データベース、アプリケーション層、キャッシュ サーバー、メッセージ キュー、ワーカー スレッド プールの組み合わせは、アプリケーション構築の 90% 以上を占め、このシンプルな構造は信じられないほどのレベルの複雑さにまで拡張できます。すぐに使用でき、Kubernetes 組織構造を持つリソースとコードを生成できるテンプレートまたはジェネレーターは非常に便利です。

良い例としては、共通要素を生成するスキャフォールディング ジェネレーターが挙げられます。 MySQL データベースが必要ですか?次のようなコマンドを使うことができます

kubectl スキャフォールド mysql --generate  

ステートフル サービスとその他の必要なもののセットを作成します。次に、1 つのコマンドだけでスキャフォールディングを k8s 環境にデプロイし、さらにいくつかのコンソール コマンドを実行すると、本番環境に対応したデータベースが作成されます。同様のアプローチは、一般的なアプリケーション フレームワーク、メッセージ ブローカー、その他考えられるあらゆるものに使用できます。

Operator と Helm の組み合わせでこれらのことを実現できるかもしれませんが、十分ではないと思います。 Kubernetes 以外にも、開発者が知っておく必要があるツールが 2 つあるからです。簡単な技術用語を理解し、新しいコマンドライン ツールをインストールするだけでも、余分な労力と思考が必要です。これらは Kubernetes のすぐに使用できるエクスペリエンスの一部であり、kubectl を通じて直接アクセスできる必要があります。

CNCFの領域は拡大している

CNCF にはますます多くのプロジェクトがありますが、これは Kubernetes に特有の問題ではありません。しかし、CNCF プロジェクトの規模が非常に大きいため、KubeCon/CNCF カンファレンスは非常に分散しており、1 つのカンファレンスで 14 のトピックがカバーされています。開発者として、自分のプロジェクトに適したツールをどうやって知ればよいのでしょうか? CNCF のプロジェクトをご覧ください:

図中のすべての項目を理解することは不可能です。事前に選択されたツールセットがすでに存在していれば、アプリケーション開発者のエクスペリエンスははるかに向上します。別のツールを追加したいのであれば、それはまったく問題ありませんが、少なくともこれらの問題について事前に考える必要はないはずです。 CNCF の複雑さと範囲の拡大が進むにつれ、基盤となるプラットフォームとしての Kubernetes のブランドが薄れる恐れがあります。どうなるかはわかりませんし、誇張しているかどうかもわかりませんが、私にはツールの寄せ集めのように見えます。インフラストラクチャ ツールの学習と構築に人生を費やしているのに、ユーザーの問題を解決するエネルギーはまだ残っていますか?

私が強調したいのは、インフラストラクチャはアプリケーション開発者がユーザーの実際の問題を解決するために存在し、配信の効率と機能を向上させるために継続的に最適化する必要があるということです。これを実現できるオープン プラットフォームが勝利するでしょう。

必要な知識

ある時点で、開発者はインフラストラクチャ ツールをより深く学習する必要があります。 Google Cloud Platform や Azure の開発者がそれぞれのクラウドに精通しているのと同様に、AWS で作業する開発者のほとんどは AWS のいくつかのコンポーネントに精通しています。 Kubernetes をベースレイヤーとして使用すると、開発者は Kubernetes を学習するだけで、任意のパブリック クラウドまたはプライベート クラウドで使用できるため、成功する可能性が高くなります。

ただし、Kubernetes の学習曲線はスムーズではありません。エコシステムとして、Kubernetes が真に成功するには、アプリケーション開発者のニーズを満たす必要があります。結局のところ、インフラストラクチャはユーザーの問題を解決するためのサポートツールです。アプリケーション開発者の生産性を向上させることが、プラットフォームの広範な採用と成功を確実にする最善の方法です。