感想文：絵で見てわかるマイクロサービスの仕組み
レガシーおっさんなので、最近の開発におけるアーキテクチャ的なものを知りたくて、本を買ってみました。
一通り読むのに6時間くらいかかりました（理解したとは言ってない）
マイクロサービスとは「細かく作れ」ではなくて「独立して作れ」だと解釈しました。
概要
アプリやシステムをマイクロサービスとして構成しようとしたときのアーキテクチャのパターン例と用いられる技術、および運用方法の解説です。
あと、dockerとkubernetesの説明がすごく丁寧で助かりました。こいつらの役割や利点がどの解説よりもわかりやすかったです。
感想
レガシーおっさんとしては、最近の人はこんなこと考えてアーキテクチャ考えているのかと、とてもためになりました。
マイクロサービスについての感想
ここで紹介されているアーキテクチャを採用するにはどういった判断材料が必要でしょうかね。 損益分岐点と言うか。
適用するなら、今後の拡張が決まっている大規模なアプリで、予算が潤沢にあって、専任アーキテクト抱えられるくらいな感じじゃないといけないような気がしないでもないです。
特に、最近流行りの「いかに早く価値を届けるか」を優先するリリースサイクルだと、環境作るのがボトルネックになるかもしれないくらいにマイクロサービスは扱いが難しいと思います。
リリースするサービスが需要を探るような最初期の段階だと、中の仕組みを頑張るより表の動く物が優先でしょうし。
（本書でも安易に適用するなとは言っている（はず））
なんかマイクロサービスに対して否定的な意見っぽくなってしまいましたが、マイクロサービスのコンセプトの一つである、サービス同士が開発のボトルネックにならないようにしようというのには賛成です。
クラウドサービスについての感想
あと、クラウドサービスについての説明もありまして。 それに対して感じたのが、クラウドサービスって、サービスを抽象的に使いたいもののはずなのに、クラウドだからこそのサービスやツールが必要になるって、なんか面倒くさいことになってないですか？
複数のサービスを保守や稼働率のために細かくコントロールする必要があるが、それぞれのサービスは独立しているのでいっぺんにコントロールできるわけでもないく、うまいこと外側からいっぺんにコントロールするためにあらたなツールを使う、みたいな印象を受けています。
とは言いつつ、よく考えたら物理サーバでもクラウドサービスに匹敵するくらいの仕掛けを実現しようとしたら同じかそれ以上に面倒なことになる気がしないでもないです。
物理サーバよりマシというというくらいの認識です。
作ろうとしているシステムの規模にもよるかもですが、私のレベルではクラウドにすると圧倒的に安く楽になります（構築・運用に工数かかりません）とはなかなか言えない難易度であります。
運用についての感想
DevOpsはマイクロサービス関係なく頑張ったほうが良いと思います。 自分たちの開発業務のシステム化なので。
以上
