ソフトウェアの宿命、最終的には死である（The inevitable trajectory of software is death.）
編訳：ワン・チーロン（王啓隆）
提供：AIテクノロジーベースキャンプ（ID：rgznai100）
K8s（Kubernetes）の初期MVPは、作成に丸一週間もかかりませんでした。
数人、数台のマシン、非常に粗いデモ：コンテナを配布でき、基本的な負荷分散を行い、プロセスが落ちたら自動的に再起動し、アップグレード時にv1からv2に切り替わる。今の基準から見れば、こんなスタートはかなり見窄らしいものです。後のクラウドネイティブの情勢を変え、事実上クラウドコンピューティングの言語体系全体を作り変えた「Kubernetes」と結びつけるのは難しいです。
しかし、この歴史で最も振り返るべき価値があるのは、Kubernetesが後にどのように事実上の標準になったかではなく、最初にそれが「なぜ作られなければならなかったのか、しかもオープンソースでなければならなかったのか」という点にあります。
今日、Brendan Burns（Kubernetesの共同創設者、その後Heptioを共同設立、現在はMicrosoft AzureでTechnical Fellow / CVPを務める）の最新インタビューで最も興味深いのは、彼がKubernetesの成功史を繰り返したことではなく、多くの人がすでに歴史的な事実として受け入れている事象を、まだ結論が出ていないあの時点に引き戻したことです。
- Kubernetes当初はたった数日で作られたデモでしたが、Brendan Burnsはすでに「このようなものは永遠に単一のクラウドベンダーのものにはなり得ない」と気づいていました。
- GoogleがKubernetesをオープンソースにしたのは、理想主義ではなく、最も現実的な判断のためです：あなたがやらなければ、誰かがやります。あなたはそれを定義する機会を失うことになります。
- Kubernetesは後にクラウドネイティブのエコシステムを統一しましたが、Brendanの見方では、振り返る価値があるのはその台頭ではなく、いつか退場するという事実です。
- 真に成熟したインフラストラクチャは、突然死ぬのではなく、「Linuxのように生きているが、単独では議論されなくなっていく」ものです。
- AI時代に最も起こりやすいのは、Kubernetesが正面から撃破されることではなく、より深い層に埋め込まれ、デフォルトで存在するが、もはや見えないシステムの土台になることです。
以下がこの対談の全訳です。
GoogleはなぜKubernetesをやらなければならなかったのか？
Q：当時、Googleの経営陣に「なぜ業界全体のためにKubernetesを作るのか」と説明するとして、どう説明しますか？
Brendan Burns：実は初期の最も難しい部分は、プロジェクトを作ることではなく、そのことを明確に伝えることでした。
私たち自身の頭の中では、このことは明確でしたが、それを人を説得するのに十分な説得力を持たせ、他人にも同意してもらうように伝えるのは容易ではありませんでした。私たちは当時、いくつかの角度から話しました。
非常に重要な背景は、「MapReduceの教訓」です。当時、Hadoopやいわゆるビッグデータ革命が熱くなっていました。Googleは最初のMapReduceの白書を書きましたが、後に業界で広く採用されたのは、Hadoopというオープンソース実装でした。Googleは最初のアイデアを出しましたが、エコシステムはGoogleを中心に回りませんでした。他人はあなたの論文を読み、似ているが完全に同じではないシステムを作り、最後に実際に稼働し、大規模に使用されたのは、あなたのものではありませんでした。
したがって、当時の中核的な判断は次の通りでした。「もしGoogleが白書を出し続けるだけで、他人が実際に実行、展開、使用できるシステムを作らなければ、技術進化の運転席に立つことはできない」ということです。
さらに掘り下げると、なぜコンテナなのか、ではなく、なぜ仮想機械（VM）を中心にし続けなかったのか、という点があります。私たちの判断は、「ソフトウェアがますます重要なインフラストラクチャになるにつれて、必ず『自動運転』のようなシステムを必要とし、アプリケーションを管理するようになる」というものでした。Google社内ですでに明らかだったのは、複雑なソフトウェアを安定して稼働させるには、人が盯着しているだけではだめで、展開、スケジューリング、復旧などを処理してくれるシステムが必要だということです。この需要はあってもなくてもいいものではなく、ソフトウェアの複雑さがある段階に達した後に必ず現れるものです。
本当に最も面白いのは、最後の問題です。「なぜオープンソースにしなければならなかったのか？」
多くの人は、「この価値を説得されたなら、なぜGoogle Cloudの独占能力にしなかったのか？それの方が商業的価値が高いのではないか？」と言うでしょう。
しかし、私たちの判断はまったく逆でした。「なぜなら、それを自分のプラットフォームでのみ使えるものにしてしまうと、勝てないからです」。この世界には、あなたのプラットフォームにいない多くのユーザーがいます。彼らは別のクラウドにいるかもしれず、オンプレミスのサーバールームにいるかもしれません。もしこうした人たちを締め出してしまえば、彼らはあなたを待ってくれず、自分たちで代替品を作るだけです。
オープンソースのエコシステムがよく勝つ理由は、より多くの場所で実行できるからです。Linuxがなぜ勝てたのか？非常に重要な点は、どこにでも行けるからです。Google Cloudにとって、もしあなたが市場の首位でないなら、そのようなものを閉鎖的な武器にしてはいけません。すべての人がそれを使えるようにし、あなたのプラットフォームで最も使いやすくなるように保証しなければなりません。そうすれば、たとえ他人があなたのプラットフォームにいなくても、彼らはまずあなたが問題を定義し、この方向についてどう話しているかを聞くことになります。
もっと直接的に言えば、「この世界には必ずオープンソース版が出現する。問題は、そのオープンソース版があなたが作るものか、他人が作るものか、ただそれだけのことです」。
Q：つまり商業的に言えば、当時のGoogleはKubernetesを通じてクラウドコンピューティングの競争格局を変えたいと思っていたのですか？
Brendan Burns：はい、それは非常に重要な部分です。
もし市場ですでに誰かが仮想機械のセットを主流にしていて、あなたが語れる物語が「私たちも同様のセットを持っていて、ある点で少し良いだけ」であるなら、それは非常に困難です。「あなたはずっと他人の物語の中で生き、他人のテールランプを追い続けることになります」。
しかし、もしあなたが新しい戦場を定義すれば、状況は完全に変わります。あなたはもはや他人を追うのではなく、問題と言葉を整理し始めます。たとえ他人が最後に直接あなたのプラットフォームで走っていなくても、彼らはまず注意力をここに向けます。なぜなら、この方向性はあなたが先に話し、先に作ったものだからです。
この種の「発言権」は量化するのが難しいですが、非常に重要です。それは市場全体で、誰が未来を定義し、誰が物語を主導しているかを変えます。
もちろん、今日振り返ってみると、Google CloudがKubernetesのおかげで一気に市場首位になったわけではないので、これを単純な商業的な勝利の物語として語ることはできません。しかし、Kubernetesは確実にGoogleをクラウドネイティブ時代のコアとなる発言のポジションに置きました。この点については、議論の余地はないと思います。
Q：あなたたちが最初に作ったそのデモは、どんな姿でしたか？
Brendan Burns：実は非常にシンプルでした。
たぶん、最も基本的なコントロールインターフェースで、コンテナを展開でき、数台のマシンに配布でき、少しの基本的な負荷分散もできました。例えば、同じ入口にアクセスすると「私はコピー1です」と言い、リロードすると「私はコピー3です」と言うことで、それが実際にコピーされて異なるマシンに分散されていることがわかるようになっていました。
また、非常に基本的なヘルスチェックもありました。プロセスを殺すと、再起動できました。さらに、初期のバージョンアップグレードのデモがあり、v1からv2に切り替わることができました。だいたいこれくらいです。
今日振り返ると、これはもちろん原始的で、完成した製品とは言えません。しかし他人を説得するには十分でした。それは1ページのPPTでも概念ドキュメントでもなく、実際に動くものだったからです。
一週間もかからず作られたデモが、後にクラウドコンピューティングを書き換えた
Q：その初期のMVPは、作るのにどれくらい時間がかかりましたか？
Brendan Burns：一週間もかかっていないでしょう、たぶん4、5日です。
もちろん、「省けるものはすべて省いた」バージョンでした。取れるショートカットはすべて取りました。多くの基本能力もゼロから自作するのではなく、既存のオープンソースプロジェクトをできるだけ利用し、持ってこられるものを持ってきて、接着剤のようなコード（glue code）で貼り付け、システムに基本的な形を持たせました。
私は以前、既存のオープンソースコンポーネントを統合して新しいシステムにするのが得意でした。この能力はKubernetesの初期段階で特に重要でした。なぜなら、「初期の原型の価値は、エレガントさではなく、他人に早く『これは成立し、動く』と見せること」にあるからです。
Q：あなたは当時、自分の正式な仕事もあったはずですが、そんなプロジェクトをする時間はどうやって捻出したのですか？
Brendan Burns：元の仕事を完全に投げ出したとは言いませんが、あれほど短い時間スケールでは、実際にはスペースを移すことができます。
私はいつも少し「危険な」アドバイスをしています。「大多数の人は、経営層に本当に気づかれずに、自分の仕事から約10%の精力を『隠し持つ』ことができると信じています」と。
私の言いたいのは、サボれということではなく、多くの組織で、あなたは実は誰も明確に指示していないが、自分自身で重要だと思うことをするための少しの自由度を保つことができる、ということです。多くの本当に影響力のあるアイデアは、このようなスペースから生まれます。
もちろん、その背後には前提があります。「失敗を受け入れること」です。
あなたがこの種のサイドプロジェクトをやっても、多くの場合成功しません。時間を費やした結果、何も起こらないかもしれませんし、不確実なことに精力を賭けたせいで、見えやすく評価されやすい仕事が少なくなるかもしれません。このリスクを受け入れ、「5回試行して1回成功するが、その1回のリターンは前の4回よりはるかに大きい」という論理を受け入れなければなりません。
このやり方に向いている人もいれば、向いていない人もいて、それは正常です。
さらに直接的で現実的な事実は、多くの人がこうした追加プロジェクトをする時間はないと言いますが、「彼らは一週間に十数時間をゲーム、YouTube、Netflixの視聴に費やしている可能性が高い」ということです。結局、時間があるかどうかの問題ではなく、あなたが自分が真に信じるために何を放棄する気があるかの問題です。
私は毎日夜遅くまで働くことを推奨する人間ではありませんが、もしあなたが本当に何かが重要だと感じるなら、それは時として、ある期間ビデオを少し見なくなり、他の娯楽を少し減らすことを意味します。
Q：つまりあなたの方法は、まずドキュメントを書いて許可を得るのではなく、まず物を作り出すことなのですか？
Brendan Burns：はい、だいたいそんな感じです。
多くのことはドキュメントでは説明しきれません。戦略説明書を書いたり、PowerPointのセットを作ったりすることもできますが、真に有効な方法は、往々にしてまず動くものを出すことです。それが動き始めれば、議論の性質が変化します。
あなたがまだ何もしていない場合、経営層が直面する問題は、「この件に時間とリソースを賭けるかどうか」です。しかし、あなたがすでに物を作ってしまえば、たとえまだ粗雑でも、問題は「このものを続けて推進し、リリースする価値があるかどうか」になります。
この2種類の議論は、完全に別物です。
前者はリソース配分について議論し、後者はそのアイデア自体が成立するかについて議論します。多くの新規プロジェクトにとって、前者の問題から後者の問題へ切り替わること自体が、決定的な進展です。
もちろん、その中にも「失敗のリスク」は依然としてあります。時間をかけて物を作った結果、誰も乗ってこないかもしれません。しかし、もしこの種のことをするなら、この点も一緒に飲み込む必要があります。成功する可能性だけ受け入れ、失敗の代償を受け入れないことはできません。
Brendan Burnsのエンジニアリング方法論は、Kubernetes自体よりも価値があるかもしれない
Q：その原型から、実際に他人が試用できるようになるまで、どれくらい時間がかかりましたか？
Brendan Burns：だいたい半年です。
非常にハックな原型から、他人が実際に試せるシステムだと感じるまでの間には、多くの基礎作業を補う必要があります。多くの目立たない细节が、最終的に一つ一つしっかりと作られる必要があります。
しかし、その段階もまた貴重でした。なぜなら、あなたはほぼ「クリーンルーム」でシステムを作り直すからです。後に加わった多くの人は、別の場所で同様のシステムをやったことがあり、頭の中に「もし私がやり直すなら、どう設計するか」というアイデアがすでに蓄積されていました。
しかし現実世界では、このような機会を実際に得られるエンジニアはほとんどいません。
多くの場合、あなたが引き継ぐのは、すでに稼働しており、大量のユーザーがおり、既存のしがらみがあるシステムです。毎日バグを修正し、歴史的な問題を互換性させ、古い設計にパッチを当てることになります。ゼロから始めて、歴史的な負債が比較的少ない状態でシステムを再構築することは、エンジニアのキャリアにおいて非常に稀な瞬間です。Kubernetesの初期にはまさにそのような窓口がありました。
Q：今日多くのエンジニアがこのような話を聞いて、「やはりGoogleだから、現実にはこんなスペースはない」と第一反応するかもしれませんが？
Brendan Burns：組織の環境にはもちろん違いがありますが、ここには個人の選択の問題もあります。
多くの人は「スペースがない」ことを絶対的な条件として理解しますが、現実はもっとこうです：スペースは小さく、リスクは高く、誰もあなたのすることが確実に価値があると保証してくれない。あなた自身が判断し、自分に賭け、成功しない結果を自分で負担しなければなりません。
さらにキャリアの発展から見れば、上に行けば行くほど、この能力はますます重要になります。なぜなら、より高い階層では、ジャンプアップを完了させるのに十分なプロジェクトをパッケージ化し、定義し、直接あなたに渡してくれる人はほとんどいなくなるからです。多くの場合、真に重要なプロジェクトは、あなた自身が見つけ、抽出し、自分で押し出すものです。
この観点から見れば、いわゆるサイドプロジェクトは単なる「趣味」ではなく、より能動的なエンジニアリングの視点と職業能力を訓練するものでもあります。
K8sも死ぬ、ただその死に方はあなたが思っているとは違うかもしれない
Q：Kubernetesは今日、事実上の標準になっていますが、それにも上限はありますか？
Brendan Burns：もちろんありますが、重要なのはその「上限」をどう理解するかです。
Kubernetesの多くのコンポーネントは本質的に水平スケールが可能です。リクエストが増えればAPI Serverを追加でき、スケジューリングの負荷が大きくなればスケジューラを追加できます。多くの部分はスケールアウトで解決できます。
本当に難しいのは、下層のストレージレイヤーです。Kubernetesのアーキテクチャでは、大量の状態が最終的にそこに戻るため、本当に無限に拡張しにくいのは往々にしてこのレイヤーです。今日、みんなに馴染みがあるのはetcdですが、将来規模がさらに一桁上がれば、それに耐えられるかどうかを再回答する必要があります。あるいは、同じコア特性を保ちながら、拡張能力が高いソリューションに置き換える必要があるでしょうか？
私はKubernetesの設計に拡張を阻む天然の天井があるとは思いません。しかしシステムが一桁の規模を超えると、問題は移動します。以前最も目立っていたボトルネックは、突然重要ではなくなり、新しいボトルネックが別の場所に浮かび上がります。以前はCPUに制限されていたものが、後にネットワークに制限されるようになるかもしれません。以前はメモリに制限されていたものが、後にストレージに制限されるようになるかもしれません。一桁の規模を超えるたびに、真の問題は移動します。
Q：あなたは「ソフトウェアの宿命は死である」と言いましたが、Kubernetesも死ぬのですか？
Brendan Burns：私はこの言葉に完全に同意します。
しかしより完全な言い方は、「自分のソフトウェアを愛してはいけない、なぜならソフトウェアの不可避な軌道は死だからです」です。本当に言いたいのは、「私が書いたから」という理由で手放すのを惜しんではいけない、ということです。それが置き換えられるべき時になったら、喜んで捨てるべきです。
業界の歴史から見れば、これはほぼ普遍的な法則です。Kubernetes内部でさえ、私が当年書いた多くのコードは、後に何度も書き直されています。
Kubernetesがどのように「死ぬ」かについては、必ずしも別の新しいシステムに完全に置き換わるわけではないかもしれません。時には、「システムは本当に消えるのではなく、ますます下層になり、見えなくなっていく」こともあります。今日Linuxはまだありますが、大多数の人は毎日Linuxについて議論しません。プロセッサアーキテクチャもまだありますが、すべての開発者が常にそれを注視しているわけではありません。
Kubernetesもこのような状態に向かう可能性があります：それまだそこにありますが、より上層のシステムに覆われ、新しい相互作用の方法で包まれ、最終的に人々がそれを直接感知することが越来越少（ますます少なく）なります。
特にAI時代では、多くの注意力がモデル、推論フレームワーク、アプリケーションインターフェースに向いており、Kubernetesは徐々に下層に退き、デフォルトで存在するが、もはや主役ではない能力になる可能性があります。
もちろん、時間を十分に引いて、例えば100年後、Kubernetesがそのまま変わらずに存在しているとすれば、私は非常に驚きます。技術世界の変化は速すぎ、今日は頑丈に見える多くのものも、数年後には緩み始めるかもしれません。将来の最大の問題は、変化を予測できなかったことではなく、変化があなたが想像するより速く来るか、あるいはあなたが思った方向とはまったく違う方向から来ることです。
鍵は「しっかりとノートを取ること」
Q：PhD（博士課程）を読むことについてはどう思いますか？多くの人が値するかどうか悩みます。
Brendan Burns：これは私が最もよく聞かれる質問の一つです。
キャリアのリターン率だけから見れば、非常に現実的な話ができます。私は後で同じ会社で学部時代の同級生に会ったことがあります。私たちは同じ年に卒業し、彼は起業し、業界に入り、私はPhDを読み、後に業界に戻りました。結果として、私たちは最終的に会社での階級は同じでした。
だから、私にPhDがキャリアの発展で顕著にリードするかどうかと聞かれれば、私の答えはたぶん「そうとは限らない」です。多くの場合、実際にはそれほど大差ありません。
しかし逆に、この経験は値するかと聞かれれば、私は「私にとっては値した。楽しんだし、非常に有用な能力を多く学んだからだ」と言います。
例えば、執筆と表現です。博士課程の訓練と指導教官の影響は、複雑なアイデアを明確に書き、話す方法を教えてくれました。後のKubernetesの初期、私たちは長い時間をかけて推進し、説得し、内部の支持を勝ち取りましたが、この能力は実際に非常に重要です。
さらに、私は後で数年間教授もしました。コンピュータを全く知らない人に授業をすると、複雑なシステムを他人がわかるように伝えるにはどうすればいいかを考えさせられます。Kubernetesの初期も同じで、多くの人がこう聞きます。「コンテナとは何ですか？オーケストレーションとは何ですか？私はなぜそれが必要なのですか？」これらの問題は、コードを書けば自動的に解決するものではなく、教えることができ、説明できなければなりません。
だから、もし私に聞かれれば、私はこう言います。「PhDは肩書きですぐにリードするかもしれませんが、長期的に非常に価値のある能力を与えてくれるかもしれません」と。
Q：若いエンジニアがあなたに尋ねるもう一つの質問は何ですか？
Brendan Burns：もう一つのよくある質問は、「私は一体何を学ぶべきですか？」です。
例えば今AIが熱いですが、システムの方が好きという人が来て、「それなら私はシステムを諦めてAIを学ぶべきですか？」と聞くことがあります。私の回答は通常、「あなたが具体的に何を学ぶかはそんなに気にしませんで、もっと気にしているのは、あなたが継続的に学習しているかどうかです」。
もしあなたがAIに全く情熱がなく、単に人気があるからと無理やり学んでも、たぶん上手くいきません。逆に、もしあなたが本当にシステムが好きなら、より多くの時間と注意力を費やすことになり、そのような継続的な投資こそが真の能力に転化する可能性が高いです。業界もいつまでも優秀なシステムエンジニアを必要としません。
多くの若い人が「方向を間違えること」を特に恐れていると感じます。しかし正直に言えば、私自身、厳密な人生計画が一度もありませんでした。私はずっと、何が面白くて価値があるかを見て、追いかけてきただけです。
もちろん、この方法にもリスクはありますが、皆さんに思い出してほしいのです。事後的に遠回りだと思う経験の多くが、最終的に最も重要な養分になることがあります。「継続的に学んでいれば、通常、悪くはなりません」。
Q：キャリアに特に大きな影響を与えた本はありますか？
Brendan Burns：エンジニア段階なら、私に大きな影響を与えた一冊は『Design Patterns: Elements of Reusable Object-Oriented Software』、いわゆるGoFの『デザインパターン』です。
後に役割が変わり、より大きなチームを率いるようになると、私は別の2冊をお勧めします：1冊は『Leadership on the Line』、もう1冊は『The Five Dysfunctions of a Team』です。
前者はよりリーダーシップ寄り、後者はよりチームコラボレーション寄りです。だいたいこう理解できます：もしあなたがまだ主にエンジニアなら、まず『デザインパターン』を読んでください。もし管理や組織のリーダーシップを始め始めたなら、後の2冊がより役立ちます。
Q：大学を卒業したばかりの時に戻れるとしたら、当時の自分にどんなアドバイスをしますか？
Brendan Burns：もっと良いノートを取ることです。
私はずっと、Kubernetesへのこの道のりは、実際に完全に一冊の本に書く価値があり、甚至は（甚だしくは）優れたビジネスケースになると思います。しかし問題は、私が当年、十分に完全な記録を残さなかったことです。
コードはもちろん残っていますが、本当に消えやすいのは、コードではなく、あの重要な瞬間の議論、パートナー間の駆け引き、組織内部の推進、人と人の間の判断と駆け引きです。これらは現在、まだ一部覚えていますが、もう完全には覚えていません。
当年にもっと完整な（完全な）ノートを残していれば、今日振り返って、きっと非常に価値があるでしょう。
元動画のリンク：https://youtu.be/FKijpCEH9D8
（投稿または報告を希望する場合：zhanghy@csdn.net）