読書メモ：クラウドネイティブで実現する マイクロサービス開発・運用 実践ガイド
Junji Watanabe正野 勇嗣; 山田 真也; 宇都宮 雅彦; 横井 一輝; 岡本 隆史. クラウドネイティブで実現する マイクロサービス開発・運用 実践ガイド エンジニア選書 株式会社技術評論社. Kindle 版.
第1章 マイクロサービス概論
1. 1. 2. 3 マイクロ サービス の 難し さ
マイクロ サービス 化 を 成功 さ せる には、 これら を 総合的 に 判断 する「 ビジネス センス ＋ フルスタックエンジニア」、 いわば スーパーマン の よう な 人 が 求め られ ます。
「スーパーマン」が必要なシステムって、維持できるんだろうか
……という疑問に答えるのがこの本という展開だった。
システムのモダナイズでマイクロサービスでやる、と決まっているなら、ODC利用すると割と簡単に実現できる気はする。ただし、マイクロサービス化する、という前提で挑むと色々面倒なことになる、というのはあちこちで語られている。
1. 2. 2. 2 過熱 する マイクロ サービス 化 の トレンド と 警鐘
Martin Fowlernの記事にあった図を和訳したものが載っている。
複雑さが低いシステムではモノリスの方がマイクロサービスより生産性が高いというもの。
ここが、ODCでも気になっているところ。小規模なアプリケーションをOutSystemsで作ることはたくさんあるので、そういうケースの対応を検討してうまく開発標準や部品として整備しないといけない。
ちなみに、非常に規模が低い場合は、全てを1Appに収めてしまうことでこの問題は起こらない（はず）。
1. 2. 4. 1 マイクロ サービス 化 の トレードオフ： モジュラーモノリス との 比較
モジュラーモノリスの説明として、「適切にモジュール化が推し進められたモノリス」というのはわかりやすくてしっくりする。この定義に従うと、Architecture Canvasに従って適切に設計したOutSystem 11アプリケーションは、モジュラーモノリスということになる。
また、この後の、「マイクロサービス化は上流の段階において、トップダウンでサービス間の依存性を強制的に排除する手段となりえます」というのはODC導入のメリットとしても言えそうなので覚えておこう。
Junji Watanabe1. 2. 4. 2 広義 の マイクロ サービス と 狭義 の マイクロ サービス
広義のマイクロサービスとして、マイクロサービス化に必要な様々なもの（アジャイル、クラウドネイティブ、DevOps）が組織に浸透していることが必要、としている。「そうしたものを通してビジネスの俊敏性が高まった状態」を広義のマイクロサービスとみるべき、と。
ODCの場合モジュラーモノリスにする選択肢が無く、強制的にマイクロサービス化させられる。
上記のようなプラクティスの導入は、いよいよOutSystemsにとって必須のものとなってしまうのだろうか？
ところで、「クラウドネイティブアプリケーション開発が浸透している」とはどのような状態を表すのか？
1. 3. 3. 2 安易 な 分割 による 落とし穴
データ依存性があるマイクロサービスを作ると、複数のマイクロサービス間で整合性を取る必要が出てきて、難易度が高まる
⇒ODCでも困る点。サービス（ODCの場合はApp）でデータ依存が無いサービスを作れればよいのだが、現実的にはそれは難しいのではないか？ その場合、↑で懸念されるようにSaga等実装の複雑さと難易度が上がってしまうのではないか。
Column 多様 な トランザクション モデル を 活用 し た さらなる マイクロ サービス 化
マイクロサービスにおいて、トランザクションの整合性を保つデザインパターンを整理した表がある（表1.3.3）。
Junji Watanabe第2章 マイクロサービスの実装
サンプルコードがついているが、想定開発環境はmacOS
マイクロ サービス 間 通信 を 実現 する gRPC
gRPCは構造化データをバイナリ化できる。そこがJSONに頼るOutSystemsのマイクロサービス間通信とは違うところ。
後の方でgrpcurlというgRPC用のクライアントツールが出てくる
2. 2. 2. 1 BFF とは
複数のマイクロサービスへの通信を集約し、フロントエンドに向けてAPIを公開するのがBFF（Backend For Frontend）。ODCでいうなら、画面上のClient Actionから直接呼ばれるServer Actionの位置になる。
BFFが必要となった背景として、クライアントの種類に応じてユーザーインターフェースとのつなぎをする部分を切り出すことが必要になった、ということなので、やはりUIを含むApp内のServer Actionの位置付け。
この後で、BFFの実現方法の例としてGraphQLが出てくる。ODCではBFFの実現方法については特に意識しなくてよいのでは。UIが入っているAppのServer Actionが自然とその役割を果たす。後は開発標準として、明示的にBFFの作成に言及するか（例えば命名規則にBFFを入れる、あるいはフォルダ名をBFFにする、特定のScreenの操作に対してBFFを作成するルールにする、などが考えられる）。
Junji Watanabe2. 2. 5. 1 イベント 駆動 型 通信 における メッセージ ブローカー
メッセージを保管でき、呼び出し側とは非同期になるメッセージブローカーを使うことで、メッセージを待つ側で何らかの障害が起きても、次回立ち上がった時にメッセージブローカーからメッセージを受け取って処理できる。Sagaで補償トランザクションを発行しようとしたときに利用できないサービス上った場合でも、この仕組みを取っていれば救うことができるはず。
「受信側のサービスの状態にかかわらずメッセージを送信・キューイングでき、受信側のサービスが起動した時にキューに格納されたメッセージを受信する、というイベント駆動型通信のメリット」メリットはこれでいいとして、実際にプロジェクトに適用する前には、設計パターン・よくある落とし穴と対策・実際に適用してみての経験談あたりは押さえておきたい。
Junji Watanabe第3章 サンプルアプリケーションへの非機能の実装
3. 3. 1. 1 サービス メッシュ とは
サービスメッシュ：マイクロサービス間の通信を管理する仕組み
サービスメッシュをはじめとする横断的関心事 (英語だと多分Cross-Cutting Concerns?) はODCだと、基本的にはODC自体が面倒見てくれるはず。そう考えると、外部のAPI GatewayやService Meshの製品をいれると、逆にOutSystemsで想定している通信方式（Service ActionやAggregateを介してマイクロサービス間でやり取りする）からそれてしまっうことになりそう。