Kubernetes 5周年: Joe Beda、Brendan Burns、Craig McLuckieがKubernetesの過去、未来、そしてオープンソースの真の価値について語る
オープンソースのエンタープライズ ソフトウェアがライセンスや収益化をめぐる議論に悩まされ、岐路に立たされている今、Kubernetes は完全な成功を収めています。
Kubernetesは、5年前にGoogleの3人のシニアエンジニアによって初めてリリースされて以来、ユーザー、メンテナー、ベンダー間のトラブルを最小限に抑えながら、分散コンピューティングに大きな影響を与えた数少ないオープンソースプロジェクトの一つです。Kubernetesをめぐる誇大宣伝は実用化をはるかに先取りしていたと主張する人も多くいますが、コンテナを中心にアプリケーションをモダナイズしている企業が、複数のクラウドプロバイダーを繋ぐ架け橋としてKubernetesが持つ可能性に注目していることは間違いありません。
先週の5周年記念イベントでは、Kubernetesの共同開発者3名（VMwareのJoe Beda氏とCraig McLuckie氏、そしてMicrosoftのBrendan Burns氏）による対談を2019 GeekWire Cloud Summitで開催することができ、大変光栄でした。プロジェクトの歴史、オープンソースソフトウェアの現状、そしてクラウドコンピューティングの未来を阻む未解決の問題について語り合いました。
その議論の軽く編集された記録を以下に示します。
GeekWire クラウド & エンタープライズ エディター Tom Krazit: この部屋にいるほとんどの人は皆さんのことを知っていると思いますが、まずは自己紹介をして、「こんにちは」と挨拶して、コンピューター サイエンスの歴史で一番好きな人物は誰で、その理由も教えてください。
Joe Beda: 私は Joe Beda です。コンピューター サイエンス分野で私のお気に入りの人物は… Ada Lovelace です。彼女は最初のプログラマーであり、すごい人で、とてもクールでした。
ブレンダン・バーンズ：ブレンダンです。…特に好きな人物はいないのですが、Appleの共同創業者の一人であり、知られざるAppleのビートルズ、スティーブ・ウォズニアックを選びます。
クレイグ・マクラッキー：こんにちは、クレイグです。コモドール64を作ったジャック・トラミエルに投票します。コモドール64がなかったら、私は孤独で憂鬱な10代を送っていたでしょう。ジャック、ありがとう。
Tom Krazit: 皆さんがここにいらっしゃる理由の一つ、そして今週の祝祭はKubernetesにまつわるものです。Kubernetesはここ数年、皆さんをずっと支えてきたプロジェクトです。これまでの進捗を振り返り、Kubernetesの現状についてお聞かせください。まずはそこから始めましょう。私たちは今どこにいるのでしょうか？プロジェクトはどのように進化してきたのでしょうか？残された課題は何でしょうか？そして、この5年間で最も誇りに思うことは何でしょうか？
ブレンダン・バーンズ：バックエンドポリシーなどについて話し始めた時に、転換点を迎えたような気がします。「ああ、これでエンタープライズ対応になったんだな」と思いました。当初のロードマップにはなかったのですが、ある程度の普及は必然だったと思います。私にとって最も誇りに思えるのは、コミュニティです。コミュニティの拡大とプロジェクトへのサポートの両面において、私たちは非常に幸運だったと感じています。そして、ある意味で、そこにドラマチックな出来事がほとんどなかったのも、本当に素晴らしいことです。
Joe Beda: おそらく1、2年前にKubernetesが退屈だ、という話をしたと思います。Kubernetesが十分に信頼できるようになったことで、Kubernetesは人々の記憶から消え、人々はただ仕事をして問題を解決しているだけで、Kubernetesのことなど考えなくなりました。その点では大きな進歩を遂げたと思います。Kubernetesが退屈な時代に入りつつあり、プロジェクトの方向性が良い方向に変化しつつあると感じています。なぜなら、人々はKubernetesに本当に依存しているからです。
Craig McLuckie: 私にとって、Kubernetesの進化を見るのは興味深いことです。Kubernetesは、初期の頃は分散システムエンジニアへのラブレターのような存在で、可能性を示していました。オープンな設計、オープンなコミュニティ、オープンな開発という理念を掲げていました。そして、それが現実のものへと成長していく様子を見るのは、ただただ感慨深く、素晴らしいものでした。
現状は現実です。素晴らしいことです。私はKubernetesに全力を注いでいる多くの企業と多くの時間を共に過ごしてきました。彼らはKubernetesを越え、次世代のステートレスワークロード管理の主要プラットフォームとして活用することを目指しています。そして、「あらゆるものを統合できるプラットフォームをどう構築するか」を真剣に考え始めています。真の「ゴルディロックス」抽象化、つまりほぼあらゆるものを実行できるほど低い抽象度でありながら、インフラストラクチャの不確定性の大部分を隠蔽できるほど高い抽象度を実現しようとしているのです。
Amazon Web ServicesがKubernetesに全面的に参入し、新たなコンテナ展開サービスを開始
将来を見据えると、サービスの完成には、セキュリティの強化と確保、そしてプラットフォームに新たなワークロードを導入していく中で発生する多くのエッジケースへの対応など、まだ多くの課題が残されていると考えています。「何に最も誇りを感じるか」という点では、組織がKubernetesを真に自分たちのものにしているのを目の当たりにできたことが、私にとって最も誇らしいことです。Kubernetesが既存のビジネスや、自らが構築した一連のテクノロジーにとって脅威となるなど、Kubernetesを競合相手として捉える十分な理由があった人はたくさんいます。
そして、ほぼすべての大手ベンダー、電力会社、そしてあらゆる組織が、（クラウド）プロバイダー側でKubernetes戦略を策定しています。本来であれば競争し、独自の方法でKubernetesを自社の環境に適応させる方法を模索しているはずの大企業が、このオープンで積極的なコミュニティを通じて真に協力し、すべてのエンドユーザーのニーズと能力を相互に高めているのを見るのは、本当に素晴らしいことです。見ていて本当に素晴らしいです。
トム・クラジット：今振り返ってみて、何を違ったやり方でやればよかったと思いますか？
ブレンダン・バーンズ：間違いはたくさんありました。… 途中で修正しました。
Joe Beda: VMwareでは、コミュニティに力を入れていることの一つに、Kubernetesを長期にわたってどのように導入・管理していくかという点があります。多くの人はクラウドプロバイダーが提供するマネージドサービスを利用すると思いますが、Kubernetesのメリットの一つは、非常に柔軟性が高く、様々な場所で活用できることだと思います。
私たちは、優れたツール、優れた意見、そして長期にわたってシステムを正しく運用するための優れたガイドを提供するという点で、早い段階で十分な成果を上げることができませんでした。現在、その点に取り組んでいるところですが、そこに到達するまでに時間がかかりすぎたと思います。
ブレンダン・バーンズ：もう一つ…今考えてみると、他に2つあります。1つは、適切な統合テストを構築していなかったことです。これは今でも私たちを悩ませています。ユニットテストと非常に大規模なエンドツーエンドテストは実施しています。しかし、中間領域でテストを実施しようとすると、プロジェクトに十分なインフラストラクチャが備わっておらず、後から変更するのが非常に難しいのです。また、ガバナンスの導入がかなり遅すぎました。幸運にも、それほど大きな問題にはならずに済みました。
トム・クレイジット：競合バージョンの出現という意味ですか？
ブレンダン・バーンズ：いえ、いえ。プロジェクトのガバナンスみたいなものです。例えば、プロジェクトの組織化のルールを策定するためにブートストラップ委員会を結成した時、私たちは規模が大きすぎました。規模が大きくなりすぎていることに気づいたので、受動的に行動したんです。もっと積極的に行動すべきだったのですが…まあ、それは分かりませんね。
ジョー・ベダ：少し歴史を振り返ってみましょう。プロジェクトを始めた頃は、比較的経験のあるエンジニアたちが、ほぼ共通のビジョンを持って、ただひたすらにコードを書き続けていました。そして、そのやり方はかなり長い間うまくいきました。
しかし、プロジェクトが複雑になり、初期段階では明らかだった部分を過ぎ、大きなビジネスになることが明らかになるにつれて、コミュニティ内で対立が生じ始めました。「この方向に進むべきか、それともあの方向に進むべきか？」今では運営委員会などを含むガバナンス体制が整備され、様々な活動が行われています。しかし、それを実行するにはあまりにも長い時間がかかりすぎました。
ブレンダン・バーンズ：私にとって本当に印象的だったのは、最初のコミュニティ調査を行った時のことです。プロジェクト、それが人々に何をもたらすのか、そしてその他あらゆることに対して、ものすごい熱意が感じられました。一方で、どのように参加すればいいのか、そしてプロジェクトがどこへ向かうのか、大きな混乱もありました。
「人々はこれにとても興奮しているが、どう支援すればいいのか、どのように意思決定が行われるのか全く分かっていない」という状況でした。これは、ガバナンスの問題があることを示していました。
Craig McLuckie: 私としては、これを別の方法で行う方法を見つけるのは非常に難しいと言わざるを得ませんが、Kubernetes の歴史を振り返って最も後悔していることの 1 つは、Kubernetes の世界と Docker の世界をもっと効率的に連携させられなかったことです。
Dockerが初期にもたらしたものをよく考えてみると、それはまさに革命的なものでした。あらゆるワークロードをパッケージ化してアトミックに把握する機能、実にエレガントで美しくまとめられたツールチェーン…そして、私たちは皆、傷ついたように感じました。
両コミュニティが真の意味で融合できなかったため、双方が痛手を負いました。Kubernetesは、DockerとDockerコミュニティが築き上げてきた多くの設計理念や開発者ツールの経験から、多大な恩恵を受けることができたはずです。Kubernetesコミュニティは、分散システム機能の面でDockerに多くの豊かさをもたらすことができたはずです。
ですから、私たちがこれをどう違ったやり方でやっていたかは正確にはわかりませんが、もし私たちの望みが通るのであれば、これら 2 つの世界をもっと早くより調和のとれた形で融合させていれば、全員に大きな利益がもたらされただろうと思います。
Tom Krazit: それは興味深いですね。DockerがSwarmでやろうとしていたこととKubernetesがやろうとしていたことの間には、実際には名目上の競合関係があったのです。Kubernetesはオープンソースプロジェクトだったのに対し、Dockerは商業企業としてやろうとしていたので、あなたがそれを正確にそう捉えているかどうかは分かりません。（しかし）それはどのようなものだったと思いますか？
ブレンダン・バーンズ：そうですね、具体的に言うと、オーケストレーション分野に競争は必要なかったと思います。むしろ、競争は必要だったと思います。そして、これは彼らの正しいやり方だったと思います。私たちは明確な線を引いて、「この線より上にはエコシステムがあり、独自のツールとエクスペリエンスを構築できる場所を用意します」と明言しました。そして、そのメリットは今、皆さんにも実感していただけると思います。
おそらく、私たちはその精神で共同コミュニティとして前進できたはずです。しかし、それは実現しませんでした。しかし、私もクレイグと同じ意見です。私たちは（単に）互いに良い影響を与え合えただけでなく、しばらくの間は採用を妨げたと思います。不確実性があり、ベンダーが「監視対象をどうしたらいいんだ？ Kubernetesで監視対象を絞ればいいのか？ それとも、他の場所で監視対象を絞ればいいのか？」と悩むのが見られたからです。
統合はエコシステムの前進に役立ちます。
Tom Krazit: 今後の展開や、皆さんが（今）考えていることについてもぜひお話ししたいと思います。でも、もう一度振り返ってみたいと思います。Kubernetesの初期段階で、最もずさんなコードを書いたのは誰だったでしょうか？
ブレンダン・バーンズ: それが私です。
ジョー・ベダ：いや、いいですよ。それで…
ブレンダン・バーンズ：それは数え方によります。
ジョー・ベダ：ああ。だって…
Brendan Burns: あなたは Bash (Unix シェル コードの一種) をたくさん書きましたね。
Joe Beda: ええ。Brendanは、何かを実際に動かして、実際に何かを証明したり、稼働させたりするのがとても得意です。それが彼のスーパーパワーだと思います。でも、初期の頃は、私は雑用的な仕事をたくさんやっていました。その中には、GCE上で実際にどうやってクラスタを起動するかといった初期の作業も含まれていました。それが…ライフサイクルツールに関して、今私たちが払っている罪なんです。初期の作業は…あまり良いものではありませんでした。
ブレンダン・バーンズ：あれは…よりもずっと長く生きていた。
ジョー・ベダ：それが実際にまだ存在しているなんて信じられません。
ブレンダン・バーンズ：…誰もそんなことは思っていませんでした。ただ、ある時クレイグがこう言ったのを覚えています… ちょっと言い換えますが、クレイグは私にこう言いました。「君は本当に素晴らしいアイデアを持っていて、本当に革新的なのに、信じられないほど汚い痕跡を残していくんだ」
クレイグ・マクラッキー：（微笑んでうなずく）
ジョー・ベダ：クレイグにとって、「Filth」という言葉はまさにその通りですね。
ブレンダン・バーンズ： 僕たちはみんなそれぞれ違った強みを持っていると思います。
未来へ船を操縦する
Tom Krazit: 分散コンピューティングにおける現在の最大の未解決問題は何だと思いますか？Kubernetesがある程度ソリューションとして機能しているとすれば、Kubernetesは成熟に向かっており、堅牢化も進んでおり、皆さんがおっしゃっているようなことが全て実現しつつあります。分散コンピューティングの世界全体を見渡してみれば、最大の未解決問題とは何でしょうか？
ジョー・ベダ：分散コンピューティングには様々な定義があります。コンセンサスアルゴリズムから、ベクトルクロックを使って地域間でデータベースを複製する方法など、あらゆるものが含まれると思います。私たちは「これは難しいから、誰かの問題にしよう」という世界へと移行しつつあると思います。そして、パターンとアルゴリズムがパッケージ化される段階に近づいています。
これをクラウドAPIなどにも広げていくと、一般的に難しい問題の一つは設定だと思います。Puppet、Chef、Terraform…Kubernetesの世界ではHelmやKustomizeなど、あらゆるものがこれに当てはまります。膨大な数のプロジェクトがありますが、どれも100%正しく設定できているわけではありません。
ある種のプログラミング言語レベルで抽象化を構築する方法については優れたアイデアのライブラリがある一方で、クラウド構成や API システムに関して言えば、より高レベルの概念を実際に構築する方法については、抽象化の代わりに合意された優れたツール セットがないと思います。
ブレンダン・バーンズ: それは無限です…その話題には無限の時間を費やすことができます。
私の観点からすると、難しすぎると思います。システム構築の知識がある人にとっては、時間がかかりすぎ、再利用性も十分ではありません。また、クラウドベースのアプリケーションをうまく構築できる開発者が扱えるリソースは、本来あるべきよりもはるかに少ないのです。
例えば、フロントエンド開発者の数とクラウド開発者の数を比べてみると、クラウド開発者の数は同数、あるいはそれ以上であるべきだと思います。しかし、現状はそうではありません。これは私たちの失敗だと思います。私たちはシステムをある程度まで構築した後、開発者が使いやすいシステムを実際に構築できていないのです。
Kubernetes は開発者にとって使いやすいものではないと思います。
トム・クレイジット：私もそう聞きました。
ブレンダン・バーンズ：ですから、これは私たちがもっと力を入れなければならない分野だと考えています。残念ながら、Kubernetesのような何かを作るのが好きな人たちは、この分野に時間を費やすことを好まないのです。ですから…
ジョー・ベダ：私たちの業界では、ユーザーエクスペリエンスは広く認知された分野であり、学位取得者や専門部署、UX責任者もいます。インフラ分野においても、開発者エクスペリエンスに関して同様の動きが必要です。一方、DX、つまり開発者エクスペリエンスは、分野としてそれほど認知されていないように思います。
Craig McLuckie: 構成です。構成の領域を超えて考えると、今まさに頭に浮かんでいることが一つあります。それは…Joeが実際にこの件に取り組んでいます。サービスアイデンティティを第一級のエンティティとして確立するという考え方です。そして、高度に接続されたフェデレーションの世界でアイデンティティを扱えるようにすることです。ユーザー原則という観点だけでなく、サービスアイデンティティを第一級のエンティティとして確立できることは、業界として投資すべき非常に重要な分野です。
アイデンティティを第一級のエンティティとしてどのように扱うかという点において、まだ臨界点に達していないと私は考えています。Googleのような企業の内部を見れば、彼らはそれに対応するための優れたシステムを持っています。多くの大手インターネット企業がこれを理解しています。しかし、企業にとって包括的にアクセス可能になっていないのです。そして、これは今後5年間で実現してほしい分野だと思います。
ジョー・ベダ：セキュリティ全般に関しては、大きなギャップがあると言えるでしょう。セキュリティは他人事、つまり後付けの問題として捉えられており、開発者にとってセキュリティは身近なもの、つまりアンビエントなものになっていません。
Tom Krazit: 現在勤務されている企業を除けば、Kubernetes上で最も興味深い取り組みを行っている企業はどこだと思いますか？本日はKubernetes APIレイヤーを活用した取り組みを行っているスタートアップ企業もいくつかお見えになりましたが、これらの課題への取り組み方として興味深いものがいくつかあります。Kubernetesの力を活用している企業を見ると、どのようなことが浮かび上がってきますか？
ブレンダン・バーンズ：私は、Kubernetes 上で立ち上がっているプロジェクトについて考えるのが好きです。そして、一般的にはそれが正しい考え方だと思います。Kubernetes は非常にユビキタスなレイヤー、非常に統一されたレイヤーになっているので、Kubernetes 上に何か面白いものを作るなら、どこにでも展開できる必要があります。そのため、一般的には、まずオープンソースプロジェクトを構築し、それをどのように製品に統合するかを考えることになります。
実は、ポリシーについて考えるのに多くの時間を費やしています。冒頭でも触れましたが、ポリシーと、CNCFのオープンポリシーエージェントの取り組みについて考えていました。クラスタの外側を保護することはできますが、実際にはクラスタ内に配置されるオブジェクトの種類についてもルールを定める必要があることに人々が気づき始めており、非常に興味深い点があります。例えば、どのような画像リポジトリを使用しているか、オブジェクトにどのようなタグを付けているかなどです。こうした点は、人々が話題にしているセキュリティ関連の問題において非常に重要であることが分かっています。
開閉
Tom Krazit : 実は、これは私が話したいと思っていたもう一つの話題、つまり現在オープンソースについて話す良いきっかけになりました。
ジョー・ベダ：それは非常に重要な話題です。
Tom Krazit : いくつか興味深い展開がありました。ここ6ヶ月で、主にデータベース関連企業がライセンス条件を変更し、より厳格な制限を設けました。そして大抵の場合、クラウドプロバイダーが（彼らに）差し迫った大惨事の脅威を突きつけ、それが正当化の根拠となっています。
もしKubernetesのようなプロジェクトを今から始めるとしたら、やはり完全にオープンソース化しますか？また、考え方は変わりますか？
ブレンダン・バーンズ：オープンソース化を徹底します。インフラがユビキタスなものになるには、オープンでなければならないことは明らかです。
一部のオープンソース企業がよりクローズドなアプローチを検討している理由
データベースは違うかもしれませんね。よく分かりません。データベースを作ったことはありません。しかし、Kubernetesのようなスタックに組み込むには、様々な企業が大きな賭けに出る必要があります。完全にオープンで、ベンダー中立でなければなりません。成功の鍵は、実際に基盤に組み込むことだと思います。つまり、オープンソースという枠を超えて、基盤に組み込む必要があるのです。
ジョー・ベダ：オープンソースを軸にした企業設立という点では、ビジネスモデルの進化が見られると思います。重要なのはビジネス上の課題を解決することだと思います。テクノロジーではなく、解決する問題です。クラウドプロバイダーの場合、運用をサービスとしてどのように提供するかが課題となることもあります。
しかし、開発者というペルソナを超えて、そのテクノロジーが開発者だけでなく、運用担当者や意思決定者など、組織の他の部分に実際にどのような影響を与えるのかという、他のビジネス上の問題もあると思います。これはオープンソースだけにとどまらない問題だと思います。
ビジネスモデルを構築する際には、まさにこの点を念頭に置く必要があると思います。しかし、多くの企業が、スタートアップのバブル期によくある問題の一つとして、興味深い技術から始めて、ビジネスモデルは後から考えようと考えていることが挙げられます。Googleのような企業を見ると、「まあ、うまくいった」という確証バイアスに陥ってしまうと思います。しかし、必ずしもうまくいくとは限りません。
オープンソースを企業としての戦略の一部として位置づけるのか、「ただ何かを公開して何が起こるか見てみましょう」というのではなく、どのような形で位置づけるのかという点で、計画を立てることが重要だと私は思います。
ブレンダン・バーンズ：しかし、多くの企業にとっての課題は、おっしゃる通り、テクノロジーからスタートしている点だと思います。ビジネス上の問題からスタートしているわけではないのです。そのため、収益化の方法を模索しているのです。
スタートアップのエコシステムでもよく見られる現象で、ベンチャーキャピタルから多額の資金を調達しすぎる人がいます。そして突然、「大変だ、収益を上げなければ…」となってしまうのです。これもまた、人々に大きなプレッシャーをかけています。
まあ、どうでしょう。これがオープンソースに対する大きな批判にならないことを願っています。そう考えるのは正しいとは思えないからです。ただ、Kubernetesはオープンソースプロジェクトとして意図されていたということも付け加えておきます。Kubernetes自体がビジネスになるはずはありませんでした。
Tom Krazit: そうですね、私も多くの人が心配していることの 1 つとして、オープンソースのエンタープライズ開発が基本的に大手ベンダーによって資金提供されている場合、潜在的に革新的なプロジェクトが実際に定着する場所を見つけられず、世間に認知される方法も見つけられず、プロジェクトを立ち上げて実行するために必要な開発、時間、労力を支援する方法も見つけられない可能性がある、という点を聞きました。
クレイグ・マクラッキー：私の立場からすると、これは永遠の課題です。ジョーが言ったように、会社を立ち上げるなら計画を立てた方が良いでしょう。そして、その計画とは「オープンソースにして、後で商用化する」といったものであってはいけません。ビジネス上の問題にしっかりと目を向けなければなりません。
私の見方では、オープンソースには古典的な商業モデルがいくつか存在します。まず一つはディストリビューション戦略です。そして、これはほぼ必ず悲惨な結末を迎えます。
そこで、「ディストリビューションを作る。完全にオープンソース化するか、あるいはいずれ競合相手が現れるだろう。もし成功すれば、彼らは私のビジネスをただ追いかけてくるだろう。彼らは私のビジネスをただ追いかけてくるだろう。彼らは私のビジネスの更新を引き受けてくれるだろう。なぜなら、そこには防御策がないからだ。彼らの顧客は既にテクノロジーを導入しているので、彼らはサポートサブスクリプションを再び契約するだけなので、彼らの売上原価は私のものよりも低い。」という考え方があります。
これがオープンコアの理念、あるいは人工的な壁を作ろうとする難解なライセンス体系へと繋がります。そうなると必然的に、自分のコミュニティ内で間違った方向に進んでしまい、悪いことが起こります。
オープンソースを収益化する2つ目の方法は、Red Hatになることです。Red Hatのようになるという意味ではなく、文字通りRed Hatになるという意味です。
彼らは非常に繊細なモデルを構築し、コミュニティ内で独自の特異点を確立しました。OEMとODMの間のプロキシとして機能することで、ISVがその点を確立したのです。
彼らはオープンソースの商業化に非常に繊細なアプローチをとってきました。そして、すべてのディストリビューションプロバイダーがそうなりたいと考えていると思います。しかし、Red Hatは永遠に一つしか存在しないでしょう。
オープンソースを収益化する3つ目の方法は明白です。それは、二次的効果を収益化することです。そして、この二次的効果を最も効率的に収益化できる組織はクラウドプロバイダーです。二次的効果とは、インフラの消費です。つまり、この二次的効果を収益化できる人は誰でも、オープンソースの利用に既得権益を持っていると言えるでしょう。
実は、第4のモデルがあると思っています。まだ完全に証明されているとは思いませんが、オープンソースには確かに優れた点がいくつかあります。採用、牽引力、遍在性といった点において、オープンソースに悪いところは何もありません。最終的には、企業のアプリケーションと物理インフラの間にあるコードがすべてオープンソースになる世界が到来するでしょう。そうなるでしょう。しかし、オープンソースには未知の部分がたくさんあります。
オープンソースは自分自身のことを知りません。適切にパッチが適用されているかどうかも知りませんし、必ずしも自分自身を管理・更新する方法も知りません。最適化する方法も知りません。だからこそ、オープンソースとSaaSのようなデータサービスの間に接点を作り、オープンソース技術のプロビジョニング、展開、管理、運用、利用をはるかに効率的に行えるようにするチャンスがあると考えています。
オープンソースではできないことを実現し、オープンソースの消費を可能にする SaaS とオープンソース自体の融合には、業界ではまだ十分に調査されておらず実現されていない重要なビジネスがあると思います。
ブレンダン・バーンズ：ええ、全くその通りだと思います。今私たちが直面している課題の一つは、ソフトウェアの運用化に非常に長けている人たちがクラウドに注力しているということです。彼らの仕事は基本的にソフトウェアの運用化だからです。そして、他の人にとってはソフトウェアの運用化は非常に困難です。
彼らは期待を高めてきました。ソフトウェアの利用方法に対するユーザーの期待は、「月額料金や時間単位の料金を支払って、SLAなど様々なものを得る」というものです。これがソフトウェアに対する期待です。「何かをインストールして、マニュアルを読んで、使い方を理解する」というものではありません。
そして、小規模な企業にとって、それを実現するのは非常に困難であることが判明しました。クラウドなどの技術によって、それがより容易になると考えています。そして、それが機能するソフトウェア経済を生み出すことを願っています。
これは、サービスを十分にうまく提供できればクラウドと競争できるという明確な証拠だと思います。Snowflakeはその好例です。誰もがデータウェアハウスを所有しているにもかかわらず、SnowflakeはAzureだけでなく、他のあらゆるプラットフォームでも販売を続けています。他にも同様の例はたくさんあります。
Tom Krazit: しかし、Snowflake はオープンソース プロジェクトではありませんでした…
ブレンダン・バーンズ：でも、そうは思えません…これが私の問題なのですが、ライセンスモデルは重要ではないと思っています。Snowflakeはクローズドソースである必要があるのかもしれませんが、よく分かりません。でも、実際にはそうは思っていません…問題はライセンスモデルよりも、ソフトウェアのオープンな合理化と、ソフトウェアの運用化における課題にあると思います。
Joe Beda: ここに興味深い再帰的な特性があると思います。Kubernetesは、大規模なシステム、特に分散システムの実行を容易にします。つまり、運用可能なソフトウェアの開発にかかるコストと複雑さを実際に削減しているのです。
Kubernetesがソフトウェアを運用するためのツールキットになるにつれて、Snowflakeのように、マネージドソフトウェアを基盤となるクラウドから分離できるようになるかもしれません。これは興味深い機会になると思います。Kubernetesは実際にそこに多くの機会を生み出すと考えています。
クレイグ・マクラッキー：もう一つ注目すべき点は、現在、業界において非常に興味深い断片的な力が生まれ始めていることです。クラウドの台頭を見れば、大規模な統合の時代が到来すると予想するのは理にかなっています。あらゆるものがよりシンプルになり、統合化されるでしょう。
しかし現実は、現代の企業の世界を見てみると、実際には逆の方向に進んでいます。私が関わっている企業はすべて、マルチクラウド調達ポリシーを策定しています。調達部門から複数のクラウドにまたがる調達を強いられています。規制当局が「もし悪意のある人物がクラウドのコントロールプレーンに侵入したらどうなるのか？ その時どう対処するのか？」と問うケースもあります。
長期的なトレンドとして、現状のクラウドの有用性は…安価な電力網に大量のインフラを設置できることにあります。そして、大規模なスケールメリットを実現できます。しかし、電力供給の分散化も進み始めています。GDPRのような規制も登場し始めています。欧州では、地域ごとのデータプライバシー法が整備され始めており、それが分断化を招いています。
クラウドプロバイダーがこの世界で繁栄し、本質的に分散化された問題に実際に対処できるようになることを妨げるものは何もありません。しかし、誰もが統合の進展を期待していた時期に、コンピューティング環境全体にわたって大規模な断片化が進行しています。そのため、運用化の必要性について言えば、特定の環境だけでなく、この高度に断片化され、分散化された環境全体で運用化を実現する必要性が高まっていると考えています。
エンタープライズ・ソフトウェア・ベンダーにとって、今後10年間のエンタープライズにおける大規模な成果は、まさにこの分野で争われることになるでしょう。巨大なクラウド・データセンターだけでなく、極めて分散化され、高度に断片化されたコンピューティング・フリートが、まさにその戦いの舞台となるのです。
トム・クレイジット：では、皆さんがスタートアップに興味を持ち、オープンソースプロジェクトを軸にした会社を立ち上げたいとします。そのビジネスモデルは何でしょうか？
Craig McLuckie: ああ、これは簡単です。サービスです。(Heptio は VMware に入社する前は Kubernetes 関連のプロフェッショナル サービスを提供していました。)
面白いのは、VC が「あなたは Mirantis になるだけですよね？」と言うのに対して、彼らは「いいえ…」と言うんです。申し訳ありませんが、Mirantis には何の問題もありません。彼らは OpenStack で素晴らしい仕事をしましたし、私たちは彼らの仕事に感謝し、尊敬しなければなりません。
「サービスだけではオープンソースを商業化できない」と言う人はたくさんいます。そして、彼らは全く正しいです。サービス事業を拡大することはできません。しかし、まずはそこから始めなければなりません。なぜなら、企業がオープンソースの技術やサービスを利用する際に直面する課題、複雑さ、そして必要性について、これほど深く理解できるものはないからです。
ですから、サービスから始めれば、たくさんのことを学べます。企業のデータセンターで6ヶ月間、あなたの首を絞めるような大口顧客と一緒にテクノロジーを展開すれば、多くのことを学べるでしょう。
そうすることで、運用上の主要なギャップ、主要な課題、このテクノロジーの何が本当に難しいのかを特定し、顧客のニーズに応えるための基盤が得られます。このプロセスを通じて多くのことを学び、問題解決のために投資すべき重要な領域を特定できるようになります。
ブレンダン・バーンズ：少し違う場面でも、私も同じ答えをします。SaaSから始めるでしょう。オープンソースかもしれませんが、最終的にはSaaS企業になる必要があると信じ、理解してください。だから、そこから始めてください。
クレイグが言ったように、オープンソースは市場への浸透、採用、そして熱意を高める上で素晴らしいものですが、結局のところ、人々はソフトウェアを操作したいわけではありません。彼らはあなたに（彼らのために）ソフトウェアを操作してもらいたいのです。それがあなたのビジネスになるということを認識して、そこに全力で取り組めば、成功のチャンスは必ずあります。
ジョー・ベダ：そうですね、最終的にはSaaSになると思いますが…実は…私はGoogleで10年ほど働いていました。開発者は皆同じではありません。Googleでの経験があっても、Midwest Bankのエンタープライズ開発の日々がどのようなものなのかを理解する準備は全くできていません。
Tom Krazit : これが、この (クラウド インフラストラクチャ) 市場における Google の大きな苦戦の原因だとお考えですか?
ジョー・ベダ：Googleはユニークな企業だと思います。彼らはユニークなタイプの人材を採用しています。彼らは、真の企業に何を提供するべきかという点で、厳しい教訓を学んでいると思います。
Tom Krazit : 残り時間がわずかですので、一つ確認させてください。Kubernetes は長い名前で、発音やスペルミスがよくあります。
ブレンダン・バーンズ：クーパーネキーズ！
Tom Krazit : Google が承認するまでに、Kubernetes に落ち着くまでに 13 種類の異なる名前を検討したという報告を読みました。
ジョー・ベダ： そうだね。
ブレンダン・バーンズ：たくさんありました。
トム・クレイジット：それでは、却下された中で一番気に入った名前は何でしたか?
クレイグ・マクラッキー：ああ、これは簡単だね。カリーナ。
ブレンダン・バーンズ：ああ、それは残念でしたね。実はコードベース全体の名前を変えたんです。本当にそうしました。適用された名前とか…
ジョー・ベダ：それは星雲です。
ブレンダン・バーンズ：これは星3つです。実はコードベース全体を調べて名前を変更したのですが、結局、その部分はやらないことにしました。
ジョー・ベダ：Googleで検索しました。
ブレンダン・バーンズ：その通りです。
ジョー・ベダ：それで、ソフトコアポルノスターみたいな名前が出てきたんです。それで「それは良くない名前だ」って思ったんです。
トム・クラジット: これには拒否権を行使した。
ジョー・ベダ：プロジェクト・セブンは本当に期待していました。本当にそう願っていたんです。
クレイグ・マクラッキー：本当にそう思うと…一番気に入ったのはロキュータスですね。
ブレンダン・バーンズ： ああ、そう言おうと思っていました。
ジョー・ビーダ: ああ、ロキュータス、そう、ロキュータスは良かった。
クレイグ・マクラッキー：それはよかったですね。
ジョー・ベダ：つまり、あれは『スタートレック』のキャラクター、ボーグの翻訳機だったんですね。でも、かなり深く関わっていたので…
ブレンダン・バーンズ：ロキュータスはボーグに変身したピカードです。（ボーグとは、Googleが自社のインフラ管理に使用していた社内システムの名称で、Kubernetesはボーグの簡易版です。）
ジョー・ベダ：それだけですか？
ブレンダン・バーンズ： そうですよね？
ジョー・ベダ： ええ、分かりません。
ブレンダン・バーンズ：その通りだと思います。（聴衆に向かって身振りで示す）彼らは知っているでしょう。（聴衆も同意する）彼らは私に話してくれたんです。分かりますか？
クレイグ・マクラッキー：そう、ボーグの大使だ。ああ、なかなかいい役だったよ。
