4/19に開催された、Japan Container Daysで登壇してきました。
www.slideshare.net
私のセッションは150人ほどの部屋でしたが、立ち見が出るほどの方に来て頂き感謝です。イベント自体もすごく良かったですね。歩留まりを考えて、定員よりもいくらか多めの人数まで申し込みを受け付けたようですが、想定を上回る出席率だった様子です。 いかにコンテナ技術が注目されているかよく分かるイベントでした。
さて、そんなコンテナづくしのイベントの中で、ちょっと違う切り口でお話をさせてもらいました。
なぜ発表しようと思ったか
昨年(2017年)一気に火がついたKubernetes。しかしその結果「そこk8sでやるべきなのか？」と疑問に思う話が各所で見られるようになりました。たとえば数コンテナの運用のためにオンプレ環境に自力でk8s立ち上げたり、その運用に○人もの専任をつけたり。
キーワード先行で上司から「コンテナやれ」「DevOpsやれ」と言われ、どうすれば分からずPaaS勉強会のk8s話聞きに来た、って人もいました。このあたりが、『コンテナ疲れ』という言葉を思いついたきっかけになりました。
また、PaaSやコンテナとは違ったパラダイムでServerlessが注目されつつあるのもみなさんご存じの通り。
じゃあ、この3つのカテゴリはどう絡んでいくんだろう？ 僕らは何を選ぶべきなのか？ と思い、今回の発表に至ったわけです。
発表の補足
コンテナつらくないですか？の話
スライドだけみるとコンテナを否定しているようにも読めたので。
ここで言いたかったことは、「コンテナは楽しい」「けど、それだけで良いんだっけ？」 ということ。
僕もそうなんですけど、この界隈は毎日のように新しい技術やツールが出てくるので非常に楽しいんですよね。ただ、それを良しとしない人だって少なからず居る。
「新しいものについていけないエンジニアなんて云々」と言ってしまうのは簡単ですが、それなりの規模の企業で普及させようとなると、そういった人たちに対してもどうやって使ってもらうかを考えなくてはいけない。となると、この技術が持つ「つらさ」は明確にしておかないといけない。
このあるある話もそう。だいたい僕の経験談なのですが、僕自身はこれに対して「新しい技術だしこのくらい当然だよね」と思っています。JKDで登壇するような人も同じだと思います。でも、『これはそういうもんだ、慣れろ！』と言ったところで他の人に通じるとは限りません。つらさはつらさとして認識して、共有したほうが次への道が拓けるんじゃないでしょうか。
なんでPaaSの話なのに○○○が無いの！
はてブのブコメにあったのですが・・・単にさまざまなPaaSに言及していたら時間も足りないし本題とずれる、ただそれだけです。Herokuはこのジャンルを切り拓いた存在だから、Cloud Foundryは自分が関わっているから、という理由で言及した次第です。
Google App EngineだろうとAzure App Serviceだろうと、Elastic BeanstalkだろうとDeisだろうとFlynnだろうとTsuruだろうと（ｾﾞｪｾﾞｪ)、今回の発表で言いたかった『PaaSはアプリケーションのライフサイクルを支援し、開発の効率を高める』という点においてはどれも同じ志向です。 特定のPaaSを掘り下げたい方は、PaaS勉強会へ是非どうぞ。
Serverlessにしても、Lambdaは言及せざるを得ないとして、じゃあ他は？となると、なかなか平等に取り上げるのは難しい話ですね。
ベンダーロックインへの考え方
会場では口頭で補足したんですが、スライドだけだとベンダーロックインダメと言っているように取られそうだったので･･･。
個人的には、ベンダーロックインはそこまで否定的に思っていません。価値の無いものに対して嫌々ロックインされるならば別ですが、ロックインされることで快適になり生産性が向上するなら、それでいいじゃないかと。
もちろん、特定のベンダーに依存するリスクも否定しません。だからこそ、大事なのは『自分のビジネスをハッキリさせること』なわけです。
自分のビジネスを見つめ直して、依存リスクよりも生産性だ！となればロックインされにいけば良いし、万が一の自体で大きな損害が発生しうるのであれば、徹底的にベンダーロックインを避ければ良い。そこは、人それぞれ異なります。
ちなみに、自分のベンダーロックインに関する考えは、5年ほど前に行った座談会の影響を受けています。『心地良いロックイン』という言葉はここで出たもので、使い勝手が良いのでよく使っています。
まとめ — 制約は創造性をはぐくむ
自分が好きな言葉として紹介させてもらいました。自分が高校生の時に偶然読んだ、戦うWebデザインという本に載っていた言葉です。
プラットフォームに関する議論をする上で、示唆に富んだ言葉だと思っているので最近よく使っています。
アプリケーションフレームワークにある、 『設定より規約(convention over configuration)』の考え方はこれに近いようで、Ruby on Railsの作者であるDavid Heinemeier Hanssonは、『制約は自由をもたらす(constraints are liberating)』と言っているそうです。
プラットフォーム選択においては、どうしても「あれができるか、これができるか」という考え方をしてしまいがちです。
しかし、あえて制約のある、しかしながら開発生産性の高いプラットフォームを選んで時間を節約すれば、より創造的な仕事ができるなんてことも多々あります。是非、この言葉を思い出しながら自身のプラットフォーム選択をしていただければと思っています
