Google Cloud Platformにおける「オープン」の正確な意味を、サム・ラムジ氏に聞いた：Kubernetesオープンソース化の背景（2/2 ページ）
Google Cloud Platformが単なるマーケティング活動の一環で「オープン」を唱えているのではないとすれば、どういう理由で、何を、どうオープンにしているか、それは他のパブリッククラウドとどう違うのか。その答えを求めて、Google Cloud プロダクトマネジメント担当バイスプレジデントのサム・ラムジ氏に、個別インタビューした。
「オープンであること」とビジネスとの関係
――最も聞きたいと思っていたことの1つは、「オープンソースやオープン性から、どのように良いビジネスを築くことができるか」ということです。
純粋に資本主義的な観点で言って、オープンであることは参入障壁を引き下げられます。LinuxとWindowsの関係にも、これが当てはまります。2000年代初期に、Microsoftは非常に高い壁を築いており、誰も破れないと考えていました。ところがLinuxはある程度の時間をかけて、これを崩しました。これにより、Linuxエコシステムの多数のベンダーが参入できました。
「non-market forces」という言葉があります。自動車では「環境に優しい車」としてアピールするケースがよく見られますが、当初は製品が完全ではなくとも、あなたの考え方に訴えることが可能です。クラウドでは現在、AWSが高い壁を築いていますが、「オープン」「自由」を訴えることで、競争の場をよりフラットなものにすれば、私たちのインフラが競争に参加できる機会が生まれます。
私は、GCPの仮想マシンやネットワーク、ストレージのパフォーマンスが、AWSやAzureに比べて優れていると思っていますが、オープンでないならば、誰が気にするでしょうか？ プロプライエタリなクラウドサービス同士が競う世界しかありません。
非常にプラグマティック（現実的）な意味で、ナンバー3であるGCPはオープンでなければならないのです。もちろん、正しいことでもあります。
オープンであるという理由から、GCPを試してくれる人はいるでしょう。そして一度試してもらえれば、ダイアン（・グリーン）が話しているように、企業における商談の60％を勝ち取っています。GCPがクラウドサービスで第3位だということを考えれば、悪くない勝率です。
私がGoogle Cloudに来た理由もここにあります。2016年7月、Cloud Foundryは現在のKubernetesに似た成長の苦しみを経験していました。
コントリビューターの数は多く、スポンサーには大企業が並んでいるのですが、例えばリリースシステムには金を使ってくれる人がいませんでした。AWSへの支払いコストは、200万ドルに達しました。当時のCloud Foundry Foundationの年間予算は800万ドルでしたから、約4分の1をCI／CD（継続的インテグレーション／継続的デリバリー）システムに費やすことになっていました。そこでエンジニアがGCP上でCIシステムを動かしてみました。結果は驚くべきものでした。2倍高速なサービスを、2分の1以下のコストで運用できると分かったのです。9月には完全なGCPへの移行を決めました。
私はその時に、品質レベルの異なるクラウドサービスだと認識しました。ですが、Google Cloudから誘われた際に、これを受け入れた理由は、「オープンを全面的に受け入れる組織なら、私も信じて仕事ができる」と考えたことにあります。
誰も、進んでオープンになどなろうとしません。ナンバー1の企業なら、オープン化はあり得ません。オープンになろうと考えるのは、市場における競争で力を得たいと考えるからです。そして、オープンになるなら、完全にやり遂げなければならないと思います。マーケティング過多であれば、人々はその匂いを敏感に感じ取るからです。
人は人を信じることができますが、組織を信じることは難しいと思います。組織の目標は容易に変わるからです。しかし、ある組織が成功のために、特定の物事をしなければならない状況に追い込まれているなら、この組織がそれを必ず実行すると信じることができます。Googleはこういう状況にあると思いますし、私はこれを信じて入社しました。
クラウドサービスにおける抽象化と、オープンソースによる抽象化
――クラウドサービスの魅力の1つは、さまざまな機能を抽象化して提供することです。抽象化してしまえば、ユーザーはあなたのサービスのAPIを使うのであり、その下で使っているのがオープンソースソフトウェアだろうが、プロプライエタリなソフトウェアだろうが、ユーザーには見えませんし、関係ありませんよね。
非常に良いポイントだと思います。ある場合には、オープンソースソフトウェア自体が抽象化の機能を果たします。例えばコンテナやコンテナオーケストレーションがこれに当たります。
Google社内や社外のさまざまな人々に、「どういう場合にオープンソース化すべきなのか」と頻繁に聞かれます。
あるソフトウェアがもたらす抽象化が非常に強力で、そのため多くの人に採用してもらう必要があるとき、オープンソース化は、このソフトウェアを広げるための有効な手段になります。このことは、ソフトウェアをオープンソース化すべき、非常に良い理由となります。
一方、サービスがあります。サービスはインフラそのものではありませんが、オープンなAPIを提供する必要があります。サービスにおけるオープンAPIは、非常に各分野特有です。Cloud Spannerの場合、データベースのクエリについてはSQL ANSI 2011が使えます。標準が存在する場合には、できるだけこれを採用すべきです。
（標準が存在しない）新しい分野については、APIをドキュメント化し、知的財産権を主張しないことで、他の人々によるコピーを許すべきです。他がやっていないことなら、あなたが抽象化したものですから、そのAPIはポータブルではありません。しかし、誰か他の人がインタフェースをコピーして別の実装を生み出せば、話は変わってきます。
あなたの指摘は正しいと思います。オープン戦略を語るとき、「何をコミットしているのか」「どれだけ余分なエンジニアリングを負担しようとしているのか」「参照実装を提供するつもりがあるか」「オープンソースにするのか、APIより下をオープンにすべきか、市場はそれを求めているか」、といったことを、ソフトウェア1つ1つについて熟考しなければなりません。
現在に至るまで、こうしたことを考えた組織はありませんでした。オープンソース、オープンクラウド、オープンAPIを1つに融合したことで、Googleが初めて取り組むことになりました。
この点で、私が頼りにしている方策の1つは、顧客諮問委員会です。顧客に「何が欲しいですか」と聞いています。現在、クラウドは第2の段階に入っており、マルチクラウドに興味を持つ組織が増えています。
サーバレスコンピューティングとオープンソース
――サーバレスコンピューティングに関する戦略はどのようなものですか？
大好きなトピックです。幾つかのことが言えます。
サーバレスは現時点では、大部分がクラウドネイティブなサービス間の「接着剤」のような機能を果たしています。Node.jsをはじめとするオープンな開発言語を、関数中心の考え方で活用し、各クラウドサービス特有の抽象化された機能にアクセスします。AWS Lambdaを使うなら、Amazon S3やAmazon Red Shiftにアクセスするわけです。そのコードは別の環境に持っていっても機能しません。通常、このクラウドネイティブな統合を、別のクラウドで動かしたいとは思いませんので、一部を除いて問題はありません。
もう1つの面白い議論は、「開発者が望む抽象化とは何なのか」ということです。関数に基づくサーバレスが、次のPaaSなのか。開発者がインフラを完全に考えなくてよくなる世界を本当に求めているなら、先ほどの議論に出たように、オープンソースによる抽象化が役立つ分野となり得ます。
現在のサーバレスコンピューティング分野における主要オープンソースソフトウェアは、ほぼ全てがKubernetesを使っています。これを非常に興味深く感じています。開発者が関数のみによるプログラミングを本格的に始めるとしたら、デスクトップ環境からローカルのテスト環境、クラウドの本番環境まで、全て同じ環境が欲しいというニーズが出てくるからです。
今は非常に初期の段階ですが、私の目標は、開発者が単一の共通な環境を活用できるようにしていくことです。その下でどんなスタックを使っていたとしても、関係がない。そうした世界を目指したいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.