CloudNative Days Tokyo 2019で登壇してきました。振り返ります。
発表資料はこちらです。
なぜプロポーザルが必要なカンファレンスに登壇するか
今回の登壇は初めてCFPに対してプロポーザルを提出し、審査を経たものでした。
なぜプロポーザルを提出する系のカンファレンスで登壇をしたいと思ったのかについては2019年1月に遡ります。
目標を立てるにあたって昨年は登壇回数を指標にしていました。それももちろん意味はあるのですが、
「自分はこれを喋る」というのを明確に定めた上で検証、準備し、そのテーマに興味のある人にダイレクトに話を届け、問い、フィードバックを得て自身の学習サイクルやスキルを向上させる
というのが意義だと思っています。
それで日々お世話になっているコミュニティへの貢献だったり、仕事で生み出す価値の質が上がれば言うことはありません。
そのため、今年は登壇回数ではなくてCFPを4ヶ月に1回出してみるというものに習慣目標を変更しました。
その後またOKRの運用を始め方針が変わったものの、プロポーザルの内容がOKRでより具体的になる感じなので両立できそうです。
テーマの選定
プロポーザルとして提出したのはこんな文章 + αでした。
講演タイトル - Abstract Title
（最大50文字）受講者の目を引くようなるべく具体的なテクノロジー名を含めることをおすすめします
Knativeで実現するKubernetes上のサーバーレスアーキテクチャ
講演内容 - Abstract
（200文字程度）どんな人に向けた講演かこの講演によって受講者がどんな情報を得られるかを含めることをおすすめします
Kubernetes（K8s）上でサーバーレスアーキテクチャを実現するKnativeが何を解決するのかを構成するコンポーネントやユースケースを交えて紹介します。
本講演は次のような方を対象にしています。
・Knativeがなんなのか、k8sとどのような関係にあるのか、どういう仕組みなのかを知りたい
・K8s上でもサーバーレスアーキテクチャを実現したい
・K8s上のアプリケーションの開発・運用負荷を下げ、機能開発により集中したい
なぜKnativeをテーマにするのかについてはこれまでのServerless Meetup、mercari.go、技術書典6など折に触れて書いてきました。
- みんな大好きLambda奴を自分で実装できるっぽい
- Kubernetes詳しくならざるを得ない状況を作れる
からです。
Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo
1〜2月にKubernetes完全ガイドでK8sに入門し、2月にk8s source code reading #1に参加してみてちょうどCFPの話があったので応募してみることにしました。
#CNDT2019 @toshi0607 による「Knativeで実現するKubernetes上のサーバーレスアーキテクチャ」を受け付けました。このプロポーザルを聞いてみたい人はいいねやリツイートでぜひ応援してください！ 公募セッション一覧はこちら #cloudnativehttps://t.co/IhZFbNrGI3
— CloudNativeDays (@cloudnativedays) February 28, 2019
提出時点ではまだKnativeに触ったことはなかったものの、5ヶ月くらい準備があり、継続して学びたいテーマであるため「自分がこの5ヶ月で理解したいこと」をプロポーザルに書くことにしました。
準備
主に準備すべきことはプロポーザルに書いたこの3つです。
①Knativeがなんなのか、k8sとどのような関係にあるのか、どういう仕組みなのか
②K8s上でもサーバーレスアーキテクチャを実現するにはどうしたらいいのか
③K8s上のアプリケーションの開発・運用負荷を下げ、機能開発により集中するにはどうしたらいいのか
①についてはServerless Meetup、mercari.go、技術書典6で調べていたのでアップデート分を調べつつ、直近の2週間では②、③を中心に検証したり調べたりしました。
特にユースケースについてREADME以上のことに触れられていなかったので、「③を実現するサーバーレスアーキテクチャを実現するためのプラットフォームを構築する」という観点でtriggermesh/knative-lambda-runtimeやOpenFaaSを調べました。
振り返り
OKR
CNDTは個人OKRを達成する上で重要な位置付けにありました。Objective2は家庭面なので、CNDTの位置付けが明示されているObjective1について振り返ります。
Objective 1
DIY FaaSのためのKnativeのユースケース、動作の仕組みを理解する
Key Result 1
どんな課題に対してどう使うのかを説明できる
- CloudNative Days Tokyo 2019 登壇
-> コンテナベースのアプリケーションを開発するにあたり、各ユースケースがどんな課題を解決するのかを意識して説明するようにしました。
K8sでサーバーレスをやる意義の中でKnativeがK8sとサーバーレスをどう捉えているか述べた上で説明した（つもりな）のでよかったんじゃないかと思います。
- ServerlessDays Melbourne 登壇
Key Result 2
Knativeを使ったプロダクトでどう利用されているか説明できる
- CloudNative Days Tokyo 2019 登壇
- Knative Lambda Runtime
-> これは今回の登壇で一番伝えたかった部分です。FaaSをDIYする上でのリファレンスアーキテクチャの思想や設計を調べるのは楽しかったし、一般化できたのは大きな進捗でした。
スライドの図 + コードを見ながら具体的に追っていくことがさらに理解を促し、自分で作る上でも意義があると思うので下に書いてあるKnative本で実現しようと思っています。
- 技術書典7執筆 既刊Knative本アップデート
- Pivotal Function Service
- OpenFaaS functions on knative
- 何かCloud Runの話できる機会があれば
Key Result 3
Knativeの主要機能の実装方法を説明できる
-> CNDTの文脈ではかすりませんでした。
- 技術書典7執筆 新刊KubernetesのコントローラーをKnativeで理解する
- 技術雑誌寄稿 kube-apiserverのクライアント
- Programming Kubernetes: Developing Cloud Native Applications 再読
mercari.goの反省を踏まえて
6月に登壇した mercari.go #8での反省を踏まえて次のようなことを意識してCNDTの準備を行いたいと書いていました。
人に事前に2回聞いてもらい、軌道修正する
- 今月（6月）中に目処を添えてお願いする
-> 何もかもできませんでした。事前に見て欲しいのは
- 道徳、コンプラ、セキュリティ面でアウトなことがないか
- 人に聴いてもらって感想をもらったら大体気づきが得られる
という目的があったと思います。
- 割とこれまで話したことが多い
- 書籍などこれまでのアウトプットに対してもらったフィードバックやこれまでの登壇のフィードバックを盛り込んでいる
などがあり「事前」にそこまでこだわらなくてもいいかもと思い始めました。
ただ、OKRを決めて集中すべきことを絞るのはギリギリまで資料作りに追われるようなスケジュールにしないという意図もあるので、何かの登壇前には一度やってみようと思っています。
やってみた上でスタイルは決めたいです。
あと事後的な感想はまだ間に合いそうなので聞きに行ってみます。
テーマである「解決する課題」を明確にして関係するユースケースを話す
- デモとかするにしても何のためにやって何を見て欲しいかを明確にする
-> けっこう久々にデモしました。「簡単さ」「手軽さ」みたいなものを伝えるならmanifestファイルをkubectlで適用するのではなくて、knコマンドなど直接それらを触らない形で見せられるとよかったのかもと思っています。
漠然と機能や実装を追わず検証のゴールを先に決める
- つぎの土日は項目出しのためにグダグダ調べていい
- ただしその後は集中すべきことに集中する。やすみやすみ！
-> 今回は何か作業する前にリスト作ってそれに集中するというのを意識的にやった気がします。それも含めた管理にNotionが適していたので使い始めました。
Good
プロポーザル出した
第一歩を踏み出せたことはよかったなぁと思います。
調べたかったことを調べて理解できた
K8s上でFaaSをどうやったら作れるか？の具体的なイメージがわく程度に調べることができてよかったです。
ただ、その主要な調査自体は1日だったので、Objectiveを達成するためにもっと近道しようと思えばできるということは意識しておきたいです。早く切り上げてより難しいことや他のことをやりたくなったとき向けに。
準備プロセスの改善
やる作業のスコープを定めて集中するのと調べる項目を洗い出すのに時間をとるのはよかったです。
とはいえ調べてる途中でも項目は変わるので、アウトプットも1つのプロダクトと思ってアジャイルしますかー
Challenge
前見て喋ろう
DEMOもするのでマイク固定で話していたら前傾して前を見れないし、反応見れないしでけっこう不安なまま突っ切った感があります。
固定できても必要なときだけホルダーに置き、基本は持つようにします。
あと今回せっかくピンマイクも使えたのに普段と違う設備でやるのが不安で避けましたが多分使えたら使うのがベストプラクティスっぽい。
後ろからDemo画面見よう
大きめにしてたけどDemo画面後ろまで見えてたかわからぬ…
スクリーンに表示して後ろから見て調整するようにします。人から今どう見えてるのかは把握しときたい。
分量
セッション枠に対してゆとりある分量にしてゆっくり喋りたい。
とりあえず資料作って読み上げたら40分枠に対して50分以上かかりました。そこから内容を削り、練習では最終的に43分くらい。本番も42分半。アウトです。
詰め込めるように練習してなんとか時間を短縮したのもあって、本番を想像すると近況が余計に増すのが何より厳しかったです。
時間が余りそうなら余りそうで不安だとは思いますけどね。
「ゆっくり話して収まるように思い切って削る」を次はやります。
セルフログミー
Serverless Meetupの登壇資料とログミーさんから出た記事の媒体の反響の差分は資料単体の拙さだったり、コンテキストの差だと思います。
今回の登壇準備で得た知見はコードを追いながら文字で説明したい部分が特に重要な箇所だったので自分でやってみようと思いました。
それがそのままKnativeの既刊に追加されそう…
表面的
技術的深掘りがREADMEから抜け出せてない感がまだまだ強いです。
今回いただいたフィードバックの観点や実装面で深掘りして新刊を出すので、そこでもう少しなんとかしたいです。
それでもアウトプットの機会を経るごとに理解できたと思うことは増えているのは思うので、理解しようとするスコープを定めて着実に進んでいこうと思います。
妥協したが理解した方がいい部分
- RouteとIstio
- RouteがIstioのリソースをいじってると思い込んでてGateway、VirtualService、DestinationRuleなど探したものの、Routeの変更が反映されたりはしていませんでした。Glooなど他のGatewayに差し替えれるにしてもRoute設定したときに何を変更しているのかなどは理解したいです。
- Tekton
- TektonでPipelineを作ってKnativeのサンプルをデプロイしようとしたもののできなかったのでその原因を調べ切りたいです。
- CloudEvents
- もっと追ってみると楽しそうでした。FaaSの課題、イベントドリブンなものを作るつもりで書いてたのにあまり触れられなかったのもイケてないです。
- Eventingのリソース
- brokerとfilterのdeployment、ラベルを消してもDeploymentを消しても何度でも蘇り消えなかったので実装追いたいです。
- issueにさっきコメントついたので読む
仕様を覚えるだけで実現する仕組みを追わないのは、他のことを追い始めても先が見えてる気がするのでここは後手に回っても最終的に妥協しないようにしたい。
あと、この文脈は関係ないけど登壇依頼される程度に特定の分野に詳しいことが認知され、なおかつその分野の正しい見識を持っている状態になりたい。
フィードバック
登壇後にAsk the speakerで何人かにご質問いただいたり、お話ししたり、インターネッツから拾ったりしました。
Knativeの発表でこんなに色々話してるの聞いたのは初めてみたいな声はお世辞でも嬉しかったです。
- K8s使い始めだとメリットが理解しづらかった
- 実際どう？使ってる？メルペイでもサーバーレスワークロードって検討してる？
- K8sクラスタでFaaSを使えるようにする意義は？
- node affinityと両立するにはどうしたらいい？（？）
- FaaSはわかるけどPaaS基盤を構築するってどういうこと？
- いつGA？ロードマップでてる？
- ブルーグリーンデプロイってK8sやIstioでもできると思うけどKnativeでやる意義は？
- 隠蔽されることで調査しづらくなったりする部分ないか
- K8sでできるけどKnative使うとできなくなることないか
- （プラットフォーム的に現実的に選択できる）Cloud Runどう使うとよさそうか
- Istio、Gloo以外にもAmbassador使えるのでは？
- EventingのIstio依存ってもうないのでは？
自分のアウトプットに対してこういう声をもらうのが目的なので本当に嬉しいと思ったり、重要な視座をもたらしてくれる人はだいたい変わらないのでそういう人に直接話に行った方が強くなれるのでは？って思ったりしています。
特に最後の5つはいざ使うときに技術選定する大事なポイントだったり、自分が情報を追う上で見つけられなかった点だったりして深めていこうと思います。
その他も言われてみたらたしかに気になる点だと思うし、node affinityの件は問題を生じる状況を理解できていないところだったりします。
一番のフィードバックは業務で得られるはずですが、それに加えて行なっている個人的な活動なのでいただいた内容を糧に強くなっていこうと思います。
