Puppetの最高製品責任者が、急速に変化する現代のソフトウェア開発の世界をどう乗り越えているか
私がこう言うと誰も信じてくれませんが、エンタープライズ テクノロジーの世界はここ数年で実に刺激的な展開を見せています。
コンピューターを使ったほぼすべての作業の背後にあるテクノロジーの急速な変化は、たとえコンピューターに身を捧げてきた人々でさえ、理解に苦しむほどです。しかも、こうした変化は必ずしも容赦がありません。企業の技術界における目覚ましい新参者から、開発者が一刻も早く解消したい埋没インフラコストへと転落するのに、それほど時間はかかりません。
ソフトウェア自動化企業Puppetに関しては必ずしもそうではありませんが、エンタープライズテクノロジーのより魅力的な部分は、Puppetの既存事業から離れ、企業が自社管理サーバー向けにソフトウェアをより迅速かつ確実に開発できるよう支援する分野へと移行しつつあると言えるでしょう。クラウド、コンテナ、そしてサーバーレスコンピューティングといった新興技術は、ソフトウェアファクトリーツール事業に関わるすべての人々の状況を一変させており、Puppetは2017年2月に入社したオムリ・ガジット氏の指揮の下、製品の方向性を転換しようとしています。
2005年に設立されたPuppetは、500人以上の従業員を擁し、1億700万ドル以上の負債および株式による資金調達を実施しています。同社は先月、従業員の3%を削減しました。これは、同社が「従業員の再編により、顧客のためにより迅速なイノベーションを実現できる」と述べている施策の一環です。
先日、ガジット氏と私はポートランドのダウンタウンにあるPuppetのオフィスで、Puppetの製品戦略の現状とエンタープライズテクノロジーの世界全体について、幅広い議論を行いました。以下のトランスクリプトは、長さと読みやすさを考慮して若干編集されています。
GeekWire: それで、入社した時、どんな指示を与えられたんですか？在職期間中、どんなことを求められたんですか？
オムリ・ガジット：サンジェイ（ミルチャンダニ、Puppet CEO）と初めて話をしたとき、彼の頭の中にはいくつか考えがありました。一つは、ルーク（カニエス、Puppet創業者で元CEO）が会社を去ることです。彼は取締役会には残り、業務には関わり続けますが、業務運営には関わりません。正式なCEOの役割以上の役割を担う必要があるのです。また、製品のイノベーションと戦略に注力する必要もありました。サンジェイはそのために適したパートナーを探していましたが、まさに私が探していたのはまさにそれでした。
しかし、さらに魅力的だったのは、サンジェイが開発者の世界、クラウドの世界、コンテナの世界にとって関連性があるだけでなく、必要不可欠であるという強い使命感を持っていたという事実です。
自動化プラットフォームを構築するというアイデアは非常に強いものでした。そして、Puppet社にはまさにその志を持つ企業があり、業界の自動化プラットフォームとなることを目指していました。私と会社としての考え方を一言で表すとすれば、包括的な自動化プラットフォームを構築したいということです。自動化とは、単にシェルスクリプトをラップして、それを一度きりで実行できるということではありません。私たちは自動化を継続的なプロセスとして考えています。
これは、私たちが提供するすべての製品に当てはまります。先日リリースしたPuppet Discoveryは、継続的なディスカバリ製品です。この製品の最大の目的は、稼働中のIT環境を常に最新の状態に保つことです。現在使用しているソリューション、例えばCMDBなどの従来型のソリューションは、導入した瞬間に時代遅れになってしまいます。そのため、継続的という概念は、私たちのあらゆる活動に浸透しており、継続的な構成自動化、継続的なデプロイメントなどにも適用されます。オリジナルのPuppetエンジンは、基本的にモデルを構築し、それを継続的に適用することに重点を置いていました。継続的なインテグレーション、継続的なデリバリー。これらはすべて、私たちにとって非常に重要な概念です。
競争環境という観点から、Puppetはどのような位置づけにあるのか？Puppetが世界の中でどのような位置を占めているのかという従来の認識がありますが、それを少し変えて、他の市場にも進出したいと考えているようですね。
オムリ・ガジット：伝統的に、私たちはガートナーが「継続的構成自動化」と呼ぶ分野に生きています。これは、私たちの従来の製品でさえも、人々がどのような用途で利用しているかという点からすると、かなり狭い定義です。私たちが特に目にした点の一つは、アプリケーションリリースの自動化、つまりARA（アプリケーションリリース自動化）に私たちの製品がかなり多く利用されていることです。昨年のForrester Waveレポートでは、私たちは非常に高い評価を受けました。これは、いわばこの分野で第一級の製品、Puppet Pipelinesをリリースする前のことでした。
従来のIT業界におけるPuppetとその役割は理解していますが、マルチクラウド、ハイブリッドクラウドなど、様々なクラウド環境が生まれ、クラウドベンダーも多くのサービスを提供しています。世界最大級の企業が強く求めている領域に参入しているという点について、どのようにお考えですか？
オムリ・ガジット：お客様が常に私たちに求めてきたものの一つは、プラットフォームに依存しない抽象化です。しかし、基盤となるオペレーティングシステムを本質的に抽象化する単一のフレームワークを持つことは、特定の層のお客様にとって非常に価値がありました。そして幸いなことに、そのセグメントは大規模です。私はこれをオープンハイブリッドセグメントと呼んでいます。
オープンクラウドとプロプライエタリクラウド、そしてパブリッククラウドのみとハイブリッドクラウドの世界について考えてみると、その象限、つまりオープンハイブリッドは、私たちが実際にかなりの確率で勝利を収めている象限です。例えば、Amazon Web Services（AWS）に100%賭けている組織は確かに存在しますが、それはそれで良いことです。彼らはこのプラットフォームを最大限に活用しようとしています。例えば、彼らはCloud Formationを使って、（仮想マシン）、ストレージ、ネットワーク、セキュリティグループなど、AWSが持つ様々なリソースの作成を自動化しています。
しかし、私たちが多くの時間を割いているお客様、つまりエンタープライズのお客様は、環境が非常に複雑です。オンプレミスとクラウド、そして従来型のアプリケーションとコンテナ化されたアプリケーションが混在しています。こうした複雑な環境に対処するための支援が必要であり、特定のソリューションに縛られる余裕はありません。そのため、これらのお客様にとって、AWS、Azure、オンプレミスを問わず、これらすべてをモデル化できる単一のプラットフォームと単一の言語を提供する当社のフレームワークは非常に魅力的です。これは非常に強力な点です。
付け加えると、私たちがシステム管理を始めようとした当時、OSベンダーである必要はなかったですよね？つまり、そのレイヤーの上に乗ることができたのです。
あなたが入社されてからこの15ヶ月の間に、レイヤーがコンテナレベル、オーケストレーションレベルへと移行し、それが現在より重要な基盤となっているように思います。Puppetはその世界でどのような位置づけにあるのでしょうか？
Omri Gazitt:ええ、その点についてはたくさん話したいことがあります。数週間前にInfoWorldに「コンテナが世界を席巻している」というゲストコラムを寄稿しました。これはMarc Andreessen氏の古い記事へのオマージュで、私たちもその考えに賛同しています。私たちは日々、その状況を目の当たりにしています。アプリケーション開発は大きく変化し、アプリケーションをコンテナイメージとしてパッケージ化するという大きな潮流が押し寄せています。Kubernetesは新しいオペレーティングシステムだと考えています。このアナロジーは、私がチームでよく使っているものです。オペレーティングシステムを所有していなくても、それを効果的に管理する上で不可欠であるように、Kubernetesにコンテナ化されたアプリケーションの構築とデプロイのプロセスに不可欠であるために、Kubernetesディストリビューションを所有する必要はありません。
Kubernetesに賭けたのは、おそらく1年前でしょう。当時は安全な賭けでした。3年前は、それほど安全ではなかったかもしれません。しかし、マルチベンダーのオープンソース・エコシステムが勝利するのは明白であり、そのレイヤーにあるものはすべてコモディティ化していることも同様に明らかです。Red Hatはディストリビューション企業であり、あらゆるディストリビューションを統合しようとしています。彼らはディストリビューション市場を独占しようとしています。私たちにとって、そこは興味深い市場ではありません。私たちが構築したいのは、本質的にはコンテナとデリバリー・プラットフォームであり、その上に構築されるものです。
重要な認識は、自動化は基本的に稼働中のシステムにおける変更管理から、ビルドおよびデプロイのパイプラインを通じた変更管理へと移行したということです。なぜなら、ビルドおよびデプロイのパイプラインから生成されるのは不変イメージだからです。つまり、その不変イメージにエージェントをインストールし、それらのエージェントを通じて稼働中のシステムに変更を加えるというやり方はもはや通用しません。これはもはや通用するモデルではありません。代わりに、自動化プロセスを実際に支援したい場合は、制御ポイントをCI/CDエンジンに移行するというモデルです。これが、昨年末に（シアトルのスタートアップ企業）Distelliに投資し、彼らを買収した理由です。私たちは既にARA、つまりアプリケーションリリースの自動化に強みを持っていましたが、パックが向かう先、つまりコンテナ化されたアプリケーション配信へと飛び込みたいと考えました。
そこで私たちは、Puppet の新しい製品ライン「Puppet Pipelines」をリリースしました。これは、従来型アプリケーション向けの競争力の高い製品である Puppet Pipelines for Applications と、Puppet Pipelines for Containers です。これら 2 つの製品ラインを揃えることは、実は非常に魅力的です。なぜなら、私たちのお客様全員、100% が従来型アプリケーションを使用しているからです。中には、本番環境でコンテナ化されたアプリケーションを使用しているお客様もいますが、ほぼ全員がそちらに移行したいと考えています。つまり、この 2 つの分野に足場を構えることで、信頼できるベンダーになることができるのです。こうした状況で私たちが成功を収める場合、多くの場合、お客様は、私たちが全く異なる世界へと移行するまで価値を提供しないのではなく、現状の顧客のニーズに応えることができたと評価してくれます。
今年、私が話す相手全員に必ず尋ねることの一つが、マルチクラウドについてです。複数のパブリッククラウドで本番環境のワークロードを運用するなど、ビッグ3のクラウド間でバランスを真に実現しているという声を耳にすることが多くなってきています。御社の顧客情報から判断すると、2018年に実際にそうしている企業はどれくらいあるでしょうか？
オムリ・ガジット氏：そうするお客様が増えています。つまり、3世代に分かれていると言えるでしょう。第1世代はAWSです。しばらくの間、AWSは非常に安全な選択肢で、他に選択肢がありませんでした。第2世代は、Amazonを競争上の脅威と見なし、AWS以外の選択肢を探していたお客様です。オンプレミスでOpenStackを使うことも可能で、Azureはその恩恵を最も受けていると言えるでしょう。多くのお客様が、いわば小売業者であるAmazonと対立関係にあるため、Azureに戦略的投資を行っているのが現状です。
そして、現在私たちが目にしているこのフェーズは、様々なクラウドにバランスの取れた投資を真に望む企業を中心に展開していると言えるでしょう。Google Cloud Platformへの関心は、昨年、一昨年と比べて大幅に高まっています。特にアジアでは、IBM Cloudを深く活用しているお客様が増えています。北米ではほとんど見られませんが、IBMは広大な帝国を築いており、シリコンバレーから離れるほど、IBMやOracleといったベンダーがシリコンバレーへの参入を志向しているのが分かります。
地域によって状況は大きく異なりますが、国内でもハイブリッド展開を行っているお客様の数は増加傾向にあります。多くの場合、AWSとGCP、あるいはGCPとAzureを組み合わせて利用されていると思います。Puppet Container Registryのシナリオについてお話ししましたが、そのキラーアプリの多くは、これらのレジストリにDockerプッシュを行い、イメージを実行場所の近くに自動的に配布できる機能です。Puppet Pipelinesはマルチクラウド製品として構築されています。
オンプレミスのワークロードの役割を常に認識していますか？あるいは、ある時点で、オンプレミスのワークロードを実行すること自体が意味をなさないのではないかと考えることはありますか？
オムリ・ガジット：スティーブ・ジョブズが言ったように、コンピューターやiPadについて語る時、車やトラックについても話していたはずですよね？ 彼が予測した通りにはならなかったかもしれませんが、このアナロジーは悪くありません。今日起業する企業は、クラウドの中で生まれたようなものです。サーバーを買う必要などありません。絶対にありません。
まあ、戦略をDropboxに保存して、ある時点で元に戻るというのであれば別ですが、それは興味深いですね。それはまた別の話になるかもしれません。
オムリ・ガジット：そうです。この移行を促す要因の一つは、ストレージ供給元である同じ企業との競合です。これは耐え難い状況です。Dropboxはインフラ企業ですが、大多数の企業は真のインフラ企業ではありません。そのため、新興企業の大多数は、インフラに関してオンデマンド型のアプローチを求めていると思います。
既存の企業、つまりほぼすべてのエンタープライズ顧客にとって、いわばITのすべてをクラウドで運用するには、依然として大きな障壁があると思います。私がHPにいた頃は、アドバイザリーサービスチームがBritish Petroleumのような企業を訪問し、文字通り1万ものアプリケーションを運用していました。最初の数か月は、基本的に評価を行うだけでした。
しかし、おそらく20%のアプリケーションは変更する価値がないことが判明しました。それらをどこかに移動してもROIが得られませんでした。そのままにしておく方がはるかに賢明でした。そして、おそらく残りの20%のアプリケーションは、もはや保持する意味がありませんでした。ただ利用可能なSaaSサービスもありましたが、（それらの）アプリケーションを継続的に実行しても全く意味がありませんでした。「既製」のサービスとして利用できるものに切り替えるだけでした。また、クラウド（仮想マシン）にリフトアンドシフトできるアプリケーションもあり、それは理にかなっています。そして、実際にモダナイズすることでROIが得られるアプリケーションもありました。これはごく一部ですよね？
ですから、あらゆるものがクラウドに移行し、あらゆるものがコンテナに移行するという考えは、あまりにも誇張されていると思います。同時に、全く新しいグリーンフィールドアプリケーションがクラウドネイティブで、コンテナとしてパッケージ化されるということを100%信じていない人は、混乱していると言えるでしょう。
そのため、当初は「コンテナだけ、クラウドだけ、コンテナかクラウドか」と非常に力強く主張していたベンダーの多くが、ここ2、3年で特にその傾向が強まっています。実際に価値、顧客、そして収益につながるようにするために、彼らはストーリーをかなり後退させなければなりませんでした。思い出します。2年前、まだベン（ゴラブ）がまだDockerを率いていた頃、彼はシアトルのステージに立ってこう言いました。「ねえ、皆さんに理解していただきたいのですが、これは既存のモノリスをコンテナ化することです。」人々は「何だって?!」という感じでした。しかし、それはDockerが、既に多くのものを持っていて、持っているものをすべて捨てることなくコンテナの波を受け入れる方法を模索している聴衆とつながる必要があったという事実を反映していました。
繰り返しになりますが、Puppetとの提携に非常に満足している理由は、お客様から非常に高い評価を得ているブランドだからです。そして、言うまでもなく、最大の課題は、私たちが未来へと導くベンダーであることをお客様に確実に理解していただくことです。しかし、これまで多くのお客様と築き上げてきた信頼関係は、私たちにとって大きな財産です。
競争の観点から見ても興味深いですね。というのも、御社は一つの場所からスタートし、顧客をコンテナの世界に少しずつ引き込もうとしているからです。コンテナの世界でスタートした企業が、オンプレミスの世界へと戻ってきようとしているのが現状です。「コンテナはお任せします。あとはお客様のニーズを把握します」と言っている企業と競合することになりますが、御社は「まずはお客様のニーズを把握し、コンテナの活用方法をお手伝いします」と言っているわけです。このアプローチはどのような反響をいただいており、どのようにお考えですか？
Omri Gazitt:もちろん、お客様は私たちを気に入ってくださっているので、多少の選択バイアスがあるかもしれませんが、過去 6 か月から 12 か月分のお客様との会話はすべて、このような感じでした。
「ねえ、君たちは何か新しいことをしてるの？」
「そうですね、私たちは CI/CD (継続的インテグレーション/継続的デリバリー)、クラウド、コンテナに重点を置いています。」
「へえ、まさにそれなんです。助けてもらえませんか？問題解決に役立つものはありますか？」
「さて、CI/CD、ここで何をしているのか説明しましょう。」
「ああ、あれは必要だ。買いたい。実は、Puppetを使って競合製品の展開をしようとしていたんだ。Jenkinsサーバーの展開も自動化しようとしていた。でも、今はもうそんなことはしなくていいんだ。だって、君が今、その問題も解決してくれているんだから。」
計画していた隣接分野への進出の可能性は十分にあり、これは私たちにとって非常にうまく機能しています。とはいえ、海面上昇はすべての船を浮かべるものであり、コンテナネイティブまたはコンテナオンリーの機能を備えて生まれた企業が成長し、繁栄していることは明らかです。ですから、私たちの考え方は気に入っています。なぜなら、最初から1,000社をはるかに超える大規模な顧客基盤を持つことができるのは、戸別訪問をして最初の数社を見つけるのに苦労するよりも、常に良いことだからです。
Puppetは、まさにそれを実現するのに最適な規模の企業だと感じています。新技術への取り組みが、旧来の企業というイメージに埋もれてしまうような巨大企業ではありません。同時に、Puppetには確固たるビジネス基盤があります。私たちは、新たな市場や隣接分野への進出に向けて、豊富な経験と実績を活かして事業を拡大していくことができます。
昨年12月にテキサスで開催されたKubeConで、PinterestがKubernetesとコンテナへの大きな賭けに出たというプレゼンテーションを見に行きました。Pinterestは完全にクラウドベースで構築されている会社なのに、「うわあ、もう時代遅れだ。業界の変化が速すぎて、（もう）やり方を見直さないといけない」と思うと、ちょっとおかしく感じました。
特に特に驚いたのは、彼らがデリバリープロセスを自動化していたPuppet関連の技術の多くを廃止しようとしていたことです。こういったプレゼンテーションではまず見られない話です。というのも、こういったことは一般的に…お二人ともこういったイベントに何度も参加されていると思いますが、こうしたプレゼンテーションでベンダーの名前が挙がるのは滅多にありません。
オムリ・ガジット：コモディティとして利用できるものは増え続けており、それに適応していく必要があります。Puppetなどの技術や、この分野の他の技術を使ってアプリケーションのデプロイメントを自動化していた多くの人々が、Kubernetesにそれらの多くの作業を任せているという状況に移行しつつあります。例えば、Kubernetesはローリングアップデートによってアーティファクトのライフサイクル管理を行います。コンテナ化されたアプリケーションの健全性を監視するという概念は、エージェントを導入しているすべての監視企業にとって破壊的なものです。ロギング、つまり様々なコンテナイメージから生成されるログを集約するという概念は、SplunkやElasticSearchなど、ロギングやログ管理を行うすべての企業にとって破壊的なものです。
では、これらの企業は一体何をしているのでしょうか。彼らは新しい抽象化を認識し、それを中心に構築しています。Puppet も例外ではありません。そのため、私たちにとって自動化への重点は、コンテナ イメージ上に存在するエージェントを通じて変更を管理する必要があるという主張から、ビルド、テスト、デプロイのサイクルを自動化することで自動化プロセスに価値を追加したいという点へと移行しました。「GitHub リポジトリのブランチに WebHook を登録し、コンテナ イメージを自動化して基本的にビルドします。その上で Docker ビルドを実行するだけです。その後、Kubernetes にデプロイします。」というシンプルなデプロイメント パイプラインを作成するのは簡単です。これは簡単です。しかし、開発からステージング、そして本番環境へのプロモーションを手動オーバーライドで管理できる、プロセス全体を含む洗練されたパイプラインを作成できるようになると、それは全く別の話です。
Puppetにとってサーバーレスはどのような位置づけになるのでしょうか？そもそも、サーバーレスは検討中でしょうか？
Omri Gazitt:お客様からそのようなご要望をいただいています。サーバーレスについても実験を行っています。従来のアプリケーション、コンテナ化されたアプリケーション、サーバーレスアプリケーションなど、あらゆるアプリケーションのビルド、テスト、デプロイのサイクルを自動化することは、まさに私たちがお客様の課題解決を支援したいと考えている範囲に完全に収まっています。サーバーレスはまだ初期段階です。常に未来へ向かうものですよね？コンテナ、つまりコンテナ技術は、もう20年近く私たちと共にあります。Dockerが登場して初めて、標準化とその後の大規模導入を可能にする、本質的にユーザビリティの高い要素がいくつか揃いました。
私はかなり初期の頃からCloud Foundryに関わってきました。Cloud Foundryの役員も務めており、まさに未来への回帰と言えるでしょう。アプリケーションをCloud Foundryにプッシュするというビジョンは、基本的にコードを提供するだけで、システムがコードを受け取り、依存関係を判断し、ベースイメージと合成し、通信したい様々なサービスへのバインディングを行うというものです。データベースやメッセージキューなど、これは古い考え方です。しかし、今では特に大手クラウドプロバイダーのユーザーエクスペリエンスが向上し、アプリケーション構築の非常に興味深い方法になっていると思います。
クラウドプロバイダーがサーバーレスサービスを提供する方法を見ると、多くの機能が実装されているように見えます。テストとデプロイの自動化など、その多くはサービスに組み込まれています。
Omri Gazitt:そうですね、これは以前、マルチクラウドやハイブリッドクラウドの導入を検討するかどうかという話と同じですね。特定のパブリッククラウドに100%依存するのであれば、そのプラットフォーム全体を導入するインセンティブがある程度あります。
1998年にマイクロソフトに入社しました。まさに最適な場所で、最適なタイミングでした。私は最初の10人のうちの1人でした。スコット・ガスリー、ジェイソン・ザンダー、そして他の数人が、このプロジェクトに着手しました。長い間、私たちはJ2EEに対抗できる価値提案を見つけるのに苦労していました。その価値提案は「一度実行すればどこでも実行できる、すべてが標準だ」というものでした。しかし、J2EEとWebSphereはそれぞれ異なっていました。WebsphereはWebLogicとは違っていたのです。
最終的に、私たちはプラットフォームを構築し、基本的に人々が.NETで開発を行うだろうと想定していました。.NETに賭けるなら、最初から最後までやり通すつもりだったはずです。大手プラットフォーム企業の考え方はまさにそれであり、MicrosoftのAzureに対する考え方も同じです。彼らは基本的に、ユーザーを可能な限り多くのサービスに結びつけようとします。AmazonもGoogleもそうです。しかし、特定の顧客層は、特定のプラットフォームに縛られることを本当に望んでいません。
したがって、マルチクラウドへの移行という概念は、私たちにとって非常に役立ちます。なぜなら、市場が成熟し、人々が真にポータブルでクロスプラットフォームなものを構築しようとしているため、Puppet のような独立系企業があらゆる状況に有効な価値提案を持つことができるからです。
コンテナやKubernetesに関しては、サーバーレスでは大きく異なるように思えます。少なくとも現状の展開方法では、サーバーレスではどのプラットフォームを選んでも、完全にロックインされてしまうからです。Lambdaで何かを構築するなら、Lambdaに完全に依存することになり、Azure FunctionsやGoogle Functionsなどに移行することはできません。それは間違いありません。つまり、サーバーレスのポータビリティの問題については、まだよく理解できていないということです。
Omri Gazitt:どのサーバーレスプラットフォームを選んでも、一貫した単一のツールを使えるようになることが重要です。Google Vision API 用に構築された特定のアプリケーションを別のプラットフォームで魔法のように使えるようになるということではありません。重要なのは、ツールの一貫性と、パイプラインなどの自動化に利用できる言語です。
サーバーレス関数のビルド、テスト、デプロイのサイクルを自動化することは、私たちにとってそれほど大きな変化ではありません。実際、ツールの85%はすでに完成しており、変更が必要なのは最後の部分だけです。
(編集者注: この投稿は、いくつかの転写エラーを修正するために更新されました。 )
