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に向け原稿進めます。

技術書典5、無事終了しましたね!関わられたすべてのみなさんお疲れ様でした。

つぎの出展に備えて振り返りたいと思います。

執筆のモチベーションについては宣伝記事に書いたので、今回はこれからに向けての話を中心に書こうと思います。

技術書典5で『Goで学ぶAWS Lambda』を出展します #技術書典

謝辞

今回は単著やで!と言いつつ、大いに助太刀してくれた2人にまずお礼を言いたいです。

まず前職の同僚@Shuheiktgwさんです。査読でわかりにくい部分を指摘してくれたことで特に2章は大きく構成を見直せました。更にGitHubのリポジトリにもPRをくれ、大きく貢献してくれました。

そして妻です。9月12日時点ではまだ原稿0のようなペースで原稿以外に時間が割けなかったので9/8に「原稿以外のすべてを頼む!!!」と一任(丸投げ)し、締切管理、表紙デザイン、ダウンロードカードデザイン、発注・入稿、当日のチェックリストに基付いたパシリまで何一つ文句も言わずにやってくれました。改めて文字にしてみるとひどい夫や。

それでも、発注してくれた本の開封の儀やイベント当日の売り子を通じて「つぎは書いてみようかな…!」なんて言ってくれるのは心の救いです。ディズニーで打ち上げしてきます。

執筆環境として、TechBoosterさんのTechBooster/ReVIEW-Template@atsushienoatsushieno/vscode-language-reviewを大いに活用させていただきました。ありがとうございます!!

フィードバックが欲しい

今回頒布した『AWS Lambda』は技術書典3の『Extensive Xamarin』で担当したXamarin.Macの章と比べ実装に基づく内容になっています。もっと言えばAWSのアカウントがありGitHubからソースコードを落としてくればそのままデプロイできるものです。

それは、書籍を執筆するとは言いつつも自分が実装する手触りが欲しかったのが1つあります。そして、自分が技術を学ぶときは最低限のルール説明を読んだら掲載したサンプル+αの粒度のコードが読みたいと思うからです。

説明しないと伝わらないソースコードなら書き方がよくないかもしれないし、どうしても必要ならコードコメントでよいのではないかと思います。

けどそれならGitHubにしっかりREADMEを書いて公開して終わりになるし、書籍にする意義が見出せません。結局、GitHubと技術書の間みたいな構成の本になりました。

幸い印刷していた分は売り切れ、ダウンロードカードも購入いただき、BOOTHで販売している分も着実に売上を伸ばしています。

つまり、売れ残った紙本に縛られず思い切って増補改訂ができ、ダウンロードカードのURLを通じて紙本を買ってくださった方にも更新情報をお伝えできる状況です。

そこで、フィードバックをくださる方にダウンロード版(PDF、ePub、MOBI)を差し上げたいと思っています。ぜひ@toshi0607までDMをください。もちろん購入いただく分は止めません。それはそれでとても嬉しいです。

  • 本としてこの形式がありと思うか?
  • ソースコードはわかりやすいか、どうすればわかりやすくなるか?
  • 構成として過不足はあるか?
  • ユースケースから自分でLambdaを利用したアーキテクチャを検討するイメージはわくか?
  • もしあまり触ったことがなければ触りたくなるか?何が辛そうか?

このあたりの感想がほしいです。

僕が欲しかったのは売上ではなく自分の技術力を高めるための言葉だったことに気がつきました。

お金は社が十分供給してくれます。

増補改訂

他の記事でちょっと書いたのですが、目次を考えている段階ではLambdaを活用する上で組み合わせそうな技術要素をもっと盛り込む予定でした。

  • 認証・認可(4章、CognitoとかAutn0とか使う) 
  • サーバーレスSPA(4章、Vue.js)
  • Lambda上でヘッドレスブラウザ使うユースケース(途中まで実装してた)
  • GitHubアサインのSlack通知
  • AWS Serverless Application Repository
  • Kinesisを使うユースケース
  • DLQの設定
  • Alexaスキル系
  • GraphQL(AppSync)
  • SQS(FIFOキュー)のユースケース
  • CQRS(とても実装したかった)

しかし、9月12日の午前段階で3目のユースケースの実装が一通り終わったような状況だったので見送りました。

4章関連とCQRSはやって章も足したい。自分が買ったPDFの技術書の章、気付いたら増えてるとテンション上がりませんか?上がらなくても大丈夫です。

ただ、仕事ではAWSに触れなくなったのでいい感じに共存したいなぁとは思っています。

AppSyncもFargateも触りたい気持ちはあります。

けど、Serverless Conf Tokyoで@marcy_teruiさんのセッションを聞いて、プロダクトそのもの以外の技術系アウトプットの理想形はこういうのだと感じました。

実運用に裏打ちされた教訓が他には無い独特かつ研ぎ澄まされた視点で語られる40分はただただ感動ものでした。

季節性のあるいい感じのアウトプットイベントに一生懸命向き合うこと自体はもちろん価値があるけれど、それが自分が向き合うべき課題の解決に関連するものであれば尚更素晴らしいということです。

逆に関連ない方がよい結果になるかもしれないけれど、やってみないことにはわからないやってみよう。

数字の整理

売上

  • 本 + ダウンロードカード(PDF、ePub、MOBI): 1000円 × 100部 = 100,000円(14時完売)
  • ダウンロードカード: 1000円 × 24枚 = 24,000円
  • BOOTH販売(PDF、ePub。MOBIは希望者に送付、技術書典終了日23時頃オープン): 1000円 × 22 = 22,000円

原価

  • 紙本印刷費(日光企画さん): 30760円
  • ダウンロードカード印刷費(プリスタさん): 940円
  • 技術書典参加費: 7,000円
  • ダイソーで小物(ホワイトボード、テーブルクロス、見本誌台など): 1,000円
  • 人の力

被チェック数

技術書典当日(10/8)最高で127、そこから減って最終的に123。

  • 10/1: 38
  • 10/3: 51
  • 10/4: 57
  • 10/6: 73
  • 10/7: 98
  • 10/8 8:00: 116

何が原因で売れる・売れないが決まるかよくわかりません。

僕は10/1の夜入稿したので、結果的に完売は嬉しかったものの100部刷るのすらだいぶこわかったです。

そのためBOOTH販売に本来紙で買ってくださる方が流れて欲しくなかったので技術書典終了後に開始しました。

ただ言えるのは技術書典で自分のブースに来てくださったお客さんを見ているとやっぱり紙の本が欲しそう。

そしてBOOTHで買ってくださる層(住んでる地域とか紙・電子書籍のスタンスとか)と違ってそう。

まとめるとやっぱりよくわかりません。テーマやサークルの配置によっても変わりそう。

いろいろと考え方はあると思いますが、僕は紙本を余裕をもって売り切ってスッキリした気持ちでつぎの技術書典を目指したいです。執筆やその根底にある技術力向上にフォーカスしたいなぁと思いました。かと言って当日のダウンロードカード販売とBOOTH販売だけ行って紙本をもっていかないのも嫌です。

技術書典は楽しくてしょうがないけれど、技術書典でアウトプットすること自体は自分にとっての目的ではありません。

これからも自分なりのスタンスで向き合っていきたいなぁと思いました。