タイトルからもっと平易な内容かと思ってしまいましたが、思ったより詳しく記載があり濃い内容だと思いました。私は過去エンジニアで、今は違うのですが、自分にとっては良いレベルでした。

まぁ、範囲が広い技術なので、かいつまんでの説明になっているけど 目次としては良いと思う CNCFのリンクは初めて知ったし

・Saga：ローカルトランザクション、イベント、補償トランザクションといった技術や手法を駆使して、複数のリソース間で同期を取るためのデザインパターン。 　CQRS(Command Query Responsibility Segregation:コマンドクエリ責務分離)とは、データアクセス処理を、更新系処理(コマンド、すなわちデータの挿入/更新/削除)と参照系処理(クエリ、すなわちデータの検索/取得)に二分し、それぞれの実装にあたって、独立したサービスコンポーネントとデータストアを配すというデザインパターンです(図3.9の上)。その発想の背景には、コマンドとクエリはまったく異なるタイプの処理である、という一種の哲学があります。 ■Sagaを実装する2つの手法 ・コレオグラフィ：データベースにアクセスするサービスが、それぞれメッセージング製品を介してデータの同期を取り合う方法。 ・オーケストレーション：Sagaオーケストレーションと呼ばれる特別なサービスが、トランザクションコーディネーションという役割を受け持つことからアプリケーション層に配置されるアプリケーションサービスとして実装。 ■リファクタリングパターンの例 ・Anti-corruption layer 　Anti-corruption layer (腐敗防止層) は、サービスとモノリス連携において生じる通信プロトコルやアプリケーションプロトコルのギャップを解決するためのマイクロサービスパターンです(4.45)。Anti-corruption layerの仕組みは至ってシンプルで、サービスとモノリスの間に、プロトコルのギャップを解決するためのアダプターを設けるというものです。 　たとえば、モノリスがSOAPベースのRPCスタイルのWeb APIを提供していると仮定しましょう。サービスが他のサービス(やモノリス)を呼び出す際には、REST APIやメッセージング等を使うのが、マイクロサービスにおける理想形です。また、前項で説明したように、サービスがモノリスに依存することは避けたほうがよいでしょう。 　そこで、Anti corruption layerを活用することにします。「腐敗防止」のためにアダプターコンポーネントを開発して配置します。このアダプターには、サービスから呼び出されるインターフェースとしてREST API、そしてREST API呼び出しを受けてSOAPを介してモノリスのWeb APIを呼び出す機能を実装します。さらに、RESTとSOAPベースのRPCの間でアプリケーションプロトコルを変換するロジックも組み込んでおきます。このようなアダプターを設けることでサービスがモノリスに依存することなく、両者が連携できるようになります。 ・Strangler application 　次に、クラウドネイティブアプリケーションへの移行に役立つマイクロサービスパターンとして、Strangler applicationについて説明します。図4.46は、Strangler applicationパターンを模式化したものです。まずこの図の見方から解説しましょう。一番左側にPoC局面があり、左から右に時間が流れるのに従って、移行局面がリリース1.0、リリース2.0、リリース3.0と進展しています。各局面の中の上段にはSystems of Engagement(SoE)、すなわち顧客接点のWebアプリケーションのサプシステム群、下段にはSystems of Record(SoR)、すなわち基幹システムのサブシステム群が配置されています。バックグラウンドが白い長方形はモノリシックなサブシステム、バックグラウンドが黒い長方形はマイクロサービス化されたクラウドネイティブサブシステムを表現しています。 　移行作業はPoCから始まります。PoC局面ではSoEとSoRの一番右側のサブシステムの一部を、マイクロサービスを利用してクラウドネイティブ化します。それと同時に、SoEとクライアントの境界である図4.46の上段部分にStrangler Podを開発/配置します。Strangler Podとは、業務アプリケーションのメニュー画面をWebアプリケ ーションとして提供する、いわばポータルシステムです。 エンドユーザーは、Strangler Podの提供するメニュー画面で業務名をクリックすることで特定のアプ リケーションを利用するのです。 　そこで、Strangler applicationパターンでは、各局面の移行作業が終わったら、アプリケーションへのリクエストがマイクロサービス化されたサービスにルーティングされるように、Strangler Podのメニューアイテムが指し示すURIを書き換えます。このような仕組みを用意しておくことで、移行作業後すぐにサービスをリリースし、エンドユーザーに使ってもらうことが可能になりますし、プロジェクトのスポンサーである経営陣にも、具体的な成果を示すことができます。 　また、新規リリースされたクラウドネイティブアプリケーションに障害があった場合には、Strangler Pod上のメニューアイテムが指し示すURIを既存の現行アプリケー ション向けのものに書き換えることで、簡単に実績あるモノリシックアプリケーショ ンに切り戻すことが可能です。 　以上のプロセスを、リリース1.0、リリース2.0、リリース 3.0と横展開することで、段階的にアプリケーションのモダン化を進めるのがStrangler applicationバターンです。 　ちなみに、いささか物騒ですが、Strangleとは「絞め殺す」という意味です。これは他の植物に絡みつき成長するつたやつるなどの植物が、最終的には宿主となっている植物を覆いつくす様を比喩しています。Strangle applicationとは、マイクロサービスがモノリスを置き換えていく様をイメージしたネーミングなのです。 ■サーバーレスとは 　サーバーレス(もしくはサーバーレスコンピューティング)とは何でしょうか?サーバーレスとは、一言でいうと「サーバー管理を必要としないアプリケーションを構築して実行する」という概念を表したものです。 　また、その名前からよく勘違いされますが、コードをホストして実行するために「サーバーが不要になった」わけではありません。サーバーレスとは、サーバーのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティ/プランニングに時間とリソースを費やす必要がないという考え方を指しています。そして、これらのタスクや機能は、すべてサーバーレスプラットフォームによって処理され、開発者や運用チームから完全に抽象化されます。 　その結果として、開発者はアプリケーションのビジネスロジックを書くことに集中することができます。運用エンジニアは、よりビジネス上で重要なタスクに集中することができます。 ■サーバーレスのユースケース 　ここまで、サーバーレスの概要やアーキテクチャを中心に見てきました。ここでは、それらサーバーレスの特長を活かしたユースケースをいくつか見ていきましょう。特にサーバーレスが有効なのは、以下のようなワークロードです。 　○非同期/コンカレント/独立した作業単位へと並列化しやすいワークロード 　○要求の頻度が低い、散発的なワークロード 　○スケーリング要件のばらつきが多く、予測不可能なワークロード 　○ステートレスで短命なワークロード 　○ビジネス要件が頻繁に変化し、開発もそれにあわせた迅速さが求められるワークロード ■サーバレスの制約 ・サーバレス固有の制約 　ステート管理の煩雑さ 　レイテンシの大きさ 　ローカルテストの難しさ ・現在の実装による制約 　コールドスタート 　ツールや実行環境の制約 　ベンダーロックイン

今の開発でもマイクロサービス化の検討をしようとしているが、なるほどと思う部分があった。が、他はまだまだ理解が追いついておらず。また必要になったら（行き詰まったら）読んでみよう。 140冊目読了。

やや自分には内容が高度であり、中身は理解が十分にできていない。 但し、マイクロサービスやコンテナを語る上で、何を知るべきかについて一定程度イメージができたことは収穫。 自らの設計力を実践にて高めた上で、マイクロサービスアーキテクチャーを本書等を再読しつつ構想していきたい。

マイクロサービスとはなんぞや本。 概念を知りたい人向けの一冊。 実際自分の担当するシステムに、適用すべきかどうか？といったジャッジには直接的に役立つものではない。 おおよそのシステムがマイクロサービス不向きなような。

マイクロサービスについてどういうものかをさっと知るだけなら2章だけで充分だと思う。マイクロサービスに付随する理解をさらに深めるなら、この書籍から得られる情報量は多く、具体例や理解が不十分な用語の理解も、しっかり読み込むことで非常に勉強になると思う。 ■クラウドネイティブコンピューティングとマイクロサービス ↓これがわかりやすい マイクロサービスとは、基盤構築のスピード感にあわせて、アプリケーション開発とメンテナンス（変更）を、タイムリーに素早く行うための設計／開発／運用手法をまとめたものです。その中心となるのは、サービスと呼ばれる独立して開発／稼働されるソフトウェアコンポーネントを複数組み合わせることで1つのアプリケーションを開発するというソフトウェア構造にあります。 各サービスは個別に開発され、それぞれ独立して各稼働環境にデプロイできる構造を有しています。各サービスを置き換えることによって、容易にアプリケーションの変更が可能となるのです。 ↓少し書籍の説明がわかりづらかったので整理 クラウドネイティブ：「クラウドの長所を徹底的に活用する」という意味を持つ言葉です。システム構築にクラウドを用いることを前提に、その特性を活かし、最適化するような設計を行うことを指します。 クラウドネイティブのランドスケープ https://landscape.cncf.io/ Cloud Native Trail Mapは、CNCFがGitHub上で公開しているチャートで、ITシステムをクラウドネイティブ化するためのロードマップを示しています。クラウドネイティブコンピューティングに取り組む際、技術適用の順番を判断するための1つの目安になるでしょう。 https://github.com/cncf/trailmap オーケストレーション：ソフトウェアやシステム、サービスなどの配備や展開、構築、導入、設定、管理、運用などに関わる作業や処理を専門的なソフトウェアを用いて自動化すること ↓マイクロサービスの向き不向き 大規模／複雑なシステム開発を、ガバナンスを利かせながら整合性をもって運営するのはなかなか大変です。このようなケースであればこそ、対象領域（ドメイン）を分割し、それぞれを独自に開発／運用するマイクロサービスが向いているのです。 ■用語 SOA：サービス指向アーキテクチャの意。企業に導入されている様々なアプリケーションまたその機能の一部を一つのサービスとしてコンポーネント化し、そういった部分部分を必要に応じて一つのサービスとして組み合わせることで新たなシステムとして使う、といった設計の手法である。 DDD：システムを作る際も業務と切り離さず、密接に設計・実装しようというものです。ビジネスの境界によって分けられたシステムというのは高凝集・疎結合に分けられるという利点があり、まさしくマイクロサービスとの親和性がすごく高いと言えます。

色々とインプットしているマイクロサービス系の知識を改めて体系的に眺めることができて良かった本です。 体系的に学べるので初学者にもオススメできるかとは思いますが、実装サンプルが皆無なので、IT技術系の事前知識がない人には少し辛いかも？とは思いました。

マイクロサービス、概念的には理解していたものの、 実際にサービス構成図を作成するとなった際に、 どう描けば良いのか？分かってなかったところもあり、 勉強のため手に取った本。 図解を多く活用してくれていて、 非常に分かりやすくなっていたと感じた。 早速学んだことをプロジェクトで活用出来たのも、 個人的には高評価です。 【勉強になったこと】 ・クラウドネイティブコンピューティングの基本形 　マイクロサービススタイルでアプリケーションを 　開発し、アプリケーションはコンテナにデプロイ 　して稼働させること。 　また、オーケストレーション機能でコンテナ化 　されたアプリケーションを運用すること。 ・REST 　HTTPプロトコル規格提唱者の1人である 　Roy Fielding氏が提唱したアーキテクチャスタイル。 　クライアントがリクエストを送信し、その後 　レスポンスを待つ同期型のプロトコル。 ・マイクロサービスを適用する理由 　アプリケーション個別の保守を可能にする 　柔軟なモジュラー構造（サービス）の実現。 ・ある特定のデータベースにはある特定のサービスを 　介してアクセスすること、これがマイクロサービス 　化で大切な概念。 ・マイクロサービスでよく利用されるサービス間連携 　REST、メッセージング ・Idempotent Consumer 　注文IDのように、オペレーションごとにユニークな 　IDを割り当てて、そのIDにひもづくオペレーション 　が実行されたか、まだ実行されていないのかを確認 　することで、同一オペレーションの重複実行を防ぐ。 ・コンテナのメリット 　環境に依存しない 　1つのサーバのリソースを効率よく利用出来る 　コンテナの構成ファイルをデプロイ作業に出来る ・サーバーレス 　サーバーのプロビジョニング、メンテナンス、 　アップデート、スケーリング、キャパプラに 　時間とリソースを費やす必要が無いという概念。 ・可観測性 　サービスの出力から内部の状態を把握できること ・サイトリライアビリティエンジニアリング(SRE) 　Google社内のエンジニアが経験した、 　大規模システムにおける成功プラクティスを 　まとめたもの 　　①組織のサイロを減らす 　　②失敗を許容する 　　③段階的な変更を実装する 　　④ツールと自動化を活用する 　　⑤すべてを計測可能、観測可能な状態にする ・ゴールデンシグナル 　分散システムにおけるモニタリングで重要な 　4つのシグナル（システムアラート） 　　①レイテンシ 　　②トラフィック 　　③エラー 　　④サチュレーション