【書評】「Severlessを支える技術 第2版」が控えめに言って神本でした #技術書典

0.はじめに

こんにちは。
エンジニアしている @gkzz です。
コロナやら、外出は自粛と今年のGWは例年と過ごし方が少し変わった方もいらっしゃるのではないでしょうか。

私はひたすら、AWS認定ソリューションアーキテクト-アソシエイトの模擬試験を解きまくるか、先日お譲りいただいた大量の技術書典の本を乱読していました。

めちゃ大量に技術書が届く！
積読しないように溜まってる本たちを読んでおかなければ💦 https://t.co/wx7pYh2efz

— gakuji tamaki (@gkzvoice) May 7, 2020

さて、乱読している本のひとつである、**「Severlessを支える技術 第2版」**が控えめに言って神本でした。
そこで、本記事では同書の書評として、 全力で自分にとっての学びを残したいと思います。

※**「Severlessを支える技術 第2版」**のリンク先は2020/05/12現在、第3版となっています。

1. 目次

• 2.どんな方におすすめ？
• 3.「Severlessを支える技術 第2版」のおすすめポイント
• 4.雑感

2.どんな方におすすめ？

• AWS lambdaやGoogle Cloud FunctionsはじめとするFaaSや、Serverless Frameworkなど管理ツールを使っている方
• Severlessという技術分野が注目される背景に関心がある方
• マイクロサービスについて、Severlessという文脈から考えてみたい方

※サーバーレス v.s. サーバレス？

同書では、「Severless」(サーバーレスサーバレス)を「サーバーレス」と記述していることから、本記事でもそれに倣い、「サーバーレス」と記述していきます。

3.「Severlessを支える技術 第2版」のおすすめポイント

ポイント１：取り扱う守備範囲がとにかく広い

目次からも本書の守備範囲の広さをうかがい知ることができます。
「サーバーレス」とは、サーバーの抽象化という、よく言われる定義に始まり、「サーバーレス」が注目される背景や設計するうえでの要所の解説、そして各クラウドベンダーのサービスの紹介と矢継ぎ早に続きます。

目次

1. サーバーレスについて 
2. 技術分野としての整理 
3. サーバーレス時代の設計ポイント 
4. 各社「サーバーレス」の概要 
5. 各社サーバーレスの比較 
6. サーバーレスの運用 
7. AWS Lambda 
8. Azure Functions 
9. Google Cloud Functions 
10. IBM Cloud Functions 
11. 未来に向けて

ポイント２：痒いところに手が届く「サーバーレス」に対する解説

上述したとおり、筆者は「サーバーレス」をサーバーの抽象化と定義しているのですが、それにとどまらず、私たち読者が抱く疑問にもまるで横で話を聞いてくれているかのように、ひとつひとつ答えてくれます。

• 「サーバーレス」のどこがウケたのか？
  • サービス同士を結合させるというコンセプト。
  • それを裏付けるエピソードとして、「サーバーレス」なサービスの代名詞としてAWS Lambdaが名乗りを挙げたことを紹介。
  • Lambdaより6年前の2008年に夜にプレビューリリースされたGoogle App Engineはブレイクしなかった。
  • GAEがブレイクしなかった理由は、フルスタックなフレームワークという主流とはかけ離れた、「限定的なライブラリの利用」を求めたから。
• 「サーバーレス」なシステムアーキテクチャを構成するうえで取り入れていくサービスは、クラウドベンダーごとにどんなものがあるのか？
• キューの待ち行列の長さに応じて、ワーカーを増減させることはできるか？
  -「サーバーレス」なシステムアーキテクチャを採用している場合、何を監視したらよいのか？
• デプロイはどうやっておこなえば？

4.雑感

続いて、本書を読んで、私個人が考えを巡らせたことを書いていきます。

その１：「サーバーレス」は分散コンピューティングとしての役割を求められたのではないか

• 「サーバーレス」が注目されるに至った背景は、システムアーキテクチャの思想が集中から分散に回帰していたからという点も考えられるのではないか。

• これは、「技術は螺旋的に進歩する」という@t_wadaさんの講演から着想を得たものなので、お時間がある方はぜひ、のぞいてみてください。

  • [技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（前編）。デブサミ2018]
    (https://www.publickey1.jp/blog/18/2018.html)
  • 技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（後編）。デブサミ2018

その２：マイクロサービスとサーバレスアーキテクチャの違い

私の考えをお伝えする前に、筆者の意見を本書から抜粋させていただきます。

ミドルウェアやライブラリ・フレームワークに相当するクラウドサービスを活用していく流れは、一見マイクロサービス化のようにも見えます。「組織が作るシステムは、その組織のコミュニケーション構造を反映した設計になってしまう」というコンウェイの法則の反省から、システムをその中のチーム毎に分割して統治することで組織構造の制約をなんとかしようというのがマイクロサービスの大きな目的の一つです。サーバーレスという文脈で見てみると、FaaSの関数を分離したりFunctional SaaSを利用したりすることは、責務の分割のためというよりは、第三者が開発したライブラリを取り込んで使うことのように近いように思います。マイクロサービスというよりは**「ナノサービス？」**とでも呼ぶべきものかも知れません。

参考：「Severlessを支える技術 第2版」, p11

私なりのマイクロサービスとサーバーレスコンピューティングの理解

(本記事で最もお伝えしたかったことなので太字にした笑。)

* マイクロサービスとサーバーレスアーキテクチャは対立軸にあるものではない。

* マイクロサービスとサーバーレスアーキテクチャは、どちらもモノシリックな、中央集権的なアーキテクチャからの反動として、分散へ回帰する動きの結果、提示されたアーキテクチャ。

* サーバーレスアーキテクチャは、マイクロサービスが目指していたコンウェイの法則を克服すると期待され、注目を浴びているのではないか。

モノシリックなアーキテクチャとマイクロサービス、そしてサーバーレスアーキテクチャについてそれぞれ図示された資料を見つけたので引用させていただきます。

参考：「Serverless Functions vs Microservices」

その３：サーバレスアーキテクチャの次に来るもの

• サーバーレスアーキテクチャでは、ビジネスロジックの構築に専念することが目指され、開発者はサーバー構成管理から解放された。
• 「サーバーレス」が目指していたビジネスロジックの構築に専念するという本質的な課題を解決するべく、ノーコード/ローコードというソースコードの管理からの解放の動きが出てきている。
  • 参考：Google、コーディング不要でアプリケーション開発ができる「AppSheet」買収。クラウドをベースにした業務アプリケーションのノーコード開発を強化
• たしかにソースコードが技術的負債となることは避けられないので、ソースコードのボリュームを縮小させたいというニーズが出てくることは妥当？
• 気になるのはノーコードサービスで設定した値はどのように管理するのかという点。
  • これはインフラエンジニアがyamlにパラメータを入力しているように、ノーコードサービスの利用者もまたパラメータファイルだけ、用意するという話になるのかどうか。

p.s. みなさんも春の読書感想文、始めてみませんか？

#春の読書感想文

Serverlessを支える技術 第2版(2020/05/09現在は第3版が公開されている)https://t.co/KRisK8i6CH

・FaaSを利用することは「責務の分割」というより、第三者のライブラリを取り込むこと。
・コンウェイの法則に従って設計される「マイクロサービス」より細かく設計できる？

— gakuji tamaki (@gkzvoice) May 9, 2020

P.P.S. Twitterもやってるのでフォローしていただけると泣いて喜びます:)

@gkzvoice