Amazonリンク https://www.amazon.co.jp/dp/4873119316/ 読んだ理由 モノリス、マイクロサービスの各アーキテクチャ特性の違いを知りたかったので積んでいた本。 ここ約3年、前職でRoRのモノリスのサービス開発をしていて、直近３ヶ月くらいはマイクロサービス的なサービスに携わり２人月程度のシステムを要件定義〜設計〜リリースまで主導した後、１日1章くらいのペースで読んでいった。きっと自分の設計思想が正しいものであったのか、もっとよい方法がないのか、ある種の答え合わせをしたかったのだろう。 読んだ感想 大変満足。設計の引き出しが増えた感と選定根拠を示す上での言語化する機会に役に立つ知識をインストールできた気がしている。 今までやってきたアーキテクトパターンや思考に名前が付いていたりと他の開発者とコミュニケーションをする上で共通認識の専門用語を使ってコミュニケーション/議論の効率化に繋がるイメージを持てた。 モノリスとマイクロサービスどちら側でもないフラットな視点で全体的に解説されていたが印象的。それぞれにメリット・デメリットがあるのでトレードオフを理解しバランスを取る必要があるとのこと。 サーガという分散トランザクションの紹介は、まさに最近の設計で少し悩ましかったところで、補償トランザクション (Compensating Transaction)っぽいことは考えていたので、思考方針としては正しかったことがわかって安心できた。 各章のメモ (一部) ### 5章 - 所有権のスコープ - 各マイクロサービスに対する所有権の扱い。組織が大所帯で自由に各マイクロサービス修正できてしまうとコードに統一感がなくなり質が悪くなりがちなので、チームで変更管理をして、他チームからはPullRequestで受ける形をとったりする - 破壊的変更 - マイクロサービス間のIFに変更があり、本番リリース後に影響が出る問題 - ロックステップリリース - 監視とトラブルシューティング - マイクロサービスの監視はモノリスと比べて複雑になりがち - まずやるべきはログ集約であり、ROIが高い。 - 本番環境でのテスト とても価値があるが、顧客に影響がないようにしよう - マイクロサービスはモノリスに加えてe2eテストを整えるのにコストがかかる自動テストは各マイクロサービスの役割に留めるのがベストプラクティス - 技術選定時の考え方 (5.9.3) - 可逆的な変更か不可逆的な変更か? - 横断チームに各チームの技術リーダーを入れて組織全体のアーキクチャを共有できるような仕組みがベストプラクティスとしてあるよ - 孤児サービス - サービス概要が時間経過に伴い不明になること。メタデータなどでサービス管理をすることで、サービスの役割、どのチームが作ったのか管理すべきか？などを管理しておくと、長期間運用しやすくなるだろう。そういった課題を解決するサービスも出てきている (biz ops ツール)

Amazonリンク https://www.amazon.co.jp/dp/4890855270/ 読んだ理由 英語公用語環境でソフトウェアエンジニアとして働きたいという理由に英語再学習することにしたが。 受験英語以降、体系的に勉強していなかったので、Atsueigoでお勧めされていたこの英文法書を購入した。 読んだ感想 700ページ弱のボリュームがあり、時間がかかったが、文法の抜け漏れや再確認ができた気がする満足。特に仮定法とか受験当時から無駄に苦手意識を持っていたが、ちゃんと理解する良い機会になった。普段から少しづつ使っていけたらと思う。 著者の大西先生の解説は気持ち・ニュアンスといった部分に寄り添う解説が丁寧。NHK放映中の「英会話 定番レシピ」でも大西先生出演されている。その番組も自分のレベルに丁度良くてよく見ている。番組内での教え方についてもよくニュアンスレベルの解説を丁寧にしてくれているのでそっちもお勧め。 1日10ページ以上進めるペースで2ヶ月くらいでゆっくり読了、無理のないノルマを設けるのは確実に進むので自分にあってた。 (読了後1ヶ月後) 読了後いつでも開けるように机の上に置いておいたが、１ヶ月経っても全く読み返さないということは、定着しているということなのか？