概要:
プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化
- 作者: Susan J. Fowler,佐藤直生,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/09/13
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
当選した方は、11月末までに、書籍の感想をブログ、Qiitaなどで公開してくださいね。
とのことで、当選した方なのでブログを書いている。 なおなぜ11月末までかかったのかというと書籍が実際に届いたのが11月24日だったからだ。
ようやくｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!今月中に読了してブログ書くぞい！！！
結論:
まず最初に結論から。 タイトルにWIPがあることからわかるようにまだ最後まで読了出来ていない。 付録を除けば残り6章と7章で34ページなのだが読んでから書いた場合間違いなく日付を交信してしまうため慌ててこのエントリを書いている。 なお本書はやる気さえあれば1日で読了できる程よいボリュームであることをここにお伝えする。
そのうえでこの本を読んだ感想は「モノリシックなサービスで心を痛めている」「マイクロサービスという名前は知っているがどういうものかきちんと理解していない」そういう人に手にとって欲しいと思わせる書籍である。
冒頭にも記載されているが本書はステップバイステップなチュートリアル的教本ではない。 マイクロサービスエコシステムをUberの事例を元に8つの原則に分解してなにか特定の言語やフレームワーク、実装に依存しないように汎用的に書かれている。 この書籍から学び取れることは本書の各章で書かれた標準をきちんと理解したうえで「さあ自分たちのサービスに当てはめるためには何が必要だ？」というマイクロサービス化する際に基準となる部分を担ってくれる実用書であるとぼくは紹介する。
なおこの内容は冒頭に書かれているが実際に読んでいるとそのことが非常に体感的にわかるようになると思う。
感想:
ぼく個人の本書を読んだ感想としては「マイクロサービスを構築するのは非常に難しく、繊細で、パワーがいる」ということが学べたと感じている。 というのもぼくは今までのプロダクトでさまざまなモノリシックなサービスに触れてきた。 そうしたときに「ここの部分だけ切り出せればいいのに…」「この部分とこの部分が疎結合にして1つの群体としてのサービスが構築できればスケールしやすく現在抱える問題も全て解決するのに…」というようなことを考えてきたし、感じてきた。
それそのものは確かに正しいのだけど「じゃあ実際にマイクロサービス化すればどうなるのか？」というところまでは考えが及ばなかった。 これは当たり前でモノリシックなサービスをマイクロサービスへ移行したことがないからだ。 (疎結合にしたことはあるがそれはマイクロサービスとは程遠いものだったので含めていない)
ともあれ、本書ではマイクロサービス化することで顕在する諸般の普遍的な問題について書かれている。 「マイクロサービス化するとここが問題になるぞ、さあどうする？」というわけだ。
そして本書はアドバイスはしているが明確な解答を避けている、何故ならマイクロサービスが同じ構成になることは極めて起こり得ないことだからだ。 Uberで解決した方法が自分たちにとっての最善でも解決にもなりえないことがわかっているからだ。
あくまでも汎用的な問題に対してどういう解決のアプローチを取るとよいか？というアドバイスレベルの内容に留めているように感じた。 そしてそれは正解だろうとぼくは感じている。
書籍プレゼントのためではないがぼくはこの書籍をあと2回、つまり都合3回は最低読み込もうと考えている。
1度目はマイクロサービスとはなんぞや？という問題を解決するために読む。 2度目はマイクロサービスエコシステムの8つの原則がどういうものか、それぞれの標準とはなにか？を理解するために読む。 3度目はマイクロサービスを自分たちのサービスに当てはめてどう調整するか？という実用としての補助のために読む。
と1度目に読んでいて「これは何度か読み直したり、理解しなくては本書の本当の価値が得られないな」と感じたためだ。
奇しくもいまぼくの職場では「障害対応」や「保守性を高める」ということで議論が起こりがちになっている。 これはここ最近問題が発生し、それが人為的なミスからシステム的な対応、根本的な解決が求められるという事態になっているためだ。 ところが「やりたい」という意思は各人持っているものの実際にどこまでやるのか、どれくらい大変なことなのか？があまり理解されていないように感じることがあった。
本書を読んでもらえればどういう方針を取るのが最適であるのか？を考える一石を投じることに繋がるのではないかなと感じ、そういう意味でも実用書としての価値が高いなと感じる事ができた。
偶然ではあるものの書籍プレゼントをされ、読む機会が得られたことを嬉しく思っている。 もし当選していなかったなら恐らく自分で購入していただろうことは間違いがない。 Kindle版がでたら是非とも購入させてもらいたいと考えているので何卒ご検討のほど……。
以上！ 実用書として素晴らしいバランスのよい良書でした。 とりあえず残りの6章7章&付録を読み切って週末に突入したいと思います。
追記:
なお、一応サボっていたわけではなくポートフォリオサイトをVueで書いたり、人と会う予定がありそちらに出向いていたりで中々まとまった時間が確保できなかっただけなのだ！と言い訳させてほしい。 恐らく本気で読めば8時間かからずに読了できるんじゃないかなと思ってるので読書が速いひとは買ったその日に読み切れる内容になっていると思います。
追記2:
読み終わったぞ！！！ 基本追記することはほぼないのだけど1箇所だけすごい刺さった部分があったのでなぜ刺さったのかだけ書いて終わりにしようと思う。
ドキュメントの更新が行われないのはサービスの技術的負債の1つ
というようなことが150ページに書かれている、原文ままではないが主旨は変わってない。
ドキュメント大事だけどどうしても実装優先だし、タスクから漏れやすいよねと常々思っていて、今の会社でレガシーなサイトを触ったときにドキュメントがオオカミ少年状態になっていて殺すぞ！！！みたいな気持ちになったので本当にドキュメントは大事だなって感じた。
だけどどうしてもドキュメントそのものはサービスの動き、そのものに影響しないので軽く見てしまいがちだったのだけど ドキュメントのメンテナンスを怠るのはそのまま技術的負債だと考えれば、定期的にドキュメントの見直しが必要だし メンテされていないならそれはしないといけないし…と考えるに至り、サービスの技術的負債という表現が非常に鋭いなと感じた。
いやいやなにいってんの、そんなの普通でしょ？と思うかもしれないがこういう現象はままあるので学びがあるなと思った。
