Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

by ·1件のコメント
Tweet
Share
0 Shares

Serverless Meetup Tokyo #11お疲れ様でした！久々に登壇したのと、Serverless Meetupには勝手ながら思い入れがあるので振り返ります。

発表資料はこちらです。

登壇経緯

Serverless Frameworkのコアメンテナをやっている@horike37さんにお声がけいただいたのがきっかけでした。

Cloud FunctionsがGoをサポートしたのをきっかけに、サンプルを書いたり、それをテンプレートをServerless Frameworkに追加するPRを出したりしていました。

その辺を踏まえ、GCPのサーバーレス周りで話せることないか？と。（1月末）

ちょうど1月頭に（Kubernetesすら何もわからん状態だったけど）Knativeについて4月の技術書典6で書く予定だったのでKnativeの話させてください！！！と、申し出たらOKをいただきました。

テーマ選定

技術書典6含め、なぜKnativeについて調べようと思ったかにはいくつか理由があります。

みんな大好きLambda奴を自分で実装できるっぽい

AWS Lambdaが好きで技術書典5のテーマはまさしくGoで学ぶAWS Lambdaでした。

ユースケース的にまだまだ実装してないこともある一方で、サービスとしてどう実装されているかが気になったタイミングで登場したのがCustom AWS Lambda Runtimesでした。

これもしかして実装もわかるのでは？という期待を胸にすでにサポートされているGoで実装してみたものの、実態はランタイムのAPIクライアント奴でした。実装しなくても仕様ドキュメント見ればわかる。

そのとき書いた記事は鳴かず飛ばず感すごかったけど、今まで自分が書いた記事の中で一番好きです。

時は突然2018年の10月末のGCPUG Shonan vol.32 feat. Serverless & Knativeに遡ります。

ここでKnativeに出会いました。ようわからんけどk8sでサーバーレスできるんやーっていう印象はあったのと、k8s含め実装は公開されているので深めるにはもってこいというのとで調べてみることにしました。

Kubernetes詳しくならざるを得ない状況を作れる

Knative調べるぞ！みたいなモチベーションがあってもk8sの上に乗るものだし、トラフィックコントロール関連でIstioへの依存もあります。

仕事でGKE + gRPC + Goなマイクロサービス開発・運用していながらk8sちんぷんかんぷんでその上に（k8sはいったん忘れて）Knativeを調べるのは筋も効率もよくありません。

そういうわけでKnativeを進める前にk8sも調べる（基準曖昧）ことにしました。

登壇準備

Kubernetes

1月半ばから2月半ばまではk8s期間として本やソースコード読みました。

この本が最高で、仕事でk8s関連の知見をまとめる際にも秩序が生まれ始めました。（自分比）

Kubernetes完全ガイド

k8s source code reading #1に行ってみると上の本書いた人がいたり、k8sとKnativeの関係がわかったりしてよかったです。

それに関連し、k8sにしてもKnativeにしても、宣言的理想状態定義と、現在の状態と理想状態を調整するコントローラーの仕組みの理解は必須な中、よい記事を社の人に教えてもらえたのもよい出会いでした。

感極まって全訳PRを出しました。

Knative

2月前半に上のKuneretes本を読み終わり、Knativeのハンズオン、ドキュメント、記事などを漁りました。

よかったものは登壇資料の付録にまとめてます。

2月半ばにPivotalさんからKnative本が出たのは大きかったです。

3/2（土）、3（日）で資料準備を終えるはずが終わらず、3/5（火）に休みをとって仕上げました。

RAKU SPA 1010 神田のコワーキングスペースで資料終わらせて整えるかーと思い行ったまではよかったのですが、先に整えてしまい、しばらく薪を眺めるという失敗をおかしました。

先にやることやってから整えような！

突然のtips

準備の過程で海外カンファレンスのCFPにプロポーザルを出す気持ちを高めたり、CloudNative Days Tokyo 2019のCFPにプロポーザルを出したりしました。

CloudNative Days Tokyoは今選考中なので、もし興味ある方はいいねとリツイートで応援していただけると嬉しいです！

技術書典後の活動に大きく関わります。

登壇内容

特にKnativeの各コンポーネントについては口で補ったので資料だけではわかりづらい部分もあるとは思います。技術的な部分は技術書典6の本で書けたらいいなぁと思います。

Serverlessとは何か、KnativeのいうServerlessとは何か、みたいな話はせずKnativeが解決してくれることみたいな部分にフォーカスしたいという思いがあっての今回の構成です。

ただ、今回の構成でもKnativeが解決すると書いてることを厳密に区別すると、

  • KubernetesでもできなくはないけどKnativeでより便利になること
  • Kubernetes + CI/CDで実現できるけどKnativeでもっとKubernetes nativeに実現できること
  • Knativeで初めて実現できること
  • Knativeが拡張するIstioの機能

とかごっちゃになってる気がするんですが、そこには目をつむりました。

これから検証したり、実装を追ったりする人にとって大枠が掴めるものになればいいなぁと。

Kubernetesとの関係性にも入り込まず付録でCRD、Operatorにちょっと触れる程度にしましたが、技術書典6の方ではその辺ももう少しだけ書こうと思っています。

Severless Meetupへの思い

いつかSeverless Meetupで登壇したいなぁという思いがありました。

ServerlessConf Tokyo 2017に参加して心踊らせたり、前職でLambdaを本番導入したりしていた中での1つの目標です。

それ以来本や記事書いたり、ServerlessConf Tokyo 2018にも参加したり、Serverlessconf Tokyo 2018 Contributor DayでServerless Frameworkに初めてコントリビューションしたりの流れの中で実現できたことなので感慨深いものがあります。

ServerlessDaysも何か話したりハンズオン担当したり（？）、海外でも登壇できたらなぁと思っています。

どちらかというと登壇そのものというよりは、人に話したくなったり、話してフィードバックもらいたくなるような好きな技術に常に触れていられたら幸せという気持ちの方が強いです。

そういうハンズオンやContributor Dayも含め、好きになる可能性のある技術に触れたり、どっかの誰かがなんか言ってる技術が自分の身近な課題を解決できるものと感じられるようになる場を作るというのにも興味を持ち始めました。

自分の技術力や思いありきな前提で、これはこれで知見がいりそうですね。

振り返り

Good

社内公開とフィードバック獲得

社内のしかるべきと思われるチャンネルに貼ったらフィードバックや、どういう観点で検証したら社にとってもプラスになりそうかという示唆が得られてよかったです。

Eventとプロバイダー間の一貫性あたりはこの辺参考に考えるとよいとのことでした。

Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services
(8. Functions and Event-Driven Processing)

1アウトプットにかける時間と粒度大きいのが増える一方で、小さめのもの（Qiitaで記事書くとかサンプルコード書くとか）が減ってる + 両立できないものでもないと思うので動き見せられたらなぁと思います。

完成する前に声に出して読む

最初Eventingを書いたところで16分くらいだろう（持ち時間は20分）と思って読んだら12分くらいだったので、完成に向けて進めるのに加えて時間収まらなさそうだから書かんでいいやって思ったのを足したらちょうどいいくらいになりました。

当日は付録の後半飛ばして20分30秒（付録飛ばせたけどイベント全体けっこう巻いてたので後半だけ飛ばした）。

Spaeker Deckに上げる（PDFにする）前提で変な作り方してるところがある分枚数多く見える（が実際1枚ページ送るだけ）部分があるのでそこはいい感じにつじつまが合うようにしたいものです。

Spaeker Deckで見たらURLクリックで飛べない（？）し、作るのはGoogleスライドだしで、もはやSpaeker Deckに上げずにGoogleスライドのURL公開すればいいのではって思いながらいくつもの季節が過ぎました。

（スライド全体が完成してから練習するのは大前提として）

Challgende

スライドのURL汚い

Speaker DeckのURL生成ルール的に原則タイトルベースで、それっぽく変えたいときはスラッシュの後ろに書く、みたいなの知ってる人増えてるはず。

こんな感じ。
入門 Knative 〜KubernetesとServerlessとの出会い〜 / getting started with knative

が、失敗してこうなりました。

h ttps://speakerdeck.com/toshi0607/getting-started-with-knative-90ff6190-1251-4b7b-ada9-bbba5a8ca4b8

一度
https://speakerdeck.com/toshi0607/getting-started-with-knative
で生成されたものの、PDFをアップロードした後にスライド処理が進まず、いったん削除して上げ直したら区別奴がついてしまいました。

結局時間がかかっても処理されるので放置するか、潔く別のURLになるように変えたりの方が意図通りのURLで公開できそうでした。

少なくとも発表ちょっと前にバタバタしながらアップロードするのやめよう。

検証少ない

去年の登壇では手を動かして作ったものについて発表をすることにこだわっていたものの、今回の発表に向けて手を動かしたのはハンズオンくらいでした。

発表までに残されていた時間と発表内容的に対して最適な手段だったとは思うものの、検証時間比率は増やします。

本出すにあたってはコードよりも原稿書かないとですが…両立できないものでもない。

まとめ

色々な思いが詰まったイベントを迎え、無事過ごすことができてよかったです。

技術書典6に向け原稿進めます。

Tweet
Share
0 Shares

1コメント

  1. ピンバック: 技術書典6で『Knativeの歩き方 KubernetesからServerlessを訪ねて』と既刊第2版を出展します #技術書典 – DoorLog

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です