マイクロサービスアーキテクチャ読書メモ 2章進化的アーキテクト
黒字部分は本書の抜粋。赤字部分は私のコメントです。
不正確な比較
アーキテクトになるのは、建築士になるのに比べて必要とされる勉強量が少ない
イギリスでは建築士と呼ばれるまでに最低七年間の勉強が必要
アーキテクトと建築士の間の類似点は少ない
この話で思い出すのは耐震偽装で逮捕された姉歯建築士である。もう１０年以上前の話なので若い人は知らないかもしれないが。建築士は間違った設計をすると建築基準法で逮捕される。アーキテクトはシステムの設計をごまかしても逮捕されない。この差はデカイよ。。。
進化するアーキテクト像
ソフトウェア開発では、建物の設計や建設を行う場合よりも、急に要件が変更される
完璧な最終製品を作成するという考え方を変え、代わりに適切なシステムが得られるようなフレーウワークを作成することに重点を置く
アーキテクトは建築家というよりもむしろ都市計画家に近い
建物を建てるのではなく、都市を区画する
区画設定
区画（サービス）間の連携には注意が必要
あるサービスがRESTを使い、別のサービスがProtocol Buffers、また別のサービスがJava RMIという具合だと統合は悪夢となる
「ボックス間で起こることについて心配し、ボックス内で起こることには寛大になる」べき
原則に基づいたアプローチ
戦略的目標
戦略的目標は組織が目指す方向性なので、技術がその目標に一致するようにする必要がある
原則
原則は目標実現のための規則で、ときどき変更される
プラクティス
プラクティスは原則を実行する方法で、原則よりも頻繁に変更されることがある
コーディング指針
ログの保管
HTTP/REST
必要な標準
監視
サービスをまたがったわかりやすいシステム健全性のビューを作成できることが、不可欠
インターフェース
標準の数は１つが適切
技術やプロトコルの選択だけでなく、RESTのエンドポイント名に動詞と名詞のどちらを使うか、リソースの改ページの対処をどうするか、エンドポイントのバージョニング等も含まれる
アーキテクチャ上の安全性
不適切な下流呼び出しから適切に身を守るようにしなければならない
サーキットブレーカーの利用
コードを介したガバナンス
指針に従っているかを確認するのに時間を費やすのはあまり楽しくなく、各サービスが実行すべきすべての標準を実装するという負荷を開発者に負わせるのも楽しくない
手本
推奨したい一連の標準やベストプラクティスがある場合、開発者たちに示すことができる手本があると便利
カスタムのサービステンプレート
DropwizardやKaryon等のマイクロコンテナを使うと、適切な実装をすぐに実現できる
サービステンプレートが適用されない新技術スタックを導入すると、労力がかかるだけでなく間違いが起こりやすくなる
押し付けられた強制的なフレームワークでチームのやる気や生産性が損なわれる例が多い
共有コードのリスクを削減するために、サービステンプレートを手動でコピーする運用をとるケースもある
（サービステンプレートのアップグレード容易性vs結合のリスク）
現在はSpring BootのシェアがDrowizard, Karyonを圧倒している。
サービステンプレート戦略は、DRY原則を逸脱しているので、一見微妙に思えるが、実践的にはかなり有力なやり方だろう。最初はサービステンプレートで運用して、ある程度成熟したところで順次共有コードに切り替えていくのもありかも。
技術的負債
例外処理
十分な例外が見つかったら、いずれは原則やプラクティスを変更して世界の新しい認識を反映する
中央からのガバナンスと指導
ガバナンスは構築しているものがビジョンに一致していることを保証し、必要に応じてビジョンを進化させること
アーキテクトの仕事と責務は多岐に及ぶので、ガバナンスをアーキテクト一人で担当すべきではない
ガバナンスはグループ活動である。十分に小さなチームでの非公式な雑談の場合も、広範囲での公式なグループメンバーとの組織的な定期会議での場合もある。
