読書メモ：Bulding Microservices Second Edition

2023/6/23 書籍

邦題『マイクロサービスアーキテクチャ』として訳されている本の第2版。

OutSystemsは、バージョン11でService Actionが導入され、今度は、全てのアプリケーションがマイクロサービスとして構成されるProject Neoのリリースを控えている。そこで、マイクロサービス開発に関する全般的知識を得たいと思ってこの本を選んだ。

原著英語版が2014年執筆開始（出版は2015年）。

この第2版は、2021-07-23: First ReleaseとPrefaceに記載がある。

目次

  1. What Are Microservices?
  2. How to Model Microservices
  3. Splitting the Monolith
  4. Microservice Communication Styles
  5. Implementing Microservice Communication
  6. Workflow
  7. Build
  8. Deployment
  9. Testing
  10. From Monitoring to Observability
  11. Security
  12. Resiliency
  13. Scaling
  14. User Interfaces
  15. Organizational Structures
  16. The Evolutionary Architect

3つのパートから構成されていて、1-4がPartⅠ Foundation、5-13がPartⅡ Implementation、14-16がPartⅢ Peopleに該当する。

特徴

マイクロサービスの検討ポイントのカタログ

目次にある通り、マイクロサービスについての広範な話題をカバーしている。

また、各話題について複数のオプションを示し、さらに各オプションの実装に使える製品も複数紹介している。よくこんなに色々知っていると驚くくらい。

例：マイクロサービス間の通信の実現方法として、Request-response・Event-driven・Common Data（データを共有するということ）のタイプを示し、更に各タイプごと複数の方法（Request-responseなら、REST・RPC・Queue-based brokersなど）がある。また、方法ごとに製品をいくつか紹介している（Message BrokerならRabbitMQ・ActiveMQ・Kafka。それからクラウドサービスベンダーのものなど）。

製品については、時間が立ってから読むと選択肢が変わってしまっているかもしれない。

概要だけ把握しておいて、必要になったときに詳しく読み込むような使い方をすることになると思う。

マイクロサービスのマイナス面、合わない場合にも言及

著者は、マイクロサービスがデフォルトのアーキテクチャとして選択されるような状況（日本では多分まだそうなっていないと思うが）にも懸念を抱いている。

 

In my experience, microservices are a poor choice for an organization primarily concerned with reducing costs, as a cost-cutting mentality—where IT is seen as a cost center rather than a profit center—will constantly be a drag on getting the most out of this architecture.（ページ: 28）

マイクロサービスを始めるときには新しい概念の学習が必要になる、レポートが難しい（マイクロサービスではデータベースをマイクロサービスごとに持ち、共有しないため）、サービス間が通信ベースなのでセキュリティ上注意が必要、機能感の連携が通信ベースになることによる遅延、データを分割することによる一貫性維持の問題等が挙げられている（他にもいくつかある。そのうちのいくつかはOutSystemsでやると決めたときには関係ないが……）。

もっと直接的に

Microservices aren’t easy. Try the simple stuff first.（ページ: 72）

という記述もあり、やはり開発者の習熟コストは問題になりそうな気がする。

気になったところ

DDD

本の最初のあたりで、マイクロサービスの定義として

Microservices are independently releasable services that are modeled around a business domain.（ページ: 3）

とあり、ビジネスドメイン単位で独立してリリース可能なサービスとある。

いかにもDDDと親和性の高そうな表現だが、予想通り、マイクロサービスにとってのDDDの重要性が強調される。

Chapter2 “How to Model Microservices”のJust Enough Domain-Driven Design以降の節で、DDDのマイクロサービス境界設計への適用が検討される（Bounded Contextがマイクロサービスの境界として適切ではないか？）。

DDDがマイクロサービス分割の手法として絶対的なものではないというのは、本の中でも記述されているが、基本として学習しておく必要はありそう。

マイクロサービスアーキテクチャに適応できない組織（ユーザー企業　または　開発チーム）はProject Neoに適応できるか？

この本の中ではマイクロサービスの難しさとそれを支える様々な要素（DDDや各種の技術要素）が紹介されている。

最近の潮流は、どうやらクラウドネイティブの方向によってきたとして、またOutSystemsがかなりの複雑さを製品内に隠蔽してくれるとして、それでもマイクロサービスへの適応に困難を感じる組織はどうすればよいのか？　と言うのは大きな懸念点。

Project Neoはアプリケーション単位で本当にマイクロサービスになってしまってアプリケーション間の通信もService Actionのはず。マイクロサービス的なことに注意を払わなくても開発できるようなCourseなどが提供されればよいのだが。