Shifterはどう生まれたのか?WCEU 2016からの1年間のお話

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

サーバーレスなWordPressホスティングサービスであるShifterを、そのプロジェクトの立ち上がりからエージェンシーとして支え、最近正式にデジタルキューブのメンバーにジョインした Daniel Olson にShifterの開発裏話なんかを聞いたのでここに掲載します。

f:id:yoshidashingo:20170803171623j:plain

位置づけとしては、以下のエントリーに対するアンサー的な感じで読んでもらえればよいかなと思います。

yoshidashingo.hatenablog.com

Shifterプロジェクト前夜

--- やぁダン。今日は小賀さんに誘われて参加した去年のWCEUの話から始めたいんだけど。

WordCamp Europe 2016 だね?

--- うん。AMIMOTOブースで終日接客していたんだけど、AMIMOTOはAMIベースのセルフホスティングもあるし、シングルインスタンスから負荷分散して大規模にスケールするマネージドホスティングサービスまであって、お客さんのニーズに合わせてユースケースやプランを説明をするのが難しかったんだよね。

ja.amimoto-ami.com

たしかに、EUにはたくさんのホスティングプロバイダーがあるけど、構成がこんなにたくさんはないよね。これだけ広く顧客ターゲットをカバーできるのもAWS上でサービスを展開しているからならではなんだけど、AWSに馴染みのないお客さんにとっては「そもそも"AMI"ってなんだろう?」とかなるよね。でも、他のプロバイダーが提供しているWordPressのホスティングサービスはリソースの割に価格が高かったりするから、リーズナブルなマネージドホスティングとして使っても自分でAMIからホストしてもコスパはいいはずなんだけど、ちょっとわかりにくかったかもしれないね。

--- そうなんだよね。あとはドメスティックのVPSを借りてるケースが多かったので、それで満足している人にはササりにくいなって。

数百万PV以上のスケーラビリティが必要な大企業向けに訴求しても良かったかも。安価なVPSにホスティングしている人だと、こっちでもDigitalOceanとかにホストしてるって話をよく聞くんだ。でもDOとAWSだと運用方法がまったく違うからね。

--- たしかに。それでね、ここからShifter誕生の話なんだけど、そのときにすでに僕らはサーバーレスの概念がこのWordPressの世界でも十分役立つんじゃないかって考えていたんだ。すでに僕らはWordPressのプラグインであるStaticPressで静的なHTMLを生成してS3やCDNから配信することに慣れているし、それ以外のAWSのノウハウにも精通しているから、これをサービス化したらいいんじゃないかって話をしていたんだ。それでイベントが終わってから君に色々オーダーが行ったはずなんだけど。

それが Shifterプロジェクト だね。

getshifter.io

Shifterができるまで

--- そうそう。それで、その後に何が起きてたのかなーって。

AMIMOTOのリブランディング

オッケー。まず、WCEUの次のWordCamp USに西川さんと小賀さんが来たときに、直接会話してみたんだ。僕自身もAWSにはよく慣れていて、AnsibleのPlaybookでサーバーを管理したりしていたから、AMIMOTOブースの説明を見て、彼らがAWS上でホスティングしているサービスが他のホスティングサービスとはちょっと違うものだなとわかったんだ。

それで、そのリーズナブルな価格設定や、内部で利用している技術を聞いて感動したんだ。PHP7やHHVMなどモダンな実行環境も割と普通に実現していたよ。

で、さらに聞いてみたら、非常に小さくて優秀なチームでそのホスティングサービスを実現しているんだ。ただし、彼らにはそれ以上の余計な人的リソースがないことにも気づいたんだ。

それで彼らと何か組めないかと思って、その夜彼らと一緒に呑んだんだ。そのとき、小賀さんや西川さんから「サードウェーブ(第3の波)=サーバーレス」について話してくれたんだ。

そのときは何を言ってるかよく分からなかったから、「いいねー、いいねー」って言って調子を合わせてただけなんだけど。

--- はっはっは(笑)

それで、まずは彼らのAMIMOTOのリ・ブランディングから手伝い始めたんだ。

AMIMOTOが次世代のWordPressホスティングであることは間違いないんだけど、顧客に製品を見つけてもらうためのブランディングってとても難しくて、良い製品があっても顧客が理解してくれないと売れないんだよね。それって問題だよね。だからまずはグラフィックを削ぎ落とすことから始めたんだ。すべてのグラフィックをわかりやすく統一して、ブースを見ただけでこの製品が何であるのか理解してもらえるようにしたんだ。Webにもそれを反映していって、AMIMOTOブランドが理解されやすくできたところで1つめのプロジェクトは無事に終わったんだ。

Shifterのブランド構築

その後に小賀さんから、次のプロジェクトの依頼があったんだ。それがShifter。そのときはまだShifterとは呼ばれてなかったけどね。

--- そのときのプロジェクト名ってなんだったの?

んー、単にStaticPressって呼んでたかな。それで彼らからStaticPressがどういうもので、どう動作するかじっくり聞いたんだ。それでも僕にはそのときその全貌は理解できなくて。

でも彼らのことは信じていたから、彼らがShifterの開発を始めるのと並行してブランドの構築を開始したんだ。彼らがWordCamp NYCの出展でフィラデルフィアにきたときに、また呑みながらじっくりと重要なコンセプトについて会話したよ。

そのとき誰かが「これはWordPressをStaticにShiftするやつだよね」って言ったんだ。そこから僕らはこのサービスをShifterという開発コードネームで呼び始めたんだ。その後100個くらい別の名前の候補をデジタルキューブのみんなで考えたし、それに合うコンセプトやイメージも作ってみたんだけど、結局最初のヤツが一番いいねってことになって Shifterに最終決定したんだ。

世の中にはさまざまなStatic Site Generatorがあるんだけど、StaticPressみたいに〇〇Pressって名前だとWordsPressのエコシステムの中から出られないと思うし、すべてのWordPressデベロッパーがStaticにするメリットを理解しているわけではないので、WordPress界隈以外でもユーザーを育てていけるという意味でこの名前で良かったんじゃないかな。

--- たしかにShifterはCMSとしてWordPressを使いつつもそのジェネレートのプロセスまで含めて完全にサーバーレスなサービスだよね。

f:id:yoshidashingo:20170809112036j:plain

そう、だから僕らはShifterをサーバーレスでホストするWordPressという独自のカテゴリに位置づけることにしたんだ。

--- ところで顧客ターゲットはどういった人たちを狙ってるの?WordPress界隈だけじゃないとするとサーバーレス界隈の開発者とかも?

すでにStatic Site Generatorに馴染みがある開発者たちであれば、Staticであるメリットや使い所をよく理解してくれるんじゃないかと考えているんだ。Shifterは技術的に言えばStatic Site Generatorだからね。

実際、今年のWordCamp EuropeではServerlessというメッセージよりStaticというワードでセッションをしたんだ。Static Site GeneratorとしてのShifterという話であれば、Serverlessなサービスというより簡単に理解してもらえるかなって。サーバーレスの文脈から始めるとその概念やメリットなどもう少し話さなくてはいけないトピックが増えてしまうからね。今はまだちょっと早いかなって。

ナレッジとサポートから

--- 見込みユーザーや使い始めのユーザーの育て方ってどう考えてる?たとえばMeetupをやるとか顧客ミーティングして回るとか

今はまず分かりやすく使ってもらえるようにサポートドキュメントを整備するのが先決かな。それでたくさん役に立つブログ記事を書くんだ。そうすれば Shifter とか Serverless WordPress とかで検索するたくさんの見込みユーザーにピンポイントに情報を提供することができるからね。で、それを続けていけばGoogle上のランクもどんどん上がっていくし、そうすればもっとたくさんの人に見つけてもらってしっかり記事を読んでもらえるからね。

もう1つの方法は Intercom という顧客管理やドキュメント管理もできるチャットツールを使ってサイトに来た人たちと直接チャットしたりサポートドキュメントを提供したりしようと思ってるんだ。これならつねにデジタルキューブでオンラインの人がいるから、すぐにサポート対応できるんだ。サイトに来る人の中には、たとえば「ShifterでWooCommerceは使える?」とか「なぜサーバーレスなの?」とか簡単な質問がしたい人もいるからね。そういう人に誰かがすぐ反応してあげれば次の段階に進む機会を得やすいんだよね。

www.intercom.com

--- 素晴らしいサポート体制だね

サーバーレス → Less Security Ops

ところで、次回のワシントンでやるWordCamp DC 2017で自分が話すトピックは「セキュリティ」なんだ。※収録日は7/7

--- セキュリティ?

そう、セキュリティ。WordPressでハックされてしまうポイントの多くがサーバー管理に関わる部分なので、サーバーやハードウェアの防衛を頑張る従来の手法もいいんだけど、サーバーレスにすることでサーバー管理上のセキュリティ懸念から解放されようって文脈なんだ。

--- 単純にすべてのセキュリティ懸念が解放されるわけではないけど、たしかにそれもサーバーレスのよい一面だね

それに、たとえばあなたがバイラルマーケターで企画が大ヒットした場合にも、サーバーレスにすればサーバーのキャパシティ管理のことは気にしなくていいんだよって話もね。

Danがデジタルキューブにジョインした経緯

--- ここまでShifterの誕生秘話を話してもらったけど、Danは外部メンバーとしてプロジェクトに入っていたんだよね。最近デジタルキューブに本格的にジョインしたって聞いたけど、それはどういった経緯だったの?

小賀さんとは2015年に初めてのWordCamp USで知り合ってから3年くらいの付き合いになるんだけど、その頃僕がいた制作スタジオがデジタルキューブの仕事を請けていて、会話自体はよくしていたんだ。

チームやサービスへの愛着

で、ShifterをローンチしてAWS re:Invent 2016で再会したときに、こうやってプロジェクトの立ち上がりから作り上げたプロダクトの行く末のことがすごく気になっていて。たとえばどうやってこの先改善して良くしていくのかとかね。それで小賀さんに伝えたんだ。「僕はあなた達との仕事が大好きだ」ってね。

--- 愛の告白みたいだね。

うん、まぁ。デジタルキューブという会社も大好きだし、もし機会があるならなんかこの先もっとスゴいこともできるんじゃないかって。そうしたら彼が僕のためのポジションをオファーしてくれて、それですぐに Yes って答えたんだ。

--- えぇ、決断早いねー

うそ、実際は本当に決断するのはちょっと大変だったんだ。デジタルキューブの仕事はとても楽しいんだけど、たとえばタイムゾーンが違うし、言語の壁もあるから結構チャレンジングだなと思うし、簡単なことは1つもないんだよね。でも、最近はみんながチャットで日本語でやりとりしてても、なんとなくどんなことを言ってるか分かるんだよ。少しづつ少しづつだけど、仕事の流れもよくしていけるといいかなと思ってる。

大事なのはチームで仕事すること

--- ところでオファーされたDanのポジションっていうのはどんなんなの?

COOだよ。もっと大きなプロジェクト、たとえば会社が次のステップに進めるような仕事をやってねとオファーされたんだ。当然Shifterがメインでフォーカスしないといけないプロジェクトだけどね。

--- ということはShifterを改善して世界に広めるためのキーマンということ?

うーん、キーマンのうちの1人くらいかな。僕らはチームで働いてるし、チーム自体が素晴らしいから、僕もあくまで1人のチームメイトさ。ここ(US)にいてサポートして、作業が詰まってしまうような部分があれば僕も対応するんだ。僕は決してブレイクスルーを起こすようなタイプじゃないし、チームメイトとして仲間と一丸となって課題に対処していくんだ。

--- 今日はありがとう。また呑もうね!

ありがとう!

f:id:yoshidashingo:20170809112058j:plain

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