Cloud Foundryについてjacopenさんに聞いてみた

セクションナイン吉田真吾@yoshidashingo)です。

前回に続いて、MasterCloudで話してもらう草間さん(@jacopen )に Cloud Foundry について聞いてみました。

--- 吉田です、今日はよろしくお願いします。はじめに簡単に自己紹介していただいてもよいですか?

草間です、どうぞよろしくお願いします。本名よりもjacopenというハンドルネームほうが定着してまして、そちらの名前で呼ばれることも多いですね。

Pivotalジャパンという会社で、Platform Architectという仕事をしております。Cloud Foundry導入前、もしくは導入検討中のお客様をサポートするのが主な仕事ですね。

その他の活動として、PaaS勉強会Cloud Foundry Tokyo Meetup のオーガナイザーもやっています。

f:id:yoshidashingo:20170809112158j:plain

paas.connpass.com

https://www.meetup.com/ja-JP/Cloud-Foundry-Tokyo-Meetup/www.meetup.com

Cloud Foundryとのかかわりについて

Cloud Foundryなら1人で運用を回せる

--- Cloud Foundry自体はだいぶ昔からありましたよね?草間さん自身はどういう関わりかたをしてきたのでしょうか?

Cloud Foundryは2011年にVMwareからOSSとして公開されたのですが、ちょうどその頃スタートアップでインフラ担当をやっておりまして。そのときはWindows Azure(今のAzure App Service )を利用していました。インフラ担当は私1人だけだったのですが、PaaSを使えばたった1人で運用を回せるぞ、これはすごいぞと。

そんなタイミングでCFに出会い、夢中になりました。ブログ書いたりミートアップに参加したり。 時を同じくしてNTTコミュニケーションズがCFを採用したPaaSサービスを開発しはじめたという話を聞き、これは行くしかない!と。即求人に応募しましたね。

CFでPaaSサービスを開発運用

入社後は開発メンバーとして参画し、2012年末にCFベースのCloudn PaaSをリリース。2013年からは開発リーダーを担当させていただき、新バージョンや企業向けバージョンの開発に携わりました。

おおよそ5年が過ぎ、CFも順調に普及していったところで、よりCFに近い場所で仕事をしたい!と思うようになりました。そこで、CF開発の中心を担っているPivotalに転職したという流れになります。

Fortune500の半数が利用するCF

--- オープン系PaaSって複数あって、Cloud Foundryは歴史的にもその筆頭だと思いますが、利用者もやはり一番多いんでしょうか?

そうですね。今年の6月にシリコンバレーでCloud Foundry Summitというイベントが開催されたのですが、キーノートで「Fortune500に載っている企業の半数がCloud Foundryを導入済み」という発表がありました。開発を主導するCloud Foundry Foundationのメンバーにも、名だたる企業が名を連ねており、利用者数は間違いなく一番だと考えられます

Docker前後の変化

--- Docker以後ってオープン系PaaSの実装もだいぶ変わったんでしょうか?DEISなどは元からDockerベースでしたよね?

全体的なアーキテクチャという意味ではそれほど大きく変わっていないですね。もともとマルチテナントなPaaSを実装するには何らかのアイソレーションの仕組みが必要であり、Docker以前もLXCやその他独自実装のコンテナランタイムが利用されていました。Docker登場以降は、ランタイム部分をDocker Engineに切り替えたり、互換機能を持たせたり・・・という流れです。

ただ、Dockerという使いやすく強力な仕組みが登場したことにより、間違いなくオープン系PaaSの数は増えましたね。DEISもそうですし、FlynnTsuruなどもそうです。PaaSのコアである「アプリケーションを動かす仕組み」の部分は自ら開発しなくともDockerを利用すればよく、あとは周辺機能を作っていけば差別化できるようになった。『俺が考える最強のPaaS』を作りやすい世界になったのは間違いないです。

サービスを利用するか自分で構築運用するか

--- BluemixやK5などのCFベースあるいはPivotal Web Servicesといったサービスを利用する人と、Yahoo! JAPANのように自身で構築して利用する人ってどのくらいの比率でいるんでしょう?またその使い分けってみんなどう決めてるんでしょう?

各サービス具体的な利用者数が公表されているわけではないので、正確な比率は分からないのですが・・・あくまでも自分の感覚になりますが、OSS CFやPivotal Cloud FoundryをプライベートPaaSとして導入して利用している企業のほうが、CFベースのパブリックPaaSを利用している人より多いのではないかなと。パブリックPaaSだとCF以外にもHerokuをはじめ強力なサービスが多く存在する上、OSSならではの特徴も生かしづらいので。一方、組織内部に導入したり、基盤の運用そのものもコントロールしたいという需要に対しては、CF以外の選択肢がそれほど多くないため強さが際立っています。

--- そもそもPaaSってインフラ(VM/コンテナ)の抽象化で開発者からは負荷分散やスケール変更が簡単にできるだけでなく、CI/CDのようなアプリのライフサイクル管理機能が便利だったりしますが、そういったPaaSならではでCloud Foundryの最近の「押し」の機能って何かありますか?

最近・・・ではなく以前からある仕組みなのですが、「Service Broker」という仕組みは今も昔も強みですね。CFのコマンドやGUIからサードパーティーのバックエンドサービスを簡単にプロビジョニングできます。コマンド一発でAWSのRDSを作ってアプリにバインドできるんですよ。すごく便利で、まさにPaaS!という感じの機能です。実は今、これをベースにした「Open Service Broker」という仕様を策定中でして、近い将来CFをだけでなくKubernetesでも同じ仕組みを使えるようになります。「CFならでは」じゃなくなりますが、エコシステムが広がるので楽しみです。詳しくは僕のスライドを参考にしてください

www.slideshare.net

Concourseという別のCIツールも

ご質問にもあるCI/CDについてですが、CF自体は非常に簡単なコマンドでアプリケーションのデプロイや削除ができます。なので、CIツール等からCFのCLIやAPIを叩いて実現する形になりますね。CIツール自体をCFの機能としては提供する予定ないのですが、PivotalがConcourseというCIツールをOSSで提供していて、CFの開発にも利用されています。このツール、ほんと便利なのでおすすめです! 最近、ブラウザで有名なFenrirさんが「Jenkins はもうオワコン? Concourse CI で iOS 向けビルドをやってみた」という刺激的なタイトルで紹介記事を書かれていました。

blog.fenrir-inc.com

構築の手間は以前の1/4程度に

--- 草間さんのスライドでCFのセットアップが大変との記載を見たことがありますが、最近はどうなんでしょうか?

スライドを書いた当時に比べるとかなりマシになりました! かかる手間は1/4くらいになってるんじゃないかなと。ただ、それでもコマンド一発というわけにはいきません。CFのインストールはIaaSレイヤーのAPIを叩いて自動でVM作成までやっちゃうBOSHという仕組みを利用する必要があり、どうしても最初の設定項目は多くなってしまうんですよね。その分、運用フェーズに入ると、他の仕組みよりも楽ちんなんですが。

CFでビジネスするためには

--- 私自身2年間くらいサーバーレス界隈見てきて、海外だとこういったパラダイムシフトの上でどうマネタイズするか真剣に考えてる人が多い印象なのですが、PaaS界隈のビジネス的な海外動向や国内動向ってどんな話題がありますか?

ビジネスの観点でいうと、PaaSというカテゴリ自体がハイプ・サイクルの幻滅期を過ぎたあたりだと考えています。なので、皆が注目するキラキラしたジャンルではとうの昔になくなっていて、実際これを導入することでいくら得すんの?とシビアに見られることが多いですね。

一方、先ほども紹介したようにFortune500企業の半分がCF採用しているという話もありますし、商用であるPivotal Cloud Foundryもかなり順調に導入が進んでいます。Red HatのOpenShiftも好調のようです。ですので、幻滅期を超えて着実な普及期に入ったのかな、という実感はありますね。今年のCloud Foundry Summitも、新機能の発表や導入方法ではなく、実際のユースケースについてのセッションが多かったのが印象的でした。国内では海外に比べるとやや出足は鈍いですが、それでも導入は結構進んでいます。

あと、最近MicrosoftがDeisを買収したのは大きなトピックになりましたね。Deisはどうマネタイズを行っていくのか興味をもって見ていましたが、Engine Yardに買収され、次にMicrosoftに買収されて今に至ります。既にさまざまなサービスを提供しているMicrosoftがDeisをどう扱っていくのか、非常に気になっているところです。

コミュニティについて

--- PaaSの普及にとってコミュニティってどういう側面で大切なんでしょうか?

PaaSはその仕組み上「開発や運用を決まったやり方に嵌めてしまう」ものなんですね。その「決まったやり方」は悪いものでは決して無く、従いさえすれば確実に効率が良くなる、いわゆるベストプラクティスなんです。「開発と運用の矯正ギプス」という表現をしても良いかもしれません。ただ、いきなり矯正ギプスをはめられて嬉しい人はいないですよね。なりたい将来像が見えてるとか、最終的に得られるベネフィットが見えて、初めて「ギプス付けるか・・・」ということになる。なので、コミュニティでPaaSについて情報共有するのはすごく重要ですし、利用している間に発生する問題点や解決方法を共有するのも、大切な取り組みだと思います。

ネタの広さと国内最速のトピックの早さ

--- PaaS勉強会は長年に渡り継続的に何十回も続いていますが、これだけ長くコミュニティが継続できる秘訣ってあるんでしょうか?

PaaS勉強会って扱うネタの幅がめちゃくちゃ広いんですよ。DeisやFlynn、OpenShiftといったアプリケーションPaaSもそうですし、今や飛ぶ鳥を落とす勢いのKubernetes、グラフィカルプログラミングツールのNode-RED、サーバーレスのOpenWhisk、いずれも日本で最初にPaaS勉強会が取り上げているんですね。

節操ないと思われるかもしれませんが・・・PaaSという言葉の定義については今でも固まってません。Cloud Foundryのようなアプリケーションを動かすプラットフォームだけをPaaSと定義している例もあれば、DBaaSやCaaSまでPaaSだと定義している例もあります。まあその定義は皆さん好きに行って頂ければ良いと思うのですが、個人的には「何もかも楽をしたい」というエンジニアの欲求が最も具現化しているのがPaaSであり、エンジニアを楽にしてくれるものならば何でもPaaS勉強会で扱っちゃおうくらいに思っています。

今の世の中どんどん良い仕組みが生まれ続けているので、ネタは尽きないんですよね。主催している自分も毎回新しいものを知ることが出来ますし、やっていて楽しいです。なので、このコンセプトがモチベーションの源泉ですね。先日は10年続けます!と宣言しました(笑)。

100人超の会場が確保しにくい

参加者が100人を超える勉強会になってきたので、会場については毎回悩むところです。開催頻度は、ネタの有無よりも会場の確保に左右されているのが現状ですね。会場提供についてのお申し出はいつでも歓迎しております! 今後については、他の勉強会ともコラボして何かやれたらなーと考えているのがひとつ。もうひとつは、東京以外での開催も企画したいなと考えています。実際にいくつか話はあり、そう遠くないうちに地方開催をアナウンスできるんじゃないかなと。

--- ありがとうございました。当日のお話も楽しみにしています。

まとめ

さすが老舗PaaS勉強会のオーガナイザーということで、メイントピックのCloud Foundry以外についても非常に幅広いネタが聞けたという印象でした。

さらに色々聞きたい人は来週のMasterCloudに参加するのだー。

mastercloud.connpass.com

www.slideshare.net

Deisについて寺田さんに聞いてみた

セクションナイン吉田真吾@yoshidashingo)です。

来週のMasterCloudで寺田さんに話してもらうので、Deisについて話を聞いてみました。

https://deis.comdeis.com

--- 吉田です、今日はよろしくお願いします。はじめに簡単に自己紹介していただいてもよいですか?

吉田さん、今日はどうぞ宜しくお願いします。私は 2015 年に日本マイクロソフト株式会社に入社し、マイクロソフトでも継続して Java on Azure をはじめとし、OSS 製品を Azure 上で扱うための啓蒙活動をしています。

Javaとのかかわりについて

--- まずはJavaの話からちょっと進めたいですが、私は昔から寺田さんをJavaのエキスパートとして認知しています。多くの人もそうだと思いますが、寺田さんのJavaとのかかわりやキャリアはどう始まり、今はどう関わっているのでしょうか?

Javaを研究した大学・大学院時代

大学時代に初めて Java (タンブリング Duke) に出会い、そのとき衝撃を受けた事を、今でも昨日の事のように覚えています。本格的に Java プログラミングをするようになったのは JDK 1.1 が出た大学院時代からでした。大学院では、Java に関するテスト技法に関する研究を行っていましたが、特に、産業技術総合研究所の一杉裕志さんが作成した、EPP という「Java の拡張プリプロセッサ」を使い、テストカバレージ・ツールを作りました。

サンへのあこがれで転職

卒業後は、2年半ほど日本企業で Java 関連の開発に携わりました。しかし、大学時代から憧れ企業であり、Java の本家本元でもあるサン・マイクロシステムズは、当時はとても魅力的な企業で、働いてみたいと思うようになり、転職を決意しました。

サンで、サポートや Java コンサル、プリセールス等を経験したのち、Java EE & GlassFish のエバンジェリスト活動をはじめました。オラクルによる会社の買収により Java SE も含めた啓蒙活動を日本全国で開始するようになりました。

日本2人目の Java チャンピオン

日本マイクロソフトへ転職したのち、日本における 2人目の Java チャンピオンになりました。オラクル時代は、Java SE/Java EE など標準 Java に対する言語使用やライブラリについて啓蒙をしていましたが、現在は Java を利用する側、特にクラウド・プラットフォームで Java アプリケーションを有効活用するための情報をお届けしています。今でも Java は大好きですし、私の青春です!!

Write Once, Run Anywhere ≒ Build, Ship, and Run Any App, Anywhere ??

--- アプリをコンテナでデプロイするというのが急速に一般化し、Mastodonブームに象徴されるようにDockerイメージやComposeファイルで配布するのが普通になってきました。最近思ったのが、これってそもそもJavaの思想にあったWrite Once, Run Anywhere と一緒だなーと思ってたんですが、どう思いますか?

まず、この思想はとても素晴らしいもので、私もそう思います。

JVM (Java Virtual Machine)は、Java のクラス・ファイル・フォーマットに従ったクラス・ファイルを実行するための環境です。任意の環境 (Windows, Linux, Mac など) でコンパイルされた Java クラス・ファイルを、任意 JVM 上で実行する事ができます。これが、いわゆる Write Once, Run Anywhere (一度書いたコードがどこでも動く)の所以です。

しかし、実際には各 OS 用の JVM に差異があるため、当初の思想とは異なり Write Once, Run Anywhere が実現できない部分もあるのが事実です。また、サーバ・サイドも同様に、実行環境 (アプリケーション・サーバ製品) の差がプログラムに影響を及ぼすことがありました。

製品の差だけではありません。本番環境でアプリケーション・サーバのクラスタ環境を構築するにしても、とても注意が必要でした。手動で OS や JDK、アプリケーション・サーバなどをインストールし、環境設定するのはミスがつきものです。私も、昔みずからデータ・センターに行き、インストールや環境設定を行いましたが、私が設計した環境ですら、みずからコマンドを打ち間違えをしたという経験もあります。つまり、サーバ・サイドで全く同じ環境を構築するのはかつてはとても困難でした。

Docker だけではありませんが、Infrastructure as Code を実現することで、環境構築・設定をテキスト (コード) で管理し、操作ミスなく環境構築できるようになったのは、とても素晴らしい進化だと思います。

さらに、ハイパーバイザー型の仮想化に対し、Docker を中心とするコンテナ技術は、より素早く、軽量に環境を構築したりスケールすることができるようになり、今後ますます注視しなければならないと思っています。

しかし一方で、Docker 単体で本番環境にたえるシステムを構築することは非常に難しいため、Docker を支えるオーケストレーション・ツールが必要になってきます。現在、Docker Swarm, DC/OS, Kubernetes などがその候補としてあげられますが、現在は、Kubernetes の利用が増えているように思います。

DEISの話

Kubernetesの機能は良いが扱いづらい

--- DEISというDockerベースのPaaS基盤ソフトウェアについて話していただけるとのことですが、ひさびさにサイトを見たら、Deis, Inc. | The Kubernetes CompanyとHPに記載されていました。Workflow(PaaS)やSteward(Service Broker)というプロジェクトからでしょうか。Kubernetes上で基盤を運用していく利点はどういう部分にあるんでしょうか。

Kubernetes は Docker を支える基盤として、オーケストレーションやスケジューリングに関してはよく実装されており、必要十分な機能を提供しているように思えます。

しかし、私は開発者側の人間です。開発者側の視点で考えると k8s は少し低レベルの操作が必要で (YAML)、扱いづらさを感じるのも事実です。従来のように、アプリケーションを開発し、開発した実行ファイルをインフラ担当に渡し、インフラ側で本番環境を作るというような場合であれば、k8s 単体でインフラ担当者が管理するのもよいかもしれません。

Deisでアプリケーションのライフサイクルを管理する

しかし今の世の中は、早急なアプリケーションのリリースが求められています。開発者もよりすばやく、簡単にアプリケーションを検証したり環境構築をする必要があります。その際、実行ファイルを手渡しではなく、継続的デリバリーとして、デプロイの自動化を試みる必要もでてまいります。さらに、変化に強いシステムを構築する必要があります。

DEIS は開発者側の視点で、ソースコードや、Dockerfile、もしくは Docker イメージから直接実行環境を構築できるほか、ログ管理の容易化、アプリケーションのバージョニングやロールバックなども容易にできるようになります。さらに「12 Factor App」の基盤としても利用することができます。
(Heroku をご存知の方にわかりやすくいうと、Heroku のような事が k8s 上でできるようになったと思っていただければ、分かりやすいかと思います。)

ご興味ある方は、ぜひ私が作成した「DEIS on Kubernetes (k8s) on Azure Container Service Hands on Lab」をどうぞお試しください。

インフラ担当者は、今まで同様 kubernetes のコマンドを利用することもできますし、Helm というツールを利用する事で、より簡単に OSS 関連製品のインストールや運用管理ができるようになります。そして開発者はより簡単に k8s を扱えるようになるため、ソースコードのビルドから実行までが、一連の流れ(ワークフロー)として簡単に扱えるようになります。

そんなにたくさんPaaS持ってどうするのMSさん?

--- オープン系PaaSが世間にはたくさんありますし、MSさんは最近Cloud Foundry Foundationにも参加したり、OpenShift もあります。そんな中でDEISの特徴というのはどういうものでしょうか?

たしかに、今オープン系の PaaS は色々な選択肢があり、それぞれとても良い製品ですし、それぞれ一長一短があります。前提として、マイクロソフトは、クラウド基盤の提供者として、お客様がお望みの環境に対して継続的に投資をおこない提供します。

以降は、私のまったくの私見になりますが、製品比較の際、オープン・ソース版と、サポートのある製品版で、考え方を変える必要があると思っています。製品版の Pivotal Cloud Foundry もしくは Red Hat の OpenShift Container Platform に関しては、それぞれ各社より技術サポートを受ける事ができます。また、必要に応じ各社、もしくは各社のパートナー企業などから、構築技術支援、開発技術支援を受けることもできるでしょう。

一方で、DEIS は現時点で Managed なサービスではないため、Azure の場合、Azure Container Service 上で自身で環境を構築する必要があります。これは、Cloud Foundry, OpenShift のオープン・ソース版を利用するのと同様で、トラブル対応を含む運用・管理に対して、ご自身で対応が必要になります。

今後の事はまだ未定ですが、今年 4 月に Microsoft が DEIS を買収したこともあり、Microsoft Azure Container Service との親和性がより高まることも期待されます。また、Microsoft の中で k8s に精通した開発者、技術者が増えたことは、今後のマイクロソフトにとって、よい材料かと思っています。

コミュニティとのかかわりについて

--- DEISにしても寺田さんの今までの経歴においてもそうですが、非常にコミュニティに力を注いできた印象を受けます。端的に、コミュニティって良いですか?

はい、もちろん、そのように思います。

業界の最新トレンドや技術的なノウハウ、そしてエンジニアとしての成長やキャリアまで含めて、コミュニティに参加して得られるメリットは数多くあると思います。

日本には、とても優秀な方が数多くいらっしゃいます。そして、その優秀な方々が、ご自身のやってきた事や、技術的なノウハウ、成功体験などをコミュニティで共有してくださっています。 その中で、自分に足りないもの、自分がしなければならない事がわかってくるのではないかと思います。

幅広い世界を見て欲しい

また、会社の枠を超えて、素晴らしいエンジニアの方々と交流を持つことで、より幅広い世界が見えてくるようになるのではないかと思います。

そして日本の技術者の皆さまには、日本でだけでなく、もっと世界のコミュニティにも参加して、世界を視野にご活動・ご活躍いただきたいなと思っています。

--- ありがとうございました。当日のお話も楽しみにしています。

まとめ

複数のPaaS基盤をポートフォリオに持つMSの中でのDEISのセルフホスティングな位置づけなどや魅力、またk8s上での展開による優位性などがよくわかりました。さらに詳しい内容に興味がある方は来週のMasterCloudにぜひ参加してみてください。

mastercloud.connpass.com

Serverless Meetup Tokyo#4 / Osaka#3 / Fukuoka#1 を開催します

セクションナイン吉田真吾@yoshidashingo)です。

今月は Serverless Meetup が3都市で開催されるのでここで軽く告知しときます。

Serverless Meetup Tokyo #4 @ソニー

すでにイベントの公開もしており、400人近く参加登録をいただいてるのですが、今から申し込んでも当日には繰り上がり参加可能になるんじゃないか(保証はできませんが)とか思っております。どうしてもという方はぜひぜひ。

  • 2017/8/9(水)開催です。
  • 今回はソニーさんと共催で開催します
    • とはいえタイムラインの構成はいつもとあまり変わらずです。

serverless.connpass.com

Serverless Meetup Osaka #3 @MOTEX

  • 2017/8/25(金)開催です。
  • VUIあたりに関心の高い人たちが多い印象の大阪も今回で3回目です。
  • 今回会場がMOTEXさんでとても広いので、まだまだ参加していただいてOKですよ。

serverless.connpass.com

Serverless Meetup Fukuoka #1 @さくらインターネット

  • 2017/8/25(金)開催です。
  • 小山さんや森田さんなどなど、サーバーレス関連のツール作成や情報発信をやってる方が多い福岡で、そういえば初めてだったかという感じですが初開催です。

serverless.connpass.com

ということでサーバーレス、まだまだ盛り上がっていきそうですね。よろしくお願いします。