KubeConサンディエゴ：CI/CDを始めるJFrogに訊いてみた

Kubernetesを中心とするクラウドネイティブなシステムのエコシステムの中で、CI/CDは今やレッドオーシャンである。多くの利用実績を誇るCloudBeesのJenkins、GoogleがプッシュするTekton、SaaSで実績をアピールするCircleCIそしてGitHubがActionsを使って実装したCI/CDまで、選択肢は数多い。そんな中、バイナリーリポジトリーの代表的なソフトウェアであるArtifactoryの開発元であるJFrogが、CI/CDの領域に打って出ようとしている。そこで、KubeConでJFrogのデベロッパーリレーションチームの責任者であるStephen Chin氏にインタビューを行った。

JFrogのDeveloper RelationsのSenior Director、Stephen Chin氏

自己紹介をお願いします。

私はJFrogでデベロッパーを支援するチームのシニアディレクターをやっています。JFrogの前は、Oracleで同じようにデベロッパーリレーションの仕事をしていました。その前もエンジニアとしてアプリケーションの開発から実装までを、DevOpsという言葉が登場する前からやっていました。

OracleからJFrogということでだいぶ企業のカルチャーが違うと思いますが、JFrogに移った時に違和感はありませんでしたか？

確かにJFrogとOracleとはだいぶカルチャーが異なりますね。JFrogはすでに創設から10年以上経っていますが、未だにアーリーステージのスタートアップという雰囲気です。Oracleとは確かに違いますが、デベロッパーを支援するという部分ではやっていることは変わっていないと言えます。JFrogは技術オリエンテッドな会社で、開発もサポートも充実しています。実は私、元々JFrogのユーザーだったのですが、その当時のサポートエンジニアの担当者が今のJFrogのCTOなんです。

ユーザーであった時代から付き合っていたエンジニアがCTOになったということですね。では、JFrogの今回のKubeConでのトピックを教えてください。

今回、発表したのはJFrog Container Registryです。JFrogのArtifactoryは、バイナリーのレジストリーとしてはすでに多くの顧客やオープンソースプロジェクトで使われています。JFrog Container RegistryはそれをDockerに特化させた形のソフトウェアですが、DockerコンテナだけではなくHelmのChartも対象にしているところが差別化のポイントですね。あとはオンプレミスとパブリッククラウドの両方をサポートしています。Container Registryを自社のクラスターにデプロイする場合は、完全に無償で使えます。一方パブリッククラウドで使う場合は、ファイルサイズと転送量によって利用料が変わります。

OracleのようにCPUのコア数で課金されるというようなものではなく？

そうですね。パブリッククラウドで使う場合、最初の1年間は毎月2GBまでのストレージ、毎月5GBまでの転送量はFree Tierとして無償で利用可能です。それを超える場合は1GB当たり10セントが毎月課金されます。Free Tierを使えば、まず評価のために利用を開始するということのハードルは非常に低くなります。他にも今回はXrayというイメージスキャンニングのソフトウェアもブースでは紹介しています。

バイナリーリポジトリーのJFrogが、CI/CDも提供すると聞きましたが？

それはJFrog Pipelineですね。JFrogの製品で最も知られているソフトウェアはArtifactoryになりますが、それを中心にCI/CDを実装したのがPipelineです。モダンなCI/CDを実現していますが、ユーザーは自分たちがすでに使っている従来のツールを組み込むこともできます。そこには選択の自由があると言えますね。もちろん、Container RegistryやJFrogの他のソフトウェアとも統合されていますので、JFrogのソリューションが使いやすいと我々は考えています。ですが、ツールを自由に選択できるというのは重要なポイントです。

JFrogの戦略について教えてください。

JFrogのArtifactoryはすでに多くのデベロッパーに使ってもらっていますが、Artifactoryの利用が拡がったのは主にコミュニティの力だと思っています。つまりまずは無償のソフトウェア、サービスを使って開発を行い、それが徐々に大きくなってセキュリティやスケーラビリティが必要となってきた段階で、有償のソフトウェアやサービスに移行するというのが自然な流れになっていると思います。JFrogは、その部分に関しては非常に良い仕事をしていると思います。

特に開発を行うエンジニアだけではなく、サポートやコンサルティングを行うエンジニアも非常にテクニカルなエンジニアが多く、信頼できると思います。よくあるバグなどのインシデントを単にワークフローに従って回しているという担当者ではなく、自社のソフトウェアをよく理解していますし、使い方も熟知しています。そのため、コンサルティングも質の高い仕事をしていると思います。先ほども触れたように、私がJFrogのユーザーだった頃に担当してくれたサポートエンジニアは今のCTOですから、サポートの重要性はよく理解していると思いますね。

日本市場においても同様にデベロッパーに対して働きかけを行う予定ですか？

そうです。JFrogにとって日本は、多くのデベロッパーとビジネスが存在する魅力的な市場です。私のチームでも日本のユーザーにリーチするためにデベロッパーアドボケイトを採用しようと考えています。私も数ヶ月前に日本に行き、ユーザーやパートナーとも会いました。Javaのユーザーグループのミーティングにも参加しましたし、日本の状況は理解しています。日本での露出を高めるための活動を増やしていく予定です。

最後にJFrogもしくはあなたにとってのチャレンジは何ですか？

人を雇うこと、ハイヤリングですね（笑）。いや冗談ではなく、シリコンバレーで良いエンジニアを雇うのは難しい仕事なのです。

今回、DockerのEnterprise部門がMirantisに売却されました。それについてのコメントは？

Dockerは、コンテナがここまでの流れになる最初のきっかけを作った企業ということで、大きな貢献をしたと言えると思います。しかし同時に二つのコードベースの開発を進めるというのは、非常に難しいということは確かですね。GitHubを例に挙げますと、SaaSであるGitHub.comとGitHub Enterpriseは別のコードで、それぞれに新機能を追加して同期させるというのは難しい仕事です。

Dockerのように、コミュニティ版が上手く行っていたとしてもそれをエンタープライズ向けに仕上げるのは、非常に難しい仕事だろうなというのが私の感想ですね。実際にはDockerのコミュニティベースのソフトウェアとEnterpriseは、上手く連動できていなかったのかもしれません。我々は誰もがDockerを使っていますし、Docker Swarmが出てきた時にこれは上手く行くかもしれないと感じたことも確かです。しかしKubernetesが出てきてすべてが変わってしまいました。

もうDocker Swarmを話題にする人はいませんね。

そのレイヤーについては、すでに決着が付いたということです。

JFrogのブース

日本国内ではArtifactoryの開発元として知られているJFrogだが、セキュリティのXrayやCI/CDのPipelineなどの自社製品によるエコシステムの強化を行う方向にシフトを始めているようだ。Chin氏が語ったように、デベロッパー自身がJFrog製品を使うことで草の根的に拡がっていくというやり方を加速するための施策を、2020年には期待したい。