OPENSHIFT.RUN で LT をやらせていただきました

先日、OPENSHIFT.RUN に参加し、LTをやらせていただきました.

LT資料はこちら.

いただいた感想は以下のような感じでした.

突っ込んでもらいたいところ全部にツッコミしてもらった感じで、大満足な感想でした(笑).

 

LTの準備

ちょうど Twitter で外部発表のあるべき姿について盛り上がってるので、準備段階で何をしていたのか書いてみます.
(本音: 上司殿とのやり取りが面白いので、書いてみたかっただけ)

※以下で「上司殿」と書く人は厳密には上司ではないのだが、先輩と呼ぶにはキャリアが違いすぎるので便宜的に上司と呼称する

CFP内容を見て上司殿と相談

RUN の CFP を見つけてきた上司殿と登壇を検討.
セッションは難しいという判断をして、LTに狙いを絞る.

 

LT の CFP を提出する

LT のコンセプトを考え、CFP の内容を検討する.
最初は Operator にフォーカスするつもりだった.
※バルゴさんのことは私も上司殿もめっちゃリスペクトしております. Operator 界のパイオニアというイメージです.

LT の前に行われるセッションで、Operator のセッションを発見.
内容をレガシーアプリに振る路線に変更.
(セッション概要を早い段階で発表いただいていて助かりました)

 

LT の CFP が採択される

無事、LT の CFP が採用される.
この時点で正式なタイトルを運営者様に返信する必要があり、タイトル案を再考する.

 

スライドの大まかな構成を決める

細かな作り込みをする前に、大まかな構成を確認する.

セッションで Operator について語られた @capsmalt さんからも助言いただいていました.

 

素案をレビューしてもらう

一旦、全てを書き上げた上でレビューしてもらう.
大枠はOKを貰えたので、ここから更に微調整する.

 

細部を微調整していく

コンセプトに合わない表現を微調整していく.
合わせて繋ぎが悪い箇所には追加でスライドを挟んだ.

 

そんなこんなで LT の準備をしました.
ターゲッティングとストーリーに力を入れた感じですね. 技術要素は薄めにしました.

当日は10分枠を9分くらいで喋っていたので、たぶん結構早口になっていたと思います.
もう少し丁寧に喋った方が良かったなと反省.

 

全体を通して感じたこと

OPENSHIFT.RUN の前に Red Hat Forum 2019 にも参加したのですが、Forum はビジネス色が強くて個人的には不完全燃焼という感じでした.
対して今回の RUN は技術色強めで、非常に満足でした.

コンテナ/オーケストレーション界隈と言うと Cloud Native イケイケな会社さんをイメージしがちですが、Red Hat さんの製品のコミュニティだけあってエンタープライズ勢も結構参加しているようでした（スーツ姿の人が半分くらいは居たかな？）.
エンタープライズの辛みを切り口にしても共感していただけたのは嬉しかったです.

また、各セッションの私の感想は以下のような感じでした.

  • Operatorに手足をつっこんでみようか。レッツエンジョイ　KAZUFUMI SAITOさん
    低級なところをいい感じに隠蔽できそうで、Operator SDK 良さげ。使ってみたい。
  • Machine Config Operatorのちょっとイイかもしれない話　ARAKI TOSHIHIROさん
    K8sの足元であるVMを、K8s自身がアップデート等を行えるのは考え方が変わる。やばい。
  • 「詰める」と「散らす」の動力学：原理・原則から理解するコンテナ配置戦略　チェシャ猫さん
    リファレンスとして最高。ここまでやれるか分からないが、困ったときの参考にしたい。
  • マイクロサービスの開発に疲れる前に dapr を使おう！　OMIZO KEIさん
    個々のユースケースをしっかり想像できた。dapr使ってみようかな…と思った人が少なくないはず。
  • お手軽で最強なOPENSHIFT CONTAINER STORAGEを使おうよ　UTSUNOMIYA TAKUYAさん
    悩ましいオーケストレーションのストレージ問題、Rook が銀の弾丸になり得るか…？

一番感銘を受けたのは Machine Config Operator でした.

エンタープライズにおいて、責任分界点をどこにするかは非常に悩ましい問題だと思っています.
今まで私は以下のような3層構造をイメージしていました.

しかし Kubernetes を介して足元の VM に手を入れることが可能となると、2層にした方がよりシンプルになると感じました.
余計な組織分断が減れば、それだけコミュニケーションコストを下げることが出来るはずです.

上記はコンセプトとしてはアプリ基盤部門の責任範囲をVMまで広げる方向性です.
なので、場合によっては『アプリ、アプリ基盤、”ド”インフラ』の3層の方が適切かもしれません.

いずれにしろ、Kubernetes を介して VM に手を入れるというアイデアは衝撃的でした.
OpenShift の一つの強みになり得るかもしれませんね.

 

総じて、非常に勉強になったカンファレンスでした.

ベンダー製品でありながらも、オープンなコミュニティを目指したいという理念も非常に共感できますし、実際に多種多様なバックグラウンドを持つ方が参加されていたのではないかと思います. エンタープライズ製品のオープンコミュニティは希少なので、この活気が続いて欲しいなと思います.

運営者の皆様、スポンサーの皆様ありがとうございました. 快く過ごすことが出来ました.
(そういえば弊社はスポンサーに参加してなかったな…)

次回もぜひ参加させていただこうと思います.

 

以上です.

Docker, Kubernetes, OpenShift, Red Hat

Posted by Daiki Kawanuma